Headroom：为 LLM 做瘦身，开源上下文压缩层

一次看似平常的 GPU 故障排查，让资深工程师 Tejas Chopra 意识到，自己向大语言模型（LLM）发送的大部分内容其实并不必要——而他却要为这些冗余数据买单。那次提问消耗了整整两倍的上下文窗口，个人项目月度账单高达 287 美元。这次经历促使他开发出开源上下文压缩层 Headroom。在停止统计之前，Headroom 在五个月内为用户累计节省约 70 万美元成本，并回收了约 2000 亿 token。Chopra 也因此离职，创立了 Headroom Labs，专注于「我们喂给 LLM 的数据大多没必要」这一命题。

起因：一笔 287 美元的账单

Chopra 起初的排查流程很标准：拉取日志 → 交给 Claude 分析 → 拿到结果继续工作。但模型在回答前把整份日志读了很多遍，最终只提取出三行关键信息，其余内容全部白跑。Chopra 事后把 prompt 改为只关注 warnings 与 alerts，响应速度提升、token 成本下降。但问题在于：并不是每位开发者都有意愿或能力去手动「整理 prompt」。

他意识到这是一项应当被工程化的能力，于是有了 Headroom——一个可以本地运行的上下文优化中间层。Chopra 在 Linux 开源峰会上展示该项目时发现，很多企业其实连「token 花在哪里」都说不清楚，更谈不上优化。

压缩管线的三道关

Headroom 的压缩流程经历了三个阶段的演进：

• JSON 瘦身：JSON 是最常见的 LLM 输入格式，但空白、逗号、引号、缩进都会消耗 token。Headroom 剥离这些噪声后转为紧凑表示，可在不丢数据的前提下即时节省约 30% 的 token。
• 统计相似性聚合：例如一个数组中 90 个值有 88 个落在 0–1 之间，只有两个离群值 99 和 100。系统无需传输全部 90 个值，只保留离群值并加注「88 个值在 0–1 之间」的汇总信息。「只需要保留一份相似数据的副本以及它的 delta」，Chopra 解释道。
• 缓存与回溯机制：每个被压缩的 payload 都对应一个缓存条目，键由会话 ID 与原始数据的哈希共同组成，因此哈希碰撞不会造成跨会话污染。完整原始数据存在本地 Redis 或 SQLite 中，TTL 默认 5–30 分钟，强制刷新而无需开发者手动管理缓存失效。企业部署可以替换为 AWS RDS、GCP Bigtable 或私有云的 Postgres 等数据库。

用智能换安全：留给模型的「面包屑」

压缩最大的风险在于：模型可能需要你扔掉的那部分信息。Headroom 的解法是在压缩后的输出中嵌入一个工具调用定义——压缩时哈希原始数据并存入本地，在压缩版本里写入一个「面包屑」式的工具描述，模型如果判断需要完整数据，可以主动调用工具取回。Chopra 表示，这种回退调用发生概率不到 1%，压缩本身被设计得足够保守，模型的智能足以在不回退的情况下完成绝大多数任务。

团队层面的复用与价值

对多人协作的团队而言，缓存的价值会被进一步放大：同一份 API 响应如果十位工程师在同一天调用，只需压缩并存储一次。TTL 也从个人层面的默认设置，变成组织层面的可统一配置策略。Headroom 的核心理念被 Chopra 概括为：把 token 预算当作计算资源一样对待，按任务实际需要来度量，而不是按模型实际消耗来度量。在他看来，「token 卫生」将是下一个需要被工程化的纪律。