Headroom 式 LLM Token 优化：降低上下文成本但不牺牲答案质量

快速结论

LLM 成本优化不应该从盲目压缩开始，而应该从上下文质量开始。Headroom 式优化器位于应用和模型之间，负责移除低价值上下文、压缩嘈杂工具输出、复用稳定 prompt 片段，并在质量允许时把简单任务路由到更便宜的模型。

目标不是“不惜一切减少 token”，而是：

• 答案质量保持稳定。
• 安全和权限指令不被改写。
• 减少重复、无关、机器生成的上下文。
• 用同一批测试集衡量节省和回归。
• 渐进上线，并保留观测和回滚。

如果你的 prompt 经常包含长日志、JSON、搜索结果、RAG 片段或完整历史对话，上下文优化很值得测试。

---

Token 浪费通常来自哪里？

浪费来源	例子	更好的做法
重复系统提示	每轮都发送同一段策略	缓存或缩短稳定指令
嘈杂工具输出	完整日志、堆栈、HTML、JSON dump	只提取当前任务需要的字段
过大的 RAG 片段	检索 20 段，但真正有用 4 段	rerank 后积极裁剪
过长历史对话	从第一轮开始全部发送	按时间和相关性窗口化或摘要
错误模型路由	简单分类也发给大模型	简单任务使用小模型
无边界重试	失败后反复发送完整上下文	增加重试预算和中间结果缓存

---

更安全的优化架构

用户请求
  -> 输入规范化
  -> 上下文选择
  -> 工具/RAG 输出清理
  -> prompt 组装
  -> 缓存查找
  -> 模型路由
  -> 模型调用
  -> 质量和成本日志

每一层都应该可度量、可单独关闭。

---

第一层：上下文选择

上下文选择决定模型真正需要看到什么。

适合移除：

• 重复指令。
• 已不相关的旧对话。
• 低相似度或低 rerank 分数的检索文档。
• 当前任务用不到的工具输出字段。
• 重复堆栈和重复日志行。

不要移除：

• 安全和权限指令。
• 用户约束。
• API 契约。
• 业务规则。
• 审计和引用需要的数据来源。

type ContextBlock = {
  id: string;
  source: "system" | "user" | "tool" | "rag" | "memory";
  text: string;
  score?: number;
  required?: boolean;
};

function selectContext(blocks: ContextBlock[], maxBlocks = 8) {
  const required = blocks.filter((block) => block.required);
  const optional = blocks
    .filter((block) => !block.required)
    .sort((a, b) => (b.score ?? 0) - (a.score ?? 0))
    .slice(0, maxBlocks);

  return [...required, ...optional];
}

---

第二层：工具输出压缩

工具输出往往是最容易浪费 token 的地方。日志、JSON、HTML、数据库行、CLI 输出，都应该在进入模型前转成任务相关摘要。

工具输出	建议发送
重复 200 次的堆栈	唯一错误、关键栈帧、首次/末次出现
500 行数据库结果	聚合、异常、样本行
原始 HTML	文本、链接、标题、元数据
完整 API JSON	当前任务需要的字段
测试日志	失败测试名、断言、相关错误块

这种“按任务清理”比通用压缩更安全，因为它保留了证据。

---

第三层：Prompt 缓存

很多 prompt 包含稳定部分：系统指令、产品规则、schema、风格指南、工具说明。把稳定块和动态上下文分开，才能更好复用。

稳定部分：
  - system policy
  - output schema
  - product rules
  - tool descriptions

动态部分：
  - 当前用户请求
  - 选中的历史
  - 选中的检索片段
  - 当前工具输出

即使模型供应商没有提供 prompt cache，应用层也可以缓存检索、rerank 和摘要结果。

---

第四层：模型路由

当任务复杂度有明确层级时，模型路由可以降低成本。

请求类型	常见路由
分类、抽取、简单改写	小模型/快模型
短上下文检索问答	中等模型
复杂推理、代码、法律审查	更强模型
安全或资金相关动作	强模型 + 人工审批

路由必须基于评测，而不是直觉。便宜模型不确定或校验失败时，应回退到更强模型。

---

先衡量质量，再谈节省

指标	为什么重要
输入 token	直接成本来源
输出 token	直接成本来源
任务成功率	最核心质量信号
人工修正率	揭示隐性质量下降
校验失败率	捕捉 schema 和事实回归
升级率	判断路由是否过激
延迟	压缩本身可能增加耗时
每个成功任务成本	比单请求成本更有意义

用真实流量或历史样例做 A/B，对比优化版和基线版输出，再扩大上线。

---

上线计划

1. 按功能、路由、工具记录 token 使用。
2. 选择一个高流量、低风险工作流。
3. 先加入上下文选择。
4. 再加入工具输出清理。
5. 缓存稳定 prompt 组件。
6. 有校验后再加入模型路由。
7. 按百分比灰度。
8. 为每个功能保留关闭开关。

不要从退款、删号、医疗、法律、安全自动化等高风险任务开始。

---

常见问题

Token 优化能节省 50% 以上吗？

有可能，尤其是 prompt 里包含重复日志、大型 JSON 或过量检索上下文时。但节省幅度取决于业务负载，必须测自己的基线。

上下文压缩安全吗？

在保护必要指令、校验输出、渐进上线的前提下可以安全。盲目压缩很危险。

所有任务都应该用小模型吗？

不应该。简单任务可以用小模型，复杂推理、高风险决策和模糊请求仍需要强模型或人工审核。

---

总结

Headroom 式 token 优化本质上是上下文工程：选择更好的上下文，清理嘈杂工具输出，缓存稳定 prompt，按任务风险路由模型，并在节省成本前先验证质量。做得好可以降低成本和延迟；做得粗暴，则可能删除模型真正需要的信息。