# OpenAI 兼容 API 的 429 错误：限流、额度与重试

> 按错误来源与响应体区分 429，结合请求和 token 配额计算吞吐，并限制 SDK、队列和工作流的重试叠加。

_发布 2026-09-29 · 更新 2026-09-29 · [KeepRouter Editorial](https://keeprouter.com/editorial-policy#editorial-team) · 4 分钟阅读_

![展示安全重试、回退、取消与副作用边界的 LLM 请求状态机](https://keeprouter.com/editorial/blog/llm-failover-design-guide.png)

_工作流调用工具或恢复异常时，分别记录尝试与结果。概念示意图。_

429 表示触及某项限制，但状态码本身不能说明耗尽的是请求频率、token 配额还是账户额度。先读错误体，并确认哪个服务返回了错误。临时限流可以延迟重试，额度或资金不足通常需要修正账户状态。

定时任务集体失败时，增加 worker 可能让所有进程一起重试，反而降低有效吞吐。

## 找出拒绝请求的层

[OpenAI 错误说明](https://developers.openai.com/api/docs/guides/error-codes)区分限流与 quota 问题；其他兼容服务可能采用不同错误码。应按真正的目标服务判断。

| 现象 | 首先检查 | 应对 |
| --- | --- | --- |
| 请求太多 | 频率与并发 | 排队、控制启动速度 |
| token 限制 | 输入长度与输出预留 | 按 token 调度 |
| 额度不足 | 服务、账户与余额 | 修正账户条件 |
| 只有一个 Key 失败 | 权限和项目限制 | 对比配置 |
| 只有某型号失败 | 型号配额与线路 | 查看具体限制 |
| 开启重试后恶化 | SDK、队列和工作流 | 消除重试叠加 |

记录时间、型号、状态码、脱敏错误与请求 ID，不保存认证头或客户提示词。网关返回错误时，不应假设用户能够直接修改上游账户。

## 计算真正约束吞吐的资源

假设账户允许每分钟 120 次请求、30,000 token。单任务约 2,000 输入加 500 输出 token，token 预算只允许约十二项任务，真正的瓶颈不是 120 次请求。

```python
requests_per_minute = 120
tokens_per_minute = 30_000
estimated_tokens_per_job = 2_500
headroom = 0.75
capacity = min(requests_per_minute, tokens_per_minute / estimated_tokens_per_job)
print(int(capacity * headroom))  # 9
```

这是规划算例，不是 KeepRouter 配额。服务可能分别计算输入、输出预留和并发，应结合实际响应规则调整。长文档同时到达时，平均值也会失真，可以与短交互任务分队列。

## 使用有边界的退避

[官方限流指南](https://developers.openai.com/api/docs/guides/rate-limits)建议带随机扰动的指数退避，也说明失败请求可能继续消耗限额。立即循环重试会延长故障。

存在有效重试时间时，在任务总截止时间内遵守它；否则使用有上限的退避。额度不足时，等待几秒不会补充额度。

明确哪一层负责重试。SDK 重试两次意味着最多三次 HTTP 尝试；队列把整个操作再执行三遍，就可能变成九次。工作流重试还会继续放大。

## 并发和吞吐分开控制

并发是同时进行的请求数，吞吐是单位时间完成数。慢响应会占住连接，但不等于创造更多有效结果。信号量限制在途请求，速率或 token 预算限制启动速度。

交互应用还要限制排队时间；离线任务可以等待更久，但仍需防重复执行。不要靠轮换账户规避服务限制，真实容量需求应申请合理额度或设计明确的替代路径。

## 恢复时不要重复完成的工作

给任务分配应用自己的 ID，保存状态。超时后先检查是否已经产生结果，再决定重试，尤其要防止下游副作用重复。

最终成功率可能掩盖重复费用和长等待，应保存尝试次数及最后错误。KeepRouter 排障从[错误参考](/docs/errors)和[服务状态](/status)开始，用[费用计算器](/tools/api-cost-calculator)把重试计入预算，再判断是否需要更换型号或线路。

## 常见问题

### 指数退避能修复额度耗尽吗？

不能。退避处理临时竞争，额度或余额问题需要修正目标服务的账户条件。

### 为什么还没到请求次数上限就被限流？

token、并发或型号限制可能更早触发。需要结合输入大小、输出预留和实际计量规则判断。

### 每一层都应该独立重试吗？

不应该。明确重试责任及总截止时间、次数预算。多层独立重试可能成倍增加请求。

## 参考的一手资料

_本文最近复核 2026-09-29_

1. [OpenAI API error codes](https://developers.openai.com/api/docs/guides/error-codes)
2. [OpenAI rate-limit guidance](https://developers.openai.com/api/docs/guides/rate-limits)

## 继续阅读

- [errors](https://keeprouter.com/docs/errors.md)
- [LLM 故障切换设计指南：恢复请求，同时避免不安全重试](https://keeprouter.com/zh/blog/llm-failover-design-guide.md)
- [LLM 流式输出中断：区分 SSE、超时和完成状态](https://keeprouter.com/zh/blog/llm-streaming-interrupted.md)

## 检查应用需要的具体行为

把文中例子用于应用时，按产品记录的请求格式与控制范围实现。

[查看产品说明](https://keeprouter.com/docs/errors)

[创建 Key，测试免费模型](https://keeprouter.com/login?returnTo=%2Fconsole%2Fkeys%3Fmodel%3Dfree)

免费测试使用 free 模型；其他付费型号需要足够预付额度。

[全部文章](https://keeprouter.com/zh/blog.md) · [模型与价格](https://keeprouter.com/models.md)