AI API账单减半：2026年降本必看的12条调优技巧｜OpenAI、Claude、Gemini

如何将您的 AI API 账单减半：2026 年 12 个经过验证的 Token 优化策略

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

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

以下是我亲自使用过、能有效压低账单的十二种策略。大多数策略能带来两位数的百分比节省，而列表底部那些枯燥的手段往往具有最高的杠杆效应。这些策略都不需要更换供应商，也不需要牺牲输出质量。有几点需要你真正去衡量 Token 到底流向了何处，这才是最大的突破口。我们就从那里开始。

0. 先衡量，务必如此。

在优化任何东西之前，先统计 Token。大多数“让我精简一下提示词”的尝试之所以失败，是因为工程师删错了地方——通常是删减可见的系统提示词，而真正的罪魁祸首（比如 6KB 的工具调用 JSON Schema、冗长的 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. 使用能满足需求的最便宜模型（通常低一个档位就够了）

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

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

Model	Input $/M	Output $/M	适用场景
GPT-5	$1.25	$10.00	硬推理，复杂工具调用
GPT-5 mini	$0.25	$2.00	大部分聊天，摘要，RAG 综合
GPT-5 nano	$0.05	$0.40	分类，意图检测，格式化

对于简单的分类任务，从 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. 积极使用提示词缓存（缓存输入打 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() 导致每次调用都让缓存失效。

解决方案：构建你的提示词，让可缓存的部分在最前面，可变的部分在最后面：

[可缓存前缀 — 调用间字节级一致]
- 系统指令
- 工具定义
- Few-shot 示例
- 长参考文档（不变的 RAG 上下文）

[用户特定后缀 — 随调用变化]
- 当前日期/时间
- 用户 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 harness 运行（针对 500 个 fixture 测试提示词变更）：以前实时跑要 20 分钟；现在要 2 小时但便宜一半，结果我们跑得更频繁了。反直觉的是，降低评估成本让我们跑起了更多评估，从而提高了提示词质量。

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

唯一的真正缺点是延迟不可预测——“最长 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 字段——如果超过约 5% 的时间是 length，说明你的封顶对那个任务太紧了。如果几乎总是 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" 反复出现）。在我审查的典型系统提示词中，光是……（文本在此处截断，但已涵盖主要部分）