「省 token」的兩個真相：語言伺服器被高估，Agent 重試成本被低估
arXiv · 2026-08-17
背景：兩個關於 token 浪費的假設
2026 年 8 月 17 日,兩篇獨立的 arXiv 論文分別戳破了 coding agent 圈子裡的兩個常見假設。第一篇 arXiv:2608.13568《Does a Language Server Save Tokens for Coding Agents?》由 Pengcheng Xu 提出一套量測方法論,直接驗證「語言伺服器（LSP）語意檢索比 grep 詞彙檢索更省 token」這句流傳已久卻少被實測的說法。第二篇 arXiv:2608.13571《Not All Tokens Are Equal: Inflation-Aware Routing for Agentic LLM Systems》由 Heming Fu、Shan Lin、Qianqian Xie、Guojun Xiong 合著,聚焦另一個更隱蔽的成本黑洞——**失敗重試**如何讓實際花費遠高於模型的標價 token 數。兩篇論文合起來描繪出同一個結論：agent 系統裡「一個 token 值多少錢」遠比想像中複雜。
研究一：LSP 不是萬靈丹
Xu 的實驗在 Python 與 TypeScript repo 上,對 Claude Opus、Sonnet、Haiku 三個模型分別測試「符號定位」「引用完整性」「程式碼編輯」三類任務,比較模型可用 LSP 工具與只能用 grep 的表現差異。結果顛覆直覺：在符號定位任務上,LSP 反而讓 token 用量增加 6%–118%,模型也因此在有 LSP 可選時仍傾向自己不用,語意工具使用率只有 0%–6%。只有在「引用完整性」這類需要抓全部呼叫點的任務上,模型才有約一半機率主動選用 LSP。
更關鍵的落差出現在程式碼編輯任務。純用 grep 的模型能完美解決跨檔案的多處重新命名（multi-file rename）,但只依賴定位型 LSP 工具的模型有 75% 的案例會漏掉呼叫點,導致編輯失敗。換句話說,LSP 提供的「精確」定位資訊,反而可能讓模型誤以為看到了完整圖景,漏掉 grep 那種暴力但全面的覆蓋率。
| 任務類型 | LSP 對 token 用量影響 | 模型選用 LSP 的比例 |
|---|---|---|
| 符號定位 | 增加 6%–118% | 0%–6% |
| 引用完整性 | 優於 grep 但省 token 有限，弱模型例外 | 約 50% |
| 程式碼編輯（多檔重新命名） | grep 完美解決；純定位 LSP 有 75% 案例漏掉呼叫點 | 依任務退回 grep |
Xu 的結論不是「LSP 沒用」,而是工具選擇需要按任務類型與模型能力動態路由，而非預設語意檢索永遠優於詞彙檢索。論文建議建立一個以任務類別、模型能力與詞彙雜訊程度為輸入的 adaptive router，而不是把 LSP 當成 agent 工具箱裡的預設選項。
研究二：重試讓帳單膨脹 4.25 倍
Fu 等人提出「token inflation（代幣通膨）」概念，指模型標價的 per-token 成本與 agent 實際跑完一個任務（含重試、升級到更貴模型）所花費的真實成本之間的落差。論文指出既有的成本優化系統如 FrugalGPT，在困難任務上可能低估真實成本超過 2 倍；而在多跳問答（multi-hop QA）任務上，一個 7B 模型的 token 通膨率最高可達 4.25×。這代表單看模型的標價 token 成本，完全無法反映 agent 系統實際要付出的帳單。
為了在事前預測哪些請求會陷入高通膨，論文提出 CoT Branching Entropy（CBE）作為難度預測指標，在預測「這個請求會不會需要昂貴重試」的任務上達到 AUROC 0.887。系統稱為 InflationAgent，其中一個關鍵設計是 fresh-escalation——當低階模型失敗時，並不是把失敗的推理鏈直接轉發給更貴的模型（如 GPT-4o）續答，而是丟棄失敗鏈、讓升級後的模型從乾淨狀態重新推理。論文發現，若把失敗鏈原封轉發，會讓 GPT-4o 的準確率反而下降最多 34.8 個百分點。
| 指標（GSM8K） | FrugalGPT | InflationAgent |
|---|---|---|
| 準確率 | 91.0% | 94.7% |
| 固定預算下的 token 用量 | 基準 | 減少 31% |
在 GSM8K 基準測試上，InflationAgent 在固定 token 預算下達到 94.7% 準確率，優於 FrugalGPT 的 91.0%，同時整體省下 31% 的 token 用量。兩篇論文放在一起看，傳遞出同一種務實態度：省 token 不能只靠換工具或換模型，得先量測任務本身的行為模式，無論是該不該用 LSP，還是該不該把失敗上下文轉發給更貴的模型。
同一個叢集多出 33 個百分點利用率：Dharma-AI 換掉的只是排程順序
Hugging Face blog（Dharma-AI）· 2026-08-17
背景：FIFO 排程的隱形浪費
Dharma-AI 團隊（Gabriel Pimenta de Freitas Cardoso、Breno de Almeida Beleza、Francisco de Almeida Rocha Alves、Bruno Duarte 等人）在 部落格文章中描述了他們對 GPU 叢集排程器的一次重寫。舊系統的邏輯是先為即時推論的尖峰需求保留固定 GPU 配額，剩下的容量再依到達順序（FIFO）分給訓練與量化等批次任務。這篇文章是該系列的第二篇，前一篇談的是「閒置 GPU 就像停在停機坪的飛機」，這次談的是把靜態保留額度換成動態需求曲線後，同一批硬體能多榨出多少產能。
核心改動：把即時需求當成曲線而非常數
新排程器不再用固定配額保留尖峰容量，而是把即時推論需求視為隨時間變化的曲線，並依整個排程視野（scheduling horizon）內的價值高低，動態決定批次任務的優先權。系統遵守五個核心限制：每個 GPU 每個時間片只能執行一個任務；任務需落在各自的需求區間內；批次類任務需佔用連續且為 2 的冪次大小的 GPU 區塊；即時任務在相鄰時間片之間的 GPU 異動次數有硬性上限；已在執行中的任務不可被搶佔。
- 目標函式：以優先權與時間衰減加權的分配獎勵，扣除未滿足即時需求的懲罰（懲罰權重為獎勵的 5–10 倍）
- 架構：熱路徑上跑啟發式分配器（延遲 1–2ms），搭配週期性執行的正式最佳化模型
- 排程視野設定 24 小時，但只提交當前時間片的決策，每 30–60 分鐘重跑一次以吸收預測誤差
規格細節：按工作負載類型分開預測
與其用單一模型估算全部需求，Dharma-AI 為不同工作負載建立了專屬預測器。訓練任務的預測器會考慮 22 個特徵，涵蓋 SFT、DPO、RLHF、LoRA 與全參數微調等 10 種不同訓練變體；量化任務則依演算法與參數量分別預測；即時推論則用每週需求輪廓對應到所需 GPU 數，並把 GPU 異動成本與最佳化目標對齊。這種按類型拆分預測的做法，是排程器能準確判斷「這個任務值不值得優先」的前提。
| 情境 | 結果 |
|---|---|
| 訓練密集情境（8 GPU） | 利用率 53.6% → 87.0%（提升 33 個百分點）；優先權加權價值提升 105.1% |
| 跨情境平均 | 優先權加權價值提升 24.6%–105.1%，平均約 52% |
| 大規模驗證（64 GPU、30 個任務） | 價值提升 15.9%，求解時間 15 毫秒 |
最突出的結果來自訓練密集情境：在 8 張 GPU 的場景下，利用率從 53.6% 提升到 87.0%，等於多出 33 個百分點的利用率，優先權加權價值同時提升 105.1%。放大到 64 張 GPU、30 個任務的規模驗證中，系統仍能在 15 毫秒內完成求解，帶來 15.9% 的價值提升。文章沒有附上 GitHub 或論文連結，目前僅以部落格形式公開這套設計與數據，方法論細節需仰賴文中描述而非可重現的程式碼。