# OpenAI 计费如何运作：ChatGPT 订阅、API Token 和预付额度

> 了解 OpenAI 如何对 ChatGPT 套餐和 API 进行计费：订阅、按 token 计量、预付额度、消费上限、速率层级，以及 AI 创业者可以借鉴的计费架构。
- **Author**: Ayush Agarwal
- **Published**: 2026-04-07
- **Category**: AI, Billing
- **URL**: https://dodopayments.com/blogs/zh/openai-billing-model

---

**OpenAI 的计费在同一账户上运行着两个独立系统。ChatGPT 按固定月费或按席位订阅销售，API 则按用量计费，根据每个 token 收费，而且不同模型的费率各不相同。** 支付其中一项不会支付另一项，这种拆分是 OpenAI 发票最常见的困惑来源。

两者之上还有一层共享机制，包括预付额度、消费上限、速率限制层级和企业开票。这一层让普通聊天用户和生产环境 API 工作负载可以共用同一账户系统，同时保留各自的定价逻辑。

大多数搜索 **openai billing** 或 **open ai billing** 的人，想知道的通常是两个问题之一。如果你想知道为什么出现 ChatGPT 扣款，或该选择哪个套餐，下面的套餐介绍会回答。如果你问的是 **openai api billing**，简短答案是：单个请求会拆成四个分别定价的部分----输入 token、缓存输入 token、缓存写入和输出 token----每百万 token 计费，费率按模型公布，费用从预付余额中扣除，或随着用量累积从银行卡扣款。

本文其余部分将解释这些组成部分如何连接，因为这种架构比任何已公布的费率都更持久。OpenAI 价格表上的每个费率自发布以来都改过多次；但订阅、预付额度、计量器和消费控制这四层结构一直没有改变。

OpenAI 的变现模式很重要，因为许多 AI 创业者现在都需要同样的能力：为终端用户提供订阅，为开发者提供预付额度，并为企业买家提供用量控制。要把这些做好，需要可靠的[权益管理](https://dodopayments.com/blogs/entitlement-management-saas)和自助式[客户计费门户](https://dodopayments.com/blogs/customer-billing-portal)，让买家可以自行管理套餐。

OpenAI API 定价页面截图，显示输入、缓存输入和输出分别公布的按 token 模型费率

如需了解相关策略，可阅读 [AI 定价模型](https://dodopayments.com/blogs/ai-pricing-models)、[按用量付费的 AI SaaS](https://dodopayments.com/blogs/pay-as-you-go-ai-saas)和 [API 变现](https://dodopayments.com/blogs/api-monetization)。如需与另一家前沿实验室对比，可阅读 [Anthropic 计费模型解析](https://dodopayments.com/blogs/anthropic-billing-model)、比较 [Anthropic 如何为 Claude 定价](https://dodopayments.com/blogs/claude-token-cost-explained-2026)，并查看 [Claude API 定价的利润计算](https://dodopayments.com/blogs/anthropic-claude-api-pricing-margin)。

## 用一句话说明 OpenAI 计费

OpenAI 计费结合了：

- 面向个人和团队的 **ChatGPT 订阅**
- 面向开发者的**预付 API 额度**
- 面向模型使用的**按用量 token 计费**
- 面向大型组织的**消费控制和开票**

因此，OpenAI 既能服务普通 ChatGPT 用户，也能服务生产环境 API 客户，而不必强迫双方采用相同的支付逻辑。

### ChatGPT 计费与 API 计费对比

两个系统共用一个账户，但几乎没有其他共同点。如果你想确认某笔扣款来自哪个系统，应先看这张表。

|              | ChatGPT 订阅计费             | OpenAI API 计费                        |
| ------------ | ---------------------------- | -------------------------------------- |
| 购买内容     | 一段时间内的产品使用权       | 按请求计量的计算资源                   |
| 计费单位     | 每月按席位或套餐             | 输入、缓存输入和输出 token             |
| 扣款时间     | 固定续费日                   | 随用量持续累积扣款，或从预付余额中扣除 |
| 价格可预测性 | 月初前即可知道               | 随模型、提示词长度和用量变化           |
| 面向对象     | 终端用户和内部团队           | 将模型嵌入自有产品的开发者             |
| 超额使用     | 套餐限制，可通过预付额度扩展 | 消费上限和速率层级，超出后硬停止       |

实际结果是：ChatGPT Plus 或 Business 订阅不会提供 API 额度，API 余额也不会提高 ChatGPT 套餐的使用上限。两者独立计费、独立计量、独立设限。

## ChatGPT 套餐体系

OpenAI 的个人和团队套餐围绕可预测的月度支出设计。与其重复一份每年变化数次的价格表，不如关注这条梯度的形状：即使具体数字变化，它仍然相当稳定。在据此建模前，请先查看 OpenAI 官方定价页面的当前数字。

| 层级       | 计费模式                                 | 买家真正购买的内容                    |
| ---------- | ---------------------------------------- | ------------------------------------- |
| 免费       | 无订阅                                   | 有限访问、用量上限、较低优先级        |
| 入门付费层 | 固定月度订阅                             | 比免费版更多的消息、上传和记忆容量    |
| 标准付费层 | 固定月度订阅                             | 高级推理模型、项目、自定义 GPT        |
| 高阶层     | 按用量倍数销售的固定月度订阅             | 相同核心功能，更大的用量额度          |
| Business   | 按席位订阅，可按年或按月，并设最低席位数 | 共享工作区、管理员控制、统一计费      |
| Enterprise | 定制开票合同                             | 安全性、控制、数据驻留、批量折扣、SLA |

有三个架构细节比确切数字重要得多，也是你可以放心借鉴的部分。

**梯度有意设计得不均匀。** 相邻层级之间的差距会随着层级提高而明显扩大。前几步足够小，容易促成冲动升级；而进入最高个人层级的跃升，则相当于下方所有层级的倍数。OpenAI 并不是按功能均匀划分层级，而是按支付意愿划分，让较宽的顶层承接少数高用量用户，避免他们破坏标准套餐的单位经济模型。

**最高层级按容量倍数而不是功能销售。** 最高个人层级提供相同的核心能力，主要区别在于包含多少用量，通常以标准套餐的倍数表示。这是披着订阅外衣的用量计费，也是市场上最干净的案例：让重度用户支付更多，却完全不向他们展示 token 计算。如果你正在为聊天产品定价，可阅读这篇关于[盈利型 AI 聊天应用定价](https://dodopayments.com/blogs/profitable-ai-chat-app-pricing)的深入解析。

**个人套餐现在也包含预付额度。** 套餐达到限制后，OpenAI 允许用户使用 ChatGPT 预付额度继续使用；部分企业和教育协议也完全按预付额度扩展用量，而不是采用固定上限。订阅和计量器不再是完全分离的系统。

还有一个值得关注的变化：广告开始作为最便宜付费 AI 层级的补贴来源进入讨论。如果这成为常态，就会改变整个市场入门层可以收取的价格，也会让成熟企业拥有第二条收入线，用来守住纯订阅业务无法匹配的价格点。

## OpenAI API 计费：token 成本如何计算

**OpenAI API 计费是纯粹的按用量付费计量，没有席位、没有套餐，也没有月度最低消费。** 你添加支付方式或预付余额后，每个请求都会从中扣除费用，费率取决于所调用的模型以及双向传输的 token 数量。

API 与 ChatGPT 的不同体现在所有关键方面。开发者按模型和用量付费，单个请求会拆分成分别定价的部分：输入 token、缓存输入 token、缓存写入和输出 token。费率按每百万 token 公布，产品线中的每个模型都不同，从旗舰推理模型到用于分类和路由的小型低价模型都是如此。

所有严肃的 AI 产品，只要转售推理能力，都会采用类似架构。[Cursor 的计费模型](https://dodopayments.com/blogs/cursor-billing-model)将其包装成美元计价的用量池，[Anthropic 的计费模型](https://dodopayments.com/blogs/anthropic-billing-model)则几乎原样呈现，因此 [AI 计费平台](https://dodopayments.com/blogs/ai-billing-platforms)的比较主要是在比较包装方式，而不是计量器。

本文有意不重复这些费率。模型名称和每 token 价格每年都会变化数次，复制到博客中的表格不到一个季度就可能过时。请从 OpenAI 官方定价页面读取当前数字，并把它们视为成本模型的实时输入，而不是硬编码常量。围绕这些费率的计费架构变化慢得多，这才是值得学习的部分。

以下结构性事实不会因价格调整而改变：

- 同一模型的输出 token 成本可能是输入 token 的数倍
- 缓存输入相较新输入有很大折扣，因此提示词复用是一项一等成本决策
- 同一系列中最小的模型可能比旗舰模型便宜一个数量级
- 工具调用、文件存储、沙箱代码执行和音频都与文本 token 分开计量
- 同一模型中，音频的成本明显高于文本

### 四个定价维度，而不是一个

多数成本模型会把"模型 X 的每 token 价格"视为一个数字。事实并非如此。OpenAI 至少沿四个维度为同一模型定价，忽略这些维度的估算在生产环境中一定会出错，而且通常会低估成本。

**上下文长度。** 超过公布的上下文分界点后，长请求的输入和输出都会采用更高费率。仅仅因为对话变长，每个请求的成本就可能大幅上升，即使模型没有改变。长时间运行的聊天线程最容易触发这一点，因为每一轮都会重新发送对话记录，而计量器会再次计算。

**延迟层级。** 同一模型提供多个服务层级：异步批处理、尽力而为的灵活层级、标准层级，以及购买更低且更稳定延迟的优先层级。批处理和灵活层级相对标准层级有折扣，优先层级则收取溢价。运行完全相同提示词时，最低和最高成本之间的差距足够大；对于不需要人工等待响应的工作负载，迁移到批处理是提高毛利的最大杠杆。

**缓存。** 缓存输入只收取标准输入的一小部分费用，但较新的模型系列还会对缓存写入本身收费。因此，缓存是一项有自身成本的决策，而不是免费的优化。当前缀在多个请求中反复使用时，它能够节省成本；否则也可能带来损失。

**工具和模态。** 工具调用与 token 分开计量。网页搜索按调用块收费；文件搜索对免费额度以上的存储数据按天收费，并另收每次调用费；沙箱代码执行按容器大小和会话计费；实时音频也与同一模型的文本分开定价。用于数据驻留的区域处理端点在符合条件的模型上还会收取额外费用，因此合规有明确的单项价格。

这就是 **openai API credits** 和用量计费的核心：成本跟随消费，而不是席位。要在自有系统中准确记录它，这是架构问题，而不是定价页面问题。在确定数据结构前，建议先阅读[如何设计 LLM token 用量计量](https://dodopayments.com/blogs/metering-llm-token-usage-architecture)。

## 将一切连接起来的计费架构

理解完整 OpenAI 计费系统最清晰的方式如下。

```mermaid
flowchart LR
    A["ChatGPT subscriptions"] --> E["Unified billing system"]
    B["API credits"] --> E
    C["Enterprise controls"] --> E
    D["Usage meters"] --> E
```

### 个人用户侧

个人用户侧表面上很简单：

1. 用户选择 ChatGPT 套餐
2. 银行卡或工作区计费按月扣款
3. 套餐控制限制、功能访问权限和模型访问权限
4. 用量上限影响行为，但不向客户展示 token 计算
5. 预付额度让重度用户超过套餐限制继续使用，而无需更换层级

第五步是最近的变化。纯订阅会迫使重度用户升级或被硬性停止。订阅之上增加预付额度后，就有了第三种选择，也把原本需要客服处理的对话转化成了收入。

### 开发者侧

API 侧更加明确：

1. 开发者添加支付方式或预付余额
2. 每个 API 请求都会生成用量事件
3. 根据模型专属 token 价格计算成本
4. 账户消费上限和速率层级控制吞吐量

### 企业侧

大型买家通常需要：

- 按工作区或项目设置消费上限
- 基于发票的付款条款
- 管理员控制和权限
- 面向财务、安全和采购团队的报告

这就是 **openai subscription billing** 从单纯的月度套餐问题，转变为收入运营问题的地方。

## 为什么 OpenAI 的计费模式有效

### 1. 它让定价匹配受众

消费者想要可预测的月度账单。开发者希望按实际用量付费。企业买家需要控制、报告和协商条款。OpenAI 为每类客户采用独立的商业逻辑，同时不割裂品牌。

### 2. 它将计算与包装分离

ChatGPT 销售的是访问权、便利性和产品体验。API 销售的是原始能力和吞吐量。这是相关产品，但不是同一个变现界面。

### 3. 它支持混合变现

OpenAI 清楚地说明了为什么 AI 公司不应把所有内容强行塞进一种计费模式。对于 AI 应用、封装产品、copilot 和平台，混合变现正在成为常态。

最明显的证据是两个系统已经开始汇合。订阅现在通过预付额度承接超额用量，Enterprise 灵活定价则完全取消固定速率限制，转而采用基于预付额度的消费。OpenAI 没有在订阅和用量计费之间二选一，而是同时构建两者，让客户处在这条光谱的任意位置。这比单独实现任一模式都更难。

### 4. 它给买家提供成本杠杆

批处理、灵活、标准和优先层级让客户可以在不离开平台或重新谈判合同的情况下，用延迟换取价格。利润承压的团队可以把后台任务迁移到异步层级，大幅降低这部分支出。这能让对成本敏感的客户留在平台上，而不是转向更便宜的竞争对手；对于任何计算成本显著的产品，这都是值得借鉴的模式。

> OpenAI 计费最重要的启示不是 token 费率，而是包装策略。订阅、预付额度和企业控制，都是同一核心计算引擎的不同外层。
>
> - Ayush Agarwal，Dodo Payments 联合创始人兼 CPTO

## AI 创业者可以从 OpenAI 计费中借鉴什么

这才是真正可以迁移的部分。少数机制就能完成大部分工作；只要一开始把数据模型设计正确，每个机制通常都能在一两个迭代周期内完成。

### 面向用户产品使用订阅

如果你的产品更像软件而不是基础设施，月度套餐比原始 token 定价更能增强买家信心。这就是 ChatGPT 套餐比向终端用户展示计量计算更自然的原因。经验法则是：如果付款的人也是点击使用的人，就销售套餐；如果付款方要将你的产品集成到自己的系统中，就销售计量用量。

关键在于，套餐并不承诺无限计算资源。请用买家能理解的单位公布包含的额度，例如消息、文档或分钟，同时将 token 计算留在后台。你仍然需要在内部计量一切，因为没有测量过的套餐无法定价。

### 为 API 和智能体工作负载提供预付额度

预付额度可以同时解决三个问题：在你为推理支付成本之前先收款，将坏账风险降至零，并为买家设置任何失控循环都无法突破的硬上限。这就是所有成熟 AI API 最终都会采用预付额度的原因。

一个能在生产环境运行的预付额度系统，需要以下组件：

- 使用账本而不是余额字段：每次充值、消费事件、退款和调整都作为只追加记录保存，余额由记录推导
- 以请求 ID 为键实现幂等扣款，确保重试的 webhook 或超时调用不会重复扣费
- 明确规定过期、是否可退款，以及促销额度是否先于购买额度消耗
- 设置自动充值的触发阈值和充值金额，并加入冷却时间，避免失控智能体在一分钟内触发几十次扣款
- 在余额较低和余额为零时及时发送 webhook，让人工有足够时间响应

预付额度也是现金流工具，而不只是控制手段，详见[计费额度、定价与现金流](https://dodopayments.com/blogs/billing-credits-pricing-cashflow)。如果你要将其加入现有应用，可参考[如何为 AI 应用添加预付额度计费](https://dodopayments.com/blogs/add-credits-billing-ai-app)，具体基础能力见[预付费计费](https://docs.dodopayments.com/features/credit-based-billing)。

这种设计面临的压力正在增加，因为支出者不再总是人类。当自主智能体持有预算并决定何时消费时，预付余额不再只是便利功能，而会成为执行边界。这正是[智能体计费](https://dodopayments.com/blogs/agentic-billing)所讨论的问题。在设计账本前，也值得了解新兴的机器支付轨道：[x402 协议](https://dodopayments.com/blogs/x402-protocol)覆盖通过 HTTP 按请求支付，[AP2 智能体支付协议](https://dodopayments.com/blogs/ap2-protocol-agent-payments)覆盖智能体如何证明自己获得授权、可以代表他人支出。如果你的产品是智能体调用的服务，而不是智能体本身，则应重点阅读 [AI 智能体的 MCP 支付](https://dodopayments.com/blogs/mcp-payments-ai-agents)。

问题在于已保存银行卡的可靠性。如果客户的保存卡过期，或充值扣款失败，而你没有[账户更新服务](https://dodopayments.com/blogs/account-updater-service)和[支付重试逻辑](https://dodopayments.com/blogs/payment-retry-logic)来保持凭证有效，这笔收入就会悄然消失。

### 可在争议中自证的用量计量

大多数 AI 计费系统会在计量环节悄然出错。真正的要求不是"统计 token"，而是"数月后仍能从原始事件重建任何一行发票明细，而不让客户产生争议"。

每个请求发出一个用量事件，至少记录：

- 请求 ID、客户 ID、API key ID，以及项目或环境
- 使用的模型标识和服务层级
- 分开记录输入 token、缓存输入 token、缓存写入和输出 token
- 将工具调用、存储和音频秒数作为独立计量维度
- 分开保存上游成本和可计费金额
- 时间戳和幂等键

以不可变方式保存原始事件，再聚合用于计费，顺序不要反过来。明细一旦丢失，聚合数据无法重新推导，而第一次严重的客户争议就会要求查看明细。定期将你的聚合结果与服务商自己的发票对账；两者持续存在差异，通常意味着事件丢失、重复计数，或某条代码路径绕过了计量器。

流式响应需要特殊处理，因为输出 token 数量要等流结束后才能确定，而客户端在流式响应中途断开，仍然会产生上游成本。应在流完成或中止时计量，而不是在请求开始时计量。设计事件流水线前，请阅读[实时流式用量计量](https://dodopayments.com/blogs/real-time-streaming-usage-metering)。端到端实现可参考 Dodo 的[按用量计费指南](https://docs.dodopayments.com/developer-resources/usage-based-billing-guide)。

### 硬上限和软上限是两种不同的产品

把消费限制当成一个功能，是最常见的设计错误。两者的目的正好相反。

软上限是沟通工具。消费跨过设定阈值时，它会发送通知，在仪表板显示预计的周期末支出，并给财务团队留出决策时间。它永远不会阻止请求。

硬上限是安全机制。预算用尽后，它会拒绝请求，返回明确且机器可读的错误，而不是通用失败信息；同时需要提供无需提交客服工单即可提高限制的路径。应按项目或 key 设置，而不只是按账户设置，否则一次实验就可能耗尽生产预算。

在达到限制之前，两者都必须显示在客户自己的仪表板中，而不是事后通过道歉邮件解释。相关界面模式见[用量上限和提醒的计费 UX](https://dodopayments.com/blogs/billing-ux-usage-caps-alerts)，而 [webhooks](https://docs.dodopayments.com/developer-resources/webhooks)可以让你无需轮询即可驱动两者。

### 按 key 归因

归因让计量器变成管理工具。每个 API key 都应关联负责人、项目和环境，每个用量事件都应记录产生该事件的 key ID。

这一字段就能满足企业买家的大部分要求：按内部团队分摊费用、为预发布和生产环境设置独立预算、key 泄露时立即限制影响范围，以及定位具体哪个智能体循环让上周账单翻了三倍。没有它，客户只能看到一个大数字，不知道该如何采取行动，用量定价也因此获得"不可预测"的名声。

### 将分层速率限制作为增长机制

速率限制通常作为防滥用控制构建，之后就被搁置在那里。将其与计费绑定后，它就会变成升级阶梯：新账户从保守吞吐量开始，随着已验证支出或账户年龄累积，限制自动提高，最高层级则通过协商获得。

这样可以同时实现三件事：限制欺诈风险和单个客户占满共享容量的风险；给成长中的客户一个明确理由，让他们将更多支出集中到你这里而不是分散给多个服务商；并消除一类销售对话，因为升级会自动发生。按 key 设计限制，让团队可以保护生产环境不受自身实验影响，并公开记录各层级阈值。[用量限制和客户配额](https://dodopayments.com/blogs/openai-usage-limits-customer-quotas)介绍了如何公开这些限制而不增加客服负担。

### 转售模型访问权的利润计算

如果你的产品建立在他人的模型之上，毛利就是一道减法题，而多数团队会因为遗漏成本项而算错。

每个可计费用户操作的真实成本包括：

- 输入 token，包括每一轮重新发送的完整对话历史
- 输出 token，这是更昂贵的一半，而且会随着系统提示词允许模型变得更冗长而增加
- 重试、失败生成，以及一次用户操作触发多次模型调用的智能体循环
- 工具调用、检索、存储，以及任何音频或图像模态
- 收入侧的支付处理费

最后一项在低客单价时绝不是舍入误差。Dodo Payments 对每笔成功的美国境内交易收取 4% + 40c；订阅和按用量计费另加 0.5%；国际卡和支付方式另加 1.5%，且不收月度平台费。对于小额预付额度充值，固定费用的影响大于百分比，这也是鼓励更大、更少频次充值，而不是进行微额扣款的直接理由。

三个习惯可以让计算保持准确。按每月活跃用户成本衡量，而不是按每次请求成本衡量，因为请求组合的平均值会掩盖重度用户尾部。明确限制输出长度，因为成本主要集中在输出。按任务路由：将分类、路由和提取发送给能力足够的最低价模型，只在质量明显值得多付费用时使用旗舰模型。

只有知道每位用户的完整成本后，才能选择价格。定价框架见[如何为 AI 封装产品定价](https://dodopayments.com/blogs/price-ai-wrapper)，[AI SaaS 按用量计费与固定费用对比](https://dodopayments.com/blogs/usage-based-billing-vs-flat-fees-ai-saas)则介绍了什么时候值得为计量器投入额外工程成本。

### 用消费控制建立企业信任

企业团队购买的不只是访问权，也购买可预测性。项目预算、工作区规则、开票和报告都是产品的一部分；在模型比较完成后，通常正是这些内容促成交易。

另请参阅 [动态定价的按用量计费 SaaS](https://dodopayments.com/blogs/dynamic-pricing-usage-based-saas)，了解这些控制如何与不断变化的价格互动。

## 如何使用 Dodo Payments 构建类似 OpenAI 的计费栈

如果你想复现这种架构，Dodo Payments 开箱即提供主要基础能力：

- [预付费计费](https://docs.dodopayments.com/features/credit-based-billing)，用于预付余额和订阅超额
- [按用量计费](https://docs.dodopayments.com/features/usage-based-billing/introduction)，用于 token 或事件计量
- [订阅计费](https://docs.dodopayments.com/features/subscription)，用于面向消费者的月度套餐或按席位的团队套餐
- [webhooks](https://docs.dodopayments.com/developer-resources/webhooks)，用于低余额和生命周期自动化

在每笔成功的美国境内交易基础费率 4% + 40c 之上，订阅和按用量计费另加 0.5%，且不收月度平台费。国际卡另加 1.5%。用量计量、开票、分析、许可证密钥以及覆盖 190 多个国家和地区的税务管理都已包含，不会作为独立模块单独销售；当你的计费面像上文所述一样包含众多活动部件时，这一点很重要。当前费率见 [Dodo Payments 定价页面](https://dodopayments.com/pricing)，[API 参考](https://docs.dodopayments.com/api-reference/introduction)介绍每个基础能力背后的端点，[集成指南](https://docs.dodopayments.com/developer-resources/integration-guide)则带你完成首次端到端实现。

由于 Dodo 是 MoR（名义商户），它会成为每笔交易的名义卖方，并承担由此产生的税务责任，从而移除一项会随着 API 销售国家增加而扩大的注册和申报工作。相关模式见[什么是名义商户](https://dodopayments.com/blogs/what-is-a-merchant-of-record)，SaaS 专属版本见[SaaS 的名义商户](https://dodopayments.com/blogs/merchant-of-record-for-saas)。结账支持 220 多个国家和地区、40 多种支付方式及 80 多种货币；对于买家很少与卖家处于同一国家的开发者产品而言，这一点很重要。

正因为如此，Dodo 很适合构建混合 AI 计费的创业者，而不必只选择固定订阅或只选择按用量定价。OpenAI 做到、而多数计费栈做不到的具体事情，是在同一账户上同时运行订阅和计量器，并用预付额度连接两者。这要求权益、计量和计费共享状态。

如需了解实现路径，还可阅读 [实现按用量计费](https://dodopayments.com/blogs/implement-usage-based-billing)、[AI 变现](https://dodopayments.com/blogs/monetize-ai)和 [SaaS 订阅与按用量计费](https://dodopayments.com/blogs/subscriptions-usage-based-billing-saas)。

也应坦诚面对自建与购买的选择。计量平台和支付平台解决的是相邻但不同的两半：计量引擎将事件聚合成发票明细，而支付平台还会收款；在 MoR 模式下，还会承担销售交易的税务责任。如果你只评估计量部分，[Orb 计费替代方案](https://dodopayments.com/blogs/orb-billing-alternatives)和 [Lago 替代方案](https://dodopayments.com/blogs/lago-alternatives)的对比说明了各产品的边界。

## OpenAI 计费仍然会造成摩擦的地方

如此复杂的计费系统不可能完全没有摩擦。

OpenAI 仍需平衡：

- 客户对 ChatGPT 套餐和 API 访问权的混淆
- 开发者不可预测的 API 支出
- 文本、语音、图像和工具之间的多维计量
- 在不减缓产品采用的前提下实现企业治理

这些都是 AI 变现中的正常取舍。关键是让这些取舍足够清晰，使买家仍然信任系统。

更多背景可阅读：[准确的计量计费](https://dodopayments.com/blogs/metered-billing-accurate-billing)、[分层定价模型指南](https://dodopayments.com/blogs/tiered-pricing-model-guide)和 [AI 定价模型](https://dodopayments.com/blogs/ai-pricing-models)。

### 这种规模的计费模式带来的合规范围

定价机制受到最多关注，但在全球销售 API 会带来一系列义务，其规模取决于客户基础，而不是工程投入。

- **企业客户期待正确的税务处理。** 向欧盟企业销售 API，意味着验证 VAT 编号，并在每张发票上应用[反向征收 VAT](https://dodopayments.com/blogs/reverse-charge-vat)；向美国企业销售，则意味着处理[销售税免税证明](https://dodopayments.com/blogs/sales-tax-exemption-certificate)，而不能默认客户声明有效。
- **美国境外卖方面临预扣税文件要求。** 任何在美国境外向美国客户收费的开发者，最终都可能被要求提交 [W-8BEN 表格](https://dodopayments.com/blogs/w-8ben-form-guide)；忽略它的默认结果是从付款中直接扣除固定比例的金额。
- **入驻审核是门槛，而不是形式。** 向企业结算资金的平台，会在首次付款结算前对企业实体及其受益所有人进行 [KYB 审核](https://dodopayments.com/blogs/kyb-verification)。

这些问题并非 AI 产品独有，但按用量定价会放大影响：按 token 计费的模型会在多个司法辖区产生大量小额发票，因此税务判定中的错误会批量重复，而不是只发生一次。

### 移动渠道将计费拆成两套故事

还有一个值得注意的接口，因为大多数 AI 产品一发布移动应用就会继承它。在 iOS 或 Android 应用内开通的 ChatGPT 订阅由应用商店而不是 OpenAI 直接计费，这意味着商店拥有支付关系、收据和取消流程，并会收取平台佣金。在网页上购买同一套餐，则会通过 OpenAI 自己的结账流程完成。

这就是为什么必须将订阅状态和支付状态分别建模；上面的架构部分已经说明了这一点。这也解释了为什么考虑移动订阅栈的团队，最终会比较基础设施层与将计费关系保留在自有系统中的网页结账方案。相关取舍见我们的 [RevenueCat 替代方案](https://dodopayments.com/blogs/revenuecat-alternatives)对比，以及[不通过应用商店销售软件](https://dodopayments.com/blogs/sell-software-without-app-store)。

## 常见问题

### 什么是 OpenAI 计费？

OpenAI 计费是一个混合系统，结合了 ChatGPT 订阅、API token 定价、预付额度和企业开票控制。它不是一张统一的价格表，而是为不同客户类型构建的多个计费层。

### OpenAI API 计费与 ChatGPT 计费有何不同？

ChatGPT 使用固定月度或按席位套餐，而 API 侧的 open ai billing 则是按用量计费，采用模型专属 token 成本和账户级消费控制。两个系统共用一个账户，但没有其他共同点：支付 ChatGPT 不会获得 API 额度，API 余额也不会提高 ChatGPT 套餐限制。

### OpenAI API 预付额度如何运作？

OpenAI API 预付额度用于预付或控制 token 消费。每个请求都会生成用量事件，成本按四种分别定价的 token 类型计算，预算或速率层级则确保账户处于允许范围内。个人用户侧现在也有预付额度，ChatGPT 用户可以超过套餐包含的限制继续使用，而不必升级或被硬性停止。

### 如何降低 OpenAI API 成本？

最大的三个杠杆是服务层级、缓存和模型选择：异步批处理相对标准费率有折扣，缓存输入只按新输入的一小部分计费，而将简单任务路由到同系列的小型模型可以大幅降低费率。让请求保持在公布的长上下文分界点以内，可以避免更高的长上下文费率；限制输出长度则能直接压缩最昂贵的请求组成部分。

### 初创公司可以复制 OpenAI 的计费模式吗？

可以。实际做法是为终端用户提供订阅，为 API 买家提供预付额度或按用量付费，并为企业客户提供管理员控制。Dodo Payments 等平台提供这些计费基础能力，无需你从头构建每个组件。

## 最后总结

**openai billing** 之所以是一个有价值的案例，是因为它展示了 AI 变现是系统设计，而不只是定价页面设计。

订阅、预付额度、用量计量器和企业消费控制之所以并存，是因为 OpenAI 面向不同买家，而不同买家有不同预期。如果你正在构建 AI 产品，这就是最值得借鉴的经验。

下一步，可以将 [Dodo Payments 定价](https://dodopayments.com/pricing)和[按用量付费的 AI SaaS 定价](https://dodopayments.com/blogs/pay-as-you-go-ai-saas)与 Dodo 文档中的[预付费计费](https://docs.dodopayments.com/features/credit-based-billing)、[用量计量器](https://docs.dodopayments.com/features/usage-based-billing/introduction)和[订阅](https://docs.dodopayments.com/features/subscription)进行比较。

如果你还处于早期阶段，仍在决定收费方式，[SaaS 的按用量计费](https://dodopayments.com/blogs/usage-based-billing-saas)介绍了模式选择，[如何将 AI 智能体变现](https://dodopayments.com/blogs/monetize-ai-agent)则讨论了当消耗计量额度的是软件而不是人时该怎么做。
---
- [More AI articles](https://dodopayments.com/blogs/category/ai)
- [All articles](https://dodopayments.com/blogs)