减半你的 AI API 账单：12 个在 2026 年依然有效的 Token 优化实战技巧

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

在过去一年半里，我经手过三次“为什么我们这个月的 AI 账单翻了三倍？”的调查——一次是在我担任顾问的初创公司，另外两次是在我自己的生产系统中。每次的模式都如出一辙：什么都没变。或者说，没有任何记录下来的变更。某位队友在系统提示词里多加了一组 few-shot 示例。聊天记录默默地从“最近 5 条消息”增长到了“最近 20 条”。那种“啊，直接把所有上下文都塞进去”的模式，默默地让单次调用成本从 $0.003 涨到了 $0.04。再乘以每天 200,000 次调用。欢迎来到账单爆炸的第三个月。

以下是我实际用来把账单降下来的十二个战术。大多数都能带来两位数的百分比节省，而列表底部那些枯燥的手段往往具有最高的杠杆率。这些都不需要切换供应商，也不需要牺牲输出质量。有几条需要你真正去测量 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 为例：

对于简单的分类任务，从 GPT-5 切换到 GPT-5 nano，在大多数用例中质量损失极小的情况下，能实现 25 倍的成本降低。不是 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 依然全价）。

catch：你必须设计便宜模型的提示词，让它能表达不确定性。要求带 logprobs 的单 Token 回答是最干净的方式；“不确定”或“需要审核”作为一个显式类别也行。别试图从自由文本中读出不确定性——模型的规避是不可靠的。

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

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

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

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

• 无缓存： 4,000 × 1,000 × $3/M = $12/小时 输入成本
• 有缓存命中（缓存输入打 1 折）： 4,000 × 1,000 × $0.30/M = $1.20/小时 输入成本（在第一次未缓存的写入之后，这比正常调用稍微贵一点）
• 也就是 系统提示词部分大约下降了 90%，而代码改动仅仅是“在提示词里加个 cache_control。”

catch——这也是团队容易跌跟头的地方——只有当你的前缀在调用之间是字节级完全一致时，缓存才有效。系统提示词里的时间戳、随机打乱的 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 per M；现在批量 $0.625/$5 per M。光那个任务每月省了大概 $4.7K。
• 每周 RAG 重新嵌入变更文档：延迟无关紧要，批量没问题。
• Eval harness 运行（针对 500 个 fixture 测试提示词变更）：以前实时跑要 20 分钟；现在要 2 小时但便宜了 50%，结果我们跑得更频繁了。反直觉的是，让 eval 变便宜反而让我们跑了更多 eval，这提升了提示词质量。

思维转换：停止问“这个能批量处理吗？”，开始问“这个需要实时吗？”大多数内部任务不需要。

唯一真正的缺点是延迟不可预测——“最长 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" 反复出现）。在一个典型的系统提示词中，我看到仅仅通过...