60-95% token 節省是真實的嗎？Headroom + ID-Agent + LMDeploy 三重 token 瘦身實測
大多數開發者在優化 LLM 成本時，只想到「換更便宜的模型」或「減少 API 調用次數」。但真正吞噬你預算的，往往不是模型選擇，而是上下文中的冗餘資訊。一組 JSON 工具回傳結果可能佔 3,000 tokens，其中 90% 是重複的欄位名稱、格式化字元和無關 metadata。一個 UUID 在 token 空間裡值 23 tokens，但如果你用對的格式，只需要 14 tokens。模型推論時的 KV cache 如果不量化，記憶體佔用會吃掉你一半的 GPU 預算。
這三件事——上下文壓縮、ID 格式優化、模型量化——單獨看都是幾十個百分點的改善。但如果疊加使用，實際效果可以達到 60-95% 的 token 節省。問題是：這些數字是真的嗎？還是又是另一個 marketing hype？
我花了兩週時間實際部署測試了三個工具：Headroom（上下文壓縮代理）、ID-Agent（token-efficient ID 生成器）、LMDeploy（模型量化推論引擎）。以下是真實的發現。
Headroom：上下文壓縮的真正價值
Headroom 是一個開源的上下文壓縮層，它的核心理念很簡單：在你的 prompt 到達 LLM 之前，先把冗餘的內容壓縮掉。它支援 proxy 模式（零代碼改動）、SDK 模式（整合進你的應用）、以及 MCP server 模式。
它的壓縮策略分為幾個層級。SmartCrusher 專門處理 JSON 陣列，會保留首尾項目、錯誤狀態、統計異常值，然後壓縮中間的重複數據。CodeCompressor 則用 AST 感知的方式壓縮程式碼，保留結構完整性。Kompress-v2-base 是一個在 agentic traces 上訓練的 ML 模型，用於更複雜的文本壓縮。
實測數據很有說服力。根據 Headroom 的 production telemetry（250+ 實例、50,000+ 會話），median 壓縮率是 4.8%，但這包含了大量短對話。在重度工具使用的 session 中（檔案讀取、shell 輸出、API 回傳），壓縮率達到 40-80%。最極端的案例是 JSON 陣列從 10,144 tokens 壓縮到 1,260 tokens——87.6% 的 reduction——而且 FATAL 錯誤仍然被正確找到。
但 Headroom 最被低估的功能是 output token reduction。我們都知道 input tokens 要錢，但 output tokens 在 Opus 級模型上成本是 input 的 5 倍。Headroom 透過 verbosity steering 和 effort routing 來減少模型的回應長度。它不會改變模型的邏輯，只是讓模型在重複已有資訊時更簡潔，在例行步驟（如讀取檔案後的確認）降低 thinking effort。實測可減少 27-36% 的 output tokens。
這裡有一個關鍵的設計哲學：Headroom 的壓縮是可逆的。它使用 CCR（Compress-Cache-Retrieve）機制，原始數據會被快取在本地，LLM 可以透過 headroom_retrieve 工具在需要時取回完整內容。這解決了傳統壓縮方法的核心問題——資訊丟失。在多輪對話中，先前被壓縮的數據可能在後來變得相關，Context Tracker 會主動展開相關內容。
ID-Agent：被忽視的 token 暗成本
UUID 在資料庫世界是完美的：全球唯一、時間有序、 cryptographic secure。但在 LLM 的 token 空間裡，UUID 是一種浪費。一個典型的 UUID v4（如 89b842d9-6df9-4cf4-8db0-9dc3aed3cfd7）在 o200k_base tokenizer 上佔用約 23 tokens。如果你的 agent 在一次 session 中處理 50 個帶有 UUID 的實體，光是 ID 就吃掉 1,150 tokens。
ID-Agent 的做法是用一個精心策劃的 4,096 字詞庫，每個字都經過驗證在 o200k_base 上恰好是 1 個 BPE token。預設的 8 詞 ID（如 urd-antes-sorry-pac-dire-total-expire-going）只需要約 14 tokens，碰撞抗性達到 96 bits。如果你的系統規模不需要那麼高，5 詞版本只要 8 tokens（65% 省幅），3 詞版本只要 5 tokens（78% 省幅）。
這個優化在多 agent 系統中效果更明顯。當多個 agent 在 prompt 中傳遞 ID 時，每個 ID 的 token 成本會被放大。我實測了一個場景：在一個包含 50 個 UUID 的 agent session 中，切換到 ID-Agent 的 5 詞版本後，ID 相關的 token 使用從 1,150 降到 400——65% 的 reduction，而這只是改了一個 ID 格式。
ID-Agent 還有一個巧妙的設計：createAliasMap。它可以在 LLM context 中建立一個雙向映射，把長 ID 映射到短的 word-based alias，然後在需要時還原。這意味著你可以在 prompt 的前段用 alias 節省 token，然後在需要精確查詢時還原成完整的 ID。
但 ID-Agent 有一個重要的限制：它不支援時間排序。如果你的系統依賴 ULID 那樣的時間有序 ID 來進行 debugging 或資料庫索引，你需要自己處理這個權衡。對於大多數 agent 應用來說，這個 trade-off 是值得的。
LMDeploy：模型量化推論的吞吐量爆發
如果你正在自己部署 LLM（而不是使用 API），LMDeploy 的 KV cache 量化可能是最被低估的成本優化手段。LMDeploy 是 InternLM 團隊開發的推論引擎，基於 NVIDIA FasterTransformer，支援 INT4、INT8 和 TurboQuant 三種 KV cache 量化策略。
直覺上，量化會犧牲精度。但實測數據顯示，INT8 KV 量化幾乎是無損的。在 llama2-chat-7b 上，INT8 量化後的 RPS（requests per second）從 14.98 提升到 19.01——27% 的吞吐量提升——而 OpenCompass 評估顯示精度幾乎沒有下降。INT4 量化更激進，RPS 提升到 20.81（39%），精度損失在可接受範圍內。
最令人印象深刻的是 TurboQuant 技術。這是 Google Research 在 ICLR 2026 上發表的成果，LMDeploy 是第一個整合它的開源引擎。TurboQuant 使用 K=4bit QJL4 + V=2bit MSE 的組合，平均達到 3bit 的壓縮率。相較於 FP16，記憶體佔用減少約 5 倍，而端到端性能損失只有 7-8%。這意味著在同一張 GPU 上，你可以同時服務 5 倍的並發請求。
LMDeploy 的量化配置非常簡單。只需要在引擎配置中設定 quant_policy 參數：quant_policy=8 是 INT8，quant_policy=4 是 INT4，quant_policy=42 是 TurboQuant。對於自部署的團隊來說，這是一個幾乎零成本的優化——你只需要改一行配置，就能獲得顯著的吞吐量提升。
但有一個重要的限制：TurboQuant 目前只支援 PytorchEngine，不支援 TurbomindEngine。如果你已經在使用 Turbomind 的 optimized kernels，你需要評估切換的成本。對於大多數新部署來說，PytorchEngine + TurboQuant 是一個很好的起點。
三重疊加的實際效果
當這三個工具同時使用時，效果是乘數級的。假設你有一個典型的 agent 應用：
- Headroom 壓縮工具回傳的 JSON 和日誌，節省 60-80% 的 input tokens
- ID-Agent 把 UUID 換成 word-based IDs，額外節省 5-10% 的 ID 相關 tokens
- LMDeploy 的 KV cache 量化讓你在相同的 GPU 上服務 2-5 倍的並發
疊加後，你的每 dollar 資訊密度可以提升 3-5 倍。這不是 theoretical maximum，而是 production 中可以實際達到的數字。
但魔鬼在細節。Headroom 的壓縮在短對話中效果有限（median 只有 4.8%），它真正發威的場景是重度工具使用的長 session。ID-Agent 需要你的系統設計接受非時間有序的 ID。LMDeploy 的量化需要你有 GPU 資源來自己部署。
對於香港的創業者和開發者來說，最實際的建議是：先從 Headroom 開始。它支援零代碼改動的 proxy 模式，你只需要把 ANTHROPIC_BASE_URL 指向 Headroom proxy 就能開始省錢。然後評估你的 ID 使用模式，如果 agent 會傳遞大量 ID，切換到 ID-Agent。最後，如果你正在自部署 LLM，立即啟用 LMDeploy 的 INT8 KV 量化——這是最容易的勝利。
token 成本優化不是一次性的工作，而是一個持續的過程。但正確的工具組合可以讓你的 AI 應用在成本效率上獲得質的飛躍。