国内模型token价格排行

成本与用量

教你在选型阶段横向盘点国内主流模型的 token 价格档位:先对齐计价口径,再按档位分组,最后落到自己的用量上比。

选型的时候打开一堆厂商定价页,输入输出价、缓存价、阶梯价、赠送额度混在一起,越看越不敢下结论。这篇不给一张会过期的排名表,而是给你一套自己排的方法:先统一口径,再分档看价位,最后用自己的用量折算成真实花费。价格数字本身随活动变动,去站内对应页面看当时的数就行。

选型的时候打开一堆厂商定价页,输入价、输出价、缓存价、阶梯价、赠送额度混在一起,越看越不敢下结论。更麻烦的是,你在群里问到的那张截图,可能已经是别人几个月前存下来的,直接照着选很容易踩坑。所以这篇不给你一张会过期的排名表,而是给你一套自己排的方法。

思路就三步:先把各家的计价口径对齐,再按档位把国内主流模型分组看待,最后拿你自己真实的 token 用量折算成月度花费。价格数字本身随活动和档位调整,具体多少去站内对应页面看当时的数就行,这里只讲怎么比、怎么排、怎么跟住变化。

为什么没人能给你一张固定的排行表

不是没人愿意做,是做了也留不住。国内厂商调价频繁,同一个模型可能同时挂着标准价、活动价、新用户价、阶梯价好几套口径,写死的名次过一阵就对不上。你拿着一份旧排行去谈判或者做预算,反而容易被动。

  • 同一家的不同档位模型定位本来就不一样,拿别人最贵那档跟自己最便宜那档比,比出来的结论没有意义;
  • 官方牌价和中转渠道折算后的实际单价经常有差距,只比官方数字会漏掉真实成本;
  • 真正要排的不是厂商榜单,而是你手里那几个任务分别该落到哪一档,这才是能直接用的结论。

比价前先对齐三件事,不然全是白比

很多人比价失败,不是数据错,是口径没对齐。A 家的价按输入输出分开算,B 家给了个打包概念,C 家还有缓存命中折扣,你直接拿三个数字比大小,等于拿三种单位的尺子量同一张桌子。先花十分钟把下面三项对齐,后面才不会返工。

计价单位
确认是每百万 token 还是每千 token,输入和输出是否分开计价、分别多少
请求特征
算清自己平均输入长度和输出长度,长输入和长输出对总价的影响方向完全不同
附加口径
缓存命中有没有单独价、批处理有没有折扣、有没有最低消费和并发限速

这三项对不齐,后面算出来的月度花费就是不准的。各家定价页的措辞不一致的时候,先去站内的 /price-watch 对一遍当期变动记录,再回各自定价页确认细节,比自己硬猜靠谱。

要核对的项常见坑怎么确认
计价单位按千计价写成每百万定价页单位那一行逐字看
输入输出方向只记了输入价忘了输出价按自己日志里输入输出比例折算
缓存与批处理折扣没算进月成本问清哪些请求算命中
限速与最低消费低价档排队拖慢整体小流量压测一遍看延迟

把国内模型按价格档位分组看待

与其记一堆具体数字,不如先记住「档位」这个概念。国内主流模型大致可以分成入门、主力、旗舰三层,同一层里不同厂商价格有高有低,但定位和适用任务是比较接近的。分组的目的是决定哪些活可以下放,而不是给厂商贴好坏标签。

  • 入门档:单价低、并发给得足,适合分类、抽取、格式转换这类判定型任务;
  • 主力档:价格和效果折中,覆盖大多数对话、写作、代码补全场景,是默认选项;
  • 旗舰档:单价最高,只用在复杂推理、长链路 Agent、代码重构这类高价值任务上;
  • 分层之后要做的是把每个业务任务归到某一层,而不是整个产品绑死一家。

补充一句:档位不是固定的,新模型出来会重新洗牌。所以每次做完分组,把分组依据记在自己文档里,过一阵重跑一遍,比背一张价格表有用。当期各档位的实际价位,去 /official-api 和 /providers 核对当时的数字。

把单价换算成你自己的月度花费

单价本身不是决策依据,你的用量折算出来的花费才是。同样一家,有人一个月花得少,有人翻好几倍,差别就在调用量和输入输出比例上。所以第三步的关键动作是先拿到真实用量,再横向代进去算。

  1. 取一周用量日志统计输入 token 总量、输出 token 总量和请求次数,别用估算值
  2. 代进成本计算用 /tools/model-cost-calculator 把候选几家单价代进去,得到同一份用量的横向数字
  3. 留出冗余实际值通常比理论值高,重试、超长上下文、工具调用都会推高用量,留出缓冲
  4. 写成组合结论结论不要是「选一个万能模型」,而是「任务A走某档、任务B走另一档」
用量特征比价时看什么容易忽略什么
输入远大于输出输入单价权重更高缓存命中能不能省一截
输出远大于输入输出单价权重更高长输出的限速会不会卡住
请求次数多、单次短每次请求的固定开销有无最低消费
偶发超大上下文阶梯价怎么跳档超长请求是否限流

什么情况下这套比价不适用

任何方法都有边界,这套也不例外。下面几种情况里,价格不该放在第一位,硬套这套流程反而浪费时间和精力。

  • 数据合规要求必须走私有化部署或指定云厂商时,价格不是第一优先级,能不能合规才是;
  • 对延迟极敏感的场景,便宜的档位可能因为排队和限速拖慢整体,省的钱抵不上体验损失;
  • 用量很小的时候,折腾比价的收益还不如先把业务跑通,等量上来了再回头算。

还有一类容易被忽略:任务对效果要求很高,便宜档位反复返工重试,实际消耗可能比一次用贵档更高。判断标准不是单价,是「跑完这件事要花多少总成本」。拿不准的时候去 /rankings 看看同期横向对比,再结合自己任务实测。

一次比价的排查顺序清单

把前面的内容收成一份可以照着走的顺序,每次选型或者复查的时候从第一步往下走,做完打勾。顺序本身比单点结论更重要,因为它能保证口径一致。

步骤动作产出
第一步锁定 2 到 3 个候选模型,不要一上来铺开十个候选清单
第二步统一口径,补齐输入输出、缓存、限速三项口径表
第三步用真实用量算月度数字,去 /official-api 和 /providers 核对当期档位成本对照
第四步跑一次小规模对照,效果不达标的直接淘汰效果结论
第五步写进选型记录,标好复查时间,价格变动后重跑选型文档

这份清单的最大价值是防止你中途跑偏,比如第三步核对档位的时候顺手翻到了别家的介绍,一上午就没了。每步产出一个明确结果再往下走,整件事基本能在半天内出结论。

排完之后怎么跟住变化

选型不是一次性动作,排完就锁死迟早会出问题。聪明的做法是把关注项登记起来,改动发生时先判断影响大不大,再决定要不要切,而不是一有风吹草动就迁移。

  1. 登记关注模型把在用的模型加进价格追踪页,改动时能第一时间收到提醒
  2. 先看差额幅度小幅波动不值得动,先判断这次改动会影响多少月度成本
  3. 同批提示词对照切换前用同一批提示词跑一次对照,别只看单价降了
  4. 折算渠道实际价如果走中转渠道,还要看渠道倍率折算后的实际单价,不能只比官方牌价

中转渠道的倍率是个容易被漏掉的变量,它的折算方式各家不一样,直接决定你实际付多少。具体规则和当期倍率去 /sites 看各家说明,再结合自己的调用量算。切换前也建议用 /tools/speed-test 压一遍,确认延迟和稳定性没退步。

比价比的不是谁便宜,是你的每一类任务落在哪一档上最划算。
下一步把你现在在用的模型和候选模型列出来,去站内价格追踪页登记一遍,再拿最近一周的真实用量算一次月度花费,你会比看十张排行表更有底。

常见问题

国内模型 token 价格排行在哪里能看到最新数字?

没人能给你一份长期有效的固定表,厂商调价和活动都很快。做法是到 /official-api 看各家官方当期档位,再用 /price-watch 对一下近期有没有变动,两个页面合起来看就是当前的真实价位。站内不写死数字也是这个原因。

为什么两个模型的单价看起来差不多,实际账单差很多?

多半是输入输出比例和缓存命中的差别。有的模型输入便宜输出贵,有的反过来;你的任务如果是长文档摘要,输入占比高,结论会完全不同。先把平均输入输出长度算出来,再回定价页代一遍,才知道差价从哪来。

便宜档位的模型能不能直接替换掉主力档?

要看任务类型。分类、抽取、固定格式输出这类判定型任务,下放到便宜档通常没明显损失;涉及多步推理、长链路工具调用、代码重构的,换过去容易反复重试,最后反而更贵。建议先挑一两个任务做小规模对照,别整体替换。

比价的时候要不要把免费额度和赠送额度算进去?

可以作为短期缓冲,但不能作为选型依据,因为额度和赠送都有有效期和限速限制。正确做法是先用付费单价算出真实成本,再单独评估免费额度能覆盖多少试跑阶段,两笔账分开。相关口径可以对照 /usage 上的实际用量分布。

自己算的月度花费和账单对不上怎么办?

先检查三处:有没有缓存命中没计入、有没有重试产生的重复请求、单价用的是不是当期档位。把这三项排掉再对比,如果还有明显差距,就把用量日志按天拆开,找出异常那天是哪类任务在烧钱。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。