砍掉90%冗余词元，省下70万美元：Netflix开源工具狙击AI账单黑洞

正如 Uber 和微软 COO 最近所领教的那样，鼓励公司工程师积极使用 AI 可能会带来巨额账单，甚至可能抵消裁员带来的所有收益。 不过 Netflix 的 AI 账单或许不会那么触目惊心，这要归功于公司的高级工程师 Tejas Chopra，他开发了一款软件，可以在指令到达大语言模型之前，以词元为单位对智能体指令进行精简。 Chopra 估计，高达 90% 的词元对于你所选择的模型来说都是冗余的。 尽管这并非 Netflix 的正式项目，但公司内部已有多个团队在使用 Headroom（ https://github.com/chopratejas/headroom），不少外部项目也依赖它。 " 在近期的开源峰会上，Chopra 表示，Headroom 已为用户节省了约 70 万美元，这些用户可以将节省的 2000 亿词元用在其他地方。 对于一个今年 1 月份才发布的开源应用来说，这样的成绩已经相当不错了。Headroom 目前仍处于较为初级的 v0.22 版本，已在 GitHub 上收获 2000 个星标，被复刻超过 120 次。 “我们的很多用户都是那些真正被词元成本灼伤过的人，”Chopra 在演讲中说道。 无损上下文压缩 一笔来自 Claude Sonnet 的 287 美元账单让 Chopra 第一次留意到词元成本优化的问题。 这笔账单是典型的个人项目开销：一些调试、一些重构、MCP 工具查询数据库。当时，Claude Sonnet 按词元计价的收费标准看似十分划算：每百万输入词元收费 3 美元，如果超出上下文窗口的 20 万词元限制，每百万收费 6 美元。即便资费单价不高，最终费用还是一路累积到了 287 美元。 仔细检查后，Chopra 发现传输给大模型的数据里存在大量冗余内容。整体来看，他手动编写的指令并非开销偏高的元凶，真正的问题在于附带的各类样板代码与机器元数据：冗余繁琐的 JSON 结构、API 返回内容里层层嵌套的模板、大量重复的数据库字段。 “这并非散文创作，也不是创意写作，而是伪装成文本的可压缩数据，”Chopra 在一篇介绍这款软件的博客文章中写道。2025 年，一组研究人员发现，读取用户输入约占所有词元消耗的 76%。 模型厂商也提出了自己的词元成本优化工具。但迄今为止，这些工具的设置对终端用户来说有些晦涩难懂。默认情况下，Claude 的前缀缓存设置仅为 5 分钟，闲置 5 分钟不活动，整个上下文窗口都需要刷新，即使大模型需要的数据是完全一样的。接口文档里还标注了一小时的生存时间（TTL）配置，但这里暗藏陷阱。“你的写入成本要翻倍才能换来读取时 90% 的节省，”Chopra 告诉听众。找到最佳平衡点只能靠你自己了。 市面上也出现了不少新的商用“词元精简工具”，比如获得 Y Combinator 投资的 Token Company（ https://thetokencompany.com/），提供词元压缩即服务。开源领域则有 " RTK（Rust Token Killer， https://www.rtk-ai.app/），它修剪冗长命令的输出，比如对代码仓库的调用。另一个开源项目 " LeanCTX（ https://leanctx.com/） " 是 RTK 的一个变体。 Chopra 承认这些工具都有用，但他设计 Headroom 的初衷是让操作内嵌在开发者的工作流中，而且它具备其他应用和服务都无法提供的功能：可逆压缩。 Headroom 会压缩所有输入用户上下文窗口的源材料——不仅包括对话历史，还包括日志、工具输出、文件、RAG 检索出的文档片段——在它们到达大模型之前。 上下文窗口是单用户会话的固定存放空间。当下顶尖的模型正迅速将上下文窗口扩展至 200 万词元以上，同时容纳输入和输出。 正如 Pope Leo 所言，这种慷慨是一把双刃剑。作为计量单位，单个词元大致相当于一个人类词汇。在按量计费模式下，塞入上下文窗口的内容越多，产生的费用也就越高。 像吃豆人一样吃掉词元 Headroom 基于 Python 和 Node，作为代理形式（端口 8787）在工程师的设备上运行。用户在命令行界面对大语言模型进行包装（例如 headroom wrap codex），工具便会自动解析输入内容。 虽然 Headroom 确实会压缩部分代码和人工指令，但它最擅长的是精简服务器日志（其中 90% 可以丢弃）、MCP 工具输出（70% 是冗余 JSON）、数据库输出和文件树（大量重复的元数据）。 Headroom 的第一步是一个叫作 CacheAligner 的过程，它只在已输入的内容中寻找发生变化的信息，只向大模型发送新增的内容，省去替换 KV 缓存内绝大部分未变动全文的操作。KV 缓存是 AI 供应商存储用户上下文窗口的缓存。 “如果系统提示词里带有日期字段或是每轮会话都会自动变化的 UUID，每次调用都会出现缓存未命中的情况，”他向听众说道，“进而造成成本大幅飙升。” 随后会经过路由处理识别数据类型，再发给对应的压缩器。抽象语法树（AST）压缩器负责压缩程序代码，JSON 压缩器、文档对象模型（DOM）压缩器则分别剔除冗余 JSON 与网页模板代码。 Headroom 还提供了一些精简处理器，它们读取文本或 JSON 输入，基于统计分析筛选有效内容。这些工具依靠反馈循环迭代优化压缩程度，根据模型调取原始未压缩提示词的频次来判断压缩是否过量或压缩不足。 最后一步为 CCR（压缩缓存与读取），让大模型能够调取原始未压缩数据。这个过程会在数据压缩处打上标记，倘若大模型需要原始上下文，可通过 Headroom MCP 从用户本地设备拉取对应内容，原始数据统一存放在 Redis 或 SQLite 数据库中。 Chopra 坦言这个工具栈仍有待完善，特别是在测试准确性方面。这个难度应该不会很高，因为 CCR 存储了原始提示词，后续还可针对金融数据等特殊数据类型开发专属压缩器。 音频、图像和视频同样需要做压缩处理（已有用户复刻项目用于视频解析）。Chopra 透露，相关项目 Headlight 即将开源。Headlight 将追踪每个词元的来源，这对于确保多模型工作的准确性来说可能特别有用。 省一个词元就是赚了一个词元 相关研究显示，合理管控词元用量既能节省开支，也有助于提升模型输出效果。 智能体推送的上下文超出模型实际所需，不仅会大幅增加用户开销，还会导致大模型的生成效果变差。 和人类一样，大模型在面对过多信息时也会出现判断混乱。斯坦福大学的一些学者发现，大模型更关注上下文窗口的开头和结尾，容易忽略中间部分。 同样，来自数据集成商 Chroma 的一组研究人员推断，在参与测评的 18 款大模型里，“输入文本越长，模型输出稳定性就越差”。 他们将这种现象称为“上下文腐烂”（Context Rot）。 精简提示词还能降低响应延迟。Chopra 在演讲中提到 Headroom 的一位用户复刻了该软件用于语音交互应用。对于语音来说，即使是沉默也会产生词元。用户期望应用能够在 200 毫秒内做出响应，这样服务听起来才自然，因此这家公司正在使用 Headroom 最大限度地缩短