AI API账单减半：2026年12个Token优化技巧｜OpenAI、Claude、Gemini

2026年实战指南：12个让AI API账单减半的Token优化策略

关于AI API费用的真相：第一笔账单没人会惊讶，但到了第三笔，所有人都会大吃一惊。第一单是“噢，四十刀，比Netflix还便宜，没事”。第三单就变成了“等等，四千二百刀？到底发生了什么？”

在过去十八个月里，我经历了三次不同的“为什么我们这个月的AI费用翻了三倍？”的调查——一次是在我担任顾问的初创公司，两次是在我自己的生产系统中。每次的罪魁祸首都一样：什么都没变。或者说，没有任何书面记录显示有什么变化。队友只是在系统提示词里多加了一个Few-shot示例。聊天记录悄无声息地从“最近5条消息”变成了“最近20条”。“啊，把上下文全扔进去吧”这种模式，让单次调用成本从0.003美元默默涨到了0.04美元。再乘以每天20万次调用。欢迎来到你的第三个月。

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

0. 先测量。永远如此。

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

别凭目测。别相信字符数。Token和字符不是一回事——对于英文散文，大约是1个Token对应4个字符，但这范围从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：

Model	Input $/M	Output $/M	When
GPT-5	$1.25	$10.00	Hard reasoning, complex tool calls
GPT-5 mini	$0.25	$2.00	Most chat, summarization, RAG synthesis
GPT-5 nano	$0.05	$0.40	Classification, intent detection, formatting

对于一个简单的分类任务，从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) {
  // First try with the cheap model
  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; // cheap model was sure
  }

  // Escalate to the bigger model only for the uncertain ~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. 积极使用提示词缓存（缓存输入享受90%折扣）

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

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

定价数学，对于一个典型的4,000 Token的系统提示词，在Claude Sonnet 4.6上每小时调用1,000次：

Without caching: 4,000 × 1,000 × $3/M = $12/hour input cost
With cache hits (90% off cached input): 4,000 × 1,000 × $0.30/M = $1.20/hour input cost（在第一次未缓存的写入之后，这比正常调用略贵）
对于“添加cache_control到你的提示词”这样的代码更改，系统提示词部分的成本大约下降了90%。

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

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

[CACHED PREFIX — byte-identical across calls]
- System instructions
- Tool definitions
- Few-shot examples
- Long reference documents (RAG context if it doesn't change)

[USER-SPECIFIC SUFFIX — varies per call]
- Current date/time
- User ID / personalization
- The actual user message

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

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

4. 对任何非实时任务使用Batch API（50%折扣）

如果你的工作不需要在用户请求内响应——夜间总结、每日摘要生成、积压的批量重新分类、针对测试集的评估运行——使用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.7K美元。
每周RAG重新嵌入更改的文档：延迟无关紧要，批处理没问题。
Eval harness runs（针对500个夹具测试提示词更改）：以前需要20分钟实时运行；现在需要2小时但便宜50%，结果我们运行得更频繁了。违反直觉的是，让评估更便宜让我们运行了更多评估，这提高了提示词质量。

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

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

5. 用`max_tokens`限制输出

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

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

正确的值取决于任务：

分类 / 单标签：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%……