选型的时候打开一堆厂商定价页,输入输出价、缓存价、阶梯价、赠送额度混在一起,越看越不敢下结论。这篇不给一张会过期的排名表,而是给你一套自己排的方法:先统一口径,再分档看价位,最后用自己的用量折算成真实花费。价格数字本身随活动变动,去站内对应页面看当时的数就行。
选型的时候打开一堆厂商定价页,输入价、输出价、缓存价、阶梯价、赠送额度混在一起,越看越不敢下结论。更麻烦的是,你在群里问到的那张截图,可能已经是别人几个月前存下来的,直接照着选很容易踩坑。所以这篇不给你一张会过期的排名表,而是给你一套自己排的方法。
思路就三步:先把各家的计价口径对齐,再按档位把国内主流模型分组看待,最后拿你自己真实的 token 用量折算成月度花费。价格数字本身随活动和档位调整,具体多少去站内对应页面看当时的数就行,这里只讲怎么比、怎么排、怎么跟住变化。
为什么没人能给你一张固定的排行表
不是没人愿意做,是做了也留不住。国内厂商调价频繁,同一个模型可能同时挂着标准价、活动价、新用户价、阶梯价好几套口径,写死的名次过一阵就对不上。你拿着一份旧排行去谈判或者做预算,反而容易被动。
- 同一家的不同档位模型定位本来就不一样,拿别人最贵那档跟自己最便宜那档比,比出来的结论没有意义;
- 官方牌价和中转渠道折算后的实际单价经常有差距,只比官方数字会漏掉真实成本;
- 真正要排的不是厂商榜单,而是你手里那几个任务分别该落到哪一档,这才是能直接用的结论。
比价前先对齐三件事,不然全是白比
很多人比价失败,不是数据错,是口径没对齐。A 家的价按输入输出分开算,B 家给了个打包概念,C 家还有缓存命中折扣,你直接拿三个数字比大小,等于拿三种单位的尺子量同一张桌子。先花十分钟把下面三项对齐,后面才不会返工。
- 计价单位
- 确认是每百万 token 还是每千 token,输入和输出是否分开计价、分别多少
- 请求特征
- 算清自己平均输入长度和输出长度,长输入和长输出对总价的影响方向完全不同
- 附加口径
- 缓存命中有没有单独价、批处理有没有折扣、有没有最低消费和并发限速
这三项对不齐,后面算出来的月度花费就是不准的。各家定价页的措辞不一致的时候,先去站内的 /price-watch 对一遍当期变动记录,再回各自定价页确认细节,比自己硬猜靠谱。
| 要核对的项 | 常见坑 | 怎么确认 |
|---|---|---|
| 计价单位 | 按千计价写成每百万 | 定价页单位那一行逐字看 |
| 输入输出方向 | 只记了输入价忘了输出价 | 按自己日志里输入输出比例折算 |
| 缓存与批处理 | 折扣没算进月成本 | 问清哪些请求算命中 |
| 限速与最低消费 | 低价档排队拖慢整体 | 小流量压测一遍看延迟 |
把国内模型按价格档位分组看待
与其记一堆具体数字,不如先记住「档位」这个概念。国内主流模型大致可以分成入门、主力、旗舰三层,同一层里不同厂商价格有高有低,但定位和适用任务是比较接近的。分组的目的是决定哪些活可以下放,而不是给厂商贴好坏标签。
- 入门档:单价低、并发给得足,适合分类、抽取、格式转换这类判定型任务;
- 主力档:价格和效果折中,覆盖大多数对话、写作、代码补全场景,是默认选项;
- 旗舰档:单价最高,只用在复杂推理、长链路 Agent、代码重构这类高价值任务上;
- 分层之后要做的是把每个业务任务归到某一层,而不是整个产品绑死一家。
补充一句:档位不是固定的,新模型出来会重新洗牌。所以每次做完分组,把分组依据记在自己文档里,过一阵重跑一遍,比背一张价格表有用。当期各档位的实际价位,去 /official-api 和 /providers 核对当时的数字。
把单价换算成你自己的月度花费
单价本身不是决策依据,你的用量折算出来的花费才是。同样一家,有人一个月花得少,有人翻好几倍,差别就在调用量和输入输出比例上。所以第三步的关键动作是先拿到真实用量,再横向代进去算。
- 取一周用量日志统计输入 token 总量、输出 token 总量和请求次数,别用估算值
- 代进成本计算用 /tools/model-cost-calculator 把候选几家单价代进去,得到同一份用量的横向数字
- 留出冗余实际值通常比理论值高,重试、超长上下文、工具调用都会推高用量,留出缓冲
- 写成组合结论结论不要是「选一个万能模型」,而是「任务A走某档、任务B走另一档」
| 用量特征 | 比价时看什么 | 容易忽略什么 |
|---|---|---|
| 输入远大于输出 | 输入单价权重更高 | 缓存命中能不能省一截 |
| 输出远大于输入 | 输出单价权重更高 | 长输出的限速会不会卡住 |
| 请求次数多、单次短 | 每次请求的固定开销 | 有无最低消费 |
| 偶发超大上下文 | 阶梯价怎么跳档 | 超长请求是否限流 |
什么情况下这套比价不适用
任何方法都有边界,这套也不例外。下面几种情况里,价格不该放在第一位,硬套这套流程反而浪费时间和精力。
- 数据合规要求必须走私有化部署或指定云厂商时,价格不是第一优先级,能不能合规才是;
- 对延迟极敏感的场景,便宜的档位可能因为排队和限速拖慢整体,省的钱抵不上体验损失;
- 用量很小的时候,折腾比价的收益还不如先把业务跑通,等量上来了再回头算。
还有一类容易被忽略:任务对效果要求很高,便宜档位反复返工重试,实际消耗可能比一次用贵档更高。判断标准不是单价,是「跑完这件事要花多少总成本」。拿不准的时候去 /rankings 看看同期横向对比,再结合自己任务实测。
一次比价的排查顺序清单
把前面的内容收成一份可以照着走的顺序,每次选型或者复查的时候从第一步往下走,做完打勾。顺序本身比单点结论更重要,因为它能保证口径一致。
| 步骤 | 动作 | 产出 |
|---|---|---|
| 第一步 | 锁定 2 到 3 个候选模型,不要一上来铺开十个 | 候选清单 |
| 第二步 | 统一口径,补齐输入输出、缓存、限速三项 | 口径表 |
| 第三步 | 用真实用量算月度数字,去 /official-api 和 /providers 核对当期档位 | 成本对照 |
| 第四步 | 跑一次小规模对照,效果不达标的直接淘汰 | 效果结论 |
| 第五步 | 写进选型记录,标好复查时间,价格变动后重跑 | 选型文档 |
这份清单的最大价值是防止你中途跑偏,比如第三步核对档位的时候顺手翻到了别家的介绍,一上午就没了。每步产出一个明确结果再往下走,整件事基本能在半天内出结论。
排完之后怎么跟住变化
选型不是一次性动作,排完就锁死迟早会出问题。聪明的做法是把关注项登记起来,改动发生时先判断影响大不大,再决定要不要切,而不是一有风吹草动就迁移。
- 登记关注模型把在用的模型加进价格追踪页,改动时能第一时间收到提醒
- 先看差额幅度小幅波动不值得动,先判断这次改动会影响多少月度成本
- 同批提示词对照切换前用同一批提示词跑一次对照,别只看单价降了
- 折算渠道实际价如果走中转渠道,还要看渠道倍率折算后的实际单价,不能只比官方牌价
中转渠道的倍率是个容易被漏掉的变量,它的折算方式各家不一样,直接决定你实际付多少。具体规则和当期倍率去 /sites 看各家说明,再结合自己的调用量算。切换前也建议用 /tools/speed-test 压一遍,确认延迟和稳定性没退步。
比价比的不是谁便宜,是你的每一类任务落在哪一档上最划算。下一步把你现在在用的模型和候选模型列出来,去站内价格追踪页登记一遍,再拿最近一周的真实用量算一次月度花费,你会比看十张排行表更有底。→
常见问题
国内模型 token 价格排行在哪里能看到最新数字?
没人能给你一份长期有效的固定表,厂商调价和活动都很快。做法是到 /official-api 看各家官方当期档位,再用 /price-watch 对一下近期有没有变动,两个页面合起来看就是当前的真实价位。站内不写死数字也是这个原因。
为什么两个模型的单价看起来差不多,实际账单差很多?
多半是输入输出比例和缓存命中的差别。有的模型输入便宜输出贵,有的反过来;你的任务如果是长文档摘要,输入占比高,结论会完全不同。先把平均输入输出长度算出来,再回定价页代一遍,才知道差价从哪来。
便宜档位的模型能不能直接替换掉主力档?
要看任务类型。分类、抽取、固定格式输出这类判定型任务,下放到便宜档通常没明显损失;涉及多步推理、长链路工具调用、代码重构的,换过去容易反复重试,最后反而更贵。建议先挑一两个任务做小规模对照,别整体替换。
比价的时候要不要把免费额度和赠送额度算进去?
可以作为短期缓冲,但不能作为选型依据,因为额度和赠送都有有效期和限速限制。正确做法是先用付费单价算出真实成本,再单独评估免费额度能覆盖多少试跑阶段,两笔账分开。相关口径可以对照 /usage 上的实际用量分布。
自己算的月度花费和账单对不上怎么办?
先检查三处:有没有缓存命中没计入、有没有重试产生的重复请求、单价用的是不是当期档位。把这三项排掉再对比,如果还有明显差距,就把用量日志按天拆开,找出异常那天是哪类任务在烧钱。