# OpenAI API 429 错误怎么解决：限流、余额与支出上限排查

> OpenAI API 返回 429 时，先用 error.code 区分请求限流、余额耗尽和组织或项目支出上限，再按响应头决定等待时间。本文给出恢复步骤、SDK 重试边界，以及 GPT-6 Astra 限额与容量计算方法。

- URL: https://blog.laozhang.ai/zh/posts/openai-api-rate-limit
- Published: 2026-04-24
- Updated: 2026-09-08
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Topic: API 接入指南
- Tags: OpenAI API, HTTP 429, API 限流, API 额度, GPT-6 Astra

---
**OpenAI API 的 429 不一定是请求发得太快，也可能是余额耗尽、月度用量受限或支出达到硬限制。** 先打开完整错误响应，查看 `error.code`、`error.type` 和 `error.message`：普通速率限制应降速并等待；账户额度类错误应先修复账户设置，连续重试只会增加失败请求。截至 2026 年 9 月 8 日，[OpenAI 中文排障文档](https://help.openai.com/zh-hans-cn/articles/5955604-troubleshooting-api-rate-limits-and-429-errors)已经分别列出这些情形。

本文适用于直接调用 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 排障说明](https://help.openai.com/zh-hans-cn/articles/5955604-troubleshooting-api-rate-limits-and-429-errors)，`slow_down` 的定义来自[API 错误码文档](https://developers.openai.com/api/docs/guides/error-codes)。不要给所有 429 加上“可重试”标签，也不要把所有 `insufficient_quota` 都翻译为“没钱了”。

## 充值后还是 429：检查限制作用在哪个账户

先确认充值、查看设置和失败请求使用的是同一个组织与项目。尤其在多个项目、环境变量和部署环境并存时，浏览器里看的账户可能与服务实际使用的密钥不一致。可以记录内部项目标识来核对，但不要把密钥写进日志或工单。

余额、获批月度用量、支出硬限制和预算告警是不同设置。**预算告警只负责通知；真正阻止请求的是生效的硬限制。** 组织硬限制会影响其下所有项目，项目硬限制只影响该项目。达到获批用量上限时，单纯增加预付余额也不代表上限已经提高。设置调整需要传播，不能承诺保存后下一秒就恢复；适用的月度支出限制也可能在月度重置后恢复。[OpenAI 支出限制指南](https://developers.openai.com/api/docs/guides/spend-limits)解释了告警与强制限制的区别。

建议按下面的顺序复测，而不是充值、换密钥和改重试参数同时进行：

1. **匹配错误码与设置。** 余额耗尽查余额，项目支出超限查项目，组织支出或用量超限查组织。
2. **确认调整已经生效。** 如果页面和接口仍不一致，记录修改时间与错误响应，不要持续轰炸接口。
3. **保持请求身份不变。** 用原来的组织、项目、密钥和模型发起一个输入与输出都较小的请求，以便判断同一问题是否解除。
4. **成功后逐步放量。** 单个小请求成功只证明这一请求通过，尚不能证明原来的并发与 Token 负载可以持续运行。

在同一个受限组织或项目里新建密钥，通常无法绕开对应限制。购买 ChatGPT 订阅也不等于给 Platform API 充值；若响应已经明确属于额度问题，可以继续查看 [OpenAI API 额度不足排查](https://blog.laozhang.ai/zh/posts/openai-api-quota-exceeded-error)。

如果余额耗尽前已经开启自动充值，却没有及时补上额度，可按 [OpenAI API 自动充值失败排查](https://blog.laozhang.ai/zh/posts/openai-api-auto-recharge-failed)核对开关、触发条件、月度限额与付款记录，并分别确认调用和自动充值是否恢复。

![OpenAI API 余额、月度用量及组织和项目支出硬限制的检查位置](https://blog.laozhang.ai/posts/zh/openai-api-rate-limit/img/quota-settings-explained.webp)

## 普通限流：把请求数、Token 和突发分开看

RPM 是每分钟请求数，TPM 是每分钟 Token 数。两者分别限制容量，组织、项目和模型也可能各有约束，部分模型还共享限额。因此，判断“我每分钟只发几十次，为什么也会 429”之前，要先看每次请求有多大，以及是否集中在很短的时间内发出。[官方速率限制指南](https://developers.openai.com/api/docs/guides/rate-limits)说明了这些限制的作用范围。

### 用响应头定位先耗尽的容量

[Platform Limits 页面](https://platform.openai.com/settings/organization/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 说明](https://help.openai.com/zh-hans-cn/articles/5955604-troubleshooting-api-rate-limits-and-429-errors)给出了相应的 Token 与重试建议。

减少输出上限不能以截断业务需要的答案为代价。先估算任务需要，再为较长请求留出容量；把数个大请求错开发出，通常比把所有任务同时送入接口更容易控制。

### 分钟平均值正常，也可能有短窗口突发

例如，一分钟只有 60 个请求，却全部在第一秒发出，并不等于每秒均匀发送一个请求。限流可能按更短时间窗口执行；`slow_down` 还专门反映流量增长过快。应该让任务进入有速率控制的队列，重启服务、恢复积压任务和增加工作进程时都逐步放量。

并发数与 RPM 也不是同一个单位。并发数控制同时在途的请求，而 RPM 控制单位时间发出的请求：当响应突然变快时，相同并发数可能产生更高的 RPM。生产端应同时限制发出速率和在途数量，不能只靠一个并发参数。

## 重试必须有停止条件，先检查 SDK 有没有替你重试

只对已经识别为暂时性限流的请求安排重试。额度类错误先处理账户；未知错误先保留信息并停止；流量爬升过快则先减速。失败请求也可能计入速率限制，所以紧密循环会让后续恢复更难。[官方限流指南](https://developers.openai.com/api/docs/guides/rate-limits)建议使用指数退避，并提醒失败请求同样消耗窗口容量。

一个可执行的重试约定应同时明确以下几项：

- **谁负责重试。** 在 SDK、业务函数和任务队列之间选定主要控制位置，避免每层各重试一轮。
- **最早何时重试。** 有合法 `Retry-After` 时遵守它；没有或无法解析时，采用带随机抖动的指数退避。抖动用于避免大量客户端在同一时刻再次冲击服务。
- **还能试几次。** 限制总尝试次数，计数包含第一次调用，而不是只计算最外层函数执行次数。
- **还能等多久。** 使用从任务开始计算的总时限，并把正在执行请求的超时预算也纳入考虑。
- **预算耗尽怎么办。** 延后到队列、返回明确的稍后重试状态，或转人工处理，不无限占用工作进程。

例如，服务端要求等待 45 秒，但当前任务只剩 20 秒预算，就应该结束本轮或延期执行，不能把等待强行截成 20 秒后立刻重试。没有服务端等待提示时，可以把带抖动的 1、2、4 秒退避作为设计起点，但这只是应用策略示例，不是 OpenAI 保证的恢复时间。

[OpenAI Python SDK](https://developers.openai.com/api/reference/python)默认会对符合条件的错误重试两次，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，表示流量增长过快。[官方错误码文档](https://developers.openai.com/api/docs/guides/error-codes)把两者分开列出。

遇到明确的临时过载，可在任务预算内遵守 `Retry-After` 或退避，但持续 503 不能证明当前账户 Tier 太低。重试预算耗尽后，应暂停或排队；若业务允许备用模型，需要事先验证质量、接口兼容和成本，并确认它是否共享同一限额。换模型不是自动获得一份独立容量。

## 用 GPT-6 Astra 限额做容量规划

故障恢复后，才需要判断业务正常负载是否已经超出当前容量。截至 2026 年 9 月 8 日，[GPT-6 Astra 模型页](https://developers.openai.com/api/docs/models/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”的估算失真。

![每次按 8000 Token 估算时，TPM 比 RPM 更早限制请求吞吐](https://blog.laozhang.ai/posts/zh/openai-api-rate-limit/img/rpm-tpm-capacity.webp)

如果不要求实时返回，可评估 Batch，但表中的 Batch 上限统计的是待处理输入 Token 总量，不是可提交文件数或请求数。它需要单独安排队列容量。Astra 输入超过 272K Token 的分界则属于长上下文重新计价，**不是触发 429 的固定阈值**；费用问题可查看 [GPT-6 Astra API 价格说明](https://blog.laozhang.ai/zh/posts/gpt-6-astra-api-pricing)。

切换到 Fast 也不会增加一份 RPM 或 TPM。同一模型的 Standard 与 Fast 共用速率限制，速度选项不能当作解除 429 的办法。[Fast mode 限额说明](https://developers.openai.com/api/docs/guides/fast-mode#rate-limits-and-ramp-rate)

在请求已平滑、无重复重试、上下文与输出预算合理之后，如果持续业务需求仍稳定接近账户实际上限，再从 Limits 页面检查提额途径。公开 Tier 表适合做规划，不代表当前密钥已经获得表中全部容量。

## 恢复之前，保留一份能定位问题的记录

无论最终由自己处理还是提交支持请求，至少记录失败时间与时区、HTTP 状态、`error.type`、`error.code`、脱敏后的错误信息、模型、接口、组织和项目标识，以及实际返回的 `Retry-After` 和 `x-ratelimit-*` 响应头。Python SDK 的 `APIStatusError` 可提供 `request_id` 和 `response`；请求 ID 有助于关联具体失败，不要只截取一行“429”。[Python SDK 参考](https://developers.openai.com/api/reference/python)

同时记录当时的工作进程数、发出速率、典型输入与输出预算，以及 SDK 和队列分别配置了几次重试。不要附上 API key、Authorization 请求头或不必要的用户原始内容。

恢复的判断也应对应最初原因：账户限制解除后，用同一身份的小请求确认；普通限流缓解后，看请求成功与窗口余量是否持续正常，再渐进恢复原负载。若错误码未知、正确账户的设置已调整却仍失败，或者有限重试已经耗尽，就停止盲目尝试，带着这份记录继续排查。

## 参考来源

本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-09-08。

- [OpenAI 中文排障文档](https://help.openai.com/zh-hans-cn/articles/5955604-troubleshooting-api-rate-limits-and-429-errors) (help.openai.com)
- [API 错误码文档](https://developers.openai.com/api/docs/guides/error-codes) (developers.openai.com)
- [OpenAI 支出限制指南](https://developers.openai.com/api/docs/guides/spend-limits) (developers.openai.com)
- [官方速率限制指南](https://developers.openai.com/api/docs/guides/rate-limits) (developers.openai.com)
- [Platform Limits 页面](https://platform.openai.com/settings/organization/limits) (platform.openai.com)
- [OpenAI Python SDK](https://developers.openai.com/api/reference/python) (developers.openai.com)
- [GPT-6 Astra 模型页](https://developers.openai.com/api/docs/models/gpt-6-astra) (developers.openai.com)
- [Fast mode 限额说明](https://developers.openai.com/api/docs/guides/fast-mode) (developers.openai.com)