同一个模型三种价:官方价、中转价、订阅价怎么折算比较

选站与采购

把官方价、中转价、订阅价统一折算成每百万 token 或每小时,给出换算步骤、常见误算点与对照模板。

同一模型,官方按量报一个价,中转站加着倍率报一个价,订阅套餐又是包月。三个数字放在一起根本没法直接比,凭感觉挑往往事后才发现亏。这篇给一套折算口径,把三种报价拉平成同一单位,再说清哪些情况算不准、算不准时该怎么办。

同一模型,官方按量报一个价,中转站加着倍率报一个价,订阅套餐又是包月,三个数字摆在一起根本没法直接比。凭感觉挑,往往事后才发现亏:要么高估了缓存省下的钱,要么忽略了输出比输入贵好几倍。

这篇给一套折算口径,把三种报价拉平成同一单位——每百万 token 或每小时,再算出一个混合单价,最后说清哪些情况算不准、算不准时该怎么办。目标不是找到全网最低价,而是让你在同样一批任务上,能算清楚到底哪条路更划算。

为什么三种价没法直接比

官方价按输入输出分开标、按量走;中转价通常在官方价上乘一个倍率,可能还改了口径;订阅价是固定月费买一个额度池。三者的计费单位、结算周期、失效条件都不一样,直接比数字等于拿长度比重量。

  • 先定「你要比什么」:是比同一批任务的绝对成本,还是比单价高低。目的不同,折算方式也不同。
  • 折算前先估自己的输入输出比例和缓存命中率,这两个数比单价本身更能左右结论。
  • 如果只是偶尔试几个任务,折算到每百万 token 意义不大,直接按小额实测花费比更省事。
  • 别拿别人晒出来的单价当自己结论,用量结构不同,同一个单价对你的意义完全不一样。

第一步:把三种报价都归到每百万 token

统一到「每百万 token」再比,核心是把每个报价都拆成输入价和输出价两个数,再用你自己的占比加权成混合单价。口径拿不准时,去站内工具页手算一遍,比凭记忆推演靠谱。

  1. 官方价直接读输入价与输出价两栏,不用换算,但要看清楚单位是「每百万」还是「每千」,单位差一个数量级。
  2. 中转价官方单价 × 站点倍率 × 分组系数。倍率和分组的含义去 /sites 与对应站点的报价单核对,别用记忆里的旧数。
  3. 订阅价拿套餐月费除以当月可用额度(按 token 计的那个数),得出名义单价。额度按次或按小时计的,先估你每次任务平均消耗多少 token。
  4. 加权成混合单价用你的输入输出占比给两个数加权:混合单价 = 输入价 × 输入占比 + 输出价 × 输出占比。这才是可比的数。
  5. 核对口径到 /tools/token-price-calculator 与 /tools/model-cost-calculator 对一遍,避免手算时单位错位或漏乘系数。
报价类型原始口径折算动作容易漏的
官方价输入/输出分开标直接取数,确认单位每百万还是每千
中转价官方价乘倍率官方价 × 倍率 × 分组第二层乘法与活动折扣
订阅价月费买额度池月费 ÷ 实用额度额度清零与结转规则
按次计费每次固定价估单次平均 token任务长度差异被抹平

这张表只是折算的动作清单,具体数字要现场填。价格会变,模板里的数值不要长期沿用。

第二步:三个最容易算错的点

同样两个单价,算错一个系数结论就反了。下面三个点是最常翻车的地方,每个都给了判断标准和不适用的边界。

  • 缓存价:命中缓存的部分通常只按输入价的一个比例计费。把整段输入都按原价算会明显高估;反过来,以为缓存能覆盖全部输入也会低估。先问清哪些请求类型能命中缓存。
  • 输出占比:输出单价普遍高于输入。任务输出很长(长文、代码、结构化数据)时,只盯输入价会挑错站。把自己的输出占比估出来再比。
  • 倍率叠加:有些报价是「官方价 × 倍率」再叠分组系数或活动折扣,两层乘法很容易漏一层。最稳的办法是让客服给出一个「最终每百万 token 单价」的口径。
  • 订阅额度清零:额度按月清零、用不完不结转的套餐,实际单价要按你真实用掉的部分算,不能按额度池总量算。
  • 不适用的边界:按次计费的站点、有并发或速率限制的套餐,折算出的单价仅供参考,真实成本还要看单次任务消耗和限速带来的等待。

第三步:套一张对照模板,再验一遍

把上面的口径固化进一张对照表,填完做两步验证,比反复讨论更有用。模板的重点不是列全,而是留出验证和复查的入口。

报价来源计费单位输入价输出价倍率/分组缓存规则额度结转备注
官方每百万 token待填待填无部分命中打折不适用以站内当时数字为准
中转 A每百万 token待填待填待填待确认不适用问客服要最终单价
订阅 B月费买额度折算折算无按规则清零/结转按真实用量算
实测按次小额不适用不适用不适用不适用不适用一次任务的实付
  1. 回填真实用量拿你最近一段真实用量填进模板,看算出来的钱和实际账单差多少。
  2. 小额实测挑一个典型任务做小额实测,比对预估值和实际扣费。偏差大就回头查口径。
  3. 定期复查价格会变,定期到 /official-api 与 /price-watch 核对当时的数字,别用旧数做长期决策。
  4. 跨模型参考要比跨模型性价比,可参考 /usage 看真实用量分布,但那是别人的用法,只能当参照不能当结论。

差值超过预期时,第一反应应该是回去查口径,而不是直接判定「这家便宜」或「那家贵」。口径错了,结论一定错。

算完之后怎么选

折算只是手段,选哪条路取决于你的用量形态和风险偏好。下面是分场景的判断标准,每种都标了失效条件。

  • 用量稳定、输入输出比例清楚、在意单价:优先按量走官方或可信中转,用混合单价对比。比例变了就要重算。
  • 用量波动大、想控制上限、怕超支:订阅或预付额度更合适,但要把额度清零规则算进去。
  • 任务量很小、只是验证效果:别急着做长期折算,先小额实测,花小钱拿到真实数据再决策。
  • 任何结论都要写清失效条件:模型换代、站点调价、任务结构变化,都会让原来的折算结果作废,隔一段时间重算一次。
单价只是入场券,你的输入输出结构和缓存命中率才是决定账单的那只手。
下一步拿你的真实用量去 /tools/token-price-calculator 跑一遍,再到 /price-watch 核对当时的中转报价,最后去 /sites 挑两三家做小额实测,比在这场讨论里空算强得多。

常见问题

中转站的倍率是乘在哪个价格上?

要问清楚是乘在官方输入输出单价上,还是乘在一个已经打包的均价上。前者你能自己验算,后者只能听客服说。让客服直接给你「每百万 token 输入多少钱、输出多少钱」,两个数拿不到就换一家比。

订阅套餐折算出来的单价更低,是不是一定更划算?

不一定。折算单价低的前提是额度能用完、且没有限速拖慢你的活。用不完、被限速、额度月末清零不结转,这三种情况都会让实际单价高于名义单价。先按你真实用量估一遍,再看名义单价。

缓存到底该怎么算进去?

先统计你的请求里有多大比例是重复前缀,乘上缓存输入价,剩下的按原价算,两部分相加再除以总输入量。比例拿不到就先按零算,得到一个保守上限,等真实用量记录出来再修正。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。