突破速率限制：扩展 Codex 和 Sora 的访问权限

📢 转载信息

原文链接：https://openai.com/index/beyond-rate-limits

原文作者：Jonah Cohen, Member of the Technical Staff

---

在过去的一年里，Codex 和 Sora 都实现了快速普及，使用量迅速超出了我们最初的预期。我们发现了一个持续的模式：用户深入使用后，发现真正的价值，然后就遇到了速率限制。

速率限制有助于平滑需求并确保公平访问；然而，当用户正在获得价值时，遇到硬性停止可能会令人沮丧。我们希望找到一种方法，让用户能够持续使用，同时保护系统性能并使用户对我们的方法保持信任。

为解决这个问题，我们构建了一个实时访问引擎来计算使用量。该引擎的一个层面是购买积分的能力。当用户超出其速率限制时，积分允许他们通过消耗其积分余额来继续使用我们的产品。

其底层是一个复杂的系统，它在一个单一的访问模型中融合了限制、实时使用跟踪和积分余额。本文将讨论扩展 Codex 和 Sora 为何需要重新思考访问控制，一个可证明正确的实时系统如何将每个请求的速率限制和积分结合起来，以及该基础如何为这两个产品解锁额外的访问权限。

从宏观角度来看，传统的访问模型往往会迫使用户做出选择：

• 速率限制：初期可能有帮助，但当用完时会给用户带来糟糕的体验：“稍后再回来”。
• 基于使用量的计费：非常灵活，但用户从第一个 token 开始就需要付费——这对于支持早期探索来说并不理想。

对于 Codex 和 Sora 而言，任何一种单独的方案都不够。如果我们只是提高速率限制，我们将失去重要的需求平滑和公平控制功能，并且没有能力为所有人提供服务。如果我们完全依赖异步的使用量计费，我们会引入延迟、超额或对账问题——这些正是用户在高度投入时最容易注意到的问题。

我们需要的则是一个结合了实时限制和按需访问的单一混合系统：

该系统必须能够：

• 直到达到限制时才强制执行速率限制
• 在同一个请求中无缝过渡到积分
• 实时做出决策
• 在跟踪积分消耗时做到严格准确和可审计

我们做出的一个关键概念转变是将访问建模为决策瀑布（decision waterfall）。我们不再问“这是否被允许？”，而是问“允许多少？从哪里获得？”在计算使用量时，系统会经历以下顺序：

此模型反映了用户实际体验产品的方式。速率限制、免费套餐、积分、促销和企业授权都只是同一决策堆栈中的层级。从用户的角度来看，他们不会“切换系统”——他们只是继续使用 Codex 和 Sora。这就是为什么积分感觉是“隐形”的：它们只是瀑布中的另一个元素。

我们评估了第三方使用量计费和计量平台来处理积分消耗。它们非常适合发票和报告，但未能满足两个关键要求：

当用户达到限制且有可用积分时，系统必须立即知道。尽力而为或延迟计数会表现为意外的阻塞、不一致的余额和不正确的收费。对于 Codex 和 Sora 这样的交互式产品，这些故障会变得可见并令人沮丧。

我们还需要对每种结果提供透明度：

• 请求被允许或阻止的原因
• 消耗了多少使用量
• 应用了哪些限制或余额

此功能需要与我们的决策瀑布紧密集成，而不是在独立的使用量计费平台中单独解决（该平台只能看到事件的一部分）。为了让用户在不损害信任的情况下访问我们的产品，我们需要对正确性、时机和可观测性拥有完全的控制权。这促使我们转向内部解决方案。

为支持这一点，我们构建了一个专为同步访问决策设计的分布式使用量和余额系统。

从高层次来看，该系统会：

• 跟踪每个用户、每个功能的使用量
• 维护速率限制窗口
• 维护实时积分余额
• 通过流式异步处理器幂等地借记余额

每个请求都通过单一的评估路径，该路径通过同步消耗速率限制（如果需要，还验证是否有足够的积分）来实时决定允许的使用量；然后返回一个明确的结果，同时异步结算任何积分借记。这确保了跨产品的行为一致性，并消除了团队间的重复逻辑。

该系统的关键设计原则之一是，我们必须能够证明我们的计费是正确的。这反映了我们积分支持的根源，该根源最初是为企业客户设计的。在上面的系统图中，我们有三个相互关联的独立数据集：

• 产品使用事件：用户实际做了什么
• 货币化事件：我们向用户收取的费用
• 余额更新：我们调整了用户积分余额的金额以及原因

这些数据集不是偶然的副产品；它们实际上驱动着系统，每个数据集都会触发下一个。将发生的事件、任何相关费用以及我们借记的内容分离开来，使我们能够独立审计、重放和对账每一层。这是一种有意为之的权衡，即我们优先考虑可证明的正确性，而牺牲了积分余额更新的即时性。我们通过以下方式实现这一点：

• 发布产品使用事件以记录所有用户活动，无论它是否驱动积分消耗。这为用户活动提供了审计跟踪，并使我们能够解释为什么我们收取或未收取积分。
• 每个事件都带有一个稳定的幂等性键，因此重试、重放或工作进程重启永远不会导致余额被重复借记，从而防止重复收费。这还允许我们运行批处理对账来离线验证我们的工作。
• 我们执行异步（但仍然接近实时）的余额更新而不是同步更新，以创建审计跟踪。我们容忍用户余额更新的短暂延迟，以便我们可以证明系统正在运行，并向用户保证我们没有错误收费。当这种短暂的延迟导致我们超出用户的积分余额时，我们会自动退款；我们选择可证明的正确性和用户信任，而不是严格执行。
• 我们在单个原子数据库事务中减少积分余额并插入余额更新记录。余额更新是按账户序列化的，因此并发请求永远不会竞相花费相同的积分。余额更新记录同时包含借记金额以及对触发更新的货币化事件的归属；将此包装在单个数据库事务中，确保我们拥有每次积分余额调整的审计跟踪。

所有这些严谨性都服务于一个目标：使访问变得简单和安全。当人们进行创作或编码时，他们不应该担心请求是否会通过、是否会被多收费，或者他们的余额是否准确。通过使使用量、计费和余额可被证明是正确的，我们为用户提供了一个不会分散其体验注意力的系统。这使得我们能够用持续访问取代硬性停止——这也使得积分可以在实际工作过程中使用，而不仅仅是在发票上。

我们方法的指导原则是保护用户动量。每一个架构决策都映射到一个面向用户的结果：实时余额可防止不必要的打断，原子消耗可防止重复收费，统一的访问逻辑可确保可预测的行为。结果是人们可以工作更长时间、探索更深入、推进项目更远，而不会遇到硬性停止或过早的计划变更。

当用户参与时，系统应该帮助他们继续，而不是阻碍他们。限制和积分会消失在背景中。

构建这种体验需要将访问、使用量和计费视为一个单一系统进行重新思考，并构建将正确性视为一等公民产品特性的基础设施。相同的底层基础可以随着时间的推移扩展到更多的产品；Codex 和 Sora 只是开始。

---

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。