90%Token是垃圾！Uber四月烧光全年预算，Netflix工程师一招砍费

随着越来越多企业开始要求工程师“全面拥抱 AI”，一个意想不到的问题也逐渐浮出水面：AI 账单正在变得越来越吓人。

不久前，Uber 和微软就先后提到，企业内部大规模使用 AI 工具后，相关开销迅速攀升：

• Uber CTO Praveen Neppalli Naga 在接受采访时透露，公司为 2026 年全年准备的 AI 工具预算，已经在今年的前四个月全部用完了。
• 微软也开始取消内部工程师对 Claude Code 的访问权限，计划 6 月 30 日前转移至自家的 Copilot CLI 工具，直接原因很可能是其成本超出了可接受的范围。

而在 Netflix，一位高级工程师正在尝试解决这个问题。

Netflix 高级工程师 Tejas Chopra 开发了一个名为Headroom 的开源项目，它能在请求发送给大语言模型（LLM）之前，对 Prompt 和上下文中的 Token 进行“瘦身”，删除大量冗余内容——根据他的估算，目前发送给 AI 模型的 Token 中，最高有 90% 都是重复或无意义的信息。

虽然 Headroom 并非 Netflix 官方项目，但目前公司内部已有多个团队在使用它，外部开发者社区也开始广泛采用。在近期举行的 Open Source Summit 上，Chopra 直接透露：

Headroom 已累计帮助用户节省约 70 万美元成本，并释放出超过 2000 亿个 Token 配额，可用于其他更有价值的任务。

对于一个今年 1 月才开源、目前版本还停留在 v0.22 的项目来说，这个成绩已经相当惊人。截至目前，Headroom 已在 GitHub 上获得超过 7400 个 Star，被 Fork 超过 500 次。（GitHub 地址：

https://github.com/chopratejas/headroom）

Chopra 直言：“很多用户找到我们，最主要的原因不是性能问题，而是他们真的被 Token 费用坑惨了。”

一张 287 美元账单引发的灵感

Headroom 的诞生，源于一次再普通不过的个人项目开发。

起初，Chopra 用 Claude Sonnet 进行调试、重构代码，并通过 MCP 工具查询数据库。而账单出来后，他愣住了——287 美元。按当时 Claude Sonnet 的定价来看，这其实并不算贵：

• 输入 Token：3 美元/百万 Token
• 超过 20 万Token上下文窗口后：6 美元/百万 Token

看上去很便宜，但当 Token 数量达到数千万甚至上亿时，费用便会迅速累积。

于是 Chopra 开始分析这些 Token 究竟花在哪里。结果发现，真正的问题并不在于自己写给 AI 的 Prompt。相反，大量成本来自各种自动生成的“垃圾信息”，包括冗余到不行的 JSON Schema、API 响应里嵌套的模板、重复的数据库列……

Chopra 在博客中写道：“这不是自然语言，不是创意写作，它只是伪装成文本的可压缩数据。”

事实上，2025 年的一项研究发现：AI 应用中约 76% 的 Token 消耗，仅仅花在读取用户输入上。也就是说，模型的大部分计算资源都浪费在“看材料”而不是“思考问题”上。

对于这个问题，不少模型厂商其实已经意识到了。

例如，Claude 提供了 Prompt Cache（前缀缓存）机制，但这功能对开发者并不友好——默认情况下，Claude 的缓存仅保留 5 分钟；超过 5 分钟无操作后，整个上下文窗口都需要重新上传，即便内容完全一样也要重新计费。虽然 API 中还提供了 1 小时 TTL（缓存存活时间）选项，但这有个坑：你要为写入操作支付双倍成本，才能为读取操作节省 90% 的费用。

与此同时，市场上也开始出现各种 Token 优化服务。比如 YCombinator 投资的 Token Company，把 Token 压缩做成了服务；开源方面有 RTK（Rust Token Killer），专门修剪冗长命令的输出；另一个开源项目 LeanCTX 也类似于 RTK 的变种。

这些工具都能在一定程度上压缩 Prompt。但 Chopra 认为它们仍存在一个问题：压缩之后无法恢复原始内容——而这正是 Headroom 最大的特点。

所以，Headroom 是如何工作的？

Headroom 本质上是一个运行在开发者电脑上的本地代理（Proxy），技术栈主要基于Python 和 Node.js。用户只需要在命令行界面通过“headroom wrap codex”命令包装自己的 LLM，之后所有发往 LLM 的请求都会先经过 Headroom 处理。

虽然 Headroom 也能压缩一些程序代码和人类指令，但它最擅长的是砍掉服务器日志（90% 可以丢弃）、MCP 工具输出（70% 是重复的 JSON）、数据库输出（全是一个 schema）和文件树（大量重复的元数据）。

换句话说，凡是准备塞进 Context Window（上下文窗口）的内容，都会先被压缩。

（1）第一步：CacheAligner

Headroom 首先会运行一个名为 CacheAligner 的模块。它的思路很简单：如果用户已经上传过一段内容，那么下一次只发送发生变化的部分，而不是重新发送整个上下文，这样可以极大提高缓存命中率。

Chopra 举了一个例子：如果你的 System Prompt 中包含日期、UUID、Session ID，这些字段每次都会变化。那么缓存实际上会持续失效（Cache Miss），最终导致 Token 成本暴涨。

（2）第二步：针对不同数据类型压缩

随后，Headroom 会自动识别输入内容类型，并交给不同的压缩器处理：抽象语法树（AST）压缩器用于压缩程序代码；JSON 和 DOM 压缩器分别删除不需要的 JSON 数据和网页数据。

（3）第三步：智能“Squasher”

这是 Headroom 最有意思的部分，一些类似于“Squasher（压扁机）”的工具会基于统计分析，从文本或 JSON 输入中判断哪些部分真正重要，还会根据模型需要回看原始未压缩提示词的频率，在一个反馈循环中学习自己是压得过头了还是压得不够。

（4）最大杀手锏：可逆压缩

如上文所说，很多压缩工具的问题在于：压缩之后不可恢复。模型一旦需要原始数据，就无能为力。为此，Headroom 则引入了一套名为 CCR（Compress Cache and Retrieve） 的机制。

CCR 会在数据被压缩的地方打上标记，如果 LLM 想获取原始上下文，它可以调用一个 Headroom MCP，从用户机器上检索所需材料——这样既节省 Token，又不会丢失信息。

Chopra 承认，这套软件栈仍有改进空间，尤其是准确性测试方面。好在CCR存储了原始Prompt，所以可优化空间不小。他还提到，未来可以针对其他特定类型的数据（如金融数据）构建更多压缩器，音频、图像和视频也需要处理（已经有用户为了视频解析 fork 了这个项目）。

与此同时，Chopra 还打造了一个相关项目叫 Headlight，并表示很快就会开源。据透露 Headlight 会追踪每个 token 的来源，这对保证多模态工作的准确性很有用。

省一个 Token= 赚一个 Token

很多开发者有一种直觉：“上下文越大越好。”但越来越多研究表明，这种观点并不完全正确。

斯坦福大学研究人员发现：大模型对 Context Window 的注意力呈现明显的“首尾效应”——LLM 倾向于更关注上下文窗口的开头和结尾，而忽略中间部分。同样，数据集成商 Chroma 的研究也发现：在 18 个 LLM 上，随着输入长度增加，模型性能变得越来越不可靠。

他们把这种现象称为：Context Rot（上下文腐化）。简单来说，就是大量无关信息不仅会增加成本，还会降低模型推理质量。

值得一提的是，精简 Prompt 还能显著降低响应时间。Chopra 在演讲中分享了一个案例：某家公司把 Headroom 改造后用于语音交互系统，在语音场景下，连静音也会产生 Token。而为了让语音助手听起来足够自然，App 必须在 200 毫秒内给出响应。因此，他们利用 Headroom 尽可能压缩上下文，从而缩短推理延迟。

除此之外，Headroom 还有一个额外收益——降低能耗。因为理论上来说，更少的 Token 意味着：更小的上下文窗口 → 更少的计算量 → 更低的 GPU 资源消耗。不过，正如 Chopra 调侃的那样：即便 Headroom 让 Token 成本下降了，开发者们大概率还是会把省下来的预算，继续投入到更复杂、更庞大的 AI 应用中。

不过至少目前来看，对于那些已经被 AI 账单“教育”过的企业来说，Headroom这样的工具无疑相当有吸引力。毕竟在大模型时代，省下一个 Token 就等于赚到了一个 Token。