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

关于 AI API 成本的残酷真相：没人会对第一张账单感到惊讶。但每个人都会被第三张账单震惊。第一张是“哦，四十美元，比 Netflix 订阅费还便宜，还行”。第三张则是“等等，四千二百美元？到底发生了什么？”

在过去的十八个月里，我亲身经历了三次“为什么我们本月的 AI 账单翻了三倍？”的调查——一次是在我担任顾问的初创公司，两次是在我自己的生产系统中。每次的模式都一样：什么都没变。或者说，没有任何书面记录显示有任何改变。一位队友在系统提示词中多加了一个 few-shot 示例。聊天记录悄悄从“最近 5 条消息”增长到了“最近 20 条”。“啊，直接把所有东西都塞进上下文”的模式让每次调用的成本从 $0.003 无声无息地变成了 $0.04。乘以每天 200,000 次调用。欢迎来到第三个月。

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

0. 先测量。永远如此。

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

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

使用真正的 Token 计数器。我构建了一个我每天都会用的工具——LLM Token Counter & Cost Estimator——它支持主流模型，对 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. 积极使用提示词缓存（缓存输入享受 90% 折扣）

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

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

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

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

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

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

[CACHED PREFIX — 调用之间字节完全相同] - 系统指令 - 工具定义 - Few-shot 示例 - 长参考文档（如果 RAG 上下文不改变） [USER-SPECIFIC SUFFIX — 每次调用不同] - 当前日期/时间 - 用户 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 重新嵌入更改的文档：延迟无关紧要，批处理没问题。
• 测试评估工具运行（针对 500 个 fixtures 测试提示词更改）：以前实时需要 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 个 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" 一次又一次地出现）。在我看到的典型系统提示词中，仅通过