砍掉 API 账单

先测量，再优化。按功能分组，记录每次请求的输入和输出 token，答案通常很明显，也通常不是你以为的那个。

下面四个杠杆按通常能省下的钱排序。

1 · 模型档位

几乎总是最大的因素。不同档位的价格相差一个数量级甚至更多，所以把高流量的任务挪低一档，胜过其他所有优化加起来。

行之有效的模式：先用小模型，只在实测失败时升级。抽取、分类和路由很少需要前沿模型，为它们付前沿模型的价格，是生产环境里最常见的可避免成本。

更好的做法是按任务路由——机械步骤用便宜模型，只在推理真正要紧的地方用贵模型。

2 · 对话历史

悄悄掏空预算的那一个。因为模型在两次调用之间没有记忆，每一轮都要把整份对话记录重新发一遍。一场 n 轮对话的总 token 数按 n² 增长，不是 n。

二十轮对话不是十轮的两倍，而是大约四倍。

修法：

**有意给历史设上限。**保留 system prompt 加上最近几轮。这个决定要你自己做，别让框架悄悄截断。

**总结较早的轮次。**用一段紧凑的摘要替换早期历史。会丢细节，但能延长可用对话的长度。

**话题变了就重新开始。**用户在第 30 轮聊别的事情时，很少还需要第 3 轮。

3 · prompt 缓存

服务商可以缓存 prompt 前缀处理后的形式。重复的前缀因此跳过 prefill，计费上有大幅折扣。

机制是 KV cache 复用：开头相同的 token 会产生相同的 key 和 value，所以算一次就能反复使用。

由此得到一条具体的结构规则：稳定的内容放前面，变化的内容放后面。

[system prompt]        ← 固定、已缓存
[少样本示例]           ← 固定、已缓存
[检索到的文档]         ← 每次查询都变
[用户问题]             ← 每次查询都变

把这个顺序倒过来，什么都缓存不到。这是最便宜的优化，而且纯粹是排序问题。

两个注意点：缓存是精确前缀匹配，前面改一个字符就会让后面全部失效——永远不要把时间戳放在 system prompt 开头。另外缓存过期很快，收益取决于请求频率。

4 · token 用量

输入和输出越小越便宜，而输出 token 比输入 token 贵。

把 max_tokens 卡在你需要的量上。「用两句话回答」再加一个低上限，在量大时就是真金白银。

少检索几个文本块。检索增强生成（RAG）的上下文是每次调用都要付的输入 token。五个够用时取二十个，成本永远是四倍——而且重排序通常能让五个比二十个更准。既便宜又更准。

**搞清楚哪些少样本示例真正起作用之后，就把别的删掉。**每个示例都是每次请求都要付的 token。

在推理没用的地方跳过推理。思维链会成倍增加输出 token，而输出 token 是贵的那种。难题推理值得，查找和格式化就是浪费。

两个结构性选项

**响应缓存。**如果同一个问题反复出现，就把答案缓存在你自己的层里，完全跳过模型。用得上就是免费。精确匹配缓存很简单；语义缓存——用 embedding 相似度匹配近似重复的问题——命中更多，但风险是把答案给了一个有细微差别的问题。

**批量 API。**多家服务商为异步处理提供大幅折扣，代价是完成时间有延迟。如果没有东西在等结果——比如每晚的分类、批量丰富数据——这是笔很大的节省，而且不损质量。

不要做的事

**不要把 prompt 压缩成看不懂的缩写。**省得不多，质量损失却是真的。

**不要为了省 token 去掉结构化输出的约束。**解析失败和重试花掉的钱比那份 schema 更多。

**不要过度总结历史，把对话搞断。**用户重复一遍问题，产生的请求比省下来的还多。

**不要在测量之前动手优化。**各功能之间的成本分布，每次都出人意料。

要点回顾

• 先按功能测 token 用量；最大的成本很少在你以为的地方。
• 模型档位是最大的杠杆，其次是对话历史——它按平方增长，通常是那个隐藏问题。
• prompt 缓存几乎免费：稳定内容在前、变化内容在后，开头永远不放时间戳。
• 少检索几个文本块，既更便宜，通常也更准。
• 响应缓存和批量 API 在适用处能直接消掉成本。

下一篇： 你怎么知道它管用？