按需计费和按容量计费的区别

很多人第一次接模型时默认选了按需计费，用着用着发现月底账单忽高忽低；也有人听说包容量更便宜就提前签了，结果量没跑满，钱反倒白花。这两种模式不是谁更好，而是看你的用量形状。这篇给一套判断顺序：先看用量是平的还是尖的，再看你能接受多大的预测误差，最后看量不够时谁承担损失。

很多人第一次接模型时默认选了按需计费，用着用着发现月底账单忽高忽低，明明没做活动却翻了一倍；也有人听说包容量单价更低，提前签了一年的额度，结果量没跑满，钱反倒白花。问题不在哪个模式更先进，而在你的用量长什么形状。

这篇给一套可落地的判断顺序：先看用量是平的还是尖的，再看你能接受多大的预测误差，最后看量不够时损失由谁承担。三种情况对应三种选法，选错了换回来也麻烦，所以先想清楚再动手。

两种模式到底在买什么

按需计费买的是「实际发生的用量」，用多少算多少，停用即停，没有承诺也没有门槛，代价是单价通常高一档。按容量计费买的是「一段时间内的可用能力」，你先把额度或吞吐占住，再在这个池子里跑，折算单价更低，但提前付、提前锁。

把最近两到四周的日调用量拉出来，做成一行数字看波动。每天差不多、工作日和周末差别不大，属于平稳型，这种曲线最容易被容量池覆盖。反过来，有明显峰谷，或者干脆是脉冲式——有任务才跑，一天可能零调用——按需更稳，因为容量池闲着的时候你照样在付钱。

有一种情况这套判断不适用：用量太小。比如一个月就几万 token 的量级，两种模式的差价还不够你花时间算，直接选按需，把精力留给别的事。

第一步：算下限把「最保守也一定会用到」的量估出来，这是唯一值得用容量覆盖的部分。估不出下限就先别签，说明用量还没稳定。
第二步：算波动上限和下限差得越多，越不适合把全部量塞进一个容量池。常见做法是只覆盖下限那一层，超出部分留给按需，两层叠着用。
第三步：算溢出确认超量以后是走按需价、被限速还是直接被拒。到 /official-api/providers/openai 这类厂商资料页核对溢出规则，规则不明就先小规模试。

这张表的用法是横向看：五项里有三项落在同一列，就按那一列选；如果两列各占一半，说明你还没到能签容量的阶段，先按需再观察一两个周期。

模式定下来之前，有四件事必须逐条核对清楚。这些细节往往决定了你到底有没有真的划算，只看单价容易被带偏。

比价的时候不要只看对方给的折算单价，要拿你自己导出的真实用量去代。具体数字各家不同，到 /price-watch 核对当时的报价和计费口径，别用记忆里的旧价签长约。

上面那套三步法建立在「用量可以被估出来」的前提上。前提不成立时，结论要反过来看。

模式本身没有优劣，只有合不合你的用量形状；形状看不清的时候，按需是唯一不会错的默认项。

量跑不满按容量池，钱会退吗？

多数情况不退，或者只允许结转有限期、不能折现。所以签之前一定要把「最保守也一定用得到」的量当成下限，只对这一层买容量，超出部分继续走按需，这才是相对安全的组合。

用量忽高忽低，还能不能买容量？

能，但只覆盖谷底那一层。峰值的部分让它溢出到按需价，整体单价会比全按需低，又不会因为峰值拉高容量档位而白付钱。前提是你要确认溢出之后是走按需价而不是直接被限速打断。

两种模式能混着用吗？

可以，而且常见。基础盘用容量压单价，突发用按需兜底。混用之后账单会分成两段，做预算和核对时要把两段加一起看，不然容易误判真实单位成本，具体口径可以到站内官方 API 价格页对照。