如何让 AI API 账单减半：2026 年 12 个真正有效的 Token 优化策略

关于 AI API 成本的真相：没人会对第一笔账单感到惊讶，但大家对第三笔账单都吓一跳。第一次看到账单你会想：“噢，四十美元，比 Netflix 还便宜，没问题。”到了第三个月：“等等，四千二百美元？到底发生了什么？”

在过去的十八个月里，我经历了三次“为什么我们这个月的 AI 费用翻了三倍？”的调查——一次是在我担任顾问的初创公司，两次是在我自己的生产系统中。每次的模式都一样：什么都没变。或者更准确地说，没有任何人记录下来的变更。队友在系统提示词里多加了一个 few-shot 示例。聊天记录悄悄从“最近 5 条”增长到了“最近 20 条”。“反正都塞进上下文里吧”的模式让单次调用成本从 $0.003 静默变成了 $0.04。再乘以每天 20 万次调用。欢迎来到第三个月。

以下是我实际使用过的 12 种策略，用来把那些账单降下来。大多数策略每次都能带来两位数的百分比节省，而列表底部那些枯燥的方法往往杠杆率最高。这些都不需要切换供应商或牺牲输出质量。有几种策略要求你实际测量 Token 都去哪了，这是最大的突破口。我们就从那里开始。

0. 先测量。永远如此。

在优化任何东西之前，先计算 Token。大多数“让我精简一下提示词”的尝试之所以失败，是因为工程师切错了地方——通常是切掉了可见的系统提示词，而真正的罪魁祸首（一个 6KB 的工具调用 JSON Schema、冗长的 few-shot 示例，或者从周二就开始累积的聊天记录）却原封不动。

不要靠目测。不要相信字符数。Token 和字符不是一回事——对于英文散文，大约 4 个字符等于 1 个 Token，但范围从 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 能以百分之一的成本处理的任务。

修复方法是机械性的。列出你的应用使用模型的所有不同任务。对于每一个任务，问“这是能用的最低档次是什么？”在有代表性的样本上测试更便宜的档次——通常 50 到 100 个例子就足够了。如果质量达标，就切换。如果不达标，提高一个档次再试一次。我的大多数应用最终 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% 的调用输入成本为 $0.05/M，而不是 $1.25/M——输入 Token 的加权节省大约是 18 倍，或者总成本大约是 8 倍（因为昂贵的升级仍然会拉高平均水平，而输出 Token 仍然是全价）。

需要注意的是：你必须设计便宜模型的提示词，以便它能表达不确定性。使用带有 logprobs 的单 Token 回答是最干净的方法；将“我不确定”或“需要审查”作为一个明确的类别也行。不要试图从自由文本中读取不确定性——模型的推测并不可靠。

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

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

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

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

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

陷阱——这也是团队容易绊倒的地方——是 缓存只有在你的前缀在调用之间是字节一致的情况下才有效。系统提示词中的时间戳、随机打乱的 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 每 M；现在批处理价格为 $0.625/$5 每 M。仅这一项工作每月就节省了大约 $4.7K。
• 每周 RAG 重新嵌入 更改的文档：延迟无关紧要，批处理没问题。
• Eval harness 运行（针对 500 个固定装置测试提示词更改）：以前实时需要 20 分钟；现在需要 2 小时但便宜 50%，而且我们因此更频繁地运行它们。反直觉的是，让评估变得更便宜让我们运行了更多评估，这提高了提示词质量。

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

唯一真正的缺点是延迟不可预测性——“高达 24 小时”实际上在实践中通常意味着 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 Token 的任务生成了 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" 一次又一次地出现）。在一个典型的系统提示词中，我看到仅通过 20-30% 的减少