Headroom 实测：号称省 20% token 的 AI 上下文压缩层，真省钱吗
最近刷到 GitHub 上一个很火的项目 headroomlabs-ai/headroom（约 74k star），宣传语很诱人：「AI Agent 的上下文压缩层，同样的回答、零头的 token」。号称把喂给大模型的东西（工具输出、日志、文件、RAG 结果）在发送前先压缩一遍，全部本地运行、数据不出机器。
正好手头有跑 Agent 的日常需求，就把整个评测流程完整做了一遍：隔离安装 → 压缩库 API 测试 → 套在真实 LLM 链路前面做端到端验收。结论先放这里：链路是真能跑通的，但它宣称的"省钱"有相当多的前提条件，README 没写。
它是什么：两条腿，规则腿和模型腿
Headroom 的压缩分两条路：
- 规则腿：SmartCrusher（压 JSON）、CodeCompressor（AST 感知压代码）、日志去重。纯本地代码，装好即用，不需要任何模型。
- 模型腿：一个自研的 kompress-v2-base 模型，负责自然语言散文的压缩。首次使用时要从 HuggingFace 下载约 260MB 的 ONNX 推理文件，CPU 上跑。
这个结构很重要，因为后面所有实测结论基本都可以归结为「规则腿很强，模型腿很弱」。
实验一：压缩库 API 直测
用 uv 起了个 Python 3.13 隔离环境装好（pip install "headroom-ai[all]"，不污染系统），直接调它的 compress()，按真实 Agent 消息结构喂三组数据：
| 场景 | 压缩前 | 压缩后 | 节省 | 关键信息保留 |
|---|---|---|---|---|
| 120 行订单 JSON（含中文备注字段） | 5,278 tok | 2,418 tok | 54% | 抽查字段全在 ✓ |
| 2000 行日志（故意埋了 FATAL/ERROR 行） | 47,107 tok | 432 tok | 99.1% | FATAL 行+订单号+表名逐字保留 ✓ |
| 中文政策类散文 | 798 tok | 798 tok | 0% | 原文一字未动 ✓ |
几个值得注意的行为：
- 它只压 tool 角色的内容，user/assistant 消息一律原样保护——这个设计很稳，不会把你的指令改掉。但也意味着：拿普通聊天消息测压缩率会得到 0%，必须构造工具调用的消息结构才测得出真实收益。
- 收益全看载荷重复度。日志、列表类结构化内容砍 54%~99%，这才是省 token 的大头；而这些都是规则腿干的，和那个 HF 模型没关系。
- 中文散文 0% 不是失败，是 router 判断「不可安全压缩」直接放行——宁可不压也不瞎删，保守但可信。
然后去验证那条「模型腿」。读了 kompress-v2-base 的模型卡：它不是生成式模型，是 150M 参数的逐 token 打「留/删」标签的判别器（ModernBERT 底座 + LoRA），输出永远是原文的子序列、不编造内容——设计思路挺聪明的。但模型卡上写着 language: en。
实测下来：英文长文压缩率 ratio=0.943，即只省 5.7%（为了 5.7% 承担删错关键句的风险，不值）；中文散文 100% 原样返回——英文 tokenizer 根本不认中文，这是硬局限，下载与否都改变不了。
（小插曲：第一次调用会因冷加载撞它的 20 秒超时保护自动原文兜底，热身后才 1.4 秒。测这类系统一定要先热身、丢弃首轮结果。）
实验二：端到端套代理
最省事的接入方式是它的透明代理：headroom proxy --port 8787，把 Agent 的 base_url 指过来就行，零代码改动。我把它接在自用的 OpenAI 兼容端点（qwen 模型）前面，构造了真实的多轮工具调用请求：
- ✅ 链路通：请求正常转发、模型正常应答，压缩后模型仍然答对了埋进去的 4/4 个订单号锚点；审计通道
/stats能逐请求回查 before/after token。 - ✅ 压缩确实发生过：有一次请求 92,110 → 522 token（省 99.4%），有记录可查。
但是，三盆冷水：
- 最新一条工具输出永远不压。单轮 Agent 请求（工具结果=最后一条消息）省 0，省钱只发生在「历史轮次」里的旧工具输出上——也就是说只有超长会话才吃得到红利，而这取决于它的 recent-read 保护策略。
- 行为不稳定。我用结构几乎相同的请求跑了几次，一次压 99.4%、一次 0%。它的「近期保护 + 模式聚类」对载荷形态很敏感，行内随机数据多的日志会被直接放弃压缩。省没省、省多少，事前不好预期。
- 数字对不上账。它自报的 token 数和上游厂商返回的 usage 口径不一致（估算器不同），dashboard 看趋势可以，别当账单用。
最终评价
值不值得用，取决于你是谁：
- 载荷以英文日志/JSON/代码为主 + 有超长多轮会话的 Agent：规则腿的收益是真实的（日志 99%、JSON 54%，中文键值也不误伤），可以试试，建议先开
--mode token并在审计通道里观察两周。 - 中文业务为主（比如我这种）：模型腿基本无用——英文散文只省 5.7%，中文 0%；而规则腿的收益又集中在"日志/报表类历史载荷"，如果日常调用以短会话为主，就碰不到。叠加自家模型端点本来就有隐式前缀缓存，这层转发的性价比就很低了。
我的决定是：停掉代理、删掉测试环境和 262MB 模型缓存，保持直连。项目本身工程质量不错（CI 完备、审计通道做得讲究、"输出必为原文子序列"的保守设计在合规视角是加分项），但「省 20% token」的宣传在真实流量上是有条件的平均数，不是无脑开关。
评测全程数据可在审计通道与模型卡复核 · 本文数据均为本机实测记录
评论