国产模型价格对比

团队要选型时，最容易卡在一堆报价页里：有的按百万 token 标价，有的分档位、有的含缓存价，直接比数字往往比错。这篇给一套能落地的横向对比流程——先把口径对齐，再按价格梯队分组，最后用自家真实用量验证一遍，并说明哪些情况下这套比法不适用。

做选型的团队一打开各家国产模型的报价页，基本都会卡住：有的只给一个输入输出价，有的按上下文长度分档，有的把缓存读写单独列一行，还有的给了阶梯折扣和赠送额度。你把这些数字抄进一张表里横向一比，大概率比错——因为你比的根本不是同一个东西。

这篇给一套能落地的对比流程：先把计价口径对齐，再按定位分成价格梯队而不是硬排名次，然后换成自家一次任务的实际开销，最后用真实调用日志验证一遍。整套流程的目标不是挑出「最便宜的那个」，而是让你在半小时内排掉大部分错误选项，并说清楚剩下两三个为什么进决赛。价格数字时刻在变，本文不给任何具体数字，凡是需要数字的地方都告诉你去哪个站内页面看当时的版本。

国产模型价格为什么不好直接比

直接比数字会失真，核心原因不是厂商藏着掖着，而是每家的报价粒度天生不同。有的厂商一个价管所有输入，有的把输入和输出拆开算；有的按上下文长度切成几档，超过某个长度单价就跳一档；有的把缓存命中价单独列出来，看起来便宜但只有特定用法才吃得到。你把这些混在一起排名，等于拿苹果比橘子。

• 粒度不同：单一定价、输入输出分离、按上下文长度分档、缓存读写单独计价，四种结构混在一起没法直接排序
• 单位与币种不同：按 token 计价和按次计价要换算，人民币直付和境外结算的实际到手成本不一样
• 折扣结构不同：阶梯价、限时优惠、批量任务价，是否计入对比取决于你的用量够不够触发
• 额度口径不同：赠送额度算不算进对比、免费额度用完后的扣费顺序，都会影响账面数字
• 所以第一步不是看数字，是先把口径统一，具体口径差异到 /official-api 逐家核对

比价前先对齐四个口径

口径不统一，后面所有换算都是白做。这一步要产出的不是结论，而是一张所有候选都遵守同一套规则的空白表。表建好了，再去 /official-api 逐家填数字，填的时候顺手把数据来源页的链接记下来，方便后面复盘时确认有没有更新。

计价单位

按 token、按次还是按套餐折算，换算基准必须写死在同一张表里，不能这家用 token 那家用次

输入输出拆分

输入输出是否分开计价，缓存读写是否单独列一档，分开计价的话要按自家输入输出比例加权

额度口径

赠送额度、阶梯价、限时折扣是否计入对比，建议统一按「不依赖任何优惠的裸价」和「实际到手价」各算一列

币种与结算

人民币直付、境外卡结算、经中转渠道的倍率各不相同，后者的实际成本通常要到 /price-watch 看追踪记录

四个口径里最容易漏的是缓存价。如果你的业务是长系统提示词加短用户输入的问答，缓存命中率可能很高，这时缓存价那一档会显著拉低实际成本；反过来，如果你的请求每次上下文都完全不同，缓存价对你就是摆设，只看它反而会误判。所以在填表时，缓存价这一列要么标注「适用于高重复上下文场景」，要么干脆按你的命中率折算后再填。

1. 建一张统一口径的空表列固定为：计价单位、输入价、输出价、缓存读写价、分档规则、优惠条件、结算方式。所有候选按同一列填，缺的项写「不适用」而不是留空。
2. 去 /official-api 逐家填数字只填当前页面上的数字，填完把该页链接记在行尾。不要用记忆或二手资料里的价格，那是最常见的错误来源。
3. 给每行标注数据日期写清楚是哪个时间点从页面取的数字。价格更新频繁，没有日期的对比表过两周就不能用了。
4. 确认换算基准如果某家按次计价，在这一行注明你用的 token 折算假设，并把这个假设单独记下来，后面验证时要回头检查它准不准。

把主流国产模型分成几个价格梯队

对齐口径之后，不要急着按单价排名次。更实用的做法是按定位粗分成几个梯队，同一梯队内部才做细致比较。原因是：旗舰档和轻量档的单价差通常很大，把它们放在一张表里排名，结论永远是「轻量档最便宜」，但这对选型毫无帮助——你本来就不该拿轻量档去跑旗舰档的任务。

梯队划分本身会随时间变动：今天算旗舰的定位明天可能被下放，新梯队也可能冒出来。所以别把梯队表当成长期资产，它只是你这次选型的临时分组。具体档位到 /models 和 /official-api 看当时的分组，站内会按能力与价格两个维度给出对照。

把挂牌价换算成一次任务要花多少

挂牌价是每百万 token 多少，但你真正关心的是「跑一次我的任务要花多少钱」。中间隔着一层换算，而这层换算里藏着最大的误差来源：你对自己任务的输入输出 token 分布到底了不了解。很多人用「平均一次请求多少 token」拍脑袋，结果长尾请求一多，实际开销比估算高出一大截。

1. 量自家的 token 分布从真实日志里抽一批请求，分别统计输入和输出的 token 数，画出分位数而不是只取平均值。重点看 P90 和 P99，长尾才是花钱的地方。
2. 用站内计算器做换算到 /tools/token-price-calculator 把单价换算成单次成本，再到 /tools/model-cost-calculator 把单次成本乘以你的日调用量，得到月度量级。
3. 代入缓存命中率如果你的系统提示词固定，估算命中率后把缓存价那一档按比例代入。命中率靠猜的话，写清楚你猜的是什么值。
4. 加上重试冗余按失败率和重试次数乘一个系数，通常一笔请求不止调用一次。这个系数在小流量下看不出来，量大之后很明显。
5. 交叉检查结果把算出来的月度开销和候选之间的差值列出来。如果差值小到不影响预算决策，就别在单价上继续纠结，转去看能力和稳定性。

用真实用量做第二轮筛选

第一轮换算之后，通常会剩下两三个候选。这时候纸面计算已经到极限了，必须拿真实调用日志回放一遍。做法是把同一批历史请求分别打到候选上，记录实际计费的 token 数和成功情况，而不是只看单价表。

• 关注长尾请求：平均值漂亮不代表长尾便宜，超长上下文和高重试请求才是成本大头
• 关注失败重试：失败请求往往也计费或至少消耗配额，候选之间的重试率差异会放大成本差
• 关注限速影响：并发上限低会导致排队，排队不直接产生费用但会拖排期，量化成「需要多少台机器或多少时间」
• 关注输出长度波动：同一个提示词在不同模型上输出长度可能不同，按输出计价时这会直接影响账单
• 对比结论要写清用量结构：多少比例是短请求、多少是长上下文、多少带缓存命中，结构变了结论可能反过来

这一步的产出不是「谁更便宜」，而是「在我的用量结构下，谁更划算」。如果你的用量结构和测试时差别很大，比如测试用的是一批短请求而线上大量是长文档，那结论作废，得按线上结构重新跑一遍。

容易被忽略的隐性成本

单价差经常不是决策的决定因素，真正吃掉预算或拖慢排期的是几项不进报价页的东西。这些成本不好量化，但可以用清单的方式在决策时逐项打勾，避免事后才发现。

隐性成本里最容易被低估的是切换适配。如果两家接口结构相似、输出格式接近，切换可能只是一天的事；如果提示词调优很深、输出解析写得很紧，换一家可能要重做一轮调优。这笔人力成本单独看可能不大，但和单价差放在一起比，经常是切换成本更高。

选型决策清单与复盘节奏

把前面几步的结果收拢到一张对比表里，每行一个候选，列固定几项，并标注每项数据的来源页面。这张表就是你做决定的依据，也是后面复盘时的基线。

• 口径列：计价单位、输入输出是否分开、缓存价适用条件、结算方式
• 梯队列：属于哪个梯队，对应的能力边界是否满足硬性要求
• 单次成本列：按自家用量结构换算出的单次和月度量级，注明换算假设
• 隐性成本列：限速、额度规则、切换工作量、合规约束，逐项写有或无
• 数据来源列：每项数据取自哪个站内页面，方便更新时核对
• 复盘触发列：什么条件下重新比一次，比如用量结构变化、价格页更新、能力边界变化

复盘节奏别定得太密。价格页更新频繁，但你的用量结构不会天天变，每次更新都重算一遍是浪费。比较实用的触发条件有两个：一是自家用量结构出现明显变化，比如长上下文请求占比翻倍；二是站内价格追踪页面出现你候选名单里的变动提示，这时候到 /price-watch 核对当时的记录再决定要不要重算。

决策上不要追求一次选到理论最优。更稳的做法是先选一个可替换的方案，把接口封装和提示词尽量做得与具体厂商解耦，留好切换路径。这样即便后面发现更划算的选项，切换成本也在可控范围内。至于哪些中转渠道在可信度上更稳，可以到 /sites 和 /rankings 看当时的检测结果，但那属于另一条决策线，不要和价格对比混在一起做。

这套比法什么时候不适用

前面整套流程默认了一个前提：你的调用量足够大，值得花时间做细致比价。这个前提不成立的时候，硬套流程反而是浪费。下面几种情况应该直接跳过比价，或者换一套判断方式。

• 调用量极小、以试用和验证为主：这时候人工比价花掉的时间成本，远高于单价差异省下的钱，先跑通功能再说
• 任务对能力下限有硬要求：如果只有旗舰档能满足，便宜档位在校验阶段就直接出局，不必进入比价流程
• 需要私有化或合规托管：公开挂牌价参考意义有限，应该转向部署测算，包括硬件、运维和人力
• 用量结构还没定型：产品还在快速迭代，请求形态一周一变，这时候的比价结论很快就会过期，先选易替换的方案
• 预算决策不由单价主导：比如合规、交付周期、SLA 才是关键约束，那就先按这些条件筛，再在剩下的里面比价

比价的目的是排掉错误选项，不是找到那个小数点后更小的数字。

还有一种情况是把比价当成一次性任务。价格和能力边界都在动，一次选型结论的有效期通常不长。与其追求一次算准，不如把对比表和分析框架留下来，设定好触发条件，下次更新时改几个单元格就能复用。