前阵子和一个做 AI 应用的朋友聊成本优化他给我看了一份后台账单。同一个 prompt在 A 模型上跑了一万次花费两百多块同样一万次换到 B 模型上只要四十多块。提示词一个字没改业务逻辑也没变差别却在五倍上下。他第一反应是自己渠道接错了第二反应是对方计费系统出了问题。其实都不是这只是大模型定价体系里最基础的现状——不同模型的计价标准从来不是统一的尺子。这篇内容就是想把这件事彻底讲清楚。我会从一张模拟账单出发拆开 token 计数的黑盒聊模型架构和算力成本的区别再告诉你那些“看起来便宜、实际更贵”的模型是怎么通过重试、输出长度和上下文管理把钱赚回去的。最后给一套我自己在项目中反复验证过的降本方案。适合正在做 AI 应用、接 API 或者刚入门提示词工程的读者看完你至少能学会一件事拿到一份模型报价单时到底应该看哪些数字。1. 先从一份真实账单说起同样的 prompt为什么计价基数不一样1.1 一个对比表同样的 prompt三款模型的报价差异假设你有一个固定的业务 prompt经过分词后输入约 1500 个 token每次回答输出约 500 个 token一个月调用一万次。我们按市场上常见模型的大致水平把价格拉开来对比以下为示意数据不代表某个具体模型的最新价格模型类型输入单价元/千token示意输出单价元/千token示意单次调用成本示意1万次调用总成本示意高端推理模型0.060.240.21 元2100 元标准大参数对话模型0.020.060.06 元600 元轻量/开源托管模型0.0020.0080.007 元70 元同样一句 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_tokens800): start time.time() try: resp client.chat.completions.create( modelmodel_name, messages[{role: user, content: prompt}], max_tokensmax_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 和参数设置需要调整。这些细节往往就是那好几倍差距的真正来源。