按量计费 还是 按次 对比计费好

选型时最常卡住的一步：同一个模型，一家按量计费（按 token 结算），一家按次计费（按调用次数结算），报价看着都行，放到你自己的业务量上就差出好几倍。这篇不讲谁绝对便宜，只给一套判断顺序——先把两种口径对齐，再算出你自己的临界点，最后看什么情况下该换另一种。

选型时最常卡住的一步：同一个模型，一家按量计费（按 token 结算），一家按次计费（按调用次数结算），报价看着都行，放到你自己的业务量上就差出好几倍。问题不在谁更便宜，而在你还没把两种口径放到同一把尺子上量。

这篇不讲结论，只给判断顺序：先把计价单位对齐，再算出属于你自己的临界点，最后看什么情况下该换另一种。全程用你自己的日志算，别用对方给的示例场景——示例都是挑过的。

两种计费，量的其实是两种不同的东西

按量计费量的是消耗：输入输出多少算多少，同一句话短和长价钱不一样。按次计费量的是动作：调一次算一次，内容长短不影响单价。这两句话决定了它们各自的友好区间，而不是谁先进谁落后。

• 先别比单价，先确认对方说的「一次」怎么界定：含不含重试、含不含流式中断、超长请求会不会被拆成多次。
• 按量那边同样要问清：缓存命中的输入算不算、图片和工具调用怎么折算、失败的请求退不退。
• 口径对齐的通用规则和几个必查字段，可以到 /ai-nav/category/ai-api 和 /official-api 对照着看。
• 把两边的说明都截图存档，之后账单对不上，这就是唯一的依据。

算出你自己的临界点：平均每次消耗多少 token

临界点不是一个别人给你的数字，是你自己日志里算出来的。拿最近一周的用量记录，用「总消耗 token ÷ 总调用次数」得到平均每次消耗。这个平均值就是你的分水岭。

1. 取样本导出最近一周的调用日志，至少覆盖一个完整的业务高峰和低谷，只取一天的样本容易失真。
2. 算均值总消耗除以总调用次数，得到平均每次 token 数。按输入、输出分开算更准，两者的单价口径常常不一样。
3. 看分布把每次消耗排个序，看头部那几次是不是特别大。少量超长请求会把均值拉高，这种情况要按分位数算，不要只看均值。
4. 做换算把按次单价折成等效 token 量，和你算出的平均值比：平均值明显低于它，按量更省；明显高于它，按次更省。换算和试算可以直接用 /tools/token-price-calculator 和 /tools/model-cost-calculator。

按次计费最容易被忽略的三件事

按次看着简单，但它的成本经常不在单价上，而在限制条款和返工里。签之前把下面三条过一遍，比多砍几个点更有用。

频次上限

按次套餐通常带调用频率限制，超了要么排队要么报错；重试一次就是再算一次钱。

内容长度上限

按次的「一次」往往有长度上限，超长请求被拒或被截断，省下的钱可能变成返工成本。

成本归因

按次很难拆出哪个功能烧得多；按量至少有 token 维度可拆，分摊做法参考免费额度相关的站内指南。

• 重试是不是单独计费，失败返回的请求算不算一次，这两条直接决定真实单价。
• 流式输出中途断开，已经产生的部分算不算一次。
• 并发限制是账号级还是 key 级，多业务共用时会不会互相挤占。
• 有没有超量后的降级策略，还是直接拒绝服务。
• 这些条款在活动价套餐里尤其容易变，到 /price-watch 核对当时的细则再决定。

一套可复用的判断顺序

把上面的动作串成固定顺序，下次换供应商直接照做，不用每次重新想。四步走完再决定，不要跳过第三步的时间维度。

1. 统一计价单位把两边都写成同一句话：多少钱对应多少 token，或者多少钱对应多少次，再各自换算成「处理同一份活要多少钱」。
2. 用真实混合比例算长短请求各占多少，用你自己的日志比例，不要用对方的示例场景。这个比例直接决定结论方向。
3. 加上时间维度量还在涨，偏按量（单价随规模走）；量稳定且请求都偏长，偏按次。预测未来三个月的量比纠结当下更重要。
4. 小流量先跑一周先按一种计费方式跑一周，对一次账单，口径有没有坑一周就能看出来。核对流程可参考 /guide 里的用量复盘方法。

什么时候不适用：量太小（比如一周只有几百次调用）时，两种方式的差额可能还不如你花在比对上的时间值钱，这时优先选接入简单、能随时换的，别为了一个零头把自己锁死。

还有一类情况：业务对延迟敏感、要求稳定并发，那就先把稳定性放第一位，计费方式退居其次——省钱的前提是服务不挂。