Headroom vs Microsoft LLMLingua：LLM Agent 向けコンテキスト圧縮フレームワークの選び方

Microsoft LLMLingua（EMNLP 2023、LongLLMLingua ACL 2024）は困惑度駆動プロンプト圧縮の学術標準：小 LM が各トークンをスコアし低情報スパンを削除、最大20×圧縮を主張。Headroom（chopratejas/headroom）はエンジニアリングレーン—ローカルプロキシポート8787、CCR 可逆、コンテンツ種別ルータ、OpenClaw + Headroom ランブック などagent統合。

常時稼働 LLM agentチームは分岐：Python で PromptCompressor（研究向け）か ANTHROPIC_BASE_URL を Headroom に（運用向け）。相互補完。本稿は本番 agent 向け意思決定マトリクス：困惑度剪定 vs プロキシ CCR、headroom proxy --llmlingua の併用、8 ステップ評価—料金表なし。

圧縮モデル並列比較

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 困惑度でトークン削除；Headroom はコンテンツ種別ルーティングと可逆 CCR—直交する設計目標。

意思決定マトリクス：学術 vs エンジニアリング

シナリオ A：長文ドキュメント山の RAG

Profile: Legal, support, or internal wiki QA—10–50 PDFs chunked into a single prompt, user question appended.

LLMLingua fit: LongLLMLingua was built for this. Use condition_in_question="after_condition", reorder_context="sort", rate=0.55 per Microsoft's examples. Contrastive perplexity beats vanilla when documents are noisy.

Headroom fit: Strong when chunks mix JSON metadata + prose (ticket exports, CI logs in KB). Proxy mode compresses without rewriting LangChain/LlamaIndex glue.

If X, do Y: If bottleneck is multi-document ordering and lost-in-the-middle, do prototype LongLLMLingua first. If bottleneck is heterogeneous tool+json context in an agent loop, do prototype Headroom proxy first.

シナリオ B：常時稼働コーディング/運用 agent（OpenClaw 級）

Profile: Nightly repo audits, MCP stdio tools, megabyte linter JSON—context grows every turn.

LLMLingua fit: Works as a pre-step if you batch-compress static prompts offline. Per-request compress_prompt() adds SLM inference latency on every gateway call unless cached.

Headroom fit: Designed for this shape—documented OpenClaw plugin, /stats Prometheus metrics, headroom mcp install. See OpenClaw + Headroom ランブック for LaunchAgent wiring.

If X, do Y: If you need drop-in proxy on macOS launchd gateways, do Headroom. If you publish research pipelines with frozen prompts, do LLMLingua in the ingest stage.

シナリオ C：ハイブリッドスタック

Headroom supports headroom proxy --llmlingua—Microsoft's perplexity compressor as an optional deeper pass after structural crushers. Trade-off: ~2 GB extra dependencies, 10–30s cold start per Headroom proxy docs.

If X, do Y: If eval shows SmartCrusher leaves >30% fat JSON, do enable --llmlingua on a 24 GB Mac mini M4 only. If latency SLO < 2s p95, do stay on structural crushers + CCR without ML pass.

推奨パス

• If you optimize ACL-style RAG benchmarks, do start with LongLLMLingua PromptCompressor and Microsoft rate sweeps.
• If you operate OpenClaw / Claude Code / Cursor fleets, do start with Headroom proxy and measure /stats-history for seven nights.
• If compliance requires verbatim audit trails, do prefer Headroom CCR over lossy perplexity-only pipelines.
• If you need KV-cache compression research, do evaluate LLMLingua-2 and Microsoft's cache line per Microsoft Research.
• If neither hits 40% savings on your traces, do fix prompt design first—compression cannot rescue redundant tool round-trips.

8ステップ評価ランブック

1. ゴールデンプロンプトセットを固定

Capture N≥20 real agent turns: tool JSON, stack traces, instructions. Store SHA-256 per fixture under ~/compression-eval/fixtures/.

2. ベースライン token 数（未圧縮）

Record input tokens from provider dashboard or tiktoken for each fixture.

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"]

Log origin_tokens, compressed_tokens, wall-clock ms.

4. Headroom プロキシアームを実行

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

POST fixtures through /v1/compress or route live agent traffic; read tokens_saved from /stats.

5. 任意ハイブリアーム

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

Compare p95 latency vs savings uplift.

6. 品質ゲート（同一下流 LLM）

Re-run each compressed fixture through your production model with identical temperature. Score: exact-match for structured fields, LLM-judge for summaries, human spot-check 5%.

7. Agent 回帰スイート

For OpenClaw operators: replay nightly audit job with each arm; compare finding counts and false-negative rate on known seeded bugs.

8. ワークロード別に勝者を選定

Document: RAG ingest → LongLLMLingua, live gateway → Headroom proxy, max compression lab → hybrid—publish internally with token $/month math.

トラブルシューティング

LLMLingua collapsed instruction-following

症状： Compressed prompt drops negation or JSON keys.

対処： Lower rate (0.55 → 0.75). Use budget controller to exempt instruction block. Compare LLMLingua-2 per Microsoft Research.

Headroom proxy saves tokens but agent misses line numbers

症状： Audit agent cites wrong file:line.

対処： Instruct model to headroom_retrieve before closing findings; set x-headroom-bypass: true on one repro. Narrow SmartCrusher if schema keys stripped.

Both arms slower than uncompressed

症状： p95 latency > 3× baseline.

対処： LLMLingua—cache SLM on GPU/MPS, batch offline. Headroom—disable --llmlingua, keep structural crushers only; co-locate proxy on same host as gateway.

FAQ

Headroom は LLMLingua のフォークか？

いいえ。Headroom は独立した Apache-2.0 プロジェクトで、--llmlingua で任意に LLMLingua を呼べます。既定は SmartCrusher、CodeCompressor、Kompress-base—困惑度剪定のみではありません。

困惑度剪定がコンテンツ種別クラッシャーに勝つときは？

プロンプトが均質な自然言語（長文、JSON 島が少ない）で、既知の質問アンカーで LongLLMLingua を調整できるとき。異種 agent ツール出力は Headroom のルーター向きです。

Headroom なしで OpenClaw 内で LongLLMLingua を使える？

はい—スキルで PromptCompressor により静的コンテキストを事前圧縮。リクエストごとのプロキシ透明性と CCR は失われます。

LLMLingua-2 と LongLLMLingua の違いは？

LLMLingua-2 は BERT 規模エンコーダによるトークン分類—Microsoft 報告では反復困惑度より 3–6 倍高速。Headroom は --llmlingua で層化可能；SLO と別評価。

20 リポ夜間監査フリートで財務はどちらを承認すべき？

第 1 週に 1 リポで 8 ステップ評価。ツール JSON 支配なら Headroom プロキシ + OpenClaw が運用統合速い；静的 RAG 支配なら LongLLMLingua が品質/ドルで勝つ場合あり。