研究：LLM 用 1866 年電報體壓縮記錄可省近半 token
一份 50 篇材料、約 1300 題的新基準（Telegraph Test，程式碼與資料已開源）顯示，只需一句小寫指令讓模型用 1866 年跨大西洋電纜時代的電報體（cablese）撰寫壓縮記錄，輸出 token 可省 40%–49%，而下游模型讀取這些記錄的準確率不低於明文（恢復比 0.99–1.10）。GLM-5.3-Flash 自身省 48.4%，qwen3.8-27b 省 48.9%，gemma-4-31b 省 40.4%；
給出可復現的跨家族電報體壓縮基準：40%–49% 的 token 節省伴隨讀取準確率持平或更好，並指出壓縮時機與推理可否關閉決定成敗，對做 agent 記憶與上下文成本最佳化的人直接可用。
原標題：Write Like It's 1866: LLMs Relearn Telegraphese
閱讀原文
| 評分 | 72 / 78（平均 75，門檻 76） |
|---|---|
| 狀態 | 未入選 |
相關報導
AI 程式設計模型集體滿口黑話：思維鏈壓縮省 70% Token
量子位發文吐槽，Fable、Sol 等與 Coding 沾邊的模型普遍輸出「15/15 全綠」「單腿啞火」這類黑話。文中分析，除 Coding 過擬合外，更主要的原因是廠商為省 Token 把思維鏈壓縮成「穴居人語」，OpenAI 最早這麼做，同樣一句話的 Token 消耗比白話文少 70%；Claude 自 Opus 4.6 起也開始如此。作者稱最新 Opus 5.5 語言能力回升明顯，而 Gemini 因輸出風格正常、排版層級清晰，被社群視為少數還能正常溝通的 AI。
llama.cpp 合併 GLM5-Next MTP 支援，可作 draft 模型
llama.cpp 合併 PR #29928，為 GLM5-Next 加入多 token 預測（MTP）的 NextN 計算圖，使其能作為投機解碼的 draft 模型使用。改動包括支援只含 NextN 層或只含主幹張量的拆分 GGUF 檔案載入，並把 MTP 圖按輸出行裁剪，無輸出行的 4-token catch-up 核心耗時從 6.9 ms 降到 2.9 ms，貪心輸出雜湊與 draft 接受率不變。
llama.cpp 新 PR 將 Qwen4 索引器視訊記憶體減半
llama.cpp 的 PR #29825 通過最佳化索引器分數記憶體，把 Qwen Flash Next 等 Qwen4 模型的視訊記憶體佔用減半。實測在上下文 131072、ub 2048 時從 3.0 GiB 降至 1.5 GiB，262144、ub 4096 時從 11.7 GiB 降至 5.6 GiB。作者稱 logits 逐位一致、pp/tg 速度不變，僅分數因 fp32 舍入有差異；有使用者反饋解碼速度約降 10%。
llama.cpp v0.6.0 發布：新增擴充套件 batch API 與 GLM-5.3-Flash 支援
llama.cpp 發布 v0.6.0，新增 llama_batch_ext 擴充套件 batch API，支援混合 token/embedding 輸入與 MTP、deepstack 狀態嵌入。本次加入 320B 的 GLM-5.3-Flash（GLM5-Next）文字+視覺混合模型、Clef 決策模型，以及 Qwen4Exp 的 MTP 投機解碼，官方稱在 DGX Spark 上解碼約快 1.5 倍。
Qwen3.8-Flash-Next 177B 在單張 RTX 5070 上跑出 11-15 tok/s
有人在 Windows 上用 llama.cpp 的專家流式方案，在單張 RTX 5070 12GB 加 32GB DDR4-2400 記憶體上執行 Qwen3.8-Flash-Next 177B（UD-IQ3_XXS），基準約 11.5 tok/s，日常對話可達 14-15 tok/s。一次長程式設計提示以 10.15 tok/s 生成 4,892 個 token，產出一個可執行的單檔案貪吃蛇遊戲。