将 AI API 账单减半：2026 年 12 条真正有效的 Token 优化策略

关于 AI API 成本的真相：没人会对第一张账单感到惊讶，但所有人都会被第三张惊到。第一张是“哦，40 美元，比 Netflix 还便宜，没事”。第三张则是“等等，4200 美元？到底发生了什么？”

在过去的十八个月里，我经历了三次“为什么我们这个月的 AI 费用翻倍了？”的调查——一次是在我担任顾问的初创公司，两次是在我自己的生产系统中。每次的情况都如出一辙：什么都没变。或者更准确地说，没有任何人记录下来的变更。一名队友在系统提示词里加了一个额外的 Few-shot 示例。聊天记录悄悄从“最近 5 条”增长到了“最近 20 条”。“啊，全塞进上下文里”的模式默默地将每次调用的成本从 0.003 美元推高到了 0.04 美元。乘以每天 200,000 次调用。欢迎来到第三个月。

以下是我实际使用过的十二种策略，用来把那些账单重新拉下来。大多数策略每次都能带来两位数的百分比节省，而列表底部那些无聊的策略往往具有最高的杠杆效应。它们都不需要切换供应商或牺牲输出质量。有少数策略要求你真正衡量 Token 去了哪里，这是最大的解锁点。让我们从那里开始。

0. 先测量。总是如此。

在优化任何东西之前，先计算 Token。大多数“让我削减提示词大小”的尝试失败的原因是工程师削减了错误的东西——通常是可见的系统提示词，而真正的罪魁祸首（一个 6KB 的工具调用 JSON Schema、一个冗长的 Few-shot 示例，或者一个从周二开始累积的聊天记录）却毫发无损。

不要凭目测。不要相信字符数。Token 和字符不是一回事——对于英文散文，大约 1 个 Token 对应 4 个字符，但范围从 1.5（密集的 Unicode）到 8（空白字符），JSON 介于两者之间。一个“小”提示词可能比看起来要大得多。

使用真正的 Token 计数器。我构建了一个我每天使用的工具——LLM Token 计数器和成本估算器——它支持主要模型，包括 OpenAI 的实际 tiktoken 编码，以及针对 Claude、Gemini、Grok、DeepSeek 和 Llama 的校准估算。粘贴你的提示词，查看计数，查看每次调用的成本，查看哪个场景（聊天 / 分类 / 长文档）落在你的上下文窗口的哪里。仅 Token 可视化就为我节省了数小时的“等等，为什么 getUserById 是六个 Token？”的调试时间。

一旦你有了一个数字，这个列表的其余部分就是决定拉动哪个杠杆。

1. 使用仍然有效的最便宜的模型（通常降一级即可）

我在生产中看到的最大浪费：用旗舰模型处理小模型就能做的工作。

具体数字，截至 2026 年 5 月的 OpenAI：

对于简单的分类任务，从 GPT-5 切换到 GPT-5 nano 可以实现 25 倍的成本降低，且大多数用例的质量损失极小。不是 25%。是二十五倍。人们抗拒这一点，因为“但旗舰更聪明”——是的，并且在不需要它的任务上你正在为这种聪明买单。

我最常看到的错误：团队在第一周选择了一个模型（“我们从最好的开始，这样我们知道质量没问题”），发货了，然后再也没有重新审视。六个月后，他们为“这封邮件是垃圾邮件吗，是或否”的决策支付 GPT-5 的价格，而微调过的 BERT 可以以百分之一的成本处理这些任务。

修复方法是机械性的。列出你的应用程序使用模型的每个不同任务。对于每一个，问“这个任务仍然可行的最便宜层级是什么？”在具有代表性的样本上测试更便宜的层级——五十到一百个示例通常就足够了。如果质量保持住，就切换。如果不保持，升级一个层级并重试。我的大多数应用程序最终在最小的模型上运行 80% 的调用，在旗舰模型上运行 20%。

同样的逻辑也适用于跨供应商。Claude Haiku 4.5 ($1/$5) 处理人们习惯性地发送给 Sonnet 4.6 ($3/$15) 或 Opus 4.7 ($5/$25) 的巨大工作量。Gemini 2.5 Flash-Lite ($0.10/$0.40) 对于大批量分类来说几乎是免费的。对于 DeepSeek 质量可接受的任务（对于许多结构化数据任务来说确实如此），DeepSeek V3 ($0.252/$0.378) 大约比 Claude Sonnet 4.6 便宜 四十倍。

2. 级联路由：先用便宜模型，不确定时再升级

#1 的自然延伸。不要为每个任务选择一个模型；让便宜的模式处理明显的案例，只有在真正需要时才升级到昂贵的那个。

以下是伪代码中的模式：

async function classify(input: string) { // 首先尝试使用便宜模型 const draft = await openai.chat.completions.create({ model: 'gpt-5-nano', messages: [ { role: 'system', content: CLASSIFY_PROMPT }, { role: 'user', content: input } ], logprobs: true, max_tokens: 10 }); const confidence = Math.exp( draft.choices[0].logprobs.content[0].logprob ); if (confidence > 0.85) { return draft.choices[0].message.content; // 便宜模型很确定 } // 仅针对不确定的 ~10-20% 升级到更大的模型 const escalated = await openai.chat.completions.create({ model: 'gpt-5', messages: [ { role: 'system', content: CLASSIFY_PROMPT }, { role: 'user', content: input } ], max_tokens: 10 }); return escalated.choices[0].message.content; } 

在我最近工作的分类系统中，升级率为 14%。这意味着 86% 的调用输入成本为每百万 Token $0.05 而不是 $1.25——输入 Token 大约节省了 18 倍的加权成本，或者总成本大约节省了 8 倍（因为昂贵的升级仍然会拉高平均水平，并且输出 Token 保持全价）。

诀窍在于：你必须设计便宜模型的提示词，使其能够表达不确定性。使用 logprobs 请求单 Token 答案是最干净的方法；“我不确定”或“需要审查”作为显式类别也可以。不要试图从自由文本中读出不确定性——模型会不可靠地进行对冲。

3. 积极使用提示词缓存（缓存输入打一折）

现在每个主要供应商都提供提示词缓存，这是列表中杠杆率最高的优化——前提是你真的正确使用了它。

这个想法很简单：你在每次调用时发送的长系统提示词或文档不需要每次都重新 Token 化和重新处理。供应商缓存前缀；后续调用命中缓存并以正常输入费率的一小部分计费。

价格数学计算，针对典型的 4,000 Token 系统提示词，在 Claude Sonnet 4.6 上每小时调用 1,000 次：

• 无缓存： 4,000 × 1,000 × $3/M = 每小时 $12 的输入成本
• 有缓存命中（缓存输入打一折）： 4,000 × 1,000 × $0.30/M = 每小时 $1.20 的输入成本（在第一次未缓存写入之后，这比正常调用稍微贵一点）
• 对于“在提示词中添加 cache_control”的代码更改，这 大致是系统提示词部分成本下降了 90%。

陷阱——这也是团队绊倒的地方——是 只有当你的前缀在调用之间字节完全相同时，缓存才有效。系统提示词中的时间戳、随机打乱的 Few-shot 示例、靠近顶部拼接的每用户变量——任何这些都会破坏缓存，并且你要支付全价。我看到过团队添加提示词缓存，账单上没有节省，然后得出结论“它坏了”。它没坏；是他们的系统提示词顶部的 Date.now() 在每次调用时都使缓存失效。

修复方法：构建你的提示词，以便可缓存的部分在前，可变的部分在后：

[缓存的前缀 —— 调用之间字节相同] - 系统指令 - 工具定义 - Few-shot 示例 - 长参考文档（RAG 上下文如果它不改变） [用户特定的后缀 —— 每次调用变化] - 当前日期/时间 - 用户 ID / 个性化 - 实际用户消息 

Anthropic 的 cache_control 标记、OpenAI 的自动前缀缓存和 Gemini 的上下文缓存都奖励这种结构。搞错了你就付全价；搞对了你就看着账单隔夜下降。

一个细微差别：缓存 TTL 很短——对于 OpenAI 和 Anthropic 通常为 5 分钟，如果你选择加入则更长。对于低流量端点（每小时几次调用），缓存可能在调用之间过期，你将看不到节省。缓存是一种高批量优化；如果你每天调用 10 次，请跳过它。

4. 对任何非实时任务使用 Batch API（半价）

如果你的工作不需要在用户请求内响应——夜间摘要、每日摘要生成、积压工作的批量重新分类、针对测试集的评估运行——使用 Batch API。全面半价，延迟高达 24 小时。

OpenAI、Anthropic 和 Google 都提供此服务。模式是一样的：提交一个包含所有请求的 JSONL 文件，完成后取回一个 JSONL 文件。

我已经转移到批处理的事情和数学计算：

• 当天客户支持票据的夜间摘要（约 3,000 张票据 × 约 2,000 个输入 Token × 约 400 个输出）：实时运行价格为 $1.25/$10 per M；批处理价格为 $0.625/$5 per M。仅这一项工作每月就节省了约 4,700 美元。
• 每周 RAG 重新嵌入 更改的文档：延迟无关紧要，批处理就可以。
• Eval harness 运行（针对 500 个夹具测试提示词更改）：过去实时需要 20 分钟；现在需要 2 小时但便宜 50%，因此我们更频繁地运行它们。反直觉的是，使评估更便宜让我们运行了更多评估，这提高了提示词质量。

思维转换：停止问“这个可以批处理吗？”，开始问“这个需要实时吗？”大多数内部工作不需要。

唯一真正的缺点是延迟不可预测性——“高达 24h”通常在实践中意味着 30 分钟到 4 小时，但你必须为上限设计。如果你的工作需要在周一早上 9 点完成，请在周日晚上提交。

5. 使用 max_tokens 限制输出

输出 Token 的成本是输入 Token 的 4–8 倍。在 GPT-5 上一次失控的 8K Token 响应成本与 64K Token 输入相同。模型没有简洁的激励——如果你不限制它，它有时会在得到答案之前生成三段“作为一个有用的助手，我很高兴...”。

max_tokens（或 max_output_tokens，取决于 API）是你的上限。设定它。

正确的值取决于任务：

• 分类 / 单标签：20
• JSON 工具调用：200
• 聊天回复：400（大多数助手上限在 300 左右）
• 文档摘要：800
• 代码片段：1,500
• 长表单生成：根据需要，但考虑它是否真的应该是一次调用

过于激进地限制的风险是模型句子中间被切断。缓解措施是监控响应中的 finish_reason 字段——如果是 length 超过约 5% 的时间，你的上限对该任务来说太紧了。如果几乎总是 stop，你的上限就是正确的。

我审计过一些应用程序，在现有调用中添加 max_tokens 将总成本削减了 25%。模型正在为需要 600 的任务生成 3,000 个 Token——纯粹是因为没人告诉它早点停止。

6. 从系统提示词中剥离 JSON

这简直让我抓狂。

我审查的一半系统提示词都有这样的东西：

{ "role": "assistant", "instructions": "You are a helpful assistant.", "rules": [ {"id": 1, "rule": "Always be polite"}, {"id": 2, "rule": "Cite sources when possible"}, {"id": 3, "rule": "If unsure, say 'I don't know'"} ], "examples": [ {"input": "...", "output": "..."} ] } 

每个 {、}、[、]、"、,、: 都是它自己的 Token。JSON 键重复（"input"、"output"、"rule" 一次又一次地出现）。在我看到的典型系统提示词上，仅通过