OpenAI API 429 Too Many Requests 怎么解决？

更新于 2026-10-30 · onomeo.cyou

简答：OpenAI API 返回 429 时，先读取响应体中的 error.type、error.code、message，再检查 Retry-After 和项目 Limits 页面。临时限流应降速并按退避策略重试；余额、组织额度或项目支出限制则先处理账单或额度，不能靠重复请求恢复。

定义：OpenAI API 的 429 Too Many Requests 表示当前请求未被接受，原因可能是请求或 Token 速率过高，也可能是余额、组织使用额度或项目支出限制，必须结合响应字段判断。

先按这张表判断：429 是该重试，还是先查额度？

截至 2026-10-30，OpenAI 官方文档明确指出，其他错误也可能使用相同 HTTP 状态，因此不能只看到 429 就认定是短暂限流。应优先保存响应体、响应头和请求时间，再根据实际字段分流。官方错误码文档与官方速率限制文档都建议结合错误代码和限制信息处理。

OpenAI API 429 常见处理方向

看到的线索	通常代表什么	先做什么	是否适合自动重试
`rate_limit_error` + `slow_down`	请求增长过快，可能尚未耗尽 RPM 或 TPM	遵守 `Retry-After`，降低请求速率，逐步恢复	可以，但要限制次数、总时长和并发
Rate limit reached 或 `rate_limit_exceeded`	请求数或 Token 速率达到限制；具体代码以实际响应为准	降低 RPM、TPM 和突发并发，检查 Limits 页面	可以谨慎重试，不能连续立即重发
`credit_balance_exhausted`	预付余额耗尽	检查并补充可用余额	不应重试
`organization_spend_limit_exceeded`	组织达到设置的月度支出限制	检查组织级 Spend Limit 或等待限制周期处理	不应重试
`project_spend_limit_exceeded`	当前项目达到项目级支出限制	检查项目设置和项目归属	不应重试
`organization_usage_limit_exceeded`	达到 OpenAI 分配的组织月度使用额度	申请提高批准额度或联系支持	不应重试
只有 `error.type`，没有明确 `error.code`	信息不足，不能仅凭类型下结论	记录完整响应，查看控制台和当前官方文档	按业务风险采用保守策略

注意：上述代码不是永久不变的白名单。不同接口、SDK 版本或服务配置可能返回不同字段；最终应以实际响应、当前官方文档和控制台显示为准。

最短排查流程：从响应体到 Limits 页面

保存完整错误信息。记录 HTTP 状态、error.type、error.code、error.message、Retry-After、x-ratelimit-remaining-requests、x-ratelimit-remaining-tokens、模型、项目和请求时间。不要记录 API Key 原文。
先做一次最小请求。使用当前项目可见的模型、很短的输入和较小输出预算，避免在原有高并发任务上继续重试。最小请求成功，只能说明当前凭证和模型路径可用，不能证明生产流量不会再次触发限制。
核对项目和组织。官方速率限制按组织和项目计算，不是只按单个用户计算。确认应用实际使用的 API Key、组织、项目和模型与控制台查看的 Limits 页面一致。
分辨 RPM 与 TPM。RPM 是每分钟请求数，TPM 是每分钟 Token 数；任何一个先达到上限，都可能导致限流。大量短请求更容易撞 RPM，少量长上下文或大输出更容易撞 TPM。
检查是否有突发流量。定时任务同时启动、多个实例共享一个 Key、失败后多层重试，都会让瞬时请求速率上升。先降低并发，再逐步恢复，而不是让所有请求一起重发。
最后才看代码重试。临时限流可以重试；余额、支出、组织额度和权限类错误必须先处理对应配置。若持续失败，按官方建议准备模型、错误消息和代码、请求头、时间及时区等信息联系支持。

官方速率限制页面列出了 Retry-After 以及多种 x-ratelimit-* 响应头。某些响应可能没有这些头，因此应用仍要准备退避和上限控制。查看官方响应头和限制说明。

临时限流怎么重试：Retry-After 优先，指数退避兜底

如果响应包含有效的 Retry-After，应至少等待该时间；为了避免多个实例同时恢复，可再增加少量随机抖动。如果没有该响应头，使用带随机抖动的指数退避，并同时限制最大尝试次数和总重试时间。官方还提醒，不成功的请求也会计入每分钟限制，连续立即重发可能让情况更糟。

import random
import time
from openai import OpenAI, RateLimitError

client = OpenAI()


def call_with_backoff(create_request, max_attempts=5, max_total_seconds=60):
    start = time.monotonic()
    delay = 1.0

    for attempt in range(max_attempts):
        try:
            return create_request()
        except RateLimitError as exc:
            # 仅把临时限流作为候选；额度、账单和支出限制应先人工处理
            code = getattr(getattr(exc, "body", None), "get", lambda *_: None)("code")
            if code in {
                "credit_balance_exhausted",
                "organization_spend_limit_exceeded",
                "project_spend_limit_exceeded",
                "organization_usage_limit_exceeded",
            }:
                raise

            wait = min(delay + random.uniform(0, 0.5), 30)
            if time.monotonic() - start + wait > max_total_seconds:
                raise
            time.sleep(wait)
            delay *= 2

    raise RuntimeError("retry limit exceeded")


response = call_with_backoff(
    lambda: client.responses.create(
        model="替换为项目可用的模型 ID",
        input="用一句话回答：什么是 API 限流？",
        max_output_tokens=80,
    )
)
print(response.output_text)

这段示例是应用层退避骨架，不应直接当作所有 SDK 和所有 429 的固定白名单。生产环境应解析实际响应体，并把 Retry-After 纳入等待时间；如果 SDK 已经自动重试，应用层不要再无条件套一层重试。OpenAI Python 和 TypeScript SDK 文档都说明，当前库会对部分 429、408、409 和 5xx 等情况默认重试，但具体行为受 SDK 版本和配置影响，需核对已安装版本。Python SDK 重试说明 TypeScript SDK 重试说明。

降低再次触发 429 的工程处理

控制并发：使用队列和信号量限制同时在途请求，不要让每个线程、进程或容器各自维护一套无限并发。
平滑发送：避免整点任务同时启动；将批量任务拆分并设置稳定的发送速率。
降低 Token 预算：缩短不必要的上下文，合理设置输出 Token 参数。具体参数名取决于所用 API 和模型，不能把 max_tokens、max_completion_tokens、max_output_tokens 当成完全等价的字段。
避免重复重试：检查 SDK、网关、任务队列和业务代码是否同时重试；统一设置总超时、最大次数和取消逻辑。
请求去重：对可重复提交的任务使用业务请求 ID 或结果缓存，避免用户重试、队列重试和网络重试共同产生重复调用。
共享 Key 要可观测：记录哈希后的 Key 标识、应用实例、项目、模型、请求类型和响应状态，便于定位多个应用共同消耗同一组织或项目额度。

这些属于通用工程实践，不代表 OpenAI 为每个应用规定了固定实现。若使用流式请求，开始传输后的错误可能以流事件出现；已经消费部分输出时，不要在没有业务去重策略的情况下自动完整重放原请求。官方流式错误与重试说明。

一个可复制的成功判定与失败分流清单

成功判定：HTTP 状态为成功，响应包含预期的响应 ID 或输出字段，且服务端没有返回错误对象；不要只用“请求没有立刻报错”判断成功。

仍是 429：重新读取实际 error.code，确认是否有 Retry-After，再查 RPM、TPM、并发和 Limits。
出现余额或 Spend Limit 代码：停止自动重试，处理余额、组织设置或项目设置。
出现 503：这不是 429；官方将 server_is_overloaded 作为模型暂时过载处理，按 Retry-After 或带抖动的退避重试。
SDK 一直重复请求：检查 SDK 默认重试、网关重试和业务重试是否叠加，降低其中一层或统一总预算。
无法确认原因：保留脱敏后的错误响应、请求时间、模型、项目和请求 ID，按官方支持要求提交，不要上传密钥和完整敏感 Prompt。

如果你需要在兼容接口中验证 Key、Base URL、模型和限流行为，建议先用一个最小请求单独确认连接，再把并发控制和重试逻辑接入业务。

广告｜需要兼容接口调用与 429 排查入口？

如果你正在配置 OpenAI 兼容接口，可将本文的 Key、Base URL、模型名和最小请求流程逐项核对，再根据实际错误字段处理限流或额度问题。推荐：犀速-AI 官网提供面向开发者的 API 接入入口，具体模型、额度和使用规则以页面及实际响应为准。

常见问题

OpenAI API 429 一定是请求太多吗？

不一定。临时限流、请求增长过快、余额耗尽、组织月度使用额度、组织支出限制和项目支出限制都可能返回 429。应读取 error.type、error.code、message 和响应头，不能只看状态码。

没有 Retry-After 还能重试吗？

如果确认是临时限流，可以使用带随机抖动的指数退避，但必须限制最大尝试次数和总时间；如果是余额、支出或组织额度错误，缺少 Retry-After 也不意味着可以继续重试。

slow_down 和 rate_limit_exceeded 有什么区别？

官方文档将 slow_down 用于请求速率增长过快的场景；rate_limit_exceeded 可能表示达到请求或 Token 速率限制。两者都应结合实际响应和 Limits 页面判断，不能把 slow_down 当成所有 429 的通用代码。

OpenAI SDK 已经自动重试，还需要自己写重试吗？

不一定。当前官方 Python 和 TypeScript SDK 文档说明，部分 429、408、409 和 5xx 默认会重试，但行为受 SDK 版本和配置影响。先确认 SDK 的重试设置，再决定是否由应用层统一管理，避免多层重试放大流量。

如何区分 RPM 和 TPM 导致的 429？

查看响应中的 x-ratelimit-remaining-requests、x-ratelimit-remaining-tokens 及对应 reset 字段，并结合请求数量和 Token 规模判断。短请求高并发更接近 RPM，大上下文或大输出更接近 TPM，但最终以实际响应和控制台 Limits 为准。