《LLM 上下文壓縮選型：Headroom 與微軟 LLMLingua 深度對比，誰才是 Agent 的最佳拍檔？》

微軟 LLMLingua（EMNLP 2023，LongLLMLingua 見 ACL 2024）是困惑度驅動提示壓縮的學術標竿：小語言模型為每個 token 打分，丟棄低資訊片段，論文宣稱最高 20 倍壓縮且下游損失極小。Headroom（chopratejas/headroom）走工程路線——本地 8787 埠代理、CCR 可逆儲存、按內容類型路由（JSON、AST、散文），以及與 OpenClaw + Headroom 運行手冊 等 Agent 一等整合。

構建常開 LLM Agent 的團隊面臨分叉：在 Python 流水線嵌入 PromptCompressor（偏研究、適合離線 RAG 入庫），或將 ANTHROPIC_BASE_URL 指向 Headroom 墊片（偏維運、適合線上閘道零改程式碼）。二者互補而非替代——它們優化不同層級：LLMLingua 在提示詞語意層做 token 級剪枝，Headroom 在傳輸與歸檔層做結構壓縮與可逆 CCR。本文是生產 Agent 維運的決策矩陣：困惑度剪枝 vs 代理 CCR、何時疊加 headroom proxy --llmlingua，以及可復現的八步評測手冊——不含租用價格表。

壓縮模型並排對比

LLMLingua family (Microsoft Research)
  Small LM (GPT-2-small / LLaMA-7B class)
    → token perplexity p(token | context)
    → drop low-perplexity tokens (budget controller + iterative passes)
    → optional distribution alignment to target LLM
  LongLLMLingua adds:
    → contrastive perplexity p(question | document)
    → document reorder ("lost in the middle" mitigation)
    → coarse-to-fine compression for RAG stacks

Headroom (engineering stack)
  Incoming messages (tools, logs, JSON, code, chat)
    → CacheAligner (KV-cache-friendly prefixes)
    → ContentRouter
         ├─ SmartCrusher (JSON arrays/objects)
         ├─ CodeCompressor (AST: Py/JS/Go/Rust/…)
         └─ Kompress-base (agentic prose, HF model)
    → CCR stores originals locally; model calls headroom_retrieve
    → Proxy forwards /v1/messages to Anthropic/OpenAI/Bedrock

可引用： LLMLingua 靠 SLM 困惑度刪 token；Headroom 按內容類型路由並保留可逆 CCR歸檔——設計目標正交，可單獨選型也可疊加。前者擅長同質長文與 RAG 重排序；後者擅長 Agent 工具 JSON、程式碼 AST 與需稽核原文的合規場景。

決策矩陣：學術 vs 工程

場景 A：長文件堆 RAG

畫像： 法務、客服或內部 wiki 問答——10–50 份 PDF 切塊拼進單一提示，末尾附使用者問題。上下文以自然語言段落為主，工具呼叫較少。

LLMLingua 適配： LongLLMLingua 為此而生。按 微軟範例 使用 condition_in_question="after_condition"、reorder_context="sort"、rate=0.55。對比困惑度在文件雜訊大、需按問題重排 chunk 時優於 vanilla LLMLingua，論文報告 NQ 多文件 QA 可提升 +21.4%。

Headroom 適配： 塊內混有 JSON 中繼資料 + 散文（工單匯出、知識庫內嵌 CI 日誌）時更強。代理模式可在不改 LangChain/LlamaIndex 膠水程式碼的前提下壓縮上下文，並保留 CCR 供模型按需檢索原文段落。

若 X 則 Y： 若瓶頸是多文件排序與 lost-in-the-middle，則先原型 LongLLMLingua。若瓶頸是 Agent 迴圈裡異構 tool+json 上下文，則先原型 Headroom 代理。

場景 B：常開編碼 / 維運 Agent（OpenClaw 類）

畫像： 夜間儲存庫稽核、MCP stdio 工具、兆位元組級 linter JSON——每輪對話上下文持續膨脹，且混入大量結構化工具輸出與堆疊追蹤。

LLMLingua 適配： 離線批次壓縮靜態提示時可作前置步驟。若每次閘道呼叫都跑 compress_prompt()，除非有 SLM 結果快取，否則每次都會增加 SLM 推理延遲，難以滿足 p95 < 2s 的線上 SLO。

Headroom 適配： 為此形態設計——有文件的 OpenClaw 外掛、/stats 與 /stats-history Prometheus 指標、headroom mcp install。代理在請求路徑上透明壓縮，模型可透過 headroom_retrieve 按需取回原文。LaunchAgent 佈線見 OpenClaw + Headroom 運行手冊。

若 X 則 Y： 若需要 macOS launchd 閘道上的即插即用代理，則選 Headroom。若發布帶凍結提示的研究流水線，則在入庫階段用 LLMLingua。

場景 C：混合棧（二者兼得）

Headroom 支援 headroom proxy --llmlingua——在 SmartCrusher、CodeCompressor 等結構壓縮器之後，可選疊加微軟困惑度壓縮器做更深一輪 token 剪枝。典型流程：先剝除 JSON 冗餘鍵與重複日誌行，再對剩餘散文段落做 SLM 困惑度壓縮。代價：約 2 GB 額外依賴（torch + SLM 權重），冷啟動 10–30 秒（見 Headroom 代理文件）。

若 X 則 Y： 若評測顯示 SmartCrusher 仍留 >30% 冗餘 JSON 或散文段落，則僅在 24 GB Mac mini M4 上啟用 --llmlingua --llmlingua-rate 0.3 做 A/B。若延遲 SLO 要求 p95 < 2s，則僅用結構壓縮器 + CCR，不跑 ML 通道。

推薦路徑

• 若優化 ACL 式 RAG 基準，則從 LongLLMLingua PromptCompressor 與微軟 rate 參數掃描起步。
• 若維運 OpenClaw / Claude Code / Cursor 艦隊，則從 Headroom 代理 起步，連續七晚觀測 /stats-history。
• 若合規要求逐字稽核軌跡，則優先 Headroom CCR，而非僅有損困惑度流水線。
• 若需要 KV-cache 壓縮 研究，則評估 LLMLingua-2 與 微軟研究院 快取線。
• 若二者在自有軌跡上均未達 40% 節省，則先修提示設計——壓縮救不了冗餘工具往返。

八步評測運行手冊

1. 凍結黃金提示集

採集 N≥20 條真實 Agent 輪次：工具 JSON、堆疊追蹤、系統指令。在 ~/compression-eval/fixtures/ 為每條 fixture 記錄 SHA-256 校驗和。

2. 基線 token 計數（未壓縮）

從提供商主控台或 tiktoken 記錄每條 fixture 的未壓縮輸入 token 數，作為後續對比基準。建議同時記錄輸出 token 與總延遲，便於計算壓縮帶來的端到端 ROI。

3. 執行 LLMLingua / LongLLMLingua 臂

pip install llmlingua

from llmlingua import PromptCompressor
pc = PromptCompressor(model_name="microsoft/llmlingua-2-xlm-roberta-large-meetingbank")
out = pc.compress_prompt(prompt_list, question=question, rate=0.55,
    condition_in_question="after_condition", reorder_context="sort",
    rank_method="longllmlingua")
compressed = out["compressed_prompt"]

記錄 origin_tokens、compressed_tokens 與牆鐘耗時（毫秒），並保存壓縮後提示詞副本供步驟 6 品質門禁復用。

4. 執行 Headroom 代理臂

pip install "headroom-ai[proxy]"
headroom proxy --port 8787 --log-file ~/.headroom/eval.jsonl

經 /v1/compress POST fixture，或將即時 Agent 流量路由至代理；從 /stats 讀取 tokens_saved。

5. 可選混合臂

headroom proxy --port 8788 --llmlingua --llmlingua-rate 0.3

對比 p95 延遲與節省率提升，判斷混合棧是否值得額外記憶體與冷啟動成本；建議與純 Headroom 臂並列記錄七日滾動均值。

6. 品質門禁（同一下游 LLM）

用生產模型在相同溫度下重跑每條壓縮 fixture，禁止在評測臂之間切換模型版本。評分：結構化欄位精確匹配、摘要由 LLM 評判、人工抽檢 5%；任一臂品質門禁失敗則不得進入生產 cutover。

7. Agent 回歸套件

OpenClaw 維運：用各臂重放夜間稽核任務；對比發現數量與已知種子 bug 的漏報率（false-negative）。若壓縮導致稽核結論漂移，應優先回退至 CCR 可逆路徑或降低壓縮率，而非直接全量上線。

8. 按工作負載選定方案

記錄：RAG 入庫 → LongLLMLingua，線上閘道 → Headroom 代理，極限壓縮實驗 → 混合棧——內部發布結論並附 token 月度成本測算。

故障排查

LLMLingua 指令遵循崩潰

現象： 壓縮後提示丟失否定詞或 JSON 鍵名。

修復： 調高 rate（0.55 → 0.75，保留更多 token）。用 budget controller 豁免指令塊。對照 LLMLingua-2，見 微軟研究院。

Headroom 代理省 token 但 Agent 漏行號

現象： 稽核 Agent 引用錯誤的 file:line。

修復： 指示模型在結案前呼叫 headroom_retrieve；單次復現可設 x-headroom-bypass: true。若 schema 鍵被剝除，收窄 SmartCrusher 規則。

兩臂均慢於未壓縮基線

現象： p95 延遲 > 3× 未壓縮基線。

修復： LLMLingua——將 SLM 快取於 GPU/MPS，對靜態 fixture 離線批次處理，避免在熱路徑重複載入模型。Headroom——禁用 --llmlingua，僅保留結構壓縮器；代理與 OpenClaw 閘道同機部署以降低 loopback 以外的網路往返。

若兩臂在七晚 /stats-history 中均未穩定達到 40% token 節省，應回到提示工程：減少冗餘工具往返、合併重複 linter 輸出，再重新跑八步評測。

常見問題

Headroom 是 LLMLingua 的分支嗎？

不是。Headroom 是獨立的 Apache-2.0 專案，可透過 --llmlingua 可選呼叫 LLMLingua。預設路徑使用 SmartCrusher、CodeCompressor 與 Kompress-base，而非單純困惑度剪枝。

何時困惑度剪枝優於按內容類型壓縮？

當提示詞以同質自然語言為主（長文、少量 JSON 孤島），且能用已知問題錨點調優 LongLLMLingua 時。異構 Agent 工具輸出通常更適合 Headroom 的 ContentRouter。

能否在 OpenClaw 裡只用 LongLLMLingua、不用 Headroom？

可以——在 Skill 腳本裡用 PromptCompressor 預壓縮靜態上下文（如儲存庫 README、固定規範文件）。但會失去每次請求的代理透明性、即時 /stats 觀測與 CCR 可逆歸檔，除非自行實作檢索層與原文儲存。

LLMLingua-2 與 LongLLMLingua 有何區別？

LLMLingua-2 將壓縮重構為 BERT 級編碼器的 token 分類，微軟報告稱比迭代困惑度快 3–6 倍。Headroom 可透過 --llmlingua 疊加；速度與 SLO 需單獨評估。

財務該為 20 儲存庫夜間稽核艦隊批哪個？

第一週對單一儲存庫跑完八步評測，記錄 token $/月 與 p95 延遲。若工具 JSON 占主導，Headroom 代理 + OpenClaw 通常維運整合更快、CCR 便於財務稽核；若靜態文件 RAG 占主導，LongLLMLingua 可能在品質/美元上更優——用數據說話，勿憑品牌選型。