OpenAI API 的 429 不一定是请求发得太快，也可能是余额耗尽、月度用量受限或支出达到硬限制。 先打开完整错误响应，查看 error.code、error.type 和 error.message：普通速率限制应降速并等待；账户额度类错误应先修复账户设置，连续重试只会增加失败请求。截至 2026 年 9 月 8 日，OpenAI 中文排障文档已经分别列出这些情形。
本文适用于直接调用 OpenAI Platform API 的请求。首先确认客户端实际使用的 API 地址、密钥所属组织和项目，以及模型名；第三方网关、Azure OpenAI 和使用 ChatGPT 登录的产品，不能直接套用同一账户的限额设置。
先看错误码，决定该等待还是处理账户
HTTP 状态码是第一层信息，error.type 是较宽的错误类别，error.code 往往更具体。例如，下面这个用于说明字段关系的响应片段中，insufficient_quota 是类别，真正指明“预付余额用完”的是 credit_balance_exhausted：
json{ "error": { "type": "insufficient_quota", "code": "credit_balance_exhausted" } }
这不是一次真实调用记录。实际排障应保存自己的响应，并结合 message 理解；只看到 SDK 抛出 RateLimitError，仍不足以确定根因。
| 错误或响应信号 | 说明 | 现在该做什么 |
|---|---|---|
| 普通请求或 Token 速率限制，错误信息指出 RPM/TPM 超额 | 当前窗口容量不足 | 暂缓新请求，查看响应头，降低请求频率或 Token 压力 |
slow_down，类别为 rate_limit_error | 流量爬升过快，分钟额度可能还有剩余 | 停止升速，等待后逐步恢复 |
credit_balance_exhausted | 组织的预付余额耗尽 | 核对正确组织的余额和充值状态 |
organization_usage_limit_exceeded | 达到组织获批的月度用量上限 | 检查用量上限，按账户可用方式申请调整 |
organization_spend_limit_exceeded | 达到组织月度支出硬限制 | 由有权限的管理员检查并调整组织限制，或等待月度重置 |
project_spend_limit_exceeded | 达到当前项目月度支出硬限制 | 检查这个项目的支出限制，或等待月度重置 |
只有 insufficient_quota，没有更具体的代码 | 额度类原因尚未明确 | 结合错误信息核对余额、用量上限和支出限制，先停止自动重试 |
| 未知代码、错误体缺失或被网关改写 | 暂时无法可靠分类 | 保留响应和请求 ID，查明原因后再决定是否重试 |
上表中的额度错误定义来自官方 429 排障说明，slow_down 的定义来自API 错误码文档。不要给所有 429 加上“可重试”标签，也不要把所有 insufficient_quota 都翻译为“没钱了”。
充值后还是 429：检查限制作用在哪个账户
先确认充值、查看设置和失败请求使用的是同一个组织与项目。尤其在多个项目、环境变量和部署环境并存时，浏览器里看的账户可能与服务实际使用的密钥不一致。可以记录内部项目标识来核对，但不要把密钥写进日志或工单。
余额、获批月度用量、支出硬限制和预算告警是不同设置。预算告警只负责通知；真正阻止请求的是生效的硬限制。 组织硬限制会影响其下所有项目，项目硬限制只影响该项目。达到获批用量上限时，单纯增加预付余额也不代表上限已经提高。设置调整需要传播，不能承诺保存后下一秒就恢复；适用的月度支出限制也可能在月度重置后恢复。OpenAI 支出限制指南解释了告警与强制限制的区别。
建议按下面的顺序复测，而不是充值、换密钥和改重试参数同时进行：
- 匹配错误码与设置。 余额耗尽查余额，项目支出超限查项目，组织支出或用量超限查组织。
- 确认调整已经生效。 如果页面和接口仍不一致，记录修改时间与错误响应，不要持续轰炸接口。
- 保持请求身份不变。 用原来的组织、项目、密钥和模型发起一个输入与输出都较小的请求，以便判断同一问题是否解除。
- 成功后逐步放量。 单个小请求成功只证明这一请求通过，尚不能证明原来的并发与 Token 负载可以持续运行。
在同一个受限组织或项目里新建密钥，通常无法绕开对应限制。购买 ChatGPT 订阅也不等于给 Platform API 充值；若响应已经明确属于额度问题，可以继续查看 OpenAI API 额度不足排查。
普通限流：把请求数、Token 和突发分开看
RPM 是每分钟请求数，TPM 是每分钟 Token 数。两者分别限制容量，组织、项目和模型也可能各有约束，部分模型还共享限额。因此，判断“我每分钟只发几十次，为什么也会 429”之前，要先看每次请求有多大，以及是否集中在很短的时间内发出。官方速率限制指南说明了这些限制的作用范围。
用响应头定位先耗尽的容量
Platform Limits 页面用于查看账户配置；一次失败响应的响应头则帮助判断当时的窗口状态。
| 响应头 | 看什么 | 对应动作 |
|---|---|---|
x-ratelimit-limit-requests、x-ratelimit-remaining-requests、x-ratelimit-reset-requests | 请求上限、剩余请求数、重置时间 | 请求数先耗尽时减少单位时间的调用次数 |
x-ratelimit-limit-tokens、x-ratelimit-remaining-tokens、x-ratelimit-reset-tokens | Token 上限、剩余量、重置时间 | Token 先耗尽时缩短输入并调整输出预算 |
| 适用的项目 Token 限额响应头 | 当前项目是否另受 Token 限制 | 与项目设置一并核对 |
Retry-After | 服务端要求至少等待多久 | 按合法值等待，等待超出任务预算则延后或停止 |
不是每次响应都会带齐这些字段。缺失表示无法从该响应获得信息，不能当成零额度或无限额度；也不要把请求窗口的重置值用于推断账户账单何时恢复。
请求少，不代表 Token 少
长历史会话、重复粘贴的文档，以及过大的输出预算都可能增加压力。应先删除不必要的上下文，按任务设置合理输出上限：Responses 使用 max_output_tokens，Chat Completions 使用 max_completion_tokens。这些输出控制也涉及推理 Token，不能简单等同于最终可见文本长度。官方 429 说明给出了相应的 Token 与重试建议。
减少输出上限不能以截断业务需要的答案为代价。先估算任务需要，再为较长请求留出容量；把数个大请求错开发出，通常比把所有任务同时送入接口更容易控制。
分钟平均值正常，也可能有短窗口突发
例如，一分钟只有 60 个请求，却全部在第一秒发出，并不等于每秒均匀发送一个请求。限流可能按更短时间窗口执行；slow_down 还专门反映流量增长过快。应该让任务进入有速率控制的队列，重启服务、恢复积压任务和增加工作进程时都逐步放量。
并发数与 RPM 也不是同一个单位。并发数控制同时在途的请求，而 RPM 控制单位时间发出的请求：当响应突然变快时，相同并发数可能产生更高的 RPM。生产端应同时限制发出速率和在途数量，不能只靠一个并发参数。
重试必须有停止条件，先检查 SDK 有没有替你重试
只对已经识别为暂时性限流的请求安排重试。额度类错误先处理账户；未知错误先保留信息并停止；流量爬升过快则先减速。失败请求也可能计入速率限制，所以紧密循环会让后续恢复更难。官方限流指南建议使用指数退避，并提醒失败请求同样消耗窗口容量。
一个可执行的重试约定应同时明确以下几项：
- 谁负责重试。 在 SDK、业务函数和任务队列之间选定主要控制位置，避免每层各重试一轮。
- 最早何时重试。 有合法
Retry-After时遵守它；没有或无法解析时，采用带随机抖动的指数退避。抖动用于避免大量客户端在同一时刻再次冲击服务。 - 还能试几次。 限制总尝试次数，计数包含第一次调用，而不是只计算最外层函数执行次数。
- 还能等多久。 使用从任务开始计算的总时限，并把正在执行请求的超时预算也纳入考虑。
- 预算耗尽怎么办。 延后到队列、返回明确的稍后重试状态，或转人工处理，不无限占用工作进程。
例如，服务端要求等待 45 秒，但当前任务只剩 20 秒预算，就应该结束本轮或延期执行，不能把等待强行截成 20 秒后立刻重试。没有服务端等待提示时，可以把带抖动的 1、2、4 秒退避作为设计起点，但这只是应用策略示例，不是 OpenAI 保证的恢复时间。
OpenAI Python SDK默认会对符合条件的错误重试两次，429 映射为 RateLimitError，5xx 映射为 InternalServerError。因此，“业务层最多尝试三次”与 SDK 每次调用内部最多三次请求叠加后，最多可能发出九次请求。SDK 的异常名称也不会替应用完成余额与速率分类。
如果业务层已经根据 error.code、等待时间和任务总预算接管重试，应在创建客户端时明确设置 max_retries=0，同时检查任务队列有没有自动重新投递。若保留 SDK 重试，则把它计入总次数和总时长。这些是配置与逻辑建议，本文没有调用真实 API，也未声称完成 SDK 集成实测。
503 与 429 相邻，但不能据此判断需要充值
service_unavailable_error / server_is_overloaded 对应 HTTP 503，表示模型暂时没有足够的服务容量；rate_limit_error / slow_down 对应 HTTP 429，表示流量增长过快。官方错误码文档把两者分开列出。
遇到明确的临时过载，可在任务预算内遵守 Retry-After 或退避，但持续 503 不能证明当前账户 Tier 太低。重试预算耗尽后，应暂停或排队；若业务允许备用模型，需要事先验证质量、接口兼容和成本，并确认它是否共享同一限额。换模型不是自动获得一份独立容量。
用 GPT-6 Astra 限额做容量规划
故障恢复后，才需要判断业务正常负载是否已经超出当前容量。截至 2026 年 9 月 8 日，GPT-6 Astra 模型页列出的公开层级如下；具体密钥实际可用的模型和限额，仍以其组织、项目的 Limits 页面为准。
| 使用层级 | RPM | TPM | Batch 队列上限（待处理输入 Token） |
|---|---|---|---|
| Free | 不支持 | 不支持 | 不支持 |
| Tier 1 | 500 | 500,000 | 1,500,000 |
| Tier 2 | 5,000 | 1,000,000 | 3,000,000 |
| Tier 3 | 5,000 | 2,000,000 | 100,000,000 |
| Tier 4 | 10,000 | 4,000,000 | 200,000,000 |
| Tier 5 | 15,000 | 40,000,000 | 15,000,000,000 |
先估算哪个上限更紧，再留余量
假设某项目实际显示 500 RPM、500,000 TPM，规划时暂以每次请求 6,000 输入 Token 和 2,000 输出预算计算，粗略估算为：
text每次规划量 = 6,000 + 2,000 = 8,000 Token Token 约束下的请求量 = 500,000 ÷ 8,000 = 62.5 次/分钟 规划上界 = min(500, 62.5) = 62.5 次/分钟
这说明在这组假设下，Token 容量会先成为瓶颈，不能直接按 500 次/分钟安排任务。这只是容量估算，不是限流器的精确计费公式或实测吞吐；实际还要观察响应头、输入分布、输出预算、共享用量和重试消耗，并为波动保留余量。极少数超长请求也可能让“平均每次 8,000 Token”的估算失真。
如果不要求实时返回，可评估 Batch，但表中的 Batch 上限统计的是待处理输入 Token 总量，不是可提交文件数或请求数。它需要单独安排队列容量。Astra 输入超过 272K Token 的分界则属于长上下文重新计价，不是触发 429 的固定阈值；费用问题可查看 GPT-6 Astra API 价格说明。
切换到 Fast 也不会增加一份 RPM 或 TPM。同一模型的 Standard 与 Fast 共用速率限制，速度选项不能当作解除 429 的办法。Fast mode 限额说明
在请求已平滑、无重复重试、上下文与输出预算合理之后，如果持续业务需求仍稳定接近账户实际上限，再从 Limits 页面检查提额途径。公开 Tier 表适合做规划，不代表当前密钥已经获得表中全部容量。
恢复之前，保留一份能定位问题的记录
无论最终由自己处理还是提交支持请求，至少记录失败时间与时区、HTTP 状态、error.type、error.code、脱敏后的错误信息、模型、接口、组织和项目标识，以及实际返回的 Retry-After 和 x-ratelimit-* 响应头。Python SDK 的 APIStatusError 可提供 request_id 和 response；请求 ID 有助于关联具体失败，不要只截取一行“429”。Python SDK 参考
同时记录当时的工作进程数、发出速率、典型输入与输出预算，以及 SDK 和队列分别配置了几次重试。不要附上 API key、Authorization 请求头或不必要的用户原始内容。
恢复的判断也应对应最初原因：账户限制解除后，用同一身份的小请求确认；普通限流缓解后，看请求成功与窗口余量是否持续正常，再渐进恢复原负载。若错误码未知、正确账户的设置已调整却仍失败，或者有限重试已经耗尽，就停止盲目尝试，带着这份记录继续排查。
