同一模型,官方按量报一个价,中转站加着倍率报一个价,订阅套餐又是包月。三个数字放在一起根本没法直接比,凭感觉挑往往事后才发现亏。这篇给一套折算口径,把三种报价拉平成同一单位,再说清哪些情况算不准、算不准时该怎么办。
同一模型,官方按量报一个价,中转站加着倍率报一个价,订阅套餐又是包月,三个数字摆在一起根本没法直接比。凭感觉挑,往往事后才发现亏:要么高估了缓存省下的钱,要么忽略了输出比输入贵好几倍。
这篇给一套折算口径,把三种报价拉平成同一单位——每百万 token 或每小时,再算出一个混合单价,最后说清哪些情况算不准、算不准时该怎么办。目标不是找到全网最低价,而是让你在同样一批任务上,能算清楚到底哪条路更划算。
为什么三种价没法直接比
官方价按输入输出分开标、按量走;中转价通常在官方价上乘一个倍率,可能还改了口径;订阅价是固定月费买一个额度池。三者的计费单位、结算周期、失效条件都不一样,直接比数字等于拿长度比重量。
- 先定「你要比什么」:是比同一批任务的绝对成本,还是比单价高低。目的不同,折算方式也不同。
- 折算前先估自己的输入输出比例和缓存命中率,这两个数比单价本身更能左右结论。
- 如果只是偶尔试几个任务,折算到每百万 token 意义不大,直接按小额实测花费比更省事。
- 别拿别人晒出来的单价当自己结论,用量结构不同,同一个单价对你的意义完全不一样。
第一步:把三种报价都归到每百万 token
统一到「每百万 token」再比,核心是把每个报价都拆成输入价和输出价两个数,再用你自己的占比加权成混合单价。口径拿不准时,去站内工具页手算一遍,比凭记忆推演靠谱。
- 官方价直接读输入价与输出价两栏,不用换算,但要看清楚单位是「每百万」还是「每千」,单位差一个数量级。
- 中转价官方单价 × 站点倍率 × 分组系数。倍率和分组的含义去 /sites 与对应站点的报价单核对,别用记忆里的旧数。
- 订阅价拿套餐月费除以当月可用额度(按 token 计的那个数),得出名义单价。额度按次或按小时计的,先估你每次任务平均消耗多少 token。
- 加权成混合单价用你的输入输出占比给两个数加权:混合单价 = 输入价 × 输入占比 + 输出价 × 输出占比。这才是可比的数。
- 核对口径到 /tools/token-price-calculator 与 /tools/model-cost-calculator 对一遍,避免手算时单位错位或漏乘系数。
| 报价类型 | 原始口径 | 折算动作 | 容易漏的 |
|---|---|---|---|
| 官方价 | 输入/输出分开标 | 直接取数,确认单位 | 每百万还是每千 |
| 中转价 | 官方价乘倍率 | 官方价 × 倍率 × 分组 | 第二层乘法与活动折扣 |
| 订阅价 | 月费买额度池 | 月费 ÷ 实用额度 | 额度清零与结转规则 |
| 按次计费 | 每次固定价 | 估单次平均 token | 任务长度差异被抹平 |
这张表只是折算的动作清单,具体数字要现场填。价格会变,模板里的数值不要长期沿用。
第二步:三个最容易算错的点
同样两个单价,算错一个系数结论就反了。下面三个点是最常翻车的地方,每个都给了判断标准和不适用的边界。
- 缓存价:命中缓存的部分通常只按输入价的一个比例计费。把整段输入都按原价算会明显高估;反过来,以为缓存能覆盖全部输入也会低估。先问清哪些请求类型能命中缓存。
- 输出占比:输出单价普遍高于输入。任务输出很长(长文、代码、结构化数据)时,只盯输入价会挑错站。把自己的输出占比估出来再比。
- 倍率叠加:有些报价是「官方价 × 倍率」再叠分组系数或活动折扣,两层乘法很容易漏一层。最稳的办法是让客服给出一个「最终每百万 token 单价」的口径。
- 订阅额度清零:额度按月清零、用不完不结转的套餐,实际单价要按你真实用掉的部分算,不能按额度池总量算。
- 不适用的边界:按次计费的站点、有并发或速率限制的套餐,折算出的单价仅供参考,真实成本还要看单次任务消耗和限速带来的等待。
第三步:套一张对照模板,再验一遍
把上面的口径固化进一张对照表,填完做两步验证,比反复讨论更有用。模板的重点不是列全,而是留出验证和复查的入口。
| 报价来源 | 计费单位 | 输入价 | 输出价 | 倍率/分组 | 缓存规则 | 额度结转 | 备注 |
|---|---|---|---|---|---|---|---|
| 官方 | 每百万 token | 待填 | 待填 | 无 | 部分命中打折 | 不适用 | 以站内当时数字为准 |
| 中转 A | 每百万 token | 待填 | 待填 | 待填 | 待确认 | 不适用 | 问客服要最终单价 |
| 订阅 B | 月费买额度 | 折算 | 折算 | 无 | 按规则 | 清零/结转 | 按真实用量算 |
| 实测 | 按次小额 | 不适用 | 不适用 | 不适用 | 不适用 | 不适用 | 一次任务的实付 |
- 回填真实用量拿你最近一段真实用量填进模板,看算出来的钱和实际账单差多少。
- 小额实测挑一个典型任务做小额实测,比对预估值和实际扣费。偏差大就回头查口径。
- 定期复查价格会变,定期到 /official-api 与 /price-watch 核对当时的数字,别用旧数做长期决策。
- 跨模型参考要比跨模型性价比,可参考 /usage 看真实用量分布,但那是别人的用法,只能当参照不能当结论。
差值超过预期时,第一反应应该是回去查口径,而不是直接判定「这家便宜」或「那家贵」。口径错了,结论一定错。
算完之后怎么选
折算只是手段,选哪条路取决于你的用量形态和风险偏好。下面是分场景的判断标准,每种都标了失效条件。
- 用量稳定、输入输出比例清楚、在意单价:优先按量走官方或可信中转,用混合单价对比。比例变了就要重算。
- 用量波动大、想控制上限、怕超支:订阅或预付额度更合适,但要把额度清零规则算进去。
- 任务量很小、只是验证效果:别急着做长期折算,先小额实测,花小钱拿到真实数据再决策。
- 任何结论都要写清失效条件:模型换代、站点调价、任务结构变化,都会让原来的折算结果作废,隔一段时间重算一次。
单价只是入场券,你的输入输出结构和缓存命中率才是决定账单的那只手。下一步拿你的真实用量去 /tools/token-price-calculator 跑一遍,再到 /price-watch 核对当时的中转报价,最后去 /sites 挑两三家做小额实测,比在这场讨论里空算强得多。→
常见问题
中转站的倍率是乘在哪个价格上?
要问清楚是乘在官方输入输出单价上,还是乘在一个已经打包的均价上。前者你能自己验算,后者只能听客服说。让客服直接给你「每百万 token 输入多少钱、输出多少钱」,两个数拿不到就换一家比。
订阅套餐折算出来的单价更低,是不是一定更划算?
不一定。折算单价低的前提是额度能用完、且没有限速拖慢你的活。用不完、被限速、额度月末清零不结转,这三种情况都会让实际单价高于名义单价。先按你真实用量估一遍,再看名义单价。
缓存到底该怎么算进去?
先统计你的请求里有多大比例是重复前缀,乘上缓存输入价,剩下的按原价算,两部分相加再除以总输入量。比例拿不到就先按零算,得到一个保守上限,等真实用量记录出来再修正。