单价相同，账单差3倍：大模型比价进入“后半场”

最近做客服工单分类的朋友遇到一个怪事：他把三家主流大模型的最新小模型报价页并排贴在屏幕上——输入 $0.10、输出 $0.50，每百万 Token。一个小数点都不差。

他第一反应是自己看错了，第二反应是其中两家抄了作业。

其实，这不叫撞价，这叫成本曲线撞在了一起。当大模型的定价逻辑走向成熟，曾经靠“标价差”来获客的时代正在过去。真正决定账单的，已经变成了隐藏在价目表背后的运营参数。

一、为什么三家的单价一模一样？

在 11 月 9 日到 10 日期间，几款新推出的轻量级模型（如 Meta Muse Ember、Claude Haiku 5.5、GPT-6 Luna）在价目表上写出了完全相同的两列：$0.10 和 $0.50。

往上看一层，形状更整齐：无论是标价 $8/$40 的旗舰，还是 $2/$10 的进阶模型，输入输出比几乎全部落在 1:4 到 1:5 这个区间。这个比例不是营销部门拍脑袋定出来的，而是底层算力结构的映射。

大模型处理输入（Prefill）时，是高度并行的矩阵运算；而生成输出（Decode）时，每吐出一个 Token 都要把权重从显存里重读一遍，卡在带宽上。输出成本天然是输入的几倍，行业经验值一直在 1:4 到 1:8。三家同时落在 1:5，说明在相近的硬件和稀疏结构下，它们跑到了同一条成本曲线上。

对开发者来说，这里有个能直接用的小结论：输入输出各占一半时，混合价大约是输入价的 3 倍。 初筛时用这一个数就足够了。

二、$0.10 只在一个“定义域”里成立

既然单价一样，比价表的第一列就失效了，得往下看脚注里的条件。

比如，某款模型标价 $0.10，但前边挂着一句话：单次提示词不超过 10 万 Token。过了这条线，输入价就会成倍上涨。对做长文档解析的人来说，这一条比单价本身重要得多。

同家厂商内部的跨度更夸张：在 10 万 Token 以内，顶级旗舰的单价可能是轻量模型的 40 倍。这意味着“选哪家”对账单的影响，远小于“选哪一档”。

此外，速度也是单独标价的。加速模式价格翻倍；部分模型还有推广期，比如标明 11 月 30 日到期，12 月 1 日起恢复原价。

把这些拼起来，标价其实不是最终价格，而是分段函数的第一个区间。 首页永远只展示最小的那个值，剩下的写在脚注和文档里。

三、真正拉开账单的，是“干完这件事烧多少”

单价一样的时候，差异只剩一个变量：同一件事要消耗多少 Token。

有第三方做过对照，拿两款单价相近的模型跑同一批任务：单题平均调用 7.3 次对 4.5 次，总消耗 28.4 万 Token 对 13 万 Token，差 2.18 倍；输出 6,200 对 2,300。单价便宜的那个，反而多绕了 62% 的轮次。

按公开价目表粗算（取闲时价），一道题的最终成本大约差 3 到 6 倍。单价上 1.4 倍的差距，被 Token 消耗量放大成了数倍。

想确认这个差距落在自己身上，别信榜单。把最常跑的一百条请求原样打两遍就够了——同一份代码换个模型名，看谁的轮次更少、总 Token 消耗更低。这也解释了排行榜上的一个错觉：调用量第一不等于效率第一。一个更啰嗦、更爱重试的模型，天然刷出更大的数字。

四、给开发者的三条实操建议

第一，比价先比形状。 输入输出比是不是 1:5，混合价能不能用“输入价乘 3”粗估，有没有分段限制。形状一样，就别在这一列上浪费 Excel 公式。

第二，把条件写进配置。 长度阈值、档位、加速开关、优惠到期日，都是会变的运营参数，千万不要硬编码在业务代码里。很多项目把单价注释写在常量旁边，半年后没人敢改。

第三，用自己的请求跑对照，并把模型名从代码里抽离。 这是唯一能得出“你这套负载下谁更便宜”的方法。对照完之后还有个工程问题：模型名别散落在业务代码里。

在多模型并存的当下，行业内更普遍的解法是引入统一的聚合网关（例如 EasyAPI）。它不仅能帮你省去搭建多套环境的功夫，更重要的是，把不同厂商的调用入口收拢在一个 Key 下，账单按模型、按请求拆分开来。当你要做 A/B 测试，或者遇到某家服务波动需要切换时，只需要改一行配置，而不用去翻二十个业务文件。

价格战打到三家报出同一个数字，其实是件好事：说明“便宜”这件事已经商品化了。剩下的功夫不在找价，而在算自己那笔账——你的输入有多长，你的模型有多啰嗦，你的任务里有多少是长尾。把配置和账本收在手里，才是应对未来变化的底气。