四大模型实测账单差10.6倍

标价差2倍，跑完任务却差10.6倍

一项近日公开的真实任务测试，把 GPT、Claude、Gemini 和 Kimi 的成本优化档模型放进同一组产品场景后发现：四个候选模型的公开标价最高仅相差约2倍，但完成全部任务产生的总成本却相差10.6倍。

这不是简单的“哪家每百万 Token 更便宜”比较。测试覆盖了10项接近线上产品的任务，包括分类、RAG 问答、多轮对话，以及先制定计划、再调用步骤执行的 Agent 任务。测试者直接请求各厂商的在线服务，并按照账单中的实际 Token 用量核算成本。

真实任务成本是模型完成一项可验收任务所消耗的全部费用，而不是输入、输出单价的简单比较。 它至少包含输入 Token、可见输出 Token、内部推理 Token、缓存读写、工具调用、失败重试和多轮上下文回传。

测试里最扎眼的案例，是一个只要求返回单个词的分类任务。某个模型在给出这个词之前，消耗了197个不会出现在最终回答里的内部推理 Token，而这些 Token 仍按输出侧费率计费。

用户看到的是一个词，账单看到的却是一段推理过程。

这次测试究竟说明了什么

这项测试的核心结论是，公开单价不能直接预测生产环境中的最终账单。 在候选模型标价区间只有2倍的情况下，真实成本区间达到10.6倍，成本离散程度被放大了5.3倍。

根据测试者公开的摘要，可以确认的关键数据如下：

| 指标 | 测试结果 | 对开发者的意义 | |---|---:|---| | 参与模型体系 | GPT、Claude、Gemini、Kimi | 覆盖四家主流闭源模型服务商 | | 任务数量 | 10项 | 比单轮问答更接近产品负载，但仍属于小样本 | | 任务类型 | 分类、RAG、多轮对话、Agent 计划与执行等 | 同时覆盖短输出、长上下文和多步骤任务 | | 候选档位 | 各厂商成本优化档 | 比较对象不是各家的旗舰高价模型 | | 公开标价最大差距 | 约2倍 | 仅看价目表，模型之间似乎没有数量级差异 | | 实测总成本最大差距 | 10.6倍 | 实际请求行为将成本差异放大至一个数量级 | | 单词分类案例 | 197个隐藏推理 Token | 极短答案不等于极低成本 | | 失败尝试与 Token 消耗相关性 | r = -0.62 | Agent 失败通常伴随更严重的 Token 浪费 |

现有公开摘要没有完整列出四个具体模型版本及逐项金额，因此不能据此严谨补出一张绝对成本排行榜。 在线模型别名还可能发生版本漂移，同一个产品名称在不同日期命中的后端版本未必相同。对这类测试，更值得复用的是方法、原始提示词和计量逻辑，而不是把一次排序永久化。

四类模型在这项测试中的观察重点，可以概括为：

| 模型体系 | 服务商 | 价目表能告诉你的 | 价目表通常不能告诉你的 | |---|---|---|---| | GPT | OpenAI | 输入、输出及缓存相关费率 | 每个任务实际触发多少内部推理与重试 | | Claude | Anthropic | 不同档位的基础 Token 价格 | 长上下文、多轮工具使用后的总放大倍数 | | Gemini | Google | 输入输出费率及上下文相关规则 | 思考预算对短任务和复杂任务的实际影响 | | Kimi | 月之暗面 | 对应模型档位的公开费率 | 不同任务下的输出长度、推理开销和成功率 |

这张表不是在说四家都“隐藏收费”。内部思考不直接展示给用户，是推理模型的正常产品设计；真正的问题在于，开发团队如果只记录最终文本、不保存 usage 字段，就很难解释账单为什么突然上涨。

隐藏推理为什么会把成本拉开

隐藏推理 Token 是模型在生成最终回答前使用、不会原样返回给用户但可能被计量的内部计算序列。 它与可见回答长度没有稳定的线性关系，同一道题可能只返回“是”或“否”，内部却先做了分类判断、约束检查和答案验证。

传统的成本估算公式通常只有两项：

任务成本 = 输入 Token × 输入单价 + 输出 Token × 输出单价

对于具备推理、缓存和工具调用能力的模型，更接近现实的公式应当是：

任务成本 = 输入成本 + 可见输出成本 + 内部推理成本 + 缓存成本 + 工具调用成本 + 重试成本

其中，内部推理 Token 往往按输出侧价格计费，而输出侧单价通常高于输入侧单价。只要模型在低难度任务上过度思考，账单就可能迅速偏离预估。

197个隐藏推理 Token 的分类案例，说明模型成本与界面中看到的答案长度并不等价。 对人工客服标签、内容审核、意图识别和路由判断这类高频任务而言，单次多出几百 Token 看起来不多，但每天执行100万次时，就会累积为数亿 Token。

更麻烦的是，这种浪费很难通过普通日志发现。业务日志通常只保存输入、最终答案、延迟和状态码；如果没有同步记录输入 Token、输出 Token、推理 Token、缓存命中和重试次数，团队看到的只会是“请求成功了”，而不是“这个单词究竟花了多少钱”。

Agent 场景比普通聊天更容易失控

Agent 任务是模型通过规划、调用工具、读取结果和继续决策来完成目标的多步骤任务。 它的成本不是单次生成成本，而是一条执行轨迹上所有模型请求与工具调用的总和。

测试引用的 TerminalWorld 研究给出了一个值得警惕的数字：失败尝试与任务表现之间呈现 r = -0.62 的负相关关系。换句话说，表现越差的执行轨迹，往往反而消耗更多 Token。

这与传统软件服务的成本结构很不一样。普通接口失败可能很快返回一个错误码；Agent 失败则可能经历以下过程：

1. 先生成一份过长的计划；
2. 调用错误工具并读取大段返回值；
3. 尝试解释错误结果；
4. 带着更长的上下文重新规划；
5. 再次调用工具；
6. 最终仍未完成任务。

失败 Agent 的危险之处，是它可能同时拉低成功率并抬高平均成本。 如果一个模型每次尝试只花0.01元但成功率只有20%，那么每个成功任务的期望成本并不是0.01元，而至少接近0.05元；如果失败路径比成功路径更长，真实数字还会继续上升。

因此，开发者真正应该比较的指标不是“每次请求成本”，而是“每个成功任务成本”：

每个成功任务成本 = 所有尝试的总成本 ÷ 通过验收的任务数量

这也是 CostBench 在 ACL 2026 相关研究中指出的盲点：领先模型并不总能选择成本最优的执行计划。一个逻辑上正确但绕了十步的方案，在生产环境里可能不如一个能力稍弱、但能三步完成任务的模型。

为什么静态价目表会失真

静态价目表描述的是 Token 的单位价格，而不是模型完成业务目标所需的 Token 数量。 最终账单由“单价”和“用量”共同决定，只比较前者，相当于买车时只看油价，不看百公里油耗。

造成价格排名反转的因素主要有五类。

1. 推理预算不一致

推理预算决定模型愿意在回答前投入多少内部计算。 较高预算可能改善数学、代码和规划任务，但在分类、抽取和格式转换任务中，额外思考未必带来可测量的收益。

如果产品把同一种高推理配置用于所有请求，简单任务就会持续为用不到的能力付费。

2. 输出风格不同

输出冗长度是不同模型在相同指令下生成文本长度的系统性差异。 有的模型会直接返回字段，有的模型会先解释判断依据，再补充注意事项。后者未必质量更高，却会产生更多按输出费率计算的 Token。

对于结构化抽取任务，应同时检查格式合规率和平均输出 Token，而不是只看答案是否“读起来更完整”。

3. 多轮上下文重复计费

上下文膨胀是历史消息、检索文档和工具结果在后续轮次中被重复送入模型的现象。 一段1万 Token 的检索材料如果连续回传5轮，并不等于只处理了1万 Token。

缓存可以缓解部分成本，但缓存命中条件、读取费率和有效时间各不相同。没有实际命中率数据时，把缓存折扣直接写进预算模型同样不可靠。

4. 失败重试放大成本

重试放大系数是完成一次有效结果所需平均请求次数。 若格式校验失败、工具参数错误或内容被截断，应用层通常会自动重试。单次看似便宜的模型，只要重试率较高，就可能在月度账单上反超。

5. 模型版本会变化

版本漂移是同一模型别名在不同时间指向不同后端版本或推理策略的现象。 在线服务持续升级后，Token 消耗、延迟和回答风格都可能改变。

所以，任何成本测试都应记录日期、区域、精确模型标识和参数。2026年7月得到的结果，不应未经复测直接用于半年后的采购决策。

10个任务足以推翻直觉，但不足以决定采购

这项测试更像一场成本机制演示，而不是覆盖所有业务的最终排行榜。 10项任务足以证明“标价排名不等于账单排名”，却不足以证明某个模型在所有场景中永远最便宜。

它至少存在四个边界：

• 样本规模有限： 10个任务无法覆盖代码生成、长文档分析、语音、多模态和高并发请求。
• 质量权重不同： 成本最低的答案如果不合格，就没有业务价值。
• 线上结果有随机性： 温度、服务端策略与模型更新都会改变输出长度和推理用量。
• 单次测试难以反映尾部风险： 平均成本正常，不代表 P95、P99 成本不会失控。

因此，开发团队不应照抄这次测试的名次，而应照抄它的思路：拿自己的真实流量回放，并以成功任务为核算单位。

开发团队应该怎样重新做成本评测

可靠的模型选型需要同时测量质量、成本、延迟和稳定性，而不是先看价格再看跑分。 一个可落地的评测流程至少包含以下六步。

第一步：按业务流量构建任务集

任务集不应只有复杂推理题，还要保留线上占比最高的简单请求。分类、改写、检索问答、工具调用和长上下文任务应分别统计，不能用一个平均数掩盖差异。

第二步：锁定模型和参数

每条记录都应保存精确模型标识、测试时间、区域、温度、最大输出长度和推理配置。只写“GPT”或“Gemini”无法支持后续复现。

第三步：保存完整 usage 数据

至少记录以下字段：

• 输入 Token；
• 可见输出 Token；
• 推理或思考 Token；
• 缓存写入与读取 Token；
• 工具调用次数；
• 重试次数；
• 首 Token 延迟与总延迟；
• 最终是否通过业务验收。

第四步：按成功任务核算

分类任务可以用准确率和每千次正确分类成本，RAG 可以用有依据回答率和每次合格回答成本，Agent 则应计算端到端完成率与每个成功轨迹成本。

第五步：报告分位数而非只有平均值

平均成本容易掩盖少量超长推理。建议同时报告 P50、P95 和 P99 Token 消耗，并单独检查成本最高的1%请求。

第六步：建立模型路由

简单分类和抽取任务没有必要默认使用高推理配置。可以先由低成本模型处理，在置信度不足、格式校验失败或任务复杂度较高时，再升级到更强模型。

模型路由的目标不是永远选择最便宜的模型，而是为每类任务选择满足质量门槛的最低成本方案。 这比试图找出一个包办所有工作的“性价比冠军”更现实。

真正该盯的是有效 Token，而不是便宜 Token

这次10.6倍的差距揭示了一个正在变得重要的工程事实：大模型成本优化已经从采购问题变成运行时问题。 厂商标价仍然重要，但它只是成本公式中的一个变量。

对于短分类任务，开发者要警惕隐藏推理和输出冗长；对于 RAG，要控制检索文档与历史上下文；对于 Agent，要限制最大步数、识别重复调用，并尽早终止无效轨迹。

这项测试并不能证明最便宜的模型一定最好，也不能证明内部推理都是浪费。复杂任务上，多花推理 Token 可能显著提高成功率，最终反而降低每个成功任务的成本。真正不划算的是：模型花了更多 Token，却没有带来可测量的质量提升。

结论很直接：模型价目表适合做预算初筛，真实流量回放才适合做选型。 当公开标价只差2倍、最终账单却能相差10.6倍时，继续用“每百万 Token 多少钱”作为唯一成本指标，已经不足以支持2026年的 AI 产品工程。

参考来源

• Reddit：Real task cost across GPT, Claude, Gemini and Kimi：测试发起者公布的原始说明，包含10项任务、10.6倍成本差距、197个隐藏推理 Token 案例，以及方法和原始结果入口。
• 知乎：警惕！大模型成本倒挂，你正在为模型的多余思考买单：对模型定价排名与实际成本排名反转现象的中文分析，讨论了内部思考对账单的影响。