削减一半的 AI API 账单：2026年实测有效的 12 个 Token 优化策略

关于 AI API 费用的真相：没人会对第一笔账单感到意外，但所有人都会被第三笔震惊。第一单通常是“哦，40刀，比 Netflix 便宜，没事”。到了第三单就变成了“等等，4200刀？到底发生了什么？”

过去十八个月里，我经历过三次“为什么我们这个月的 AI 账单翻了三倍？”的调查——一次是在我担任顾问的初创公司，另外两次在我自己的生产系统中。每次的模式都一样：什么都没变。或者更准确地说，没有任何文档记录的东西发生了改变。某位队友在系统提示词里多加了一个 few-shot 示例。聊天历史悄悄从“最近 5 条消息”膨胀到了“最近 20 条”。那种“管他呢，全扔进上下文里”的模式，默默地把单次调用成本从 0.003 美元拉升到了 0.04 美元。再乘以每天 20 万次调用。欢迎来到第三个月。

以下是我亲自用过、能有效把账单拉回来的十二条策略。大部分策略能带来两位数的百分比节省，而列表底部那些枯燥的方法往往杠杆率最高。这些都不需要你更换供应商或牺牲输出质量。其中有几条要求你实际测量 Token 都去哪儿了，这可是最关键的解锁点。我们就从这儿开始。

0. 先测量。必须的。

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

别靠目测。别信字符数。Token 和字符不是一码事——对于英文散文，大约 4 个字符对应 1 个 Token，但范围从 1.5（密集的 Unicode）到 8（空白字符）不等，JSON 处于中间位置。一个“小”Prompt 可能比看起来要大得多。

用一个真正的 Token 计数器。我做了一个每天在用的——LLM Token Counter & Cost Estimator——它支持主流模型，针对 OpenAI 使用了真正的 tiktoken 编码，并对 Claude、Gemini、Grok、DeepSeek 和 Llama 做了校准估算。贴入你的 Prompt，看计数，看单次调用成本，看哪个场景（聊天/分类/长文档）落在你的上下文窗口哪里。光是 Token 可视化就帮我节省了数小时的“等等，为什么 getUserById 占了六个 token？”的调试时间。

一旦你有了数据，这份列表剩下的部分就是决定拉动哪根杠杆。

1. 使用能用的最便宜模型（通常只需降一级）

我在生产环境中看到的最大浪费：用旗舰模型干小模型能干的活。

具体数据，截至 2026 年 5 月的 OpenAI 价格：

对于一个简单的分类任务，从 GPT-5 切换到 GPT-5 nano，成本能降低 25 倍，而在大多数用例中质量损失微乎其微。不是 25%。是二十五倍。人们抗拒这一点是因为“旗舰机型更聪明”——没错，但你在不需要聪明才智的任务上为那份聪明买单了。

最常见的错误：团队在第一周选了一个模型（“先用最好的，确保质量没问题”），然后上线了，之后就再也没看过。六个月后，他们为了判断“这封邮件是不是垃圾邮件，是或否”这种决策支付着 GPT-5 的价格，而其实一个微调过的 BERT 就能以百分之一的成本搞定。

解决办法是机械的。列出你的 App 使用模型的每一个不同任务。对每一个任务问：“这个任务至少能在哪个便宜的层级上运行？”在一个代表性样本上测试更便宜的层级——五十到一百个例子通常就够了。如果质量稳住了，就切换。如果不稳，升一级再试。我的大多数应用最终都是 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 V3 ($0.252/$0.378) 大约比 Claude Sonnet 4.6 便宜四十倍，在 DeepSeek 质量可接受的任务上——对于很多结构化数据任务来说，确实如此。

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 依然全价）。

注意事项：你必须设计便宜模型的 Prompt，以便它能表达不确定性。要求使用带 logprobs 的单 Token 回答是最干净的方式；明确的“我不确定”或“需要审核”类别也行。别试图从自由文本中解读不确定性——模型的模棱两可是不可靠的。

3. 极致利用 Prompt 缓存（缓存输入打 1 折）

现在每家主流供应商都提供 Prompt 缓存，这是这份列表中杠杆率最高的优化——前提是你得用对。

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

以在 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/小时输入成本（在第一次未缓存写入之后，那次写入比正常调用略贵）
• 这相当于为了一个“添加 cache_control 到你的 Prompt”的代码改动，系统提示词部分成本下降了约 90%。

陷阱——也是团队容易栽跟头的地方——在于只有当你的前缀在调用之间字节完全一致时，缓存才有效。系统提示词里的时间戳、随机打乱的 few-shot 示例、拼接在顶部的每用户变量——这些任何一个都会破坏缓存，让你支付全额费用。我见过团队加上了 Prompt 缓存，却发现账单没省，得出结论“这玩意儿坏了”。其实没坏；是他们在系统提示词顶部的 Date.now() 每次调用都让缓存失效了。

解决办法：构建你的 Prompt，让可缓存的部分排在前面，可变的部分排在最后：

[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 per M，现在批处理是 $0.625/$5 per M。光这一项工作每月就省了约 $4.7K。
• 每周 RAG 重新嵌入 变更的文档：延迟无关紧要，批处理没问题。
• Eval harness 运行（针对 500 个 fixture 测试 Prompt 变更）：以前实时跑要 20 分钟；现在要 2 小时但便宜了 50%，结果我们跑得更频繁了。反直觉的是，让评估变便宜反而让我们跑了更多评估，从而提高了 Prompt 质量。

思维转换：别问“这个能批处理吗？”，开始问“这个必须实时吗？”大多数内部任务都不必。

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

5. 用 max_tokens 限制输出

输出 Token 的价格比输入 Token 贵 4 到 8 倍。GPT-5 上一次失控的 8K Token 输出响应，成本等同于 64K 的输入。模型没 incentive 简洁——如果你不限制它，它有时会在给出答案前生成三段废话，比如“作为一个乐于助人的助手，我很乐意……”。

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

正确的值取决于任务：

• 分类 / 单标签：20
• JSON 工具调用：200
• 聊天回复：400（大多数助手在 300 左右就到顶了）
• 文档摘要：800
• 代码片段：1,500
• 长文生成：按需，但要考虑是不是真的该一次搞定

限制得太 aggressive 的风险是模型话没说完就被截断。缓解措施是监控响应中的 finish_reason 字段——如果 length 出现的频率超过约 5%，说明你的上限对该任务来说太紧了。如果几乎总是 stop，那就对了。

我审计过一些应用，仅给现有调用加上 max_tokens 就把总成本削减了 25%。模型生成 3,000 个 Token 去干只需要 600 的活——纯粹因为没人让它早点停下。

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% 的缩减。