最近在做一个 AI 产品的计费功能时，我遇到了一个很典型的问题。
用户发送了一句很短的消息。系统先估算了一次费用，发现余额够用，于是创建 Agent 任务并开始执行。可等到真正调用大模型时，完整的系统提示词、Agent 指令、工具定义和历史上下文都被带了进来，第二次估算的费用变高了，系统又返回余额不足。
这件事表面上是一次余额校验不一致，背后其实是一个更值得讨论的问题：
AI 产品到底应该先付费再执行，还是先执行再扣费？余额能不能变成负数？订阅、积分和按 Token 计费之间又是什么关系？
这篇文章不讨论某个具体项目，而是把 AI 产品常见的计费方式拆开，看看它们各自适合什么场景。
一、先别急着谈扣费，要区分两个问题
很多人讨论 AI 产品付费方式时，会把订阅制、Token 计费、预充值和后付费放在一起比较。
其实它们属于两个不同维度。
1.1 按什么计价
这是定价单位的问题，常见方式包括：
- 按月或按年订阅；
- 按 Token 用量计费；
- 按调用次数计费；
- 按图片张数、视频时长、生成页数计费；
- 按任务结果计费，例如成功生成一份报告收取固定费用。
1.2 什么时候结算
这是资金风险和结算时机的问题，常见方式包括：
- 先充值，余额足够才能使用；
- 请求开始时预扣，结束后多退少补；
- 允许产生少量负余额，下次充值时补回；
- 完全后付费，月底统一出账单；
- 套餐、赠送额度、预充值和超额后付组合使用。
一个产品完全可以同时采用多种方式。
例如，用户每月支付 99 元订阅费，套餐包含 100 万 Token；超出的部分按 Token 计费，并从预充值余额中扣除。企业客户则可以不充值，月底统一结算。
所以，真正需要选择的不是某一个名词，而是一套组合。
二、方式一：订阅制
订阅制是用户按月或按年购买使用权。
它最大的优点不是技术简单，而是用户容易理解。用户不需要每次发消息前都计算 Token，也不会因为一次长对话突然被打断。
适用场景
- 面向个人用户的 AI 助手；
- 使用频率相对稳定的办公产品；
- 单次调用成本较低，而且不同用户的成本差异不夸张；
- 产品价值主要来自持续使用，而不是某一次生成结果。
容易踩的坑
纯订阅并不代表可以完全不统计用量。
如果一个用户每天问十次，另一个用户每天跑几百次长 Agent 任务，两人的上游成本可能相差几十倍。完全不限量很容易被少数重度用户拖垮。
因此实际产品通常会增加公平使用限制，例如：
- 每月包含一定 Token；
- 高级模型每天限制调用次数；
- 图片、视频和高成本工具单独收费；
- 超出套餐后降速或转为按量计费。
订阅制适合解决"用户愿不愿意持续付费"，但不能代替底层用量账本。
三、方式二：严格预付费
严格预付费的逻辑很直接：没有余额，就不允许产生任何新的费用。
在真正执行操作之前，系统先冻结一笔预计费用；任务完成后按实际费用结算，多余的冻结金额再释放。
text
检查可用余额
↓
冻结预计费用
↓
调用模型或工具
↓
按实际用量结算
↓
释放剩余冻结金额这里的关键不是"检查"，而是"冻结"。
如果系统只是读取一次余额，检查通过后什么都不做，那么两个并发请求可能同时认为余额足够。等到真正扣费时，要么其中一个突然失败，要么发生超扣和账目覆盖。
适用场景
- 图片、视频等单次成本较高的生成任务；
- 固定价格的 Tool 或 Skill；
- 会调用付费第三方 API 的 Agent；
- 没有绑定支付方式的个人用户；
- 平台不能承受任何坏账的场景。
容易踩的坑
Agent 的最终费用往往无法在开始时准确预测。
它可能调用一次模型后执行三个工具，再调用两次模型；也可能因为工具返回结果不理想继续循环。如果试图在任务开始前一次性估算整个 Agent 的最终费用，通常只能得到一个很粗糙的数字。
更合理的方式是按每个收费步骤进行授权：
text
LLM 预授权 → LLM 结算
Tool 预授权 → Tool 结算
LLM 预授权 → LLM 结算
任务结束 → 释放剩余冻结固定价格的工具可以精确预扣，Token 费用则根据完整输入和最大输出上限预授权。
四、方式三：软预付费，允许有限负余额
AI 调用有一个天然问题：最终用量只有执行结束后才知道。
即使请求开始前已经估算，实际输出 Token、缓存命中、推理 Token 和供应商返回的 usage 仍可能与估算存在差异。
软预付费的做法是：请求开始前确认账户仍有可用额度，但请求一旦获得授权，就一定按实际用量记账。实际费用略高于预估时，允许余额暂时变成负数；余额为负后，再阻止下一次调用。
OpenAI 的预付费说明也提到，由于停止服务可能存在延迟，账户可能出现负余额，超出的使用量会从下一次购买的额度中扣除。
适用场景
- 普通文本大模型调用；
- 单次成本低、调用频繁的 AI 对话；
- 流式响应已经发送给用户，无法在结尾撤销的请求；
- 希望避免用户在回答生成到一半时被计费逻辑打断。
负余额不能没有边界
允许负余额不等于允许无限透支。
至少需要限制：
text
单个请求最大未结算金额
单个用户最大负余额
同一用户最大并发请求数
高成本模型和工具的独立上限例如，普通 LLM 可以允许最多透支 0.1 积分，但一次收费 100 积分的图片生成仍然必须严格预扣。
软预付费本质上是用一小部分可控资金风险，换取更稳定的用户体验。
五、方式四：纯后付费
后付费不依赖钱包余额。系统持续记录用户的实际用量，在每天、每周或每月生成账单。
Stripe 的用量计费就是典型的 Meter 模式：业务持续上报用量事件，计费系统异步聚合，最后应用到订阅账单。
适用场景
- 已签合同的企业客户；
- 已绑定可靠支付方式的用户；
- 有明确授信额度和催收流程；
- 用量较大，需要统一对账、开票和结算；
- 客户不能因为余额不足突然中断生产任务。
容易踩的坑
后付费把技术复杂度从"预扣"转移到了"信用管理"。
平台需要处理：
- 客户信用额度；
- 欠费停用策略；
- 账单争议；
- 支付失败重试；
- 发票、税务和退款；
- 延迟用量和补记事件。
因此，后付费通常适合企业客户，不适合默认开放给所有个人用户。
六、方式五：混合计费
现实中最常见的往往不是前面某一种，而是混合模式。
text
订阅套餐赠送额度
↓
预充值余额
↓
余额不足自动充值
↓
企业客户使用信用额度后付费Stripe 的 Billing Credits 也采用类似思路：通过 Credit Grant 发放预付或促销额度，再把额度应用到具体的用量型产品。它还特别区分账本余额和可用余额，并通过不可变流水记录额度变化。
适用场景
- 同时服务个人用户和企业客户；
- 产品中既有低成本对话，又有高成本工具；
- 希望用订阅保证收入，同时按量覆盖重度用户成本；
- 需要赠送新用户额度、活动额度或补偿额度。
对大多数 AI SaaS 来说，混合模式通常是最终形态。
七、预算告警不是扣费门禁
还有一种经常被误认为计费方式的能力：预算。
预算可以提醒用户"本月已经花了 80%"，也可以在达到阈值后关闭某些能力，但它通常不是实时的强一致门禁。
AWS Budgets 的官方文档就明确说明，资源使用、费用入账和预算通知之间可能存在延迟。在告警发出前，实际费用仍然可能继续增加。
因此，预算适合做：
- 消费提醒；
- 成本趋势分析；
- 部门或项目额度管理；
- 达到阈值后的降级和通知。
但如果业务要求"余额不足时绝对不能再调用一次收费接口"，仍然需要实时授权和预扣机制。
八、AI 产品到底应该怎么选
可以先根据费用是否可预测、单次成本和客户信用做判断。
| 场景 | 推荐方式 |
|---|---|
| 普通 AI 对话 | 订阅额度 + 软预付费 + 有限负余额 |
| 固定价格 Tool/Skill | 执行前精确预扣 |
| 图片、视频、昂贵第三方 API | 严格预付费 |
| 企业生产任务 | 后付费 + 信用额度 |
| 同时服务个人和企业 | 混合计费 |
| 成本提醒和部门管理 | 预算告警，不能代替实时扣费 |
我个人更推荐下面这套组合：
- 普通 LLM 使用软预付费，请求获得授权后允许小额透支结算；
- 固定价和高成本工具严格预扣；
- 个人用户余额为负后禁止发起新请求，并支持自动充值；
- 企业用户配置独立信用额度，按月后付；
- 所有余额变化都进入不可变账本；
- 预算只负责提醒和风控，不承担实时结算职责。
这套设计并不是最简单的，但它把成本风险和用户体验放在了相对合理的位置。
九、最后再回到开头的问题
开头那个"外层检查通过，Agent 启动后却余额不足"的问题，并不是把第一次估算调大一点就能解决。
真正的问题有三个：
- 两个地方使用了不同的计费输入，却都把自己当成最终判断；
- 检查通过后没有冻结额度，并发请求仍然可以抢同一份余额；
- 余额不足被包装成普通 Agent 故障，用户不知道真正发生了什么。
合理的改法应该是：只保留一个权威计费授权机制，每个收费步骤执行前授权，结束后按实际费用结算；对于无法完全预测的普通 LLM 调用，允许受控的小额透支；对于固定价和高成本操作，坚持严格预扣。
计费系统最重要的从来不是把余额减掉，而是同时回答好三个问题：
这笔钱为什么扣？什么时候扣？失败后能不能准确退回来？
只要这三个问题没有统一答案，余额数字做得再漂亮，也迟早会变成一次"Agent 执行失败"。