按量计费 还是 按次 教程计算

很多人选计费方式时只看单价，结果真跑起来账单和预期差一大截：按次看着便宜，但次数上去了并不省；按量看着灵活，可请求短、调用密的时候又未必划算。这篇给一套能直接套用的换算流程：先对齐口径，再用你自己的用量算一遍，最后看哪些变量会翻盘。全程只讲怎么算，具体单价去站内页面核当时数字。

选计费方式最容易踩的坑，是拿两种不同口径的单价直接比大小。按量计费的单位往往是 token、字符、秒、张，按次计费的单位是「一次请求」或「一个任务」，这两个数字放在一起本来就不可比。真跑起来账单和预期差一大截，多半不是价格变了，而是当初比的时候口径就没对齐。

下面这套流程分三步：先把两种计费换算到同一个分母，再用你自己的调用量和长度分布算总账，最后找盈亏平衡点、看清哪些变量会让结论翻盘。全程只讲怎么算，具体单价一律到站内页面核对当时的数字，别拿记忆里的旧价做决策。

第一步：把两种计费的单位对齐到「一次任务」

先选一个共同分母，一般就用你自己的典型任务，比如「生成一份周报」「跑一次代码审查」「转写一段录音」。这个分母选得越贴近真实业务，后面的账越准。分母定好之后，两边都往它身上换算，换算没做完就别急着比较。

• 按量口径：拿一段真实请求完整跑一遍，把输入、输出、重试、附带工具的消耗都记下来，只算主请求会严重低估
• 去 /usage 看真实用量的量级做参照，确认你记的数量级和账单展示的对得上
• 按次口径：先问清「一次」到底包多少，是否含重试、是否含失败调用、有没有并发或长度上限
• 口径含糊的方案先搁置，条件不清就比，等于用两个假数字互相验证，结论没有意义

第二步：用你自己的调用量和长度分布算总账

总账等于单个任务成本乘以月调用量，再叠加固定部分。调用量小的时候，固定成本占比大，单价差异几乎看不出来；调用量上去之后，单价差异才会被真正放大。所以同样两个方案，在不同团队手里结论可能相反，这很正常。

1. 按长度分档把你的请求按输入输出长度分成短、中、长几档，分别估出各档占比。按量计费对长请求更敏感，按次计费对长请求更友好，但短请求密集时结论常常反过来，不分档就会算错。
2. 加进重试成本估一个失败率，跑一版重试成本清单。按次方案里失败和重试往往照样计次，这部分漏算会让按次看起来比实际便宜。
3. 单列固定部分把月费、起步费、包含额度这类固定项单独摊到月调用量上，别混进单次成本里。去 /plans 和 /coding-plans 核对当期的档位与限额，只用当时的数字代入。
4. 两头各算一遍同一个用量分别按两种口径算出总成本，写成两行对照，差多少一目了然，再决定往哪边靠。

做完这一步，你应该能回答一个具体问题：在我现在的调用量和长度分布下，每个月哪种方式的总支出更低。如果算完两边差不多，那说明价格不是决策主因，转而看限速、稳定性、接入成本这些更实际的东西。

第三步：找盈亏平衡点，并确认哪些情况下结论会翻盘

盈亏平衡点就是两种方式总成本相等的那个月调用量。低于它偏向一边，高于它偏向另一边。把这个数字算出来，比记住「谁更便宜」有用得多，因为你的业务量会变，而这个点短期内相对稳定。

这套算法也不是万能的。用量波动极大、根本估不出月调用量的时候，算出来的平衡点参考价值有限；有强合规或数据驻留要求、只能走特定通道的时候，两种计费的差价往往不是决策主因，先满足硬约束再谈省钱。这些情况就别硬套流程，改用「先选可用方案、再在可选范围内比价」的思路。

• 结论要写成一句可复用的话：在我的用量区间和长度分布下，哪种更省、省在哪、什么条件下需要重算
• 给结论加一个复查触发条件，比如调用量翻倍、请求平均长度变化明显、或者价格出现调整
• 别把一次算出来的结论当永久结论，业务一变就该重跑一遍流程
• 具体数字随时会变，任何单价和限额都以站内页面当时的展示为准

比价之前先对齐口径，比完之后记住平衡点，而不是记住谁更便宜。