按量计费 还是 按次 推荐计费好

同一个功能，有人报按 token 算，有人报一次调用多少钱，签完才发现账单口径对不上。这篇不讲哪家便宜，只给你一套判断顺序：先看你的调用形态是长是短、是稳定还是稀疏，再去站内页面把当期单价抓出来套进去比。看完能自己下结论，也能说清什么情况下这套算法不成立。

同一个功能，A 家按 token 报，B 家按一次调用报，你把两份报价单摊在一起，发现根本没法直接比大小。这不是谁贵谁便宜的问题，是口径不一样：一个把波动留给你，一个把波动留给供应商。要选对，顺序是先看你自己的调用形态，再拿站内页面上的当期单价套进算式，最后看哪些条件会让这套算盘失灵。

下面不讲哪家划算，只给一套可以自己跑一遍的判断流程。看完你应该能自己下结论，也能说清什么情况下这套算法不成立、需要重新算。

先把两种口径的差别说清：变的是谁承担波动

按量计费的单价挂在计量单位上，token、字符、分钟、张数都算，你的调用内容越长、次数越多，账单就跟着涨。按次计费则是一笔调用一个价，这次你塞了一千字还是十个字，对费用基本没影响，账面上更像一笔固定成本。

真正要盯的不是单价高低，而是波动落在谁头上。你自己的内容长度不可控，波动就转嫁给供应商，按次更稳；你自己的调用次数不可控，按量反而不会因为次数爆发而顶到天花板。

• 按量：单价跟着用量走，账单随调用形态波动，长文本、批量任务里消耗会明显放大
• 按次：单价跟着调用笔数走，单次内容量对费用几乎无影响，适合内容长度不可控的场景
• 比价前提是先对齐单位，别拿「一次」和「一千 token」直接相除，口径不一致算出来的结论一定是错的
• 隐形项要先摆出来：按量有缓存、批量优惠，按次有并发上限、超时重试另算，这些不进公式就会低估

什么形态配什么计费：三个自测问题

不用一上来就找最便宜的报价，先回答三个关于自己业务的问题，答案会把方向收窄到某一侧。

1. 看单次内容量稳不稳固定模板抽字段、固定长度摘要，内容量稳定，按量算得清楚；用户随手贴长文、上传附件、多轮对话，长度忽长忽短，按次更省心。判断方法：抓一批真实请求，看单次长度的分位数，头部和尾部差得越远，越偏向按次。
2. 看调用频率稳不稳高频密集的调用，按量更容易在采购时谈出阶梯或折扣；低频零星的调用，按次不用预测用量，结账时不会因为某个周末的活动量翻倍而吓一跳。
3. 看失败重试多不多按次计费下重试等于再付一次钱，按量计费下重试只消耗实际用掉的那部分。重试率高的链路要单独拉出来算一遍，不然总价对不上。

三个问题里有两个指向同一侧，基本就可以定。只有一个指向，说明你的用量规模还不够大到让口径差异产生决定性影响，先按接入成本更低、对账更省心的那侧走，后面量起来了再重算。

动手比一遍：把两种报价折算到同一批真实用量上

这一步的核心是把两种口径压到同一批真实数据上，而不是拿两份报价单当模型去推演。下面这个顺序照着做，中间别跳步。

算完别忘了加隐形项：重试率、失败率、超时、并发上限带来的排队成本，都挂在真实成本上。单价是会动的，站内官方价格页和模型成本计算器给的是当期数字，换算的时候去那里核对，别用几个月前的记忆。

这些情况套公式会算错

上面那套换算在干净的前提下成立，一旦掺进下面几种情况，结论会失真。算之前先对一遍，中了的先把这部分剥离或单独标注。

• 有免费额度或赠送额度混在账单里：分摊口径没对齐，算出来的实际单价会偏低，先把免费部分剥掉再看
• 有缓存、批量、阶梯折扣：实际单价不等于挂牌单价，折扣条件不满足就白算，要确认触发门槛
• 业务量本身在爬坡：今天的临界点过一阵子就被推翻，用量翻倍要重新跑一遍换算
• 按次计费带隐含时长或并发上限：超了要么排队要么加钱，这部分不体现在单价里，务必向供应商问清

还有一种情况：你的调用量小到两种口径的差额还不如一次接入的人力成本，这时候别继续纠结，选接入流程短、对账简单的那侧，把精力留给业务本身。

落成一份能拿给团队和供应商的对照表

算完之后不要只留一个结论在脑子里，落成一张表，让团队和供应商都能对着同一组数字说话。表里至少包含两种口径下的月总价、单价临界点、隐形加项三项，谁的账更清楚，谁在评审里更容易被选中。

表下面写清不适用条件：低于多少调用量时不用纠结口径，哪个前提变了要重算。再约定一个复盘周期，用量结构一变就重跑一遍上面的换算，别让当初的选择一直挂在那里。

落地时还要留痕：实际用量和账单做定期核对，用站内用量日志的字段口径对齐记录，后面换方案或跟供应商对账时拿出来就有据可依，不用靠回忆拼账。