很多人比价是打开两个中转站页面,看谁那行数字小就选谁,结果充完发现实际单价比对方高一截——因为一行便宜的是输入价,另一行便宜的是首充赠送换算出来的假单价。这篇不评谁便宜,只给一套对齐口径:先在同一个模型、同一个计费项、同一个时间点上把数字摆平,再讨论贵不贵。
很多人比价的方式是打开两个中转站页面,看谁那行数字小就选谁,结果充完发现实际单价比对方高一截。问题不在眼力,在口径:一行便宜的是输入价,另一行便宜的是首充赠送换算出来的假单价,两个数根本不是一个东西。这篇不评谁便宜,只给一套对齐口径,先在同一个模型、同一个计费项、同一个时间点上把数字摆平,再讨论贵不贵。
核心思路只有四个字:三列对齐。模型对齐、计费项对齐、时间点对齐。这三列没对齐之前,任何价格差都是假的。对齐之后,再把赠送、月卡、限时特惠从单价里剥出来,你看到的数字才是能拿来算总价的钱。
三列对齐:模型、计费项、时间点
第一列锁模型。同一家的不同档位、或不同家的同名档位,先确认是不是同一个东西。同名不代表同版本,档位名称相近也不代表能力相同。版本对不上,后面比出来的数就没有参考价值,直接跳过这组。
第二列锁计费项。输入、输出、缓存写、缓存读、图片按张、语音按分钟,这些在计价上是分开的项,不是同一个价格。你把输入价和输出价放在一行里比,等于拿苹果比橘子。第三列锁时间点。价格会变,两边页面若是不同时期截的图,比出来的是时间差不是差价。
| 对齐列 | 要确认什么 | 不对齐的后果 |
|---|---|---|
| 模型 | 档位是否同一个东西,版本能不能对上 | 版本不同,单价无可比性 |
| 计费项 | 输入 / 输出 / 缓存读 / 缓存写 / 按张 / 按分钟 | 把输入价和输出价比,结论翻转 |
| 时间点 | 两边数据是不是同一时期的 | 比的是时间差不是差价 |
三列都对齐之后再谈倍率。倍率本身没有好坏,它只是一个系数。基准价一样、倍率一样,出来的单价才一样。基准不同、倍率相同,单价照样差得远。所以看到「我们倍率低」这种话,先确认它乘的那个基准是不是你比的那一个。
把赠送、月卡、限时特惠从单价里剥出来
首充赠送要除以它附带的额度上限。除出来的不是长期单价,是「前 N 次调用」的均价。额度用完就回到原价,这才是你要比的数。如果你一个月只跑几次,赠送确实能用很久,但那是你用量小,不是它单价低。
月卡类套餐要换算成「额度 ÷ 有效期」,再和你按量调用量比。用量低于套餐额度时,套餐并不划算,你等于为没用到的额度付了钱。限时特惠要标注失效条件,把到期后的价格一并记上。「有效期」和「用量上限」这两个条件,只要有一个不满足,这套结论就不适用于你。
- 首充赠送:除以附带的额度上限,得到的是前几次调用的均价,不是长期单价
- 月卡套餐:额度除以有效期,再对比你的实际调用量,用量低于额度就不划算
- 限时特惠:标注失效条件和到期后价格,比的是活动价还是常态价要分清
- 阶梯定价:写清每一档的触发用量,跨档之后单价会变,不能只看第一档
对比表的列怎么设计
列设计的目标是让下次比价不用重来。下面这套列,一行放一个模型档位,不同站点横向排,比纵向堆站点看得清。行数多的时候按档位分组,同一档位放一行。
| 列名 | 用途 |
|---|---|
| 站点 | 哪个中转站,名称写全 |
| 模型档位 | 对齐后的同一档位,标清版本 |
| 输入单价 | 原始单价,不含任何优惠 |
| 输出单价 | 原始单价,不含任何优惠 |
| 缓存项单价 | 读写分开记,混在一列会看不清 |
| 倍率说明 | 乘的是哪个基准,写清楚 |
| 优惠形式 | 首充 / 月卡 / 限时,注明条件 |
| 优惠后等效单价 | 单独一列,不要改动原始单价列 |
| 数据日期 | 复盘时唯一能解释差异的字段 |
「优惠后等效单价」单独一列,不要直接改动单价列。否则下次比价你分不清哪个是原价、哪个是折算过的。「数据日期」这列容易被省掉,但它是复盘时唯一能解释差异的字段:两个数不一样,先看日期是不是同一天。
一次完整对比流程
下面这套流程走完一遍,你手上会有一张能复用的对比表,而不是一个模糊的「感觉谁便宜」。每一步都有验证动作,做完再进下一步。
- 先写用法写下你要跑的任务,以及预估的输入输出比例。比例不对齐,便宜的定义会翻转:输出重的任务和输入重的任务,最便宜的那家往往不是同一个。
- 圈定候选到 /ai-nav/category/ai-api 挑出候选站点,先筛掉口径明显不明的。口径都说不清的,价格数字再小也没法用。
- 记原始单价逐站记录三列对齐后的原始单价,先别记优惠。这一步只记原价,优惠留到下一步单独处理。
- 单独记优惠用单独一栏记优惠形式与等效单价,换算可以到 /tools/token-price-calculator 做。原始单价列不要动。
- 代用量算总价把预估用量代进去算总价,而不是比单价大小。小额用量下单价的差异,往往被最低充值门槛和结算周期吃掉。
- 存档并更新结果连同数据日期存档,下次价格变动时只更新变动的格子。记住是哪几格变了,比重新比一整套省事。
第六步容易被跳过,但它是这套流程里最值钱的一步。没有存档,下次比价等于从零开始;有了存档,你只需要盯着变动的那几格看。
几种常见的错比法
下面这几种比法,结果看起来有数,其实不能用。对号入座一下,能省掉不少返工。
- 拿 A 站的输入价对比 B 站的输出价,两个计费项不同,这种对比没有意义
- 拿含赠送的等效单价对比别人的原价,会低估自己的实际支出
- 用不同时间点的截图做对比,尤其是刚调过价的那几天,比出来的全是时间差
- 只看单价不看最低充值门槛和结算周期,小团队容易在这里翻车
- 把不同档位的模型放在一行里比,档位不同,倍率和基准都可能不一样
还有一种更隐蔽的:拿「限时特惠价」当成长期成本写进预算。活动结束那天,你的成本结构就变了。比价时把活动价和常态价分两行记,就不会混。
比价不是比谁那行数字小,是把口径摆平之后再看谁的总价低。下一步拿一张真实的用量单,到 /price-watch 和 /official-api 核对当期数字,用上面的列设计做一张自己的对比表。→
常见问题
为什么两家写的单价差不多,实际账单差挺多?
多半是计费项没对齐。输入、输出、缓存读写的价格倍数关系各家不一样,你的任务如果输出占比高,看输入价得出的结论就会反。先把任务的实际输入输出比例算出来,再按这个比例加权,才有可比性。具体单价到站内官方 API 价格页核当期数字。
首充赠送算不算便宜?
算,但只算在你用完赠送额度之前。它改变的是前一段的均价,不改变长期单价。判断方法:把你预估的月用量代进去,算有赠送和无赠送两个总价,如果用量远超赠送额度,两者会快速靠近。这类对比的前提是你确实会把赠送额度用掉,用不掉就不适用。
月卡和按量哪个更值得比?
两者不是同一类东西,不能直接比单价。月卡比的是「额度够不够用、用不完亏多少」,按量比的是「用多少付多少」。做法是先看你的月用量落在套餐额度的哪个位置,明显低于就选按量,长期贴着上限才考虑套餐。套餐额度口径可以到 /coding-plans 翻对应档位页。