ai大模型价格对比

选型时最容易踩的坑，是拿A家的输入单价去比B家的订阅月费，或者拿官网标价去比中转站倍率，比完自己都说不清差在哪。这篇只讲一件事：把主流大模型的调用价和订阅价拉到同一条线上，用你自己的用量反推月成本，再决定选谁。适合正要给项目定模型、或者手上已经有两三个候选在纠结的开发者。

选型时最容易踩的坑，是拿A家的输入单价去比B家的订阅月费，或者拿官网标价去比中转站倍率，比完自己都说不清差在哪。这篇只讲一件事：把主流大模型的调用价和订阅价拉到同一条线上，用你自己的用量反推月成本，再决定选谁。

适合正要给项目定模型、或者手上已经有两三个候选在纠结的开发者。全文不给一个具体数字，因为单价、档位、倍率都在变，写死就没意义了；需要看当期数值时，会告诉你去哪个站内页面核对。

读完之后你应该能产出一张自己的比价表：左边是候选模型，右边是按你的真实用量算出来的月成本区间，中间标清楚哪些数是实测的、哪些是估的。

先分清两套价格体系：按量调用 vs 订阅套餐

调用价按 token 计费，用多少付多少，适合量不稳定、刚起步、或者用量有明显的波峰波谷。订阅价按月或按年固定，额度内不额外收费，适合每天高强度用、用量稳定的人。两套体系的计费触发点完全不同，混着比一定出错。

最常见的错是：拿订阅月费除以某个模型的输入单价，反推「相当于多少 token」，然后说订阅更划算。这一步的问题在于分母选错了——真正该除的是你自己的混合单价（输入输出加权后的），而且订阅额度往往不是按 token 计的。

• 判断标准一：一个月内使用天数超过一半、且每天有稳定强度，订阅才有比较的意义；偶尔用一次就按量
• 判断标准二：用量波动超过三倍时，按量更安全，订阅容易要么浪费额度、要么频繁超限
• 判断标准三：团队多人共用一个订阅时，先确认额度是账号级还是席位级，这直接决定覆盖率怎么算
• 具体单价和套餐档位不背数字，到 /official-api 与 /plans 看当期数值

比价前必须对齐的四个口径

单价看起来是个简单数字，实际上背后藏了四个口径。口径不对齐，后面的计算全是白费。下面这张表是把两家的数字放在一起之前，先逐项打勾用的。

四个口径里，最容易忽略的是渠道性质。官方页面的价格是直连价，中转站给你的往往是折算后的倍率，两者放一起比，就像拿标价和折扣价比，结论没有意义。判断方法是：先确定你要走哪条链路，再只在同一链路内比。

先用用量倒推，再谈谁便宜

比价的方向应该反过来：先算出自己一个月要花多少 token，再套进候选模型的单价。没有用量数据就比价，等于在猜。用量从哪来？有日志就从日志取，没有就先跑一批真实样本压测。

1. 取三个基础数日均请求数、平均输入长度、平均输出长度。输入输出一定要分开统计，因为两者的单价比例各家不同。
2. 乘出月 token 量日均请求数 × 30 得到月请求数，再分别乘平均输入长度和平均输出长度，得到两个独立的月 token 量。
3. 套进候选单价把输入量和输出量分别乘以候选模型的对应单价，相加得到该候选的月成本。每个候选算一遍，得到一列而不是一个数。
4. 区分实验期与上线后实验期用量通常偏小很多，选型要按上线后的量算。如果还没上线，就按预期的用户规模估一个区间，宁可估高一点。
5. 记录口径用量字段怎么留、按什么维度聚合，参考 /usage 的展示维度，或按 token-cost 里讲过的埋点口径去记，方便以后回填。

做完这一步你会得到一列月成本区间，而不是一个精确数字。区间就够了——选型阶段真正要判断的是「差几成还是差几倍」，不是小数点后的差异。

调用价和订阅价怎么放进同一张表

把按量成本和订阅成本放到同一张表里，关键动作是换算成同一个单位：token。每个候选做两栏，一栏是按量算出的月成本，一栏是订阅月费折算出的等价 token 额度。

订阅档位的额度口径各家不一样，有的是请求数、有的是积分、有的是信用点。先把它换算成 token，再和你的预测月 token 量比。换算这一步不要凭感觉，按官方给的额度口径硬算。

• 覆盖率 = 订阅额度 ÷ 你预测的月 token 量，这个比值是决定订阅还是按量的核心指标
• 覆盖率明显大于一，说明订阅大概率划算；覆盖率不到一半，通常别硬上订阅
• 超出额度的部分往往按更贵的口径计费，要单独算一遍超出部分的成本再相加
• 换算工具和订阅档位参数可以对着 /tools/model-cost-calculator 与 /coding-plans 一起看

注意一个容易漏的点：订阅额度是有有效期的。有的按月清零、有的滚存有限期。如果你的用量集中在某几天，订阅的额度可能用不完就浪费了，这种情况按量反而更合适。

阶梯价、缓存价、批处理价这些「看似更低」的价

价格表上经常有一堆比标准价低得多的数字：阶梯价、缓存命中价、批处理折扣价。看到这些先别高兴，它们都有触发条件，不满足时一个都用不上。

实操建议：先用标准价算一版保底成本，作为决策基准；再把上面这些优化价按你自己的命中率估一版乐观成本。两个数字都写进表里，差距大就说明你的用量模式对这些优化不友好。

按任务算，而不是按模型算

同一个任务换模型，成本变化其实来自两个地方：单价变了，以及 token 消耗量变了。便宜模型有时候话更多、思考更长，最后总价未必低。所以比价的最小单位应该是「任务」，不是「模型」。

1. 挑代表性任务从你的业务里挑两三个高频且典型的任务，覆盖短输入短输出和长输入长输出两类。
2. 各跑一遍完整链路每个候选模型在每个任务上跑一遍完整流程，记录实际的输入 token 和输出 token，不要用理论值。
3. 先确认效果够用把「效果够用」作为前置条件。效果不达标就直接淘汰，进入价格比较的必须是效果都过关的候选。
4. 比总价而不是单价用实测的 token 量乘以单价，得到每个任务在每个候选上的单次成本，再乘月调用量。

这一步不用追求精确，只要知道同一任务在候选之间是差几成还是差几倍就够了。差几成可以靠其他因素决定，差几倍基本不用纠结。

落到一张选型决策清单

前面所有步骤的产出，最后要收敛成一张能拍板的清单。清单的作用不是好看，是让你在评审时能说清楚每个结论的依据。

• 月用量估计：写清日均请求数、平均输入输出长度，以及上线后的预期规模
• 候选模型清单：只放效果已经验证过关的，不达标的单独列出去
• 按量月成本：每个候选一列，写明是标准价口径还是含优化口径
• 订阅折算成本：订阅月费换算成等价 token 额度，算出覆盖率
• 不确定项标注：哪些数字是实测的、哪些是估的，估的部分留出余量
• 切换阈值：设定月成本或用量超过多少就重新评估，避免上线后被动改

清单里最该被认真对待的是「不确定项」那一栏。选型阶段几乎不可能所有数字都实测，把猜测标出来，等上线后用真实账单回填，偏差大的原因记下来，下次会准很多。

哪些情况下这套比法不适用

比价方法有适用边界，硬套会得出错误结论。下面这几种情况，价格排序要让位给别的因素。

• 对延迟或稳定性有硬要求时，先看接口测速结果，在达标的候选里再比价格
• 有数据合规或部署位置限制时，可选范围本来就窄，比的是范围内谁更划算而不是全网最低
• 用量极小（个人试用、demo）时，花时间精算不划算，直接选接入成本最低的那个
• 候选之间模型能力差距跨档时，先按能力分层，同层内再比，否则单价比较没有意义

还有一种情况：如果你的业务对成本不敏感、但对效果敏感，那这套方法的输出应该被当成约束条件而不是决策依据——先选效果最好的，再确认成本在可接受范围内。

比价的目的不是找到最便宜的模型，而是让你能说清楚为什么选了这个，以及什么情况下该换。