主导航

遗留 API

速率限制

了解 API 速率限制与限制条件。

速率限制是指我们的 API 对用户或客户端在特定时间段内访问我们服务的次数所施加的限制。

为什么要设置速率限制?

速率限制是 API 的常见做法,设置它们的原因有以下几点:

  • 它们有助于防止对 API 的滥用或误用。 例如,恶意行为者可能会向 API 发送大量请求,试图使其超载或导致服务中断。通过设置速率限制,OpenAI 可以防止此类活动。
  • 速率限制有助于确保每个人都能公平地访问 API。 如果某个人或组织发出的请求过多,可能会拖慢其他所有人的 API 响应速度。通过限制单个用户可以发出的请求数量,OpenAI 确保了尽可能多的人有机会在不经历延迟的情况下使用 API。
  • 速率限制可以帮助 OpenAI 管理其基础设施上的总负载。 如果对 API 的请求急剧增加,可能会增加服务器压力并导致性能问题。通过设置速率限制,OpenAI 可以帮助维护所有用户顺畅且一致的体验。

请完整阅读本文档,以更好地了解 OpenAI 的速率限制系统是如何运作的。我们提供了代码示例和解决常见问题的潜在方案。此外,我们还在下方的“使用层级”部分中包含了有关如何自动增加速率限制的详细信息。

这些速率限制是如何运作的?

速率限制使用诸如 RPM(每分钟请求数)、RPD(每天请求数)、TPM(每分钟令牌数)、TPD(每天令牌数)、IPM(每分钟图像数)以及某些流式音频模型的每分钟音频时长等指标。根据触发条件的先后顺序,任何选项都可能达到速率限制。例如,您可能向 ChatCompletions 端点发送了 20 个请求,其中仅包含 100 个令牌,即使您在这些请求中没有达到 150k 令牌(假设 TPM 限制为 150k),但这也会填满您的限制(如果您的 RPM 限制为 20)。

Batch API 的队列限制是根据给定模型排队的总输入令牌数计算的。待处理批处理作业的令牌会计入您的队列限制。一旦批处理作业完成,其令牌将不再计入该模型的限制。

其他值得注意的重要事项

  • 速率限制是在组织级别和项目级别定义的,而不是在用户级别定义的。
  • 速率限制因使用的模型而异。
  • 对于像 GPT-4.1 这样的长上下文模型,有单独的长上下文请求速率限制。您可以在开发者控制台中查看这些速率限制。
  • 此外,组织每月在 API 上花费的总金额也有限制。这些限制也称为“使用限制”。
  • 某些模型系列具有共享速率限制。在您的组织限制页面上列出的属于“共享限制”下的任何模型,都在它们之间共享一个速率限制。例如,如果列出的共享 TPM 为 350 万,则对给定“共享限制”列表中的任何模型的调用都将计入这 350 万次限额。
  • 向量存储摄取(Vector store ingestion)也按向量存储 ID 进行速率限制。/vector_stores/{vector_store_id}/files/vector_stores/{vector_store_id}/file_batches 每个向量存储共享每分钟 300 个请求的限制。对于较大规模的摄取,建议使用 /vector_stores/{vector_store_id}/file_batches

使用层级

您可以在账户设置的限制部分查看您组织的速率和使用限制。随着您在 API 上的消费增加,我们会自动将您升级到下一个使用层级。这通常会导致大多数模型的速率限制增加。

层级资格要求使用限制
免费 (Free)用户必须位于允许的地区$100 / 月
Tier 1$5 已付费$100 / 月
Tier 2$50 已付费$500 / 月
Tier 3$100 已付费$1,000 / 月
Tier 4$250 已付费$5,000 / 月
Tier 5$1,000 已付费$200,000 / 月

要查看各模型的速率限制概览,请访问模型页面

请求头中的速率限制

除了在您的账户页面查看速率限制外,您还可以在 HTTP 响应头中查看有关速率限制的重要信息,例如剩余请求数、令牌数及其他元数据。

您可以预期看到以下响应头字段:

字段示例值描述
x-ratelimit-limit-requests60在耗尽速率限制前允许的最大请求数。
x-ratelimit-limit-tokens150000在耗尽速率限制前允许的最大令牌数。
x-ratelimit-remaining-requests59在耗尽速率限制前剩余的允许请求数。
x-ratelimit-remaining-tokens149984在耗尽速率限制前剩余的允许令牌数。
x-ratelimit-reset-requests1s距离速率限制(基于请求)重置为初始状态的时间。
x-ratelimit-reset-tokens6m0s距离速率限制(基于令牌)重置为初始状态的时间。

微调(Fine-tuning)速率限制

您组织的微调速率限制同样可以在仪表板中找到,也可以通过 API 获取。

curl https://api.openai.com/v1/fine_tuning/model_limits \
  -H "Authorization: Bearer $OPENAI_API_KEY"

错误缓解

我可以采取哪些措施来缓解此问题?

OpenAI Cookbook 提供了一个 Python 笔记本,解释了如何避免速率限制错误,以及一个用于在批量处理 API 请求时保持在速率限制内的示例 Python 脚本

在提供程序化访问、批量处理功能和自动化社交媒体发布时,您也应保持谨慎——考虑仅针对受信任的客户启用这些功能。

为了防止自动化和高容量的误用,请在指定时间框架(每日、每周或每月)内为单个用户设置使用限制。考虑对超出限制的用户实施硬性限制或人工审核流程。

使用指数退避进行重试

避免速率限制错误的简单方法是使用随机指数退避自动重试请求。使用指数退避重试意味着在遇到速率限制错误时进行短暂休眠,然后重试失败的请求。如果请求仍然失败,则增加休眠时长并重复此过程。这一过程将持续进行,直到请求成功或达到最大重试次数。这种方法有许多优点:

  • 自动重试意味着您可以在不崩溃或丢失数据的情况下从速率限制错误中恢复。
  • 指数退避意味着您的首次重试可以快速进行,同时如果前几次重试失败,仍能受益于更长的延迟。
  • 在延迟中添加随机抖动(Jitter)有助于防止所有重试请求在同一时间发送。

请注意,失败的请求也会计入您的每分钟限制,因此持续不断地重新发送请求是无效的。

以下是几个针对 Python 使用指数退避的示例解决方案。

减少 max_tokens 以匹配您的补全大小

您的速率限制是根据 max_tokens 和基于请求字符数估算的令牌数中的最大值计算的。尝试将 max_tokens 值设置得尽可能接近您的预期响应大小。

批量处理请求

如果您的用例不需要即时响应,您可以使用 Batch API 来更轻松地提交和执行大量请求,而不会影响您的同步请求速率限制。

对于确实需要同步响应的用例,OpenAI API 对每分钟请求数每分钟令牌数有单独的限制。

如果您达到了每分钟请求数的限制,但每分钟令牌数仍有可用容量,您可以通过将多个任务批量放入每个请求中来提高吞吐量。这将使您能够处理更多的每分钟令牌数,特别是在使用我们较小的模型时。

发送一批提示词的工作方式与普通 API 调用完全相同,只是您向 prompt 参数传递一个字符串列表,而不是单个字符串。在 Batch API 指南中了解更多信息

© . This website operates independently and is not affiliated with or endorsed by OpenAI, Inc. All brand names, logos, and trademarks are the property of their respective owners.