AI 里最贵的 token，往往是那个没必要出现的 token
很多团队一谈 AI 成本优化，第一反应都是：
- 换更便宜的模型
- 降低输出长度
- 调小
max_tokens - 减少请求次数
这些都没错，但很多时候，它们并不是最该优先动的那一层。
真正把账单推高的，常常不是模型本身，而是那些根本没必要被送进上下文的 token。
也就是说，AI 系统里最贵的 token，往往不是模型生成出来的那个，而是系统自己塞进去、但几乎没有创造价值的那个。
这听起来有点反直觉，但只要你拆过几次 production workload 的 token composition，就会发现这几乎是常态。
真正的问题：成本黑洞往往不在 user prompt
有个很典型的例子：
- User prompt：~20 tokens
- System prompt：~900 tokens
- RAG context：~6000 tokens
- Model reply：~400 tokens
总共大约 7320 tokens。
其中用户真正输入的部分，只占：
0.27%
这意味着什么？
意味着在很多真实系统里，用户根本不是成本主体。真正贵的部分，是系统为了“让模型更聪明”而不断往上下文里加的东西：
- 越来越长的 system prompt
- 一股脑塞进去的 RAG 文档片段
- 多轮 pipeline 的中间调用
- 失败后的 retries
- 工具输出的长尾噪音
所以很多 AI 成本问题，本质上不是 model pricing 问题，而是 context engineering 问题。
为什么“无效 token”会越来越多？
这不是某个团队的偶然事故，而是 AI 系统很自然的演化结果。
1. system prompt 会不断膨胀
一个系统上线后，团队总会不停往 system prompt 里补规则：
- 新增安全要求
- 补充输出格式要求
- 加 edge cases
- 修某次事故的 prompt patch
- 加几句“永远不要……”
短期看，每一条都很合理。
长期看，prompt 往往会变成一个没有人真正维护的“规则沉积层”。
问题在于：
- 不是所有规则都还有效
- 不是所有规则都值得每次请求都携带
- 不是所有规则都真的能被模型稳定吸收
于是你每次调用模型，都在为一堆低收益说明书付费。
2. RAG 很容易从 retrieval 退化成 document dumping
RAG 的目标本来是“找最相关的上下文”。
但在很多实现里，最后变成了：
- 查到了 10 段就全塞
- 每段 1000+ tokens
- 不 rerank
- 不做 relevance cutoff
- 不先摘要压缩
这其实不是 retrieval，而是 context dumping。
模型收到的不是“高信号证据”，而是一堆未经筛选的文本块。
结果就是：
- 成本变高
- 延迟变长
- 注意力被稀释
- 回答质量未必更好
最糟糕的是，团队往往还误以为“喂更多信息更安全”。
很多时候，事实正好相反：
喂太多低相关文本，不是在增强模型，而是在稀释模型。
3. pipeline 设计会隐形放大 token 消耗
还有一类浪费，不在单次 prompt 里，而在整个链路结构里。
比如一个请求可能会经历：
- query rewrite
- retrieval
- rerank
- planner
- executor
- final answer
如果每一步都要调模型，那 token 不只是线性增长，而是“多段累加 + 失败重试 + 中间结果回填”。
这时很多团队看的只是单次回复成本，却忽略了真正烧钱的是：
- 一个请求背后到底调用了几次模型
- 哪些调用其实可合并
- 哪些中间步骤根本没必要是 LLM
4. 工具输出和失败重试经常被低估
在 agent 系统里，tool result 往往是另一个大洞。
比如：
- 把整段 HTML 回填给模型
- 把完整日志文件塞回上下文
- 把几十 KB 的 JSON 原样注入
- 失败后自动重试三次
这些 token 看起来不是“prompt 设计”的锅，但最后都会变成账单上的成本。
而且比成本更糟的是，它们会拖累：
- latency
- cache hit
- context window 可用空间
- 后续推理质量
为什么“没必要的 token”不只是成本问题？
这是我觉得最应该被强调的一点。
很多人把 token 优化理解成 FinOps 或 API bill 管理。
但实际上，无效 token 会同时伤害三件事：
1. 钱
这个最直观。
输入 token、输出 token、多轮调用、长上下文，都直接计费。
2. 速度
token 越多：
- prefill 越重
- 传输越慢
- 生成开始得越晚
- 整体响应时间越长
很多用户感知到的“AI 好慢”，并不是模型本身慢，而是你喂了太多不该喂的东西。
3. 质量
这反而最容易被忽略。
上下文不是越大越好。因为 attention 资源不是免费的。
当上下文里充满：
- 冗余规则
- 低相关检索结果
- 长而无结构的工具输出
- 重复中间状态
模型会更难抓住真正重要的 signal。
所以无效 token 的危害，不是只有“贵”，还有：
它会稀释推理注意力，降低有效信息密度。
这就是为什么有些系统把上下文砍掉一半，回答反而更稳。
不是模型突然变聪明了，而是噪音终于少了。
成本优化第一步，不该是换模型，而是拆 token composition
如果你真想看清 AI 系统的成本问题，第一步不该是上来就比模型单价。
第一步应该是拆账：
- user prompt 占多少
- system prompt 占多少
- retrieved context 占多少
- tool outputs 占多少
- intermediate calls 占多少
- retries 占多少
- final response 占多少
如果不先做这件事，后面的优化大概率都是盲修。
因为你根本不知道钱花在哪。
很多团队最后会发现：
- 模型切换节省了 20%
- 但 retrieval + prompt compression 一做，直接省了 50%-80%
这两类优化的 ROI 完全不是一个量级。
高 ROI 的优化，往往是这 4 类
1. 压缩 system prompt
不是所有规则都该在每次调用里携带。
你应该持续问：
- 这条规则还在起作用吗？
- 能不能合并表达？
- 能不能只在特定 workflow 下注入？
- 能不能通过 code / middleware / validation 实现，而不是靠 prompt 记住？
很多 prompt 之所以越来越长，不是因为系统更复杂了，而是因为本该落在程序层的约束，被偷懒塞进了 prompt。
2. 改善 retrieval，只发 top 3–5 chunks
RAG 最常见的浪费不是 recall 不够，而是 recall 太宽。
真正高价值的动作是：
- 更好的 chunking
- 更好的 retrieval 召回
- rerank
- relevance threshold
- top-k 收紧
让模型看到的是“最相关的少量证据”，而不是“可能相关的大量文本”。
3. 长文档先摘要，再送主模型
很多文档并不需要原文直塞。
尤其是：
- 长报告
- 网页正文
- 日志片段
- 历史对话
先做一层压缩、摘要、结构化提炼，往往能显著提升信噪比。
这也是为什么 compaction、context pruning、memory extraction 这些机制越来越重要。
4. 对高频 query 和稳定中间结果做 caching
如果同类问题会被反复问到，就不该每次都从头跑一遍：
- retrieval 结果可缓存
- 摘要可缓存
- 工具结果可缓存
- 结构化转换结果可缓存
缓存不仅省钱，还会提升速度和稳定性。
对 agent 系统尤其重要的一点：最好的 compaction，是根本别把垃圾送进去
这点和最近很多 agent 系统的实践非常吻合。
大家现在越来越重视：
- context pruning
- transcript hygiene
- auto-compaction
- memory extraction
- tool result trimming
但如果再往前走一步，你会发现最理想的状态不是“压缩得很好”，而是：
很多没必要的 token，从一开始就不该进上下文。
换句话说：
- compaction 是补救
- pruning 是减重
- 但最优设计是 源头控流
这和基础设施世界里的原则很像：
- 最便宜的流量，是没发出去的流量
- 最稳的重试，是不需要重试
- 最省的计算，是根本没算那次
放到 AI 这里就是：
最便宜的 token，是从来没被发送的 token。
一个实用 checklist：排查“token 都烧到哪去了”
如果你在看一个 AI workload，可以先用下面这张清单排查：
Prompt 层
- system prompt 是否异常膨胀？
- 是否存在历史补丁不断叠加？
- 是否把本应由程序保证的约束塞进 prompt？
Retrieval 层
- top-k 是否太大？
- chunk 是否过长？
- 是否缺少 rerank？
- 是否整篇文档直接塞入？
Workflow 层
- 一个请求要调几次模型？
- 哪些步骤其实可以不用 LLM？
- 中间结果是否重复注入下游？
Tool / Agent 层
- 是否把超长工具输出原样回填？
- 是否缺少 trimming / summarization？
- retries 比率高不高？
Infra 层
- cache 是否有效？
- GPU / batch 是否有空转？
- latency 变高是模型慢，还是上下文太胖？
这类排查一旦做下来，通常都会发现：
真正昂贵的，不是“模型太贵”，而是“系统太胖”。
结语
AI 成本优化最容易犯的错，就是把注意力全放在模型价格上。
但在真实系统里，很多最贵的东西根本不是模型选择，而是那些：
- 用户没要求
- 模型未必需要
- 团队也没认真治理
却每次都被送进上下文的 token。
所以如果只记一句话，我会记这句：
AI 里最贵的 token，往往不是生成出来的那个，而是那个本来就不该出现的 token。
当你开始用这个视角看系统，很多优化优先级会立刻重排：
- 先做 token composition 分析
- 再做 prompt compression
- 再做 retrieval 收紧
- 再做 caching 和 workflow 精简
- 最后才是模型单价优化
因为很多时候，真正高 ROI 的成本优化，不是换模型，而是减少无意义上下文。
