Headroom 式 LLM Token 優化：降低上下文成本但不犧牲答案品質

快速結論

LLM 成本優化不應該從盲目壓縮開始，而應該從上下文品質開始。Headroom 式優化器位於應用和模型之間，負責移除低價值上下文、壓縮嘈雜工具輸出、重用穩定 prompt 片段，並在品質允許時把簡單任務路由到更便宜的模型。

目標不是「不惜一切減少 token」，而是：

• 答案品質保持穩定。
• 安全和權限指令不被改寫。
• 減少重複、無關、機器產生的上下文。
• 用同一批測試集衡量節省和回歸。
• 漸進上線，並保留觀測和回滾。

---

Token 浪費通常來自哪裡？

浪費來源	例子	更好的做法
重複系統提示	每輪都發送同一段策略	快取或縮短穩定指令
嘈雜工具輸出	完整日誌、堆疊、HTML、JSON dump	只提取目前任務需要的欄位
過大的 RAG 片段	檢索 20 段，但真正有用 4 段	rerank 後積極裁剪
過長歷史對話	從第一輪開始全部發送	按時間和相關性視窗化或摘要
錯誤模型路由	簡單分類也發給大模型	簡單任務使用小模型
無邊界重試	失敗後反覆發送完整上下文	增加重試預算和中間結果快取

---

更安全的優化架構

使用者請求
  -> 輸入規範化
  -> 上下文選擇
  -> 工具/RAG 輸出清理
  -> prompt 組裝
  -> 快取查找
  -> 模型路由
  -> 模型呼叫
  -> 品質和成本日誌

每一層都應該可度量、可單獨關閉。

---

第一層：上下文選擇

適合移除：

• 重複指令。
• 已不相關的舊對話。
• 低相似度或低 rerank 分數的檢索文件。
• 目前任務用不到的工具輸出欄位。
• 重複堆疊和重複日誌行。

不要移除：

• 安全和權限指令。
• 使用者約束。
• API 契約。
• 業務規則。
• 稽核和引用需要的資料來源。

---

第二層：工具輸出壓縮

工具輸出往往是最容易浪費 token 的地方。日誌、JSON、HTML、資料庫列、CLI 輸出，都應該在進入模型前轉成任務相關摘要。

工具輸出	建議發送
重複 200 次的堆疊	唯一錯誤、關鍵堆疊、首次/末次出現
500 行資料庫結果	聚合、異常、樣本列
原始 HTML	文字、連結、標題、元資料
完整 API JSON	目前任務需要的欄位
測試日誌	失敗測試名、斷言、相關錯誤塊

---

第三層：Prompt 快取

很多 prompt 包含穩定部分：系統指令、產品規則、schema、風格指南、工具說明。把穩定塊和動態上下文分開，才能更好重用。

穩定部分：
  - system policy
  - output schema
  - product rules
  - tool descriptions

動態部分：
  - 目前使用者請求
  - 選中的歷史
  - 選中的檢索片段
  - 目前工具輸出

---

第四層：模型路由

請求類型	常見路由
分類、抽取、簡單改寫	小模型/快模型
短上下文檢索問答	中等模型
複雜推理、程式碼、法律審查	更強模型
安全或資金相關動作	強模型 + 人工審批

路由必須基於評測，而不是直覺。便宜模型不確定或校驗失敗時，應回退到更強模型。

---

先衡量品質，再談節省

指標	為什麼重要
輸入 token	直接成本來源
輸出 token	直接成本來源
任務成功率	最核心品質信號
人工修正率	揭示隱性品質下降
校驗失敗率	捕捉 schema 和事實回歸
升級率	判斷路由是否過激
延遲	壓縮本身可能增加耗時
每個成功任務成本	比單請求成本更有意義

---

上線計畫

1. 按功能、路由、工具記錄 token 使用。
2. 選擇一個高流量、低風險工作流。
3. 先加入上下文選擇。
4. 再加入工具輸出清理。
5. 快取穩定 prompt 組件。
6. 有校驗後再加入模型路由。
7. 按百分比灰度。
8. 為每個功能保留關閉開關。

---

總結

Headroom 式 token 優化本質上是上下文工程：選擇更好的上下文，清理嘈雜工具輸出，快取穩定 prompt，按任務風險路由模型，並在節省成本前先驗證品質。做得好可以降低成本和延遲；做得粗暴，則可能刪除模型真正需要的資訊。