摘要
1) 一句话摘要 为解决 Codex 和 Sora 用户因速率限制导致的使用中断问题，团队自建了一套融合实时限额与异步额度扣减的混合访问控制系统，在保障计费准确可查的同时维持用户创作的连续性。
2) 关键点
- 业务背景：Codex 和 Sora 使用量激增，传统的“单一速率限制（导致中断）”或“纯按量计费（阻碍早期探索）”模式已无法满足需求。
- 核心解决方案：构建支持额度消耗的实时访问引擎。当用户超出免费速率限制时，系统可在同一次请求中无缝切换至扣减额度余额，避免强制中断。
- 瀑布式决策模型：将访问机制设计为按顺序逐层判断的“决策瀑布”（依次评估速率限制、免费额度、付费额度、促销权益等），对用户实现无感切换。
- 自建系统原因：弃用第三方计费平台，因为它们无法满足实时交互产品所需的“实时正确性（同步访问决策）”和“深度可对账能力”。
- 混合处理架构：系统在前端同步执行速率消耗与额度校验以实时返回访问结果，在后台通过流式处理器异步、幂等地完成额度扣减。
- 数据分层设计：将计费数据严格拆分为“产品使用事件”、“计费事件”和“余额更新”三类，确保每一层均可独立审计、重放与对账。
- 防重复计费机制：所有事件均带有稳定的幂等键，结合单账户串行处理与原子数据库事务（同步写入扣减金额与更新记录），彻底避免并发竞争和重复扣费。
3) 风险/不足
- 余额更新延迟与超扣风险：为保留完整的审计链路并优先保障可验证的正确性，系统容忍异步余额更新存在短暂延迟；若该延迟导致了额度超扣，系统将通过自动退款机制进行补偿。
正文
过去一年里，Codex 和 Sora 的采用速度迅猛，使用量远超最初预期。我们发现了一种清晰的规律：用户一旦深入使用并获得真实价值，很快就会触及速率上限。
速率限制有助于平衡需求、保障公平，但当用户在高效创作过程中遇到强制中断，难免会感到沮丧。我们希望在保障系统性能与用户信任的前提下，让用户能够不中断地继续使用。
为此，我们构建了一套实时访问引擎，用于精确统计使用量。其中一项关键机制，是支持购买额度。当用户超出速率限制时，可以通过消耗额度余额继续使用产品。
在这背后，是一种将限额控制、实时使用追踪与额度余额整合为统一访问模型的复杂系统。本文将介绍：为什么在扩展 Codex 和 Sora 时必须重构访问控制机制；一种可验证正确的实时系统如何在单次请求中融合速率限制与额度；以及这套基础设施如何为两款产品带来更灵活的访问能力。
为什么现有访问模式难以支撑增长
从更宏观的角度来看，传统访问模式往往迫使我们在两种方案之间做取舍：
- 速率限制在初期有效，但一旦用尽，用户只能“稍后再访问”，体验随之中断
- 按用量计费更灵活，但用户从第一个 token 起就需要付费 — 这并不利于早期探索
对于 Codex 和 Sora 来说，单一模式都不足以满足需求。如果单纯提高速率上限，就会削弱需求调节与公平机制，甚至影响整体服务能力。如果完全依赖异步计费，则可能引入延迟、超额或对账问题 — 而这些问题，往往在用户最投入时最容易被察觉。
因此，我们真正需要的是一个融合实时限额与按需付费能力的混合访问系统。
这套系统必须能够：
- 在达到上限 之前，严格执行速率限制
- 在同一次请求中，无缝切换至额度机制
- 实时完成访问决策
- 在额度消耗追踪上做到严谨、准确、可审计
访问机制：瀑布式，而非闸门式
我们做出的一个关键转变，就是将访问机制建模为决策瀑布。与其问“是否允许？”，不如问“具体允许多少？从哪里扣减？”在计算使用量时，系统会按既定顺序逐层判断：
这种模型更贴近用户的真实体验。速率限制、免费层次、额度、促销权益、企业权限，本质上只是同一决策体系中的不同层级。对用户而言，他们并不会感知到“系统切换”，而只是持续使用 Codex 和 Sora。也正因如此，额度机制几乎是无感的 — 它只是决策瀑布中的一层。
为什么选择自主构建
我们曾评估第三方计费与计量平台来处理额度消耗。它们适合开票与报表场景，但无法满足两个核心要求：
实时正确性
当用户达到上限且仍有可用额度时，系统必须 立即 做出判断。延迟或“尽力而为”的计数，可能导致意外阻断、余额不一致或错误扣费。对于 Codex 和 Sora 这样的实时交互产品，这类问题会直接影响体验。
可对账能力与信任保障
我们还需要对每一次决策保持透明：
- 为什么某个请求被允许或被拒绝
- 实际消耗了多少使用量
- 使用了哪类限额或余额
这项能力必须深度整合进决策瀑布，而不能交由一个只掌握局部数据的独立计费平台处理。要在不损害信任的前提下开放访问，我们必须完全掌控正确性、时效性与可观测性。因此，我们选择了自建系统。
构建大规模的使用与余额系统
我们打造了一套分布式使用与余额系统，专门支持同步访问决策。
从整体架构来看，该系统能够：
- 按用户与功能维度追踪使用情况
- 维护速率限制窗口
- 维护实时额度余额
- 通过流式异步处理器以幂等方式完成余额扣减
每个请求都会进入统一评估路径：系统同步消耗速率额度，并在必要时校验额度是否充足，实时返回最终访问结果；额度扣减则在后台异步结算。这样既保证了跨产品的一致行为，也避免了团队间重复实现逻辑。
一个可验证正确的计费系统
该系统的核心设计原则是：我们必须能够 证明 计费是正确的。这一理念源自我们为企业客户提供额度支持的实践。该系统将数据拆分为三类：
- **产品使用事件：**用户实际执行了什么操作
- **计费事件：**哪些使用行为产生了费用
- **余额更新：**调整了多少额度，以及原因
这些数据并非附属产物，而是驱动系统运行的核心机制，彼此依次触发。将“发生了什么”“产生了什么费用”“实际扣减多少额度”分离，使我们能够对每一层独立审计、重放与对账。这是一种有意识的权衡：我们优先确保可验证的正确性，即便余额更新会存在轻微延迟。具体实现方式如下：
- 所有用户活动都会生成使用事件，无论是否涉及额度消耗。这为用户行为提供完整的审计轨迹，也让我们能够清晰解释为何扣减或未扣减额度。
- 每个事件都带有稳定的幂等键，因此重试、重放或服务重启都不会重复扣减余额，从而防止重复计费。系统还支持离线批量对账验证。
- 我们采用异步（但接近实时）的余额更新机制，以保留完整审计链路。我们容忍余额更新存在短暂延迟，以便能够证明系统运行正常，并向用户保证不存在误扣费用。若短暂延迟导致超扣，我们会自动退款 — 系统会优先保障可验证正确性与用户信任，而非绝对强制执行。
- 我们在单个原子数据库事务中完成 额度余额 扣减，并写入 余额更新 记录。余额更新按账户串行处理，避免并发请求竞争同一额度。余额更新 记录既包含扣减金额，也关联触发更新的计费事件；通过原子事务封装，确保每一次余额调整都有完整审计链路。
所有这些严谨设计，都服务于一个目标：让访问更简单、更可靠。当用户创作或编写代码时，不必担心请求是否成功、是否被误扣费用，或余额是否准确。通过让使用、计费与余额具备可验证的正确性，我们提供了一个不会干扰创作体验的系统。这让我们能够用连续访问替代硬性中断，也让额度在真实工作过程中自然发挥作用，而不仅仅体现在账单上。
为用户动量而设计的架构
我们的核心原则是保护用户的创作动量。每一个架构决策，都对应一个用户体验结果：实时余额减少不必要中断，原子扣减防止重复计费，统一访问逻辑确保行为可预测。最终，用户可以更长时间地工作、更深入地探索，并将项目推进到更远的阶段，全程不会遭遇强制中断，也无需过早调整计划。
当用户高度投入时，系统应提供助力，而非制造阻碍。限额与额度退居幕后。
实现这一体验，需要将访问、使用与计费视为一个统一系统重新设计，并将“正确性”作为核心产品能力来构建基础设施。这套基础架构未来可扩展至更多产品 — Codex 和 Sora 只是起点。
致谢
特别感谢打造额度系统的 FinEng 团队全体成员。
相关文档
- 将 PostgreSQL 扩展至支持 8 亿 ChatGPT 用户；关联理由：延伸思考；说明：两文分别覆盖高并发系统中的访问控制与数据库扩展，可组合理解 OpenAI 在不同技术层面的扩容策略。