遇到 OpenAI API rate limit，不应立即增加并发或反复重试。限流可能与请求速率、Token 吞吐或共享项目的用量有关；余额不足也可能表现为调用失败，但处理路径不同。对于使用 API 中转的团队，解决问题的关键是区分限制来源，再协调排队、重试和预算，避免把一次失败变成持续的费用与拥塞。
先定位：是速率限制，还是额度问题？
排查时记录 HTTP 状态码、错误体中的类型与代码、请求 ID，以及可获得的限流响应头。不要只凭 429 判断需要充值或升级：应结合错误信息，区分请求过密、Token 速率受限，以及额度或计费相关问题。具体限制以实际账户、模型和接入渠道的信息为准。
- 直连调用：检查对应项目与模型的限制、计费状态，以及是否有其他应用共享用量。
- 中转调用：确认错误来自上游模型服务，还是中转网关自身的限速、余额或并发策略。
- 突发失败：按时间窗口汇总请求量、输入与输出 Token、在途请求数，寻找流量尖峰。
接入 openmagic.ai 等中转服务时，应先核对目标模型标识、错误透传方式和用量查询能力；不能假定更换入口就会消除上游限制。
控制 Token：降低单次负载，而非只减少请求数
请求频率不高仍可能触发限制，因为长上下文和大输出会消耗更多 Token 处理能力。优先清理重复系统提示、无关历史消息和冗余检索片段，再根据任务设置合理的输出上限。部分限制计算可能参考请求预估量，具体应以对应模型说明和实际响应为准。
把“每次任务预算”与“每日总预算”分开设置。前者约束上下文长度、输出规模和允许重试次数；后者用于告警或停止非关键任务。成本统计应覆盖原始请求、重试和降级调用，按实际计费用量及渠道规则核算，不能将所有失败请求一概视为免费。
稳定性方案：排队、退避与并发一起调整
为入口设置有界队列，按模型及业务优先级控制请求放行。并发数不等于每分钟请求数：响应越快，相同并发可能产生越高的请求频率。因此需要同时观察请求速率、Token 吞吐与等待时间，而不是只调一个并发参数。
对可重试的限流错误采用带随机抖动的指数退避，若响应提供有效的重试等待信息，可据此安排等待。设置最大重试次数与总超时；持续失败时暂停低优先级任务。余额不足、认证失败或参数错误，不应通过相同请求无限重试。
流式输出中途断开时，重试可能重复生成已返回内容，增加费用并影响体验。应用需记录任务状态，避免重复执行外部操作。切换模型也应先验证能力、上下文和输出格式，不宜把降级当成无成本替代。
选择 API 中转：核对成本与排障能力
评估 Token 批发或中转接入方案时，不要只比较标价，还要确认计费单位、失败请求规则、限流维度、余额告警和日志能力。中转不是绕过官方限制的保证，更重要的是让流量管理与问题定位可观测、可控制。
上线前用接近真实业务的上下文和流量进行压测，记录成功率、等待时间、每个成功任务的成本与重试比例。先降低浪费，再按监测结果申请合适的容量，才能同时改善预算可控性与调用稳定性。