大模型API成本优化指南：从token计费到模型选型实战

前阵子和一个做 AI 应用的朋友聊成本优化，他给我看了一份后台账单。同一个 prompt，在 A 模型上跑了一万次，花费两百多块；同样一万次，换到 B 模型上只要四十多块。提示词一个字没改，业务逻辑也没变，差别却在五倍上下。他第一反应是自己渠道接错了，第二反应是对方计费系统出了问题。其实都不是，这只是大模型定价体系里最基础的现状——不同模型的计价标准，从来不是统一的尺子。

这篇内容就是想把这件事彻底讲清楚。我会从一张模拟账单出发，拆开 token 计数的黑盒，聊模型架构和算力成本的区别，再告诉你那些“看起来便宜、实际更贵”的模型是怎么通过重试、输出长度和上下文管理把钱赚回去的。最后给一套我自己在项目中反复验证过的降本方案。适合正在做 AI 应用、接 API 或者刚入门提示词工程的读者，看完你至少能学会一件事：拿到一份模型报价单时，到底应该看哪些数字。

1. 先从一份真实账单说起：同样的 prompt，为什么计价基数不一样？

1.1 一个对比表：同样的 prompt，三款模型的报价差异

假设你有一个固定的业务 prompt，经过分词后，输入约 1500 个 token，每次回答输出约 500 个 token，一个月调用一万次。我们按市场上常见模型的大致水平，把价格拉开来对比（以下为示意数据，不代表某个具体模型的最新价格）：

同样一句 prompt，没有改任何逻辑，单次调用成本能从 0.21 元掉到 0.007 元，整整 30 倍。这里面最关键的差异有两个：第一个是 token 单价不同，第二个是同一个 prompt 在不同模型里被拆出来的 token 数量不同。单价差异大家都能看到官网标价，容易被忽略的是后者——同一句话，不同模型拆 token 的方式不一样，所以“计费基数”从一开始就不相等。

1.2 从单价到总价：付费算的是 token，不是字数

很多刚接触 API 的人会想当然地认为，我往输入框里敲了 1000 个汉字，计费就按 1000 字算。实际完全不是，平台计费的最小单位是 token，不是字符，也不是字节。token 可以理解成模型读取文本时使用的一个个“知识碎片”，一个 token 可能是半个词、一个汉字、一小段代码，也可能是几个字符的组合。这个拆分动作由模型自带的 tokenizer 完成，每家模型的 tokenizer 都是独立训练的，拆分逻辑也完全不同。

举一个直观的例子。英文里 “tokenization” 这个词，在 OpenAI 的 tiktoken 分词器里大概被拆成 2 到 3 个 token；在另一些开源模型的分词器里，可能被拆成 4 个甚至更多。中文场景更明显，有的模型把常见汉字一个个映射到 token 表里，一个汉字一个 token；有的模型会按词组合并，两个汉字一个 token；遇到生僻字或 emoji，可能一个字符就要吃掉 3 到 5 个 token。所以同样的中文 prompt，在不同模型之间，token 数量差个百分之三五十完全正常。

这时候再叠加单价差异，总价差几倍就不奇怪了。你真正应该关心的公式是：总费用 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价。输出单价通常比输入单价贵三到五倍，因为生成过程是逐 token 推理，计算量大得多。很多新手只看输入单价，觉得模型很便宜，结果一跑起来发现输出 token 才是花钱大头。

2. token 计数的黑盒：分词器差异、语言损耗和系统提示词的隐形费用

2.1 同一句话，中文和英文的 token 数量可以差一倍以上

我自己踩过一个大坑，当时做一个内容分类项目，输入是一段大约 300 字的中文通知。我在测试环境里用的是英文示例，一切正常，成本估算也看着很美。上线后我拉出真实账单，发现 token 使用量比预估高了一倍。排查了半天才意识到，问题出在语言上。

很多主流大模型的分词器，对英文的压缩率非常高，一个英文单词平均 0.7 到 1 个 token；但中文因为字符表庞大，分词器里不可能把所有常用词都装进词表，于是会把一个汉字或一个双字词拆成 1 个到 3 个 token。在部分开源模型里，中文字符的平均 token 占用甚至是英文字符的 2 到 3 倍。同样表达“我今天要去公司开会”，英文 “I need to go to the office for a meeting today” 大约 9 个 token；中文这 10 个字在某些模型里拆出 14 到 18 个 token 都很正常。

这就带来一个很现实的问题：如果你的业务主要跑中文 prompt，选择模型时不能只看官网标价，还得看这个模型的中文分词效率。怎么验证？很简单，用一个三百字左右的中文段落，分别调用不同模型 API，查看回传的 usage 字段里的 prompt_tokens 数量，一对比就知道谁更划算。这个动作我建议在模型选型时必做，因为它直接影响你的输入成本基数。有些模型英文 token 便宜，但中文损耗大，实际总费用反而更高。

2.2 系统提示词、多轮历史、工具调用：账单里没人告诉你的隐形 token

另一个容易被忽略的是请求里其实包含的不只是你写的那段用户 prompt。真实业务里，一次 API 调用通常由三部分组成：系统提示词（system prompt）、历史对话或示例、用户当次输入。系统提示词可能固定不变，但它在每次调用里都会被重新计费，因为服务器端要把完整上下文重新编码一遍。

具体来说，我见过不少团队在系统提示词里写了一大段角色设定、输出格式说明、行业术语表，洋洋洒洒两千字。这段内容每次调用都在扣钱，日积月累很可观。多轮对话场景更夸张，每一轮新请求都会把之前所有轮次的历史记录重新发给模型，于是上下文长度会随对话轮数线性增长，到第 20 轮时，输入 token 可能已经从 500 涨到了 8000，而你真正新增的问题只有 200 个 token。

工具调用和结构化输出也会产生额外的“看不见的 token”。一些模型 API 支持 function calling 和 JSON schema 输出，但你定义的工具参数、函数描述、格式模板，同样会被转换为 token 进入计费。更隐蔽的是，某些模型的 API 会在服务端悄悄追加一些默认指令、安全摘要或输出 format 说明，这些你从控制台上看不到，但 usage 字段里是实实在在扣了钱的。我遇到过两次这类情况，后来养成了一个习惯：每次调用结束，都把 response 里的usage.prompt_tokens字段打出来，和本地自己算的 token 数对一下，差异超过 20% 就说明有隐藏 token。

3. 模型背后的算力账：架构决定成本，定价只是最后一道折算

3.1 稠密模型和稀疏模型：推理时哪部分真正在烧钱

抛开 token 计数，再往底层看一眼。为什么不同模型单价差距那么大？表面上是商业定价策略，底层是推理成本。推理成本的核心，是模型每次生成一个 token 时到底要激活多少参数。

传统的大规模参数模型是“稠密模型”，典型如一些 70B、175B 参数模型，输入任何一句话，整个网络的几百亿参数都要参与计算，每生成一个 token 都要做全量矩阵运算。这意味着推理一小时的 GPU 算力消耗非常固定，且单价天然高。而近年来大放异彩的“混合专家模型”（MoE），比如 DeepSeek 系列、Mixtral 这些，采用的是稀疏激活。它们把模型切分成很多个“专家模块”，每次输入只激活其中几个专家，一个 671B 总参数的模型，实际每次推理只动用 30 到 40B 参数。推理效率高了一大截，单 token 的算力成本就降下来了。

所以你会发现一个反直觉的情况：一个总参数更大的 MoE 模型，推理成本可能比一个总参数小得多的稠密模型还要低。选模型不能只看“参数多一定贵”这种直觉，要搞清楚它走的是 dense 还是 MoE 路线。这些信息在一些模型发布的技术报告里都会写，做技术选型时值得翻一翻。推理成本不仅体现在 API 单价上，也体现在你自己的私有化部署里——如果你打算自己买卡部署开源模型，一个稠密 70B 模型可能需要 2 张 80G 显卡才能流畅跑，而一个 MoE 模型虽然总参数更大，可能 1 张卡就能凑合推理。

3.2 训练成本折旧、上下文窗口和维护开销

有人会追问，训练一个模型动辄烧掉几百万美元，这些成本不会摊进 API 价格里吗？会，但不是主要部分。训练是一次性投入，API 定价更多由边际推理成本、市场需求和竞争格局决定。训练成本会进入定价的战略考量，但真正决定你每花一分钱能换多少输出的是推理端的资源需求。

上下文窗口是另一个隐蔽的成本变量。一个模型支持 128K 上下文，不是说它存下这 128K token 就完事了。每处理一个请求，模型都要为当前上下文维护一个 KV 缓存（key-value cache），上下文越长，缓存占用的显存越大。你把上下文从 8K 提到 128K，理论上单请求显存占用会翻十几倍，这对服务商来说是真金白银的算力成本。这也是为什么长上下文模型常常单价更高，或者在长上下文场景下会激活额外的计费规则。

再加上服务商要做的模型灰度、安全审查、并发扩容、客服支持，这些运维成本都会打散到单价里。你会发现同一个开源模型，在不同服务商那里托管价格可以相差一倍，原因不是模型本身变了，而是服务商的基础设施利用率、并发策略和定价目标完全不同。有的厂家用低价开源模型引流，把成本当作获客投入；有的厂家专做高可用高并发，价格自然更高。这些商业因素会在单价上体现得非常明显。

3.3 高价模型“贵”在能力边界，低价模型“便宜”也可能有代价

价格差异里还有一部分，是模型能力梯度造成的。推理模型，比如带强化学习微调的深度思考类模型，在回答前会先生成一大段内部推理过程，这些推理 token 也是要计费的，而且推得的输出 token 一起按输出单价计算。即使你最终只想要一句话的答案，模型可能已经默默“想”了 2000 个 token，于是你的账单就是 2000 个思考 token + 100 个回答 token。这类模型比普通对话模型贵出 5 到 15 倍，贵在它解决问题的能力边界确实更强，能处理复杂逻辑、数学推理和代码调试。如果你的 prompt 本身只是“把这句话翻译成英文”这类简单任务，用推理模型就是大炮打蚊子，每一发都在浪费钱。

反过来，低价模型便宜，但它的错误率、输出质量也可能更差。我做过很多次对比测试：同一个复杂编码任务，便宜模型给出的代码可能有 3 处 bug，你来回调试要额外调用 5 次 API；贵模型一次给出的代码就能编译通过。算总账的时候，便宜模型的单次成本低，但总调用次数高，总费用未必省。这个点在后面展开。

4. 看起来便宜未必省钱：重试、输出长度和上下文膨胀的蝴蝶效应

4.1 失败重试的重复扣费，比你想的更常见

我见过最多的预算超支，不是来自模型单价高，而是来自失败重试。尤其是用便宜模型处理复杂任务时，失败率会明显上升。这里的“失败”不单指 API 返回错误，还包括：返回的 JSON 格式不合法、解析失败需要重新调用、生成内容被安全策略拦截返回空值、超时中断、上下文长度超限导致输入被截断。每一次失败，你都已经为那次调用付过费了，重试意味着再次付费。

这里的关键是：重试成本不仅包含重试次数乘以单次成本，还包含你追加的调试提示词和修正指令。比如你在第一次调用后追加一句“请你重新生成，上次输出不完整”，这句话本身也是一个带计费的 prompt。复杂任务里，从失败到成功可能需要 3 到 5 次调用，总成本可能是理想情况的 4 到 6 倍。便宜模型的单次成本低，但失败概率可能是高价模型的 3 倍以上，一算总账，便宜模型反而成了最大的成本黑洞。

我的经验是，做任何模型选型都先做“失败成本测试”：挑一个代表性任务，连续调用 50 次，记录成功率、平均重试次数、最终成功时的累计 token 消耗。这样算出来的单次有效成本，才具备参考意义。只看官网页面上那个像素级的输入单价做决策，太容易踩坑。

4.2 max_tokens 上限没设好，一次回复的账单直接翻倍

另一个高频坑是 max_tokens 参数配置。模型生成是流式逐 token 的，如果你没设置 max_tokens，很多模型会一直生成到自己的终止条件。对于问答类任务，结果往往是废话连篇，把同样的意思重复输出好几遍，你的账单也跟着翻倍。反过来，如果你设置了过大的 max_tokens，而模型实际只生成了很少的内容，未使用部分通常不会计费，所以这个参数主要防的是“生成失控”，而不是预占成本，但也别真的放任不管。

真正需要警惕的是推理模型的输出预算。前面提到，推理模型会在最终回答前先输出大量思考 token，这些 token 同样计入输出 token。问题在于，同一段思考过程在不同模型里会有完全不同的长度。有的推理模型思考简洁直接，有的则习惯反复自我校验，把同样的解法换着角度推演好几遍。如果业务本身允许，可以通过参数控制“思考强度”，把深度推理模型的思考 budget 调低，能显著压缩输出 token。我在实际项目中对比过，同一道数学题，高思考强度下输出 token 达到 5500，低思考强度下是 1200，价格差直接体现在账单上。所以用推理模型时，不要默认跑满配置，先根据任务难度设一个合理的输出上限。

4.3 上下文膨胀：反复塞历史记录，价格不是线性上涨

多轮对话和 agent 类应用另一个烧钱点是上下文膨胀。我们做一个客服机器人时，发现对话超过 10 轮后，每轮调用成本是第 1 轮的 15 倍。原因很简单，第 1 轮的总输入 token 只有系统提示 + 200 字用户问题；第 10 轮时，每次请求都要带上之前 9 轮全部问答历史。那段历史不会变小，只会越积越多，于是每新开一轮，就重复付一次历史上下文的全额费用。

更糟糕的是，有些 agent 框架在单个任务循环里会自动调用多次模型，每次调用都重复发送完整上下文。几个循环下来，一个原本简单的抓取任务，直接吃掉几万 token。这类成本不是由 prompt 本身决定，而是由工程架构决定。修法有几种：每轮对话结束后用便宜模型把历史压缩成摘要;设定最大轮次，超过就强制开启新会话;对不再需要的工具调用结果做截断，而不是全量保留。这些在后面详细讲。

5. 怎样花更少的钱跑通同样的 prompt：分层选型、压缩提示与缓存技巧

5.1 先量化：跑一组基准测试，算出你业务的实际单位成本

既然要省钱，第一步不是拍脑袋选模型，而是先量化。我自己维护了一套模型选型脚本，每次测试新模型或新版本时都会跑一遍。思路很简单：选 3 到 5 个有代表性的真实业务 prompt，分别调用各家模型 API，记录 usage 字段、耗时、成功率，再按官网价格算出单次有效成本。

这里可以分享一个极简的 Python 测试脚本思路，不是完整代码，但足以说明统计逻辑：

import json, time def test_model(client, model_name, prompt, max_tokens=800): start = time.time() try: resp = client.chat.completions.create( model=model_name, messages=[{"role": "user", "content": prompt}], max_tokens=max_tokens, ) usage = resp.usage elapsed = time.time() - start return { "model": model_name, "input_tokens": usage.prompt_tokens, "output_tokens": usage.completion_tokens, "total_tokens": usage.total_tokens, "elapsed": round(elapsed, 2), "success": True, } except Exception as e: return {"model": model_name, "success": False, "error": str(e)}

统计的核心不是单个样本，而是 30 到 50 次调用的累计数据。我会算“每千次有效成功调用消耗多少 token”，然后乘上各家 API 单价，得出一个可比的数值。这一步做完，你才会真的理解：为什么表面单价差三四倍的模型，折合到真实业务上可能差十几倍。

另外，建议把这个基准测试和“输出质量验收”绑定。最好把返回结果落到本地文件，抽样人工检查，或者用一套自动化断言判断输出是否符合预期。只有跑通了质量验收，才能让成本优化有底线——单纯追求便宜而牺牲质量，最后赔掉的更多。

5.2 路由与颗粒选型：把复杂推理和简单抽取分开

降本最有效的策略，不是找一个“又便宜又好”的万能模型，而是建立模型路由。把任务按难度分类，简单任务走便宜模型，复杂任务才用贵模型。听起来简单，实施起来需要一套调度逻辑。

我做过一个内容分析系统，处理三种任务：关键词提取、情感判断、深层逻辑推理。前两个任务用轻量模型就能达到 95% 以上的准确率，第三个任务需要推理模型才能过关。如果所有任务都统一走推理模型，成本是分层方案的 8 倍。后来加了一层路由分类器：先用一个小模型识别任务类型，再分发到对应模型，整体调用成本降了 60% 以上，准确率反而更高，因为任务和模型能力匹配度提升了。

路由逻辑不一定要很复杂。可以用规则关键词匹配，也可以用模型本身来分类。关键是找到“模型性能曲线”的拐点——什么时候某个模型的能力已经不足以完成任务，必须升级。这个拐点需要你前面做的基准测试数据来支撑，而不是靠感觉。

还有一个颗粒度层面的优化：同一家模型的多版本，如标准和“推理版”，价格差异很大。如果你的业务里 70% 的请求都是简单问答，把默认选型改成标准版，只把 30% 的复杂问题留给推理版，总账单会非常可观地下降。

5.3 提示缓存、压缩与结构化输出的省钱技巧

最后聊几个实打实的省钱操作。

第一，善用提示缓存。很多 API 提供商对重复的前缀 token 提供缓存功能，命中缓存后输入价格可能打 1 折甚至免费。做法是保持系统提示词和前端 k 条历史记录不变，启用服务商的自动缓存开关（有的平台无需设置自动启用，有的需要显式声明），然后在每次请求时把固定前缀放在变量部分前面。缓存是按照“前缀匹配”工作的，只要前缀完全一致就能命中。这意味着你在设计系统提示词时，应该把最稳定的内容放在最前面，把会变化的用户问题放在最后。

第二，压缩历史记录。对于多轮对话，与其把全部历史 token 原样塞进上下文，不如用便宜的模型定期把历史压缩成结构化摘要。例如对话超过 10 轮时，触发一次总结调用，用轻量模型把前面的问答浓缩成“用户问题 + 已解决问题 + 待办事项”三段式摘要，然后从第 11 轮开始用摘要替代原始历史。这样上下文长度基本恒定在某个上限，不会随对话轮数无限膨胀。代价是摘要过程本身消耗少量 token，但只要摘要调用频率控制得当，省下的远大于花的。

第三，控制输出格式和长度。结构化输出（JSON mode）不只是一个格式要求，还能抑制模型长篇大论的习惯。你在 prompt 里明确“只输出 JSON，不要解释”，输出 token 会显著下降。加一行“如果答案是空的，输出空对象，不要补充说明”，也能少掉一大截无意义输出。我在一个数据抽取项目里，把输出 token 从平均 800 降到平均 200，成本直接砍了 75%，而且解析成功率反而上升了，因为模型不再输出干扰信息。

第四，尤其要留意 prompt 工程中的“重复有效信息”。有些提示词工程教程鼓励写超长示例，但示例里的无关内容也会进入计费。每增加一千个输入 token，就在为每次调用多付一笔钱。做 prompt 优化时，可以考虑把冗长示例压缩成关键的最小样本，或者把多次调用的共同前缀提取出来，放缓存区，尽量避免反复计费。

试过的同学都知道，AI 应用的成本不是只看模型标价，更看你的工程细节。同样的 prompt、同样的模型，在 A 团队手里每月几毛钱，在 B 团队手里每月几百块，中间隔着的就是这些 token 层面的精细操作。

我现在养成了一个习惯：每次查看模型 API 账单时，不是只盯总金额，而是同时看“每千次调用的 token 分布”和“缓存命中率”。如果缓存命中率低于 50%，说明系统提示词设计有优化空间；如果输出 token 比输入 token 还多，说明 prompt 和参数设置需要调整。这些细节，往往就是那好几倍差距的真正来源。