速率限制
速率限制是我们的 API 对用户或客户端可以 在指定时间内访问我们的服务。
为什么我们有速率限制?
速率限制是 API 的常见做法,设置速率限制的原因有以下几个:
- 它们有助于防止 API 被滥用或误用。例如,恶意行为者可能会向 API 发送大量请求,以试图使其过载或导致服务中断。通过设置速率限制,OpenAI 可以防止此类活动。
- 速率限制有助于确保每个人都能公平地访问 API。如果一个人或组织发出过多的请求,则可能会使其他所有人的 API 陷入困境。通过限制单个用户可以发出的请求数量,OpenAI 确保尽可能多的人有机会使用 API,而不会遇到速度变慢的情况。
- 速率限制可以帮助 OpenAI 管理其基础设施上的聚合负载。如果对 API 的请求急剧增加,则可能会给服务器带来负担并导致性能问题。通过设置速率限制,OpenAI 可以帮助所有用户保持流畅一致的体验。
这些速率限制如何运作?
速率限制以五种方式衡量:RPM(每分钟请求数)、RPD(每天请求数)、TPM(每分钟令牌数)、TPD(每天令牌数)和 IPM(每分钟图像数)。任何选项都可以达到速率限制,具体取决于首先发生的情况。例如,您可以向 ChatCompletions 终端节点发送 20 个请求,其中只有 100 个令牌,这将填满您的限制(如果您的 RPM 为 20),即使您在这 20 个请求中没有发送 150k 令牌(如果您的 TPM 限制为 150k)。
Batch API 队列限制是根据为给定模型排队的输入令牌总数计算的。来自待处理批处理作业的令牌将计入您的队列限制。批处理作业完成后,其令牌不再计入该模型的限制。
其他值得注意的重要事项:
- 速率限制是在组织级别和项目级别定义的,而不是在用户级别定义的。
- 速率限制因使用的模型而异。
- 组织每月可以在 API 上花费的总金额也会受到限制。这些也称为 “使用限制”。
- 某些模型系列具有共享的速率限制。您的组织限制页面中“共享限制”下列出的任何模型在它们之间共享一个速率限制。例如,如果列出的共享 TPM 为 3.5M,则对给定“共享限制”列表中任何模型的所有调用都将计入该 3.5M。
使用套餐
您可以在账户设置的 limits (限制) 部分下查看组织的速率和使用限制。随着您对 OpenAI API 的使用量和您在我们 API 上的支出的增加,我们会自动将您升级到下一个使用层级。这通常会导致大多数模型的速率限制增加。
层 | 资格 | 使用限制 |
---|---|---|
自由 | 用户必须位于允许的地理位置 | 100 美元 / 月 |
第 1 层 | 已付 5 美元 | 100 美元 / 月 |
第 2 层 | 已支付 50 美元,首次成功付款后 7+ 天 | $500 / 月 |
第 3 层 | 已支付 100 美元,首次成功付款后 7+ 天 | 1,000 美元 / 月 |
第 4 层 | 已支付 250 美元,首次成功付款后 14+ 天 | $5,000 / 月 |
第 5 层 | 已支付 1,000 美元,首次成功付款后 30+ 天 | $200,000 / 月 |
选择下面的一个层级,查看每个模型的速率限制的高级摘要。
免费套餐速率限制
这是一个高级摘要,每个模型都有这些限制的例外情况(例如,一些旧模型或具有较大上下文窗口的模型具有不同的速率限制)。要查看您账户的每个模型的确切速率限制,请访问账户设置的限制部分。
MODEL | 转速 | RPD | TPM (TPM) | 批处理队列限制 |
---|---|---|---|---|
gpt-3.5-turbo | 3 | 200 | 40,000 | 200,000 |
text-embedding-3-large | 3,000 | 200 | 1,000,000 | 3,000,000 |
text-embedding-3-small | 3,000 | 200 | 1,000,000 | 3,000,000 |
text-embedding-ada-002 | 3,000 | 200 | 1,000,000 | 3,000,000 |
omni-moderation-* | 500 | 10,000 | 10,000 | - |
whisper-1 | 3 | 200 | - | - |
tts-1 | 3 | 200 | - | - |
dall-e-2 | 5 img/分钟 | - | - | - |
dall-e-3 | 1 img/分钟 | - | - | - |
标头中的速率限制
除了在账户页面上查看速率限制之外,您还可以在 HTTP 响应的标头中查看有关速率限制的重要信息,例如剩余请求、令牌和其他元数据。
您可能会看到以下标题字段:
田 | 样本值 | 描述 |
---|---|---|
x-ratelimit-limit-requests 请求 | 60 | 在用尽速率限制之前允许的最大请求数。 |
x-ratelimit-limit-tokens | 150000 | 在用尽速率限制之前允许的最大令牌数。 |
x-ratelimit-remaining-requests | 59 | 在用尽速率限制之前允许的剩余请求数。 |
x-ratelimit-remaining-tokens | 149984 | 在用尽速率限制之前允许的剩余令牌数。 |
x-ratelimit-reset-requests | 1 秒 | 速率限制(基于请求)重置为其初始状态之前的时间。 |
x-ratelimit-reset-tokens | 6 分 0 秒 | 速率限制(基于令牌)重置为其初始状态之前的时间。 |
错误缓解
我可以采取哪些措施来缓解这种情况?
OpenAI 说明书有一个 Python 笔记本,用于说明如何避免速率限制错误,以及一个在批处理 API 请求时保持在速率限制下的 Python 脚本示例。
在提供编程访问、批量处理功能和自动社交媒体发布时,您也应谨慎行事 - 考虑仅为受信任的客户启用这些功能。
为了防止自动和大量滥用,请在指定时间范围内(每天、每周或每月)为单个用户设置使用限制。考虑对超出限制的用户实施硬上限或手动审核流程。
使用指数退避重试
避免速率限制错误的一种简单方法是使用随机指数退避自动重试请求。使用指数退避重试意味着在遇到速率限制错误时执行短暂的睡眠,然后重试不成功的请求。如果请求仍然不成功,则增加休眠时间并重复该过程。这将一直持续到请求成功或达到最大重试次数。 这种方法有很多好处:
- 自动重试意味着您可以从速率限制错误中恢复,而不会崩溃或丢失数据
- 指数退避意味着您可以快速尝试第一次重试,同时在前几次重试失败时仍会受益于更长的延迟
- 向延迟添加随机抖动有助于同时重试所有命中。
请注意,不成功的请求会影响您的每分钟限制,因此持续重新发送请求将不起作用。
以下是一些使用指数回退的 Python 示例解决方案。
缩小 以匹配完成的大小max_tokens
您的速率限制是根据请求的字符数计算的令牌的最大值和估计数量的。尝试将该值设置为尽可能接近您的预期响应大小。max_tokens
max_tokens
批处理请求
如果您的使用案例不需要立即响应,则可以使用 Batch API 更轻松地提交和执行大量请求,而不会影响同步请求速率限制。
对于需要同步响应的使用案例,OpenAI API 对每分钟请求数和每分钟令牌数有单独的限制。
如果您达到了每分钟请求数的限制,但每分钟令牌数有可用容量,则可以通过将多个任务批处理到每个请求中来提高吞吐量。这将允许您每分钟处理更多的代币,尤其是对于我们的较小模型。
发送一批提示的工作方式与普通 API 调用完全相同,不同之处在于您将字符串列表而不是单个字符串传递给 prompt 参数。