摘要
1) 一句话总结 为解决 Codex 和 Sora 用户触及速率限制时的体验中断问题，团队内部构建了一套实时的混合访问与计费系统，通过“决策瀑布”模型无缝衔接速率限制与积分消耗。
2) 关键要点
- 混合访问模型：摒弃了单一的“硬性速率限制”或“纯按量计费”，采用“决策瀑布”模型，在单一请求内按顺序评估速率限制、免费额度、积分和企业权限。
- 内部构建决策：放弃第三方计费平台，选择内部构建，以确保交互式产品所需的实时正确性（避免意外拦截）和可对账性（透明的审计跟踪）。
- 分布式系统架构：系统实时跟踪每个用户和功能的使用情况，维护速率限制窗口和实时积分余额，并通过流式异步处理器扣除余额。
- 三层独立数据：将系统数据拆分为产品使用事件、货币化事件和余额更新，各层相互驱动且可独立审计与核对。
- 全面记录使用事件：无论是否消耗积分，系统都会发布所有用户活动的产品使用事件，以提供完整的审计跟踪。
- 稳定的幂等键：为每个事件分配稳定的幂等键，确保在重试、重放或节点重启时不会对用户余额进行重复扣款。
- 原子数据库事务：在单一数据库事务中同时执行“减少积分余额”和“插入余额更新记录”，并按账户序列化，防止并发请求产生竞态条件。
3) 风险与不足
- 异步更新导致的超扣风险：为保证可证明的正确性和审计跟踪，系统在积分余额更新时容忍了轻微的延迟；这种延迟可能导致扣除金额超出用户的实际积分余额（系统通过自动退款机制来解决此问题）。
- 第三方系统的延迟风险：文中明确指出，若使用尽力而为或存在延迟的第三方计算平台，会导致意外的拦截、余额不一致和错误扣费。
正文
过去一年中，Codex 和 Sora 的采用率激增，使用量迅速超出了我们最初的预期。我们观察到了一个固定的模式：用户深入体验产品，发现了真正的价值，然后就触及了速率限制（rate limits）。
速率限制有助于平滑需求并确保公平的访问权限。然而，当用户正在获取价值时，被硬性叫停会让人感到十分挫败。我们需要一种方法让用户能够继续使用，同时保护系统性能以及用户对我们处理方式的信任。
为了解决这个问题，我们构建了一个计算使用量的实时访问引擎。该引擎的其中一个层级是购买积分（credits）的功能。当用户超出速率限制时，积分系统允许他们通过消耗积分余额来继续使用我们的产品。
在这背后，是一个将限制、实时使用量跟踪和积分余额融合在单一访问模型中的复杂系统。本文将探讨为什么扩展 Codex 和 Sora 需要重新思考访问控制，一个可证明正确的实时系统如何将速率限制与按请求扣除积分相结合，以及这一基础架构如何为这两款产品解锁更多的访问权限。
现有访问模型的不足之处
从宏观来看，传统的访问模型通常迫使我们在两者之间做出选择：
- 速率限制：在初期很有帮助，但当额度耗尽时会给用户带来糟糕的体验（“请稍后再来”）。
- 基于使用量的计费：非常灵活，但要求用户从消耗第一个 token 起就开始付费——这不利于支持早期的探索体验。
对于 Codex 和 Sora 来说，这两种单一模型都不够用。如果我们仅仅提高速率限制，就会失去重要的需求平滑和公平控制机制，最终导致没有足够的容量来服务所有人。如果我们完全依赖异步的使用量计费，就会引入延迟、超额扣费或对账问题——而这些正是用户在最投入时最容易察觉到的问题。
相反，我们需要的是一个将实时限制与现收现付（pay-as-you-go）访问相结合的单一混合系统。这个系统必须做到：
- 执行速率限制，直到达到上限。
- 在同一个请求内无缝过渡到积分消耗。
- 实时做出上述决定。
- 在跟踪积分消耗时，做到严格准确且可审计。
将访问权限视为瀑布，而非闸门
我们做出的一个关键概念转变，是将访问权限建模为决策瀑布（decision waterfall）。系统不再问“这是否被允许？”，而是问“允许多少，从哪里扣除？”。在计算使用量时，系统会按顺序进行评估。
这种模型反映了用户的实际体验。速率限制、免费额度、积分、促销和企业权限都只是同一个决策栈中的不同层级。从用户的角度来看，他们不需要“切换系统”——他们只需继续使用 Codex 和 Sora。这就是为什么积分感觉是“隐形”的：它们只是瀑布模型中的另一个元素。
为什么选择内部构建
我们曾评估过使用第三方使用量计费和计量平台来处理积分消耗。它们非常适合开票和报告，但无法满足两个关键要求：
实时正确性
当用户达到限制且有可用积分时，系统必须立即知晓。尽力而为或延迟的计算会导致意外的拦截、余额不一致和错误扣费。对于 Codex 和 Sora 这样的交互式产品，这些故障会变得非常明显且令人沮丧。
可对账性与信任
我们还需要对每个结果提供透明度：
- 请求被允许或拦截的原因。
- 该请求消耗了多少使用量。
- 应用了哪些限制或余额。
这种能力需要紧密集成到我们的决策瀑布中，而不是在一个只能看到部分情况的独立计费平台中孤立解决。为了在不损害信任的情况下让用户访问我们的产品，我们需要对正确性、时序和可观测性拥有完全的控制权。这促使我们选择了内部构建方案。
构建大规模使用量与余额系统
为了提供动力，我们构建了一个专为同步访问决策设计的分布式使用量和余额系统。
从宏观上看，该系统：
- 跟踪每个用户、每个功能的使用情况。
- 维护速率限制窗口。
- 维护实时积分余额。
- 通过流式异步处理器幂等地（idempotently）扣除余额。
每个请求都会通过单一的评估路径，通过同步消耗速率限制并在需要时验证是否有充足积分，来实时决定允许的使用量；然后返回一个明确的结果，同时异步结算任何积分扣除。这确保了跨产品行为的一致性，并消除了团队间重复的逻辑。
可证明正确的计费系统
该系统的核心设计原则之一是，我们必须能够证明我们的计费是正确的。这源于我们最初为企业客户提供积分支持的初衷。在我们的系统中，有三个相互关联的独立数据集：
- 产品使用事件：用户实际执行的操作。
- 货币化事件：我们向用户收取的使用费。
- 余额更新：我们调整用户积分余额的金额及原因。
这些数据集不是偶然的副产品；它们实际上驱动着整个系统，每个数据集都会触发下一个数据集。将已发生的操作、相关费用和扣款分离开来，使我们能够独立审计、重放和核对每一层。这是一种有意的权衡：我们优先考虑可证明的正确性，代价是积分余额更新会有轻微延迟。我们是如何实现这一点的：
- 发布所有使用事件：无论是否消耗积分，都会发布所有用户活动的产品使用事件。这提供了用户活动的审计跟踪，并允许我们解释扣费或不扣费的原因。
- 稳定的幂等键：每个事件都带有稳定的幂等键，因此重试、重放或工作节点重启绝不会对余额进行双重扣款，从而防止重复收费。这也允许我们离线运行批量对账以验证我们的工作。
- 异步余额更新：我们采用异步（但接近实时）的余额更新来创建审计跟踪。我们容忍更新用户余额时的微小延迟，以证明系统正常运行并向用户保证我们没有错误计费。如果短暂的延迟导致扣除超出了用户的积分余额，我们会自动退款；我们选择了可证明的正确性和用户信任，而不是严格的强制执行。
- 原子数据库事务：我们在单一的原子数据库事务中减少“积分余额”并插入“余额更新”记录。余额更新按账户序列化，因此并发请求绝不会竞态消耗相同的积分。“余额更新”记录包含扣款金额以及触发更新的货币化事件的归因；将其封装在单一数据库事务中，保证了我们对积分余额的每次调整都有审计跟踪。
所有这些严谨的设计都服务于一个目标：让访问变得简单且安全。当人们在创作或编码时，他们不应该去猜测请求是否会通过、是否会被多扣费，或者余额是否准确。通过让使用量、计费和余额变得可证明正确，我们为用户提供了一个不会分散他们注意力的系统。正是这一点让我们能够用持续的访问取代硬性停止，也正是这一点让积分在实际工作中变得真正可用，而不仅仅是账单上的数字。
服务于用户节奏的架构
我们方法的指导原则是保护用户的创作节奏（momentum）。每一个架构决策都对应着面向用户的结果：实时余额防止不必要的中断，原子消耗防止重复收费，统一的访问逻辑确保可预测的行为。结果是，人们可以工作更长时间，探索更深，将项目推进得更远，而不会面临硬性停止或过早的计划变更。
当用户全神贯注时，系统应该帮助他们继续，而不是成为阻碍。限制和积分应当隐退到背景中。
构建这种体验需要将访问、使用量和计费作为一个单一系统重新思考，并构建将正确性视为一等产品功能的底层基础设施。同样的基础未来可以扩展到更多产品；Codex 和 Sora 仅仅是个开始。
相关文档
- 超越速率限制：扩大 Codex 和 Sora 的访问规模；关联理由：同一事件；说明：两文均对应同一篇 OpenAI 原文，可用于交叉核对翻译措辞与信息完整性。