OpenAI 兼容 API 的 429 错误：限流、额度与重试
按错误来源与响应体区分 429，结合请求和 token 配额计算吞吐，并限制 SDK、队列和工作流的重试叠加。
发布 2026-09-29 · 更新 2026-09-29 · KeepRouter Editorial · 4 分钟阅读
429 表示触及某项限制，但状态码本身不能说明耗尽的是请求频率、token 配额还是账户额度。先读错误体，并确认哪个服务返回了错误。临时限流可以延迟重试，额度或资金不足通常需要修正账户状态。
定时任务集体失败时，增加 worker 可能让所有进程一起重试，反而降低有效吞吐。
找出拒绝请求的层
OpenAI 错误说明区分限流与 quota 问题；其他兼容服务可能采用不同错误码。应按真正的目标服务判断。
| 现象 | 首先检查 | 应对 |
|---|---|---|
| 请求太多 | 频率与并发 | 排队、控制启动速度 |
| token 限制 | 输入长度与输出预留 | 按 token 调度 |
| 额度不足 | 服务、账户与余额 | 修正账户条件 |
| 只有一个 Key 失败 | 权限和项目限制 | 对比配置 |
| 只有某型号失败 | 型号配额与线路 | 查看具体限制 |
| 开启重试后恶化 | SDK、队列和工作流 | 消除重试叠加 |
记录时间、型号、状态码、脱敏错误与请求 ID，不保存认证头或客户提示词。网关返回错误时，不应假设用户能够直接修改上游账户。
计算真正约束吞吐的资源
假设账户允许每分钟 120 次请求、30,000 token。单任务约 2,000 输入加 500 输出 token，token 预算只允许约十二项任务，真正的瓶颈不是 120 次请求。
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 配额。服务可能分别计算输入、输出预留和并发，应结合实际响应规则调整。长文档同时到达时，平均值也会失真，可以与短交互任务分队列。
使用有边界的退避
官方限流指南建议带随机扰动的指数退避，也说明失败请求可能继续消耗限额。立即循环重试会延长故障。
存在有效重试时间时，在任务总截止时间内遵守它；否则使用有上限的退避。额度不足时，等待几秒不会补充额度。
明确哪一层负责重试。SDK 重试两次意味着最多三次 HTTP 尝试；队列把整个操作再执行三遍，就可能变成九次。工作流重试还会继续放大。
并发和吞吐分开控制
并发是同时进行的请求数，吞吐是单位时间完成数。慢响应会占住连接，但不等于创造更多有效结果。信号量限制在途请求，速率或 token 预算限制启动速度。
交互应用还要限制排队时间；离线任务可以等待更久，但仍需防重复执行。不要靠轮换账户规避服务限制，真实容量需求应申请合理额度或设计明确的替代路径。
恢复时不要重复完成的工作
给任务分配应用自己的 ID，保存状态。超时后先检查是否已经产生结果，再决定重试，尤其要防止下游副作用重复。
最终成功率可能掩盖重复费用和长等待，应保存尝试次数及最后错误。KeepRouter 排障从错误参考和服务状态开始，用费用计算器把重试计入预算，再判断是否需要更换型号或线路。
常见问题
指数退避能修复额度耗尽吗？
不能。退避处理临时竞争，额度或余额问题需要修正目标服务的账户条件。
为什么还没到请求次数上限就被限流？
token、并发或型号限制可能更早触发。需要结合输入大小、输出预留和实际计量规则判断。
每一层都应该独立重试吗？
不应该。明确重试责任及总截止时间、次数预算。多层独立重试可能成倍增加请求。
参考的一手资料
本文最近复核 2026-09-29