打开几家官方价格页,一个按百万 token 标、一个按千 token 标、一个按字符标,还有一个写着倍率折扣,看半天也不知道谁便宜。这篇不给你结论,而是给一套可以自己套的换算思路:先把单位拉齐,再把赠送、折扣、缓存这些口径折成系数,最后乘上你的真实用量得到可比数字。每一步都给算式和检查点。
打开几家官方价格页,一个按百万 token 标、一个按千 token 标、一个按字符标,还有一个写着倍率折扣,看半天也不知道谁便宜。这篇不给你结论,而是给一套可以自己套的换算思路:先把单位拉齐,再把赠送、折扣、缓存这些口径折成系数,最后乘上你的真实用量得到可比数字。每一步都给算式和检查点,能自己验算,也能拿去和账单对。
核心就一句:比价不是把页面上的数字排个序,而是把每家报价化成「同一分母、同一口径、同一任务量」之后再比。下面四步按顺序做,做完你手上应该有一张自己算出来的对照表,而不是从别处抄来的排名。数据来源和当时的数字,去 /official-api 和 /price-watch 核对。
第一步:把单位统一到同一个分母
先确认分母是什么。有的按 token 报,有的按字符报,有的按张、秒、分钟报。分母不同就不能直接相减,这是最常被忽略的一步。中文按字符报价的,要先估出字符与 token 的换算比例再折算,比例因模型分词器而异,别套用固定值,最好拿你自己的样本实测一段算出来。
- 统一量级把「每千 token」乘一千、「每百万 token」除以一百万,统一成你习惯的那个量级,写成便于口算的系数,比如每百万 token 的价换算成每千 token 就除以一千。
- 拆开输入输出输入单价和输出单价是两条报价,平均价要按你自己的输入输出比例加权,公式是加权价=输入单价×输入占比+输出单价×输出占比,不能取算术平均。
- 机械换算出结果可到 /tools/token-price-calculator 和 /tools/model-cost-calculator 做机械换算,避免手算出错,再用自己的样本核对一次。
第二步:把折扣、赠送和倍率折成系数
统一单位之后,报价还只是「标价」,不是你实际会付的价。把每一项调整都写成一个系数,乘进算式里,别只在脑子里调。基本形式是:实付单价=标价×折扣系数×汇率系数×渠道倍率。哪一项不是 1,就在算式里显式写出来,后面复查才找得到来源。
- 折扣系数
- 按量阶梯或活动价,取值小于 1,注意它可能有时间窗口或用量门槛
- 汇率系数
- 外币报价换算成本地货币,取当天汇率,写清取值时点
- 渠道倍率
- 中转站在标价基础上的乘数,先看该站口径说明再决定乘在哪一步
- 赠送额度
- 一次性抵扣,有上限,不等于永久降价,要写成前 N 个 token 便宜、之后回到原价的分段表达式
- 赠送额度只在预算窗口内有效,折进单价时要写清分段边界,不能当成整体折扣
- 中转渠道的倍率含义各家不一样,有的乘在单价上,有的乘在用量上,结果相同但算式位置不同,先去 /sites 看该站口径说明再动手
- 缓存命中价通常单独一档,和普通输入单价不是一回事,漏掉它会把高频调用的成本算高
- 如果只是粗略排除明显更贵的几家,可以跳过赠送项,它通常不改变量级排序
第三步:从单价倒推出「一次任务多少钱」
单价层面的比较容易骗人,真正能跨计费模式比较的是「每完成一件活的成本」。公式是:单次成本=输入 token 数×实付输入单价+输出 token 数×实付输出单价。这里 token 数用你自己任务的平均值,不要用官方示例里的数字,示例往往是理想化的短文本。
| 任务类型 | 输入特征 | 输出特征 | 算的时候注意 |
|---|---|---|---|
| 长文档总结 | 一次几万 token 输入 | 输出较短 | 输入单价权重高,缓存命中要单独算 |
| 短问答 | 输入几百 token | 输出几百 token | 输入输出两边权重接近,别只比一边 |
| 批量改写 | 输入输出都中等 | 条数多 | 按单条算再乘条数,别直接乘批量总量 |
| 固定月费订阅 | 用量波动 | 可能超量 | 按临界用量两侧分别算,超量后跳到按量价 |
- 拿 3 个代表性任务各测一遍,任务间差距大的模型,比价结论会随任务类型翻转
- 把结果除以任务数,得到每完成一件活的成本,这个口径才能和按次、按订阅的模式比
- 固定月费订阅在低用量时单次成本被摊薄,一旦超量就跳到按量价,要按临界用量两侧分别算
- 如果任务量小到订阅用不满,按量模式可能反而更合适,别只看标价高低
第四步:交叉验证与常见算错点
算完不要直接信自己的表。拿上个月的真实账单对一次,看偏差方向。偏差明显就去查是不是漏了缓存命中、失败重试、限速后的重发,或者把输入输出单价搞混了。对得上,这套算式才算可靠,对不上,先修算式再下结论。
| 常见错法 | 错在哪 | 正确做法 |
|---|---|---|
| 输入输出单价相加当总价 | 两者适用比例不同 | 按实际输入输出占比加权 |
| 折扣后的价再乘一遍倍率 | 系数重复计入 | 每个系数只乘一次,写清位置 |
| 按字符报价当成按 token 报价 | 分母不同 | 先实测字符与 token 比例再折算 |
| 只看标价忽略缓存价 | 高频调用成本算高 | 缓存命中单独一档计价 |
| 结论不标时点 | 价格和口径都会变 | 标上基于哪天的页面报价,过段时间重新取数 |
结论一定要带上两个备注:一是基于哪天的页面报价,二是用了什么用量假设。价格会变,口径也会变,过一段时间回 /price-watch 和 /official-api 重新取数,把新数字代进同一套算式,就能快速更新自己的对照表。
下一步把这套算式落到一张自己的对照表上,再去站内价格追踪页核对当时的数字,比直接抄一份排名可靠得多。→常见问题
两家价格一家按千 token 标、一家按百万 token 标,怎么快速比?
统一到同一个量级再比,最省事的做法是都把倍数归到百万 token 上:按千 token 报价的乘以一千。注意输入和输出是两条价,别只比输入那一条,输出价往往才是成本大头。
折扣和赠送额度能直接当成降价吗?
不能。折扣是长期的、作用在单价上;赠送是有上限的一次性抵扣,用完就回原价。比价时把两者分开写:折扣写进系数,赠送写成前多少用量的分段优惠,这样算出来的数字不会过于乐观。
算出来的单价更低,就一定更划算吗?
不一定。单价低但输出冗长、重试率高、限速频繁的模型,实际完成同一件活的成本可能更高。建议用「每完成一件活的成本」来比,也就是把单价乘上你自己任务的平均 token 消耗,而不是只比裸单价。