为什么 OpenAI 的模式是行业标准
传统 SaaS 计费无法很好地处理 AI 使用量的可变成本。OpenAI 的模式同时解决了三个问题:- 可预测的收入与低风险:由于 API 使用量是预付的,用户无法产生自己无力支付的账单。OpenAI 会预先收到款项,用户则在使用服务时逐步消耗余额。
- 开发者可扩展性:充值 5 美元是一个较低的入门门槛。随着应用增长,开发者可以自动充值或购买更大的额度包。起步成本低,使用量也可以增长,而无需更换套餐。
- 用户心理:以美元计价的额度比抽象的“tokens”或“积分”更直观。余额就像 AI 服务的预付账户,让企业更容易进行预算管理。
OpenAI 如何计费
OpenAI 针对不同用户采用两种计费模式。- API(按量付费):API 使用预付费、以美元计价的额度。用户可以为账户充值 $5、$10、$50 或更多。额度显示美元价值,但无法在 OpenAI 之外使用。OpenAI 按 token 计费,并分别为输入和输出 token 设定不同费率。购买的额度会在购买一年后过期,且不可退款(OpenAI 帮助中心)。余额达到 $0 时,API 调用会失败。
- ChatGPT Plus、Business 和 Enterprise:这些是固定费率订阅。ChatGPT Plus 每月收费 $20,Business 方案(前身为 Team)按月计费时为每位用户每月 $25。它们设有软性使用上限:高频用户会被切换到较小的模型,而不是被阻止使用。
- 基于支出的费率层级:随着总支出随时间增加,账户会解锁更高的 API 速率限制。可用权限会随着计费记录逐步提升。
独特之处
四个特征使 OpenAI 的计费模式对 AI 服务尤其有效:- 法定货币计价的额度:额度以美元计价,因此用户会将其视为货币。开发者可以直接读取请求的价格。
- 较长的有效期:购买的额度有效期为一年,降低了“用掉或作废”的压力。用户更愿意充值较大的金额。
- 多维度计量:输入和输出 token 分别进行跟踪,但会从同一余额中扣除。OpenAI 可以将成本较高的输出 token 定价为高于输入 token。
- 信任层级:随总支出提升的速率限制会奖励长期客户,并鼓励他们持续使用。
战略优势
该模式会自我强化。较低的入门成本可以吸引开发者。预付费额度能够提供即时现金流。基于使用量的定价意味着开发者取得成功后,OpenAI 的收入也会增加。订阅则为非开发者用户带来稳定的基础收入。使用 Dodo Payments 构建此模式
你可以使用 Dodo Payments 构建 OpenAI 的计费模式。在 API 侧使用 Credit-Based Billing,在 ChatGPT Plus 侧使用标准订阅。1
Create a Fiat Credit Entitlement
在 Dodo Payments 控制面板中,转到 Products → Credits,然后点击 Create Credit。此额度是每位用户的中心余额。
- Credit Type: Fiat Credits,并将 Unit Currency 设置为 USD
- Credit Expiry: Custom,365 天(与 OpenAI 一年的有效期一致),或 Never
- Rollover: 不需要(额度不会在每个周期重置)
- Allow Overage: 已禁用
2
Create Top-Up Products
为不同的额度包创建一次性付款产品,例如 $5、$10、$50 和 $100。将你的法定货币额度附加到每个产品。将发放的额度数量设置为额度包的美元价值。$50 的额度包会发放 50 个额度。
3
Create Usage Meters
创建两个 meter 来跟踪 token 使用量:
llm.input_tokens:在tokens属性上进行 Sum aggregation。llm.output_tokens:在tokens属性上进行 Sum aggregation。
计算每个 Credit 对应的 Meter Units
要匹配 OpenAI 的 GPT-4o 定价,请计算 $1(即一个法定货币 credit)可以支付多少 token:- Input Tokens: 1,000,000 tokens / $2.50 = 每 $1 400,000 个 token。
- Output Tokens: 1,000,000 tokens / $10.00 = 每 $1 100,000 个 token。
4
Send Usage Events
每次 LLM 请求后,将使用量发送到 Dodo Payments。一次请求可以同时携带输入和输出事件。此代码片段会复用上一步中的
client。5
Handle Balance Depletion
在处理 API 请求前检查用户余额。如果余额为零或负数,则拒绝请求,例如返回
402 状态。处理低余额 Webhook
在用户余额达到 $0 之前通知他们。附加额度时设置 Low Balance Threshold,然后在收到credit.balance_low webhook 时发送电子邮件或应用内通知。使用 LLM Ingestion Blueprint 加速
上述步骤需要手动构建并发送使用量事件。LLM Ingestion Blueprint 则会封装你的 OpenAI client 并自动跟踪 token。inputTokens、outputTokens 和 totalTokens,并将它们与 model 一起作为事件元数据发送。将 meter 的 Over Property 设置为你希望计费的 token key。
实现基于支出的费率层级
OpenAI 的费率层级通过信任度管理容量。要构建此功能,请跟踪每位客户的生命周期支出。- **跟踪生命周期支出:**监听
payment.succeededwebhook,并将付款金额加到数据库中该客户的total_spend字段。金额以最小货币单位表示,因此 5000 就是 $50.00。 - **定义层级:**将支出金额映射到速率限制:
- Tier 1:支出 $0 - $50 -> 3 RPM
- Tier 2:支出 $50 - $250 -> 10 RPM
- Tier 3:支出 $250+ -> 50 RPM
- **执行限制:**在 API middleware 中查找客户所属的层级,并应用该层级的速率限制。
完整实现示例:API Proxy
在生产环境中,API proxy 通常位于用户与 LLM provider 之间。proxy 会验证请求身份、检查 credit 并报告使用量。 下面的 handler 实现了该 proxy:处理边界情况
类似 OpenAI 的计费系统需要规划多个边界情况。竞态条件
余额较低的用户可能会同时发送多个请求,并在任何事件得到处理之前超出余额。为防止这种情况,请保留少量缓冲,或在每次请求期间对客户余额持有分布式锁。事件摄取延迟
Dodo Payments 会异步扣除 credit。后台 worker 大约每分钟处理一次新事件,因此扣除操作可能滞后于 API 调用。若要严格实时执行限制,请在本地缓存每位用户的余额,并在处理请求时更新缓存。退款处理
退还额度包购买款不会移除该购买所发放的 credit。退款时,请使用 debit 自行扣除这些 credit:在客户的 Credits 标签页中使用 Apply Credit/Debit,或调用 Create Ledger Entry API。然后更新应用中显示的余额,避免用户花费他们已经不再拥有的 credit。多模型支持
要支持价格不同的多个模型,可以选择以下两种方案之一:- **Separate Meters:**为每个模型创建一组 meter,例如
gpt-4o.input_tokens和gpt-4o-mini.input_tokens,并分别设置 Meter units per credit。 - **Weighted Events:**使用一个 meter,在发送事件前将
tokens乘以权重。例如,如果 GPT-4o 的成本是 GPT-4o-mini 的 10 倍,则 GPT-4o 请求应发送 10 倍的 token 数量。
架构概览
下面的循环展示了从购买到阻止调用的预付费流程: meter 会跟踪 token,并按照你配置的费率从用户的 credit 余额中扣除对应的美元价值。当余额达到零时,你的应用会阻止调用。结语
借助 Dodo Payments,你可以像 OpenAI 一样,将基于使用量的计费与预付费 credit 的可预测性结合起来。客户预先付款,按需使用,并在需要更多额度时充值。 同样的组件既适用于大型 LLM 平台,也适用于小型 AI 工具:法定货币 credit、充值产品、token meter,以及每次请求前的余额检查。使用的主要 Dodo 功能
以下 Dodo Payments 功能支持这一实现:Credit-Based Billing
管理用户的预付费法定货币 credit 和 entitlement。
Usage-Based Billing
跟踪 token 等细粒度使用量,并据此计费。
One-Time Payments
通过 checkout 销售额度包和充值。
Event Ingestion
向 Dodo Payments 发送高吞吐量的使用数据。
Webhooks
实时了解 credit 余额变化和低余额提醒。
LLM Ingestion Blueprint
自动跟踪 OpenAI 和其他 LLM provider 的 token。