AI 账单正在变成很多团队的心病。Uber、微软的 COO 都领教过：鼓励工程师用 AI，账单可能大到抵消裁员省下的钱。Netflix 高级工程师 Tejas Chopra 给出了一个开源解法——Headroom（v0.22），它在你和大模型之间当一道「闸」，把指令里高达 90% 的冗余词元砍掉再发送。这个今年 1 月才开源的项目，已为用户节省约 70 万美元、2000 亿词元，GitHub 收获 2000 个星标。

这篇讲清楚 Headroom 解决什么问题、怎么工作、怎么装上用。

它解决什么问题

一笔来自 Claude Sonnet 的 287 美元账单让 Chopra 开始查词元成本。他发现：自己手写的指令并不是大头，真正的元凶是附带的机器元数据——层层嵌套的 JSON、API 返回的模板、重复的数据库字段、服务器日志。

「这并非散文创作，也不是创意写作，而是伪装成文本的可压缩数据。」

一项 2025 年的研究发现，读取用户输入约占所有词元消耗的 76%。模型厂商虽提供前缀缓存等优化，但默认 TTL 仅 5 分钟，且写入成本要翻倍才能换 90% 的读取节省，平衡点只能自己摸。

Headroom 怎么工作

Headroom 基于 Python 和 Node，作为本地代理（端口 8787）跑在工程师的设备上，在指令到达大模型之前完成压缩。整个链路分几步：

1. CacheAligner：只在已输入内容里找变化，只把新增部分发给大模型，避免刷新整个 KV 缓存。系统提示词里若有日期或 UUID 每轮都变，本来会导致每次缓存未命中，这一步直接堵掉。
2. 路由识别数据类型：自动分发到对应压缩器。
3. 类型专用压缩器：
   • AST 压缩器：压缩程序代码（抽象语法树）
   • JSON 压缩器：剔除冗余 JSON
   • DOM 压缩器：精简网页模板代码
4. 精简处理器：基于统计分析筛选有效内容，靠反馈循环迭代——根据大模型回头调取原始未压缩提示词的频次，判断压缩是否过量。
5. CCR（压缩缓存与读取）：让大模型在需要时调回原始数据。压缩处打上标记，大模型可通过 Headroom MCP 从本地 Redis 或 SQLite 拉取对应原始内容。

各类型可压缩比例（实测）：

关键差异：可逆压缩

Headroom 跟市面上其他词元精简工具最大的不同是 可逆。商用方案如 Y Combinator 投资的 Token Company 提供「压缩即服务」；开源领域有 RTK（Rust Token Killer）修剪冗长输出、LeanCTX（RTK 变体）。这些工具都有用，但大多是有损修剪。

Headroom 把原始提示词完整留在本地（Redis / SQLite），大模型随时能调回完整上下文。这意味着压缩激进一点也不会丢信息，压缩是否过量由模型自身的「回看频次」反馈决定。

💡 提示：精简词元不只省钱，还能提升输出质量。斯坦福的研究发现大模型更关注上下文开头和结尾、容易忽略中间；Chroma 团队在 18 款大模型上观察到「输入越长、输出稳定性越差」，称为「上下文腐烂（Context Rot）」。

怎么用

Headroom 在命令行里包装你的大模型调用：

headroom wrap codex

工具会自动解析输入内容并完成压缩。它最擅长的是精简服务器日志、MCP 工具输出、数据库输出和文件树。

GitHub 仓库：https://github.com/chopratejas/headroom

适合谁用

• 被词元账单灼伤过的开发者：尤其是重度使用 MCP 工具、RAG 检索、长日志分析的智能体工作流。
• 语音交互应用：对延迟敏感的场景（用户期望 200ms 内响应），更少词元意味着更短延迟。已有用户复刻 Headroom 用于语音应用。
• 关注能耗的团队：更少词元 = 更小上下文窗口 = 更少能源消耗。

已知局限

Chopra 坦言工具栈仍在完善，尤其是测试准确性方面。音频、图像、视频的压缩还没做（已有用户复刻用于视频解析），相关项目 Headlight 即将开源，会追踪每个词元的来源，对多模型协作的准确性有帮助。

参考

• GitHub：https://github.com/chopratejas/headroom
• 原文（The Register）：https://www.theregister.com/ai-ml/2026/05/31/netflix-wiz-creates-app-to-slash-ai-bills-then-open-sources-it/