将你的 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 和字符不是一回事——英文散文大约是 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%。是二十五倍。人们抗拒这一点，因为“旗舰机型更聪明”——是的，但你正在为那些不需要这种聪明度的任务买单。

我最常见的错误是：团队在第一周选了个模型（“我们从最好的开始，这样质量没问题”），上线了，然后就再也没回头看。六个月后，他们还在付 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. 积极使用提示词缓存（缓存输入打一折）

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

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

以 Claude Sonnet 4.6 上典型的 4,000 Token 系统提示词、每小时调用 1,000 次为例，算算账：

• 无缓存： 4,000 × 1,000 × $3/M = $12/hour 输入成本
• 有缓存命中（缓存输入打一折）： 4,000 × 1,000 × $0.30/M = $1.20/hour 输入成本（第一次未缓存的写入略贵于正常调用）
• 这仅仅是代码改动为“给提示词加上 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 per M；现在批处理 $0.625/$5 per M。光这一个任务每月省了大约 $4.7K。
• 每周 RAG 重新嵌入变更文档：延迟无关紧要，批处理没问题。
• Eval harness 运行（针对 500 个 fixture 测试提示词变更）：以前实时跑要 20 分钟；现在要 2 小时但便宜 50%，结果我们反而跑得更频繁了。反直觉的是，让评估变得更便宜让我们跑更多次评估，从而提升了提示词质量。

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

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