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

关于 AI API 成本的残酷真相：第一份账单从不出意料，但第三份账单总会让人大吃一惊。第一份账单通常是“哦，40 美元，比 Netflix 会员还便宜，没关系”。到了第三份账单就变成了“等等，4200 美元？到底发生了什么？”

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

以下是我实际上使用过的十二个策略，成功把这些费用打了下来。大多数策略都能带来两位数的百分比节省，而列表底部那些枯燥的方法往往杠杆率最高。这些都不需要切换供应商，也不需要牺牲输出质量。有几点需要你真正去衡量 Token 到底去哪儿了，这才是最大的突破口。我们就从那儿开始。

0. 先测量，这是铁律。

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

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

用一个真正的 Token 计数器。我构建了一个每天都在用的工具——LLM Token Counter & Cost Estimator——它支持主流模型，针对 OpenAI 使用了真实的 tiktoken 编码，并对 Claude、Gemini、Grok、DeepSeek 和 Llama 提供了校准后的估算。粘贴你的提示词，查看计数，查看单次调用成本，看看哪种场景（聊天/分类/长文档）落在了你上下文窗口的哪个位置。光是这个可视化功能就为我节省了数小时的调试时间，那种“等等，为什么 getUserById 占了 6 个 Token？”的疑惑。

一旦你有了具体数字，这份列表剩下的部分就只是决定拉哪个杠杆了。

1. 使用能干活的最便宜模型（通常低一个档位就行）

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

具体数字，以 OpenAI 2026 年 5 月的价格为例：

对于简单的分类任务，从 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——输入 Token 大约节省了 18 倍，或者总成本节省了约 8 倍（因为昂贵的升级仍然会拉高平均值，且输出 Token 仍按全价计算）。

关键点：你必须设计便宜模型的提示词，让它能表达不确定性。要求使用 logprobs 给出单 Token 回答是最干净的方式；将“我不确定”或“需要审核”作为一个显式类别也可以。别试图从自由文本中读取不确定性——模型的估测并不可靠。

3. 积极利用提示词缓存（缓存输入仅需 10% 的钱）

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

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

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

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

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

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

[CACHED PREFIX — calls across byte-identical] - 系统指令 - 工具定义 - 少样本示例 - 长参考文档（如果不变则包含 RAG 上下文） [USER-SPECIFIC SUFFIX — varies per call] - 当前日期/时间 - 用户 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 输入 tokens × 约 400 输出）：以前实时跑 $1.25/$10 per M；现在批处理 $0.625/$5 per M。仅这一项工作每月节省约 4,700 美元。
• 每周 RAG 重新嵌入 更改的文档：延迟无关紧要，批处理没问题。
• 评估工具运行（针对 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" 反复出现）。在我看到的典型系统提示词中，光是