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

关于 AI API 成本的残酷真相：第一份账单没人觉得惊讶，但第三份账单总会让人大吃一惊。第一份是“哦，四十块，比 Netflix 会员还便宜，还行”。到了第三份就成了“等等，四千两百刀？这到底发生了什么？”

在过去十八个月里，我经历了三次“为什么我们这月的 AI 账单翻了三倍？”的调查——一次是我担任顾问的初创公司，两次是我自己的生产系统。每次的模式都如出一辙：什么都没变。或者更准确地说，没有任何文档记录显示发生了变更。某位队友在系统提示词里多加了一个 few-shot 示例。聊天历史默默地从“最近 5 条”增长到了“最近 20 条”。那个“啊，不管三七二十一全塞进上下文”的模式，让单次调用成本悄然从 $0.003 涨到了 $0.04。再乘以每天 200,000 次调用。欢迎来到第三个月。

以下是我亲身使用过、能把这些账单打下来的十二条策略。大多数策略都能带来两位数的百分比节省，而列表底部那些枯燥的手段往往具有最高的杠杆率。这些策略都不需要你更换供应商或牺牲输出质量。其中有几条要求你真正去衡量 Token 的去向，这恰恰是最大的突破口。我们就从那里开始。

0. 先行度量。务必如此。

在进行任何优化之前，先统计 Token。大多数“让我缩减提示词”的尝试之所以失败，原因是工程师砍错了地方——通常是那些肉眼可见的系统提示词，而真正的罪魁祸首（比如一个 6KB 的工具调用 JSON 架构、冗长的 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 能用百分之一的成本搞定。

解决方案是机械式的。列出你的应用中使用模型的每一项任务。针对每一项，问自己“这项任务在哪个最便宜的档位依然能跑通？”在一个代表性样本上测试这个便宜档位——五十到一百个例子通常足够了。如果质量扛得住，就切换。如果扛不住，就升一个档位再试。我的大多数应用最终都是 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——这带来了大约 18 倍的加权 Token 节省，或者大约 8 倍的总成本节省（因为昂贵的升级依然会拉高平均值，且输出 Token 依然按原价计算）。

陷阱：你必须设计好便宜模型的提示词，使其能够表达不确定性。要求带 logprobs 的单 Token 回答是最干净的方式；明确的分类如“我不确定”或“需要人工审核”也行得通。别试图从自由文本中读出不确定性——模型在这方面会不可靠地含糊其辞。

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

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

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

价格计算示例，针对在 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”这样的代码改动，系统提示词部分的成本大约下降了 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 重新嵌入变更文档：延迟无关紧要，批量没问题。
• Eval 套件运行（针对 500 个 fixture 测试提示词变更）：以前实时跑要 20 分钟；现在要 2 小时但便宜了一半，结果我们跑得更频繁了。反直觉的是，让评估变便宜反而让我们跑得更多，从而提升了提示词质量。

思维转换：停止问“这个能批量吗？”，开始问“这个必须实时吗？”。大多数内部任务其实没必要。

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

5. 用 max_tokens 封顶输出

输出 Token 比输入 Token 贵 4 到 8 倍。GPT-5 上一次失控的 8K Token 输出，成本等同于 64K 的输入。模型没动力长话短说——如果你不限制它，它有时会先给你生成三段废话，比如“作为一个乐于助人的助手，我很乐意……”然后才给答案。

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" 一再出现）。在典型的系统提示词中，仅通过