速率限制是 API 对用户或客户端在指定时间段内访问服务次数的限制。
为什么需要速率限制?
速率限制是 API 的常见做法,其设立有以下几个原因:
- 它们有助于防止 API 被滥用或误用。 例如,恶意攻击者可能会通过向 API 发送大量请求,试图使其过载或导致服务中断。通过设置速率限制,OpenAI 可以防止此类行为。
- 速率限制有助于确保所有人都能公平地访问 API。 如果某个人或组织发起过多的请求,可能会导致其他用户的 API 访问变慢。通过限制单个用户可以发起的请求数量,OpenAI 可以确保大多数用户有机会使用 API 而不会遇到速度变慢的情况。
- 速率限制可帮助 OpenAI 管理其基础设施的总负载。 如果对 API 的请求量急剧增加,可能会导致服务器负载过高并引发性能问题。通过设置速率限制,OpenAI 可以帮助为所有用户维持流畅且一致的体验。
请完整阅读本文档,以更好地了解 OpenAI 的速率限制系统是如何运作的。我们提供了代码示例以及处理常见问题的可能解决方案。我们还包含了有关您的速率限制如何在下方使用层级部分中自动增加的详细信息。
这些速率限制是如何运作的?
速率限制使用的指标包括 RPM (每分钟请求数)、 RPD (每天请求数)、 TPM (每分钟令牌数)、 TPD (每天令牌数)、 IPM (每分钟图像数),以及部分流式音频模型的每分钟音频分钟数。速率限制可能会在达到上述任一指标时触发,具体取决于哪个先发生。例如,您可能仅使用 100 个令牌向 ChatCompletions 终端节点发送了 20 个请求,这就会耗尽您的限制(如果您的 RPM 为 20),即使您在这 20 个请求中没有发送 150k 个令牌(如果您的 TPM 限制为 150k)。
Batch API 队列限制是根据排队等待给定模型处理的输入令牌总数计算的。待处理的批处理作业中的令牌将计入您的队列限制。一旦批处理作业完成,其令牌将不再计入该模型的限制。
其他需要注意的重要事项:
- 速率限制是在 组织级别 和项目级别定义的,而不是在用户级别定义的。
- 速率限制因所使用的 模型 而异。
- 对于像 GPT-4.1 这样的长上下文模型,长上下文请求有单独的速率限制。您可以在 开发者控制台.
- 组织也受到每月在 API 上可消费总额的限制。这些也称为“使用限制”。
- 某些模型系列共享速率限制。在您的 组织限制页面 中列在“共享限制”下的任何模型都共享一个速率限制。例如,如果列出的共享 TPM 为 3.5M,那么对给定“共享限制”列表中任何模型的所有调用都将计入该 3.5M。
- 向量存储摄取也按向量存储 ID 进行速率限制。
/vector_stores/{vector_store_id}/filesand/vector_stores/{vector_store_id}/file_batches每个向量存储共享每分钟 300 个请求的限制。对于较大的数据摄取,建议使用/vector_stores/{vector_store_id}/file_batches.
使用层级
您可以在帐户设置的 限制进行比较 部分下查看组织的速率和使用限制。随着您在我们 API 上的支出增加,我们会自动将您升级到下一个使用层级。这通常会导致大多数模型的速率限制增加。
| 层级 | 资格条件 | 使用限制 |
|---|---|---|
| 免费 | 用户必须位于 允许的地区 | $100 / 月 |
| 层级 1 | 已支付 $5 | $100 / 月 |
| 层级 2 | 已支付 $50 | $500 / 月 |
| 层级 3 | 已支付 $100 | $1,000 / 月 |
| 层级 4 | 已支付 $250 | $5,000 / 月 |
| 等级 5 | 已支付 $1,000 | $200,000 / 月 |
要查看每个模型的速率限制高级摘要,请访问 模型页面.
标头中的速率限制
除了在您的 账户页面,你还可以在 HTTP 响应头中查看有关速率限制的重要信息,例如剩余请求数、令牌数以及其他元数据。
您可能会看到以下标头字段:
| 字段 | 示例值 | 描述 |
|---|---|---|
| x-ratelimit-limit-requests | 60 | 在耗尽速率限制前所允许的最大请求数。 |
| x-ratelimit-limit-tokens | 150000 | 在耗尽速率限制前所允许的最大 token 数。 |
| x-ratelimit-remaining-requests | 59 | 在耗尽速率限制前剩余的请求数。 |
| x-ratelimit-remaining-tokens | 149984 | 在耗尽速率限制前剩余的 token 数。 |
| x-ratelimit-reset-requests | 1s | 速率限制(基于请求数)恢复到初始状态所需的时间。 |
| x-ratelimit-reset-tokens | 6m0s | 速率限制(基于 token 数)恢复到初始状态所需的时间。 |
微调速率限制
您组织的微调速率限制可以 在控制面板中找到,也可以通过 API 检索:
curl https://api.openai.com/v1/fine_tuning/model_limits \
-H "Authorization: Bearer $OPENAI_API_KEY"错误缓解
我可以采取哪些步骤来缓解此问题?
OpenAI Cookbook 提供了一个 Python 笔记本 解释了如何避免速率限制错误,以及一个 Python 脚本 示例,用于在批量处理 API 请求时保持在速率限制之内。
在提供编程访问、批量处理功能和自动发布社交媒体时,您也应谨慎行事——考虑仅对受信任的客户启用这些功能。
为防止自动化和大量滥用,请在指定时间范围(每天、每周或每月)内为单个用户设置使用限制。考虑对超过限制的用户实施硬性上限或手动审查流程。
使用指数退避重试
避免速率限制错误的一种简单方法是使用随机指数退避自动重试请求。使用指数退避重试意味着在遇到速率限制错误时短暂休眠,然后重试未成功的请求。如果请求仍然不成功,则增加休眠时间并重复该过程。此过程将一直持续,直到请求成功或达到最大重试次数为止。这种方法有许多好处:
- 自动重试意味着您可以从速率限制错误中恢复,而不会发生崩溃或数据丢失
- 指数退避意味着你可以快速尝试首次重试,同时在前几次重试失败后,依然能从较长的延迟中受益
- 在延迟中加入随机抖动有助于避免所有重试请求同时发起。
请注意,不成功的请求也会计入你的每分钟请求限额,因此持续不断地重发请求是行不通的。
以下是一些示例解决方案 for Python 它们使用了指数退避。
降低 max_tokens 以匹配你的补全结果大小
你的速率限额计算方式为 max_tokens 以及基于请求字符数估算的 token 数这两者的最大值。请尽量将 max_tokens 值设置为接近你预期的响应大小。
批量请求
如果你的用例不需要立即获得响应,你可以使用 Batch API 来更轻松地提交和执行大量请求,而不会影响你的同步请求速率限额。
For use cases that do 需要同步响应,OpenAI API 对 每分钟请求数 and 每分钟 token 数.
如果你达到了每分钟请求数的限制,但每分钟令牌数仍有余量,你可以通过将多个任务批量打包到每个请求中来提高吞吐量。这允许你每分钟处理更多的令牌,尤其是使用我们较小的模型时。
发送批量提示词与普通的 API 调用完全相同,只是你需要向 prompt 参数传入一个字符串列表,而不是单个字符串。 在 Batch API 指南中了解更多信息.