AI API 返回 429：速率限制、配额与安全重试排查

先区分临时限流和人工处理项

429 是“请求过多”的 HTTP 状态语义，但具体 API 还会用错误类型和错误码区分请求速率、令牌速率、流量爬升、配额或账户问题。记录 UTC 时间、模型、组织/项目上下文、错误类型、错误码和 request ID；密钥、Authorization 与用户原文必须脱敏。

读取 Retry-After 与限流头

Retry-After 存在时把它作为最短等待时间。x-ratelimit-limit、remaining 和 reset 系列字段可帮助判断请求数、令牌数或项目令牌窗口；字段可能缺失，客户端必须允许缺失并结合错误体判断。不要把某次响应中的限制数值写死为所有模型和项目的长期上限。

重试必须有唯一总预算

临时且可安全重放的请求可使用带随机抖动的指数退避，同时限制最大尝试次数和总截止时间。OpenAI 官方 SDK 可能已重试符合条件的 429/503；应用、网关和 SDK 必须共享或核算同一预算，避免嵌套重试让请求倍增。配额、账单和配置错误应停止自动重试。

记录: status, error.type, error.code, request_id, Retry-After, x-ratelimit-*
预算: max_attempts + total_deadline + concurrency_limit
禁止: API key、Authorization、未脱敏用户内容

并发和流量爬升也要控制

平均 RPM 或 TPM 未超限仍可能因瞬时突发、共享模型组或流量爬升触发保护。使用集中队列、并发信号量或令牌桶平滑多实例流量；恢复时分阶段提升并发，每一阶段观察 429 率、成功率、等待队列和 P95 延迟。

修复后的验证

用一个脱敏最小请求验证错误分类和响应头解析，再以小流量确认重试次数没有叠加。分别覆盖请求数突发、长输入令牌、项目配置错误和 Retry-After 缺失场景。只有在预定观察窗口内错误率与队列恢复，才解除临时降速。

429 可以立即无限重试吗？

不可以。失败请求也可能计入限制；应遵循 Retry-After，设置次数和总时长上限，并避免多层重试叠加。

所有 429 等待后都会恢复吗？

不会。临时速率限制可能随窗口恢复，但配额、账单、支出限制或项目配置需要人工处理，应以错误类型、错误码和当前官方文档为准。