如何让你的 AI API 账单减半：2026 年 12 个切实可行的 Token 优化策略

关于 AI API 成本的真相：没人会对第一张账单感到意外，但所有人都会被第三张账单震惊。第一张是“哦，四十美元，比 Netflix 会员还便宜，无所谓”。第三张则是“等等，四千两百美元？到底发生了什么？”

过去十八个月里，我经历了三次“为什么我们这个月的 AI 账单翻了三倍？”的调查——一次是我担任顾问的初创公司，两次是我自己的生产系统。每一次的剧情都如出一辙：什么都没变。或者更准确地说，没有任何被记录下来的变更。某位队友给系统提示词多加了一个 few-shot 示例。聊天历史静悄悄地从“最近 5 条消息”膨胀到了“最近 20 条”。“啊，直接把所有东西都塞进上下文”的模式让单次调用成本从 0.003 美元无声无息地涨到了 0.04 美元。再乘以每天 20 万次调用。欢迎来到第三个月。

以下是我亲测有效的十二个策略，能把那些失控的账单拉回现实。大多数策略每次都能带来两位数的百分比节省，而列表底部那些枯燥的手段往往杠杆率最高。所有策略都不需要切换服务商或牺牲输出质量。其中有几项需要你切实地测量 Token 到底花哪儿去了，这才是最大的解锁点。让我们从那里开始。

0. 先测量。永远如此。

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

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

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

一旦你有了数据，剩下的列表就是决定拉动哪个杠杆。

1. 使用能用的最便宜模型（通常低一档就够了）

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

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

在简单的分类任务上从 GPT-5 切换到 GPT-5 nano，意味着在大多数用例中，成本降低 25 倍而质量几乎无损。不是 25%。是二十五倍。人们抗拒这一点，理由是“但旗舰模型更聪明”——没错，但你在不需要这种聪明的任务上为聪明付了费。

我最常犯的错误：团队在第一周选了一个模型（“我们要先用最好的，确保质量没问题”），然后上线，之后就再也不回顾了。六个月后，他们还在付 GPT-5 的价格来处理“这封邮件是不是垃圾邮件，是或否”这种决策——这种任务微调后的 BERT 只要百分之一的成本就能搞定。

解决办法是机械性的。列出你应用中使用模型的每个不同任务。对每一个任务，问“这个任务最低能在这个档位上正常运行吗？”在一个代表性样本上测试更便宜的档位——通常 50 到 100 个例子就足够了。如果质量能守住，就切换。如果守不住，就升一档再试。我的大多数应用最终都在最小模型上运行 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% 的调用的输入成本是每百万 Token $0.05 而不是 $1.25——加权输入成本节省约 18 倍，或者总成本节省约 8 倍（因为昂贵的升级仍然会拉高平均水平，且输出 Token 依然是全价）。

诀窍在于：你必须设计便宜模型的提示词，使其能够表达不确定性。要求带有 logprobs 的单 Token 回答是最干净的方法；将“我不确定”或“需要审查”作为一个显式类别也可以。不要试图从自由文本中读取不确定性——模型在这方面会不可靠地闪烁其词。

3. 积极使用提示词缓存（缓存输入折扣 90%）

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

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

定价数学题，以在 Claude Sonnet 4.6 上每小时调用 1000 次的典型 4000 Token 系统提示词为例：

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

陷阱——这也是团队容易绊倒的地方——是只有当你的前缀在每次调用之间字节完全一致时，缓存才有效。系统提示词里加了时间戳？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；现在是批处理每百万 $0.625/$5。仅这一项工作每月就省了约 $4,700。
• 每周 RAG 重新嵌入变更文档：延迟无关紧要，批处理没问题。
• Eval harness 运行（针对 500 个 fixture 测试提示词更改）：以前实时运行需要 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 的任务生成了 3000 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% 的减少。

7. 用 logit_bias 稍微调教模型

高级技巧，但能省大钱。你可以禁止模型生成特定 Token（例如停止词、JSON 键或仅仅是废话），从而将输出集中在有用内容上。

例如，如果你有一个分类任务，并且你知道有效的输出只有“肯定”和“否定”，你可以将 logit_bias 设置为将“也许”、“可能”或“我不确定”的 logits 设为负无穷。模型学会直接跳过废话，直接给出答案。

在数据集上，这使我的输出 Token 量减少了约 40%，因为模型停止生成“基于您的电子邮件……”之类的前缀。

8. 使用更小、更快的工具模型

如果你在大量调用工具（例如搜索、数据库查询、API），请使用较小、更快的模型作为“路由器”或“工具选择器”。

大模型擅长生成有效载荷；小模型擅长选择要调用哪个工具。为什么要用 GPT-5 来决定是调用 getWeather 还是 getStockPrice？

在最近的 Agent 架构中，我将工具选择卸载到了一个小模型，将成本降低了 60%，同时将延迟降低了 70%。大模型仍然执行实际的工作（生成 SQL、分析数据），但路由是免费的。

9. 减少 few-shot 示例（或完全删除它们）

Few-shot 示例非常棒，但它们很昂贵。每个示例都是数百个重复每个提示词的 Token。

现代模型比 2024 年的模型好得多；它们在不需要手把手教的情况下理解指令的能力也要强得多。尝试删除你的示例，只留下清晰的指令。如果质量下降，把最有效的那个加回来。通常，一两个精心挑选的例子就足够了。

在我审查的一个系统中，删除 10 个示例并替换为 3 条清晰的规则将成本降低了 35%，而没有损失准确性。

10. 将静态文档移至 Retrieval（RAG）而不是 Context

停止在系统提示词中粘贴整篇手册、整个代码库或整份 PDF。这很浪费。

使用检索。将文档存储在向量数据库中（甚至只是全文搜索），并且仅将与当前用户查询相关的块注入到上下文中。

在一个聊天机器人中，将上下文从“整个知识库”（500k Token）切换到“检索到的前 3 个块”（2k Token）使每次调用的成本降低了 250 倍，同时提高了答案的相关性。

11. 流式传输（用于延迟），但批量处理（用于成本）

流式传输在用户体验（UX）方面很棒，但如果没有保存在任何地方，它有时会鼓励冗长的输出（用户不会等待）。对于非交互式任务，请坚持使用标准 API。

等等，实际上，就成本而言，流式传输与普通 API 相同。这里的真正教训是：不要流式传输只是为了在内部日志中查看结果。流式传输是为了用户。

12. 审计你的日志

这是最无聊但最有效的一步。

下载过去一周的 API 日志。查看 max_tokens 使用情况、模型选择和提示词大小。

你会惊讶地发现有多少次调用使用了 gpt-5，而本来用 gpt-5-mini 就可以了。你会惊讶地发现有多少调用因长度限制而中止。

我就是这样发现“12 月以来累积的聊天历史”问题的——通过查看日志并注意到 prompt_tokens 周期性地跳涨。

最后，这里有一个令人清醒的现实：优化 API 成本是一场永无止境的游戏。模型会变得更便宜，但我们会找到更多使用它们的方法。唯一真正的杠杆是自律。衡量、切断、自动化。