API 按量还是买订阅：先算盈亏平衡点，再看三个变量
有个团队让我帮着看一笔账：他们给十几个人开了订阅席位，同时后端还接了 API 做批量处理，月底财务把两笔钱加在一起，问”能不能只留一个便宜的”。我把两边的用量拉出来一看，问题根本不是”哪个便宜”——订阅那十几个席位平均每天用不到二十次，按 token 算成本低得可以忽略；而后端那条批量链路一天几千次调用，订阅席位压根覆盖不了。两笔钱买的是两件不同的东西，硬要合成一件，只会两头都不舒服。
所以先把问题换个问法。不要问”订阅和按量哪个划算”，要问：这两种买法把不确定性分给了谁，哪一种不确定性我更扛得住。
- 订阅：成本固定，用量风险自担。你付一个确定的月费，用多用少都是这个数。用不满，钱白花；用超了，要么被限制要么被收超额费。
- 按量：成本随用量走，预算风险自担。你只为实际消耗付钱，但月末账单是多少，上线前谁也不敢打包票——它没有天花板。
这两句话里藏着本文剩下所有的内容。
一、盈亏平衡点：先把这道算术做完
任何关于”哪个划算”的争论，在算出平衡点之前都是空转。公式非常简单：
平衡用量 = 订阅月费 ÷ 单次按量成本
低于这个用量，按量划算；高于这个用量，订阅划算。难的不是公式，是右边那两个数你得填自己的。
假设参数的完整算例
下面这组数字全部是假设值，不代表任何厂商的实际报价，只是把算术演示一遍，你照着把自己的数替进去。
假设条件：
| 项目 | 假设值 |
|---|---|
| 订阅月费 | 200 元 / 席位 / 月 |
| 单次调用输入 | 2000 token |
| 单次调用输出 | 600 token |
| 输入单价 | 4 元 / 百万 token |
| 输出单价 | 12 元 / 百万 token |
单次成本：
- 输入：2000 ÷ 1 000 000 × 4 = 0.008 元
- 输出：600 ÷ 1 000 000 × 12 = 0.0072 元
- 合计：0.0152 元 / 次
平衡用量：
200 ÷ 0.0152 ≈ 13158 次 / 月
按每月 22 个工作日摊：13158 ÷ 22 ≈ 598 次 / 人 / 天。
这个结果值得盯着看一会儿。一个真人坐在对话框前，一天点五百多次是什么概念？基本不可能。也就是说，在上面这组假设下，一个交互式用户的纯 token 成本，远远填不满一个订阅席位的月费。
那订阅是不是就没意义了？不是。这道算术真正告诉你的是：订阅的定价基础从来就不是 token 本身。你付的那 200 元里，token 只占很小一块，剩下的是产品界面、会话管理、文件处理、权限与审计、以及”不用你自己写一行代码就能用”这件事的价格。拿订阅费去和裸 token 成本比大小，是在比两个不同的东西。
反过来看程序化那一侧。假设后端每天 3000 次自动化调用：
3000 × 22 = 66000 次 / 月
66000 × 0.0152 ≈ 1003 元 / 月
这一千块，是任何数量的订阅席位都替代不了的——原因见第三节。
你该去查自己的哪几个数
公式里的每个数都有明确的出处，别拍脑袋：
- 单次调用的真实 token 数。不要用测试样本估，用生产日志里的实际请求。最好取分位数而不是均值：P50 决定日常成本，P95 决定你会不会被少数长输入拖爆预算。系统提示词、few-shot 示例、RAG 召回的上下文全都算输入，这几块通常比正文大得多。
- 实际单价。以你所用平台控制台和官方价目表为准，注意输入输出分开计价、注意是否有缓存命中的差异价、注意计费单位到底是”千 token”还是”百万 token”——这个量级错一次就是三个数量级。相关坑我在价格表里那些容易看漏的地方里展开过。
- 每月真实调用次数。不是”预计用户数 × 预计频次”这种两层估算，是过去 30 天的实际计数。没有历史数据就先小规模跑两周，把单位经济账先算出来再谈月度总额。
- 重试和失败的放大系数。这一项最容易漏。失败重试同样计费，一个 5% 失败率加两次重试的链路，实际成本会比理论值高出可观的一截。
二、平衡点之外，还有三个变量决定结论
算完平衡点你会发现，很多情况下两边差得不远。真正决定该选哪个的，是下面三件事——而它们都不在那个公式里。
变量一：用量的波动性（要看分布，不要看均值）
均值一样，分布不同，结论可以完全反过来。还是用上面那组假设参数，再补两条假设：订阅方案含 10000 次 / 月额度，超出部分按 0.02 元 / 次计（同样是假设值）。
现在有两个团队，年度总用量完全相同，都是 157896 次，月均正好 13158 次——刚好卡在平衡点上。
A 团队（平稳型）：每月都在 13000 次上下。年度按量成本约 157896 × 0.0152 ≈ 2400 元；年度订阅成本 200 × 12 = 2400 元。两边打平，选哪个都行。
B 团队（尖峰型）：8 个月每月只有 5000 次，另外 4 个月每月 29474 次（8×5000 + 4×29474 = 157896，年均一致）。
- 按量：总量没变，还是 2400 元。
- 订阅：
- 淡季 8 个月，每月 200 元 = 1600 元。这 8 个月每月买了 10000 次额度只用 5000 次，白扔了 40000 次。
- 旺季 4 个月，每月超额 29474 − 10000 = 19474 次，超额费 19474 × 0.02 = 389.48 元，加月费共 589.48 元；4 个月合计 2357.92 元。
- 全年合计：1600 + 2357.92 = 3957.92 元。
同样的年度用量，订阅比按量多花 1557.92 元，贵了约 65%。订阅对波动的惩罚是双向的：淡季吃”用不满”的损失，旺季吃”超额单价通常高于标准价”的损失，两头都亏，中间没有补偿机制。
所以判断标准是：把过去 6 到 12 个月的月度用量画出来，看的是波动幅度，不是平均线。月度峰谷比在 1.5 倍以内，平衡点算出什么就是什么；峰谷比超过 3 倍，订阅要打个不小的折扣才值得考虑。
变量二：对可预测性的需求
这一条经常被工程师忽略，但在财务那边权重很高。
有些场景里，订阅的价值根本不在便宜，而在这个数字是确定的。典型情况：
- 对外报价里含了 AI 功能，你必须先锁成本才能定价，否则毛利飘着没法签合同；
- 预算走年度审批，超一分都要重新走流程，“可能三千也可能一万五”这种答案批不下来；
- 成本要摊进项目核算，需要一个能写进预算表的固定行；
- 团队里没人有精力天天盯账单。
在这些场景下，即便算出来订阅比按量贵 20%，也可能是对的选择——那 20% 买的是确定性，是一种保险费。反过来，如果你的业务本身就按用量向客户收钱（用得多收得多），成本随用量浮动反而是好事，两边天然对冲，这时候花钱买固定成本就是浪费。
判断方法很直接：问自己”如果这个月账单是预期的 3 倍，会发生什么”。如果答案是”财务问一下、解释清楚就过去了”，按量没问题。如果答案是”合同要亏损”或者”预算流程要重走”，那你需要的是可预测性，不是低价。至于按量这一侧怎么把可预测性补回来，见月度预算怎么定。
变量三：订阅席位到底含不含程序化调用（最常见的误判）
这是我见过最多人栽跟头的地方，单独拿出来讲透。
订阅席位和 API 额度，在绝大多数平台上是两套彼此独立的东西。 订阅通常是按”人”计价的产品使用权，覆盖的是一个真人坐在界面前的交互式使用；API 是按”调用量”计价的接口调用权，覆盖的是你的程序自动发请求。买了前者不等于自动获得后者，这两笔账往往在控制台里都是分开的两个页面、分开的两份账单。
误判长什么样，我列几个真实模式：
- “我们全员都买了订阅，后端直接调接口就行了吧？“——接口大概率需要单独的密钥和单独的计费主体，跟席位没关系。
- “订阅里写了不限量，那我写个脚本批量跑总可以吧？“——不限量的前提通常限定在正常的交互式使用范围内，脚本化的高频调用是否被允许，要看具体条款，很多时候是明确排除的。
- “我买 20 个席位，让程序共用其中一个账号的登录态去自动化。“——这种做法在技术上可能一时能跑通，但在合规上风险很高，账号共享和自动化模拟登录常常是被条款明确禁止的，一旦被识别，封号损失远大于省下的钱。
- “订阅和 API 是同一个厂商，额度应该能互相抵扣。“——通常不能。额度池独立、计价方式独立、结算周期也可能不同。
所以在做选型时，第一步不是比价，是先确认你要的是哪一类使用：
| 使用形态 | 特征 | 通常对应 |
|---|---|---|
| 交互式 | 真人操作、一问一答、频次低、要界面 | 订阅席位 |
| 程序化 | 代码发起、批量/定时/事件触发、频次高、无人值守 | API 按量 |
| 嵌入式 | 你的产品里内置 AI 功能给你的客户用 | API 按量（几乎必然） |
如果你两类都有，结论不是”选一个”，而是下一节。
三、混合才是常态，关键是划分标准
我接触过的团队里，稳定跑下来的几乎都是混合结构：交互式场景走订阅，程序化批量走 API。这不是妥协，是因为两类需求本来就该用两种买法。
划分标准可以用三个问题来定，任意一个答”是”就应该走 API：
- 发起方是程序还是人？ 有定时任务、有消息队列消费者、有 webhook 触发，就是程序。
- 调用量会不会随业务量线性增长？ 用户翻倍调用就翻倍的，是 API 型负载；用户翻倍但每人还是一天用几十次的，是席位型负载。
- 输出要不要进入你自己的系统？ 结果要写库、要进流程、要给下游程序消费，那就必须走接口。
反过来，三个问题都答”否”、纯粹是员工日常查资料写文案的，买订阅通常更省事——省的不只是钱，还有你自己搭一套界面、做会话管理、配权限的工程量。
落地时有两条建议。一是分账：让订阅和 API 的成本在财务上分成两条线，别混在一个”AI 支出”科目里，否则你永远不知道涨的是哪一边。二是别用订阅当兜底：不要出现”API 预算超了就让大家去界面上手工处理”这种设计，人工兜底的隐性成本比多付那点 token 费高得多。
四、签订阅之前必须确认的五件事
下面这些我不给任何具体产品的答案——条款各家不同、随时会改，我没核实过就一个字都不写。但该问什么是通用的，把这五条抄下来去问销售或翻文档，逐条得到白纸黑字的答复再签。
- 席位是否可转移、可回收。 员工离职后席位能不能重新分配给新人？中途换人要不要重新计费？只允许增加不允许减少的席位，在团队规模波动时会变成长期负担。
- 额度是否跨月累计。 这个月没用完的部分，下个月还在不在？大多数情况是”用完即清”，但你必须问清楚，因为它直接决定第二节里”淡季浪费”那笔损失有多大。
- 超额怎么计费。 超出后是自动按某个单价继续跑，还是直接停止服务，还是降速？如果是继续跑，超额单价和标准按量单价是什么关系？前面的算例里超额单价高于标准价才导致订阅吃亏——这个关系必须问明确，别假设。
- 能否中途降级或退订。 年付方案里途中减少席位、降低档位、提前终止，各自的规则是什么？有没有违约条款？一个不能降级的年付合同，等于你把一整年的用量预测风险全揽了。
- 是否包含程序化调用。 也就是第三个变量那件事。要问到具体：席位是否附带 API 密钥？附带的额度是多少、和交互使用是否共享同一个池子？自动化脚本使用是否被条款允许？这一条问不清楚就别签，因为它决定了你到底需不需要再买一份 API。
再补一条不算问题的提醒：所有答复尽量落到书面（合同、订单、官方文档链接）。口头承诺在续费换了对接人之后，通常就不作数了。
五、按量这一侧的风险控制：给它装个天花板
按量最大的风险只有一句话：它没有天花板。一个死循环、一个被刷的公开接口、一次上下文管理失误导致每次请求都把全量历史带上，都能在几小时内烧掉你一个月的预算，而且中间没有任何东西会自动拦住它。
订阅是天然有上限的（最多就是月费加上超额费，且超额往往有硬闸），按量则必须由你自己把这个上限造出来。至少做四层：
- 预算上限（硬闸）。在平台侧设置预算或消费上限，设成”到达即停”而不只是”到达通知”。能不能设、怎么设、是硬停还是软提醒，以你所用平台控制台的实际能力为准，先去找一遍这个开关在哪。
- 速率上限（自己那侧）。别只依赖平台的限速。在你自己的服务里加一层每分钟、每用户、每租户的调用配额，这层是你唯一能百分之百控制的闸门。公开面向终端用户的功能尤其要做按用户配额，否则一个脚本小子就能把你的账单打穿。
- 告警（分级）。至少两档：一档是”用量达到月预算的 X%“，一档是”小时用量超过日常均值的 N 倍”。第二档更重要——预算百分比告警发出来的时候，钱已经花了；速率突变告警才有可能在事故进行中就把你叫醒。具体怎么设阈值、怎么避免告警疲劳，月度预算与告警那篇里写得更细。
- 单次请求上限。限制单次调用的最大输入 token 和最大输出 token。这是最容易做也最容易被跳过的一层，它能挡住”某个用户上传了一份三百页 PDF”这类意外。
另外，如果你走的是预付费额度的形式，把额度耗尽当成一次可能发生的线上事故来准备——余额告警、自动充值、以及余额为零时服务怎么降级，这三件事要在上线前就想好，细节见预付费额度怎么管。至于超额之后计费规则怎么读，超额计费的坑那篇可以对照着看。
六、重估节奏：这不是一次性决策
用量在变，价格也在变。我见过太多团队一年前签的方案一直续到今天，中间既没复核用量也没复核价格——这两边任何一边动一动，当初的结论就可能已经不成立了。
建议设两个触发器，任一触发就重算一次平衡点：
周期触发：每季度一次。 不用很复杂，半小时的事：拉出这三个月的实际用量和实际支出，重新代入第一节的公式，看结论有没有翻转。同时顺手核对一遍官方价目表——单价调整、新增缓存折扣、计费单位变更，都会改变平衡点的位置。
用量触发：月度用量偏离基线 ±40% 且连续两个月。 单月异常可能只是一次活动或一次故障，连续两个月就是趋势了。涨上去要看订阅是不是该上档或者反过来该换成按量，跌下去要看席位是不是买多了。
还有两个额外的重估时机容易被忘掉：
- 业务形态变化时。比如原本纯内部使用的功能开放给了外部客户，负载性质从”席位型”变成了”API 型”，这时候不重估，几乎必然出问题。
- 合同续费前至少一个月。别等到自动续费扣款那天才想起来。留出一个月，才有时间做对比、谈条件、或者平滑迁移。
顺便说一句心态上的事：重估的目的不是每次都要换供应商或换计费方式。大多数季度重估的结论应该是”不动”——如果你每次都在换，说明你的用量预测方法有问题，那才是要修的东西。
自查清单
签合同或改计费方式之前，把这几条过一遍：
- 我算过盈亏平衡点吗？公式里的单次成本用的是生产日志里的真实 token 数（含系统提示词和 RAG 上下文），不是测试样本？
- 我看的是用量分布还是均值？过去 6 个月的月度峰谷比是多少，超过 3 倍了吗？
- 我的场景里，是”便宜”更重要还是”数字确定”更重要？如果账单突然变成 3 倍，业务上会发生什么？
- 我要的使用形态是交互式还是程序化？如果两者都有，是否已经分开买、分开记账？
- 订阅方案的五件事（席位可转移、额度是否累计、超额怎么算、能否降级、含不含程序化调用）我都拿到书面答复了吗？
- 按量这一侧，预算硬闸、自建速率配额、两档告警、单次请求上限，四层都装了吗？
- 下一次重估是什么时候？触发条件写下来了没有，谁负责？
- 合同续费日在日历上吗？提前一个月的提醒设了吗？
最后重复一遍开头那句：这道题的答案不是”哪个便宜”，而是”哪种不确定性我更能承受”。把平衡点算清楚只是把选项摆到桌面上，真正做决定的是波动性、可预测性需求，和你到底要不要程序化调用这三件事。