遇到 OpenAI API rate limit，直接增加重试次数或购买更多余额，未必能恢复服务。限流可能来自请求频率、Token 吞吐、模型配额，也可能出现在 API 中转层。排障应同时检查错误信息、实际用量与预算，避免把一次限流变成持续重试和成本失控。
先区分限流与额度不足
收到 HTTP 429 后，应读取响应中的错误类型、提示和请求标识，而不是仅凭状态码判断。请求速率受限与账户额度不足的处理方式不同；若经过中转网关，还需确认错误来自网关还是上游。余额充足不等于拥有更高的速率上限，补充余额也不能自动解决所有限流。
- 请求频率受限：统计短时间内的请求量，检查是否存在集中触发的定时任务。
- Token 吞吐受限：检查长上下文、大批量任务及过高的输出上限。
- 额度或预算不足：核对项目预算、账户状态与中转账户余额。
- 网关侧受限：核对套餐并发、路由规则及上游返回的原始错误。
若响应提供限流相关头部或重试等待信息，可据此安排后续请求；具体字段与可见性取决于接口及中转实现，不宜假定所有渠道都能完整透传。
用队列与退避解决突发并发
多线程同时请求、失败后立即重发，容易形成重试风暴。建议在应用侧设置统一队列、并发信号量与发送速率限制，让交互请求优先，离线批处理错峰执行。并发数控制的是在途请求，不能代替每分钟请求或 Token 速率控制。
重试应采用带随机抖动的指数退避，并设置次数和总时长上限。存在有效的等待提示时优先遵循；对额度不足、鉴权失败等问题，不应反复自动重试。还要检查 SDK、业务服务和网关是否分别开启重试，避免叠加放大调用量。连接中断后是否已完成生成可能不明确，重复请求可能增加费用，应通过业务任务标识防止重复执行。
把 Token 消耗纳入预算控制
压缩重复历史、按需检索上下文，并为输出设置合理上限，通常比盲目扩容更可控。减少输出上限可能降低容量压力，但最终计费与限流计量并不一定采用同一口径，应分别核对。简单分类、字段提取等任务可测试成本更低的适配模型，不能仅凭模型名称判断质量。
预算可按“预计调用量×平均单次输入输出成本”估算，再为重试和流量峰值预留空间。上线后以响应中的实际用量及账单校验，记录模型、输入输出 Token、耗时、失败率和重试次数。同时设置日预算告警、单任务成本上限与异常熔断，比只观察账户余额更容易及时止损。
购买 API 中转或 Token 额度前核对什么
评估 openmagic.ai 等 API 中转方案时，应核对模型映射、计费口径、并发限制、余额查询方式，以及错误码与用量字段的透传情况。Token 批发或预充值并不天然意味着独享上游配额，也不代表可以绕过上游限制。
先用小规模真实任务压测，再逐步提高发送速率，观察延迟、429 比例和单位成功任务成本。确认日志能够关联业务任务、网关请求与上游响应后，再决定是否增加预算或调整接入方案。目标是以可预测成本获得稳定吞吐，而不是让请求无上限地重试。