遇到 OpenAI API rate limit，直接增加重试次数或购买更多余额，未必能恢复业务。限流可能来自请求频率、Token 吞吐、项目额度，也可能来自中转网关的独立限制。解决问题的关键，是先找到限制发生在哪一层，再控制并发、Token 消耗与重试预算。
先分清限流、额度与余额问题
收到 HTTP 429 时，不要只看状态码。应同时记录响应中的错误类型、错误消息、请求 ID，以及可用的限流响应头。速率限制与额度不足不是同一种问题：前者通常需要降低发送速度或等待窗口恢复，后者则应核查账户、项目预算及计费状态。具体以实际错误信息和控制台为准。
- 请求数受限：短时间发送过多请求，应削峰、排队并限制请求启动速率。
- Token 吞吐受限：长上下文与批量生成容易触发，应减少输入长度和单次输出上限。
- 额度或余额异常：核查上游项目及中转账户，充值不等于提高速率上限。
- 网关层限流：确认当前密钥、模型路由与套餐是否另设并发或吞吐限制。
用队列和退避降低重复消耗
应用侧应同时设置并发信号量和速率控制器：并发限制负责约束在途请求数量，速率控制负责约束单位时间内的请求与预计 Token。仅降低并发，仍可能因单次输入过长而触发 Token 限流。多个实例部署时，还需共享计数，避免每个实例单独合规、汇总后超限。
对可重试的限流错误，可采用带随机抖动的指数退避；响应提供 Retry-After 等等待提示时，应结合提示调度。必须设置最大重试次数和总等待时长，额度不足等非瞬时问题不应循环重试。还要检查 SDK、业务服务和网关是否都启用了重试，避免多层叠加形成请求风暴。
Token 预算如何兼顾成本与稳定性
为每类任务设定输入预算、输出上限和超时，而不是所有请求使用同一配置。客服问答可压缩历史对话，文档处理可先检索相关片段，长文生成则适合拆分步骤。输出上限应覆盖正常结果但不过度放大；部分限流计算可能参考请求参数，具体以当前接口说明为准。
建立请求级台账，记录模型、输入与输出 Token、重试次数、延迟和业务结果。成本应按一次成功任务计算，而不只比较单次调用报价。客户端超时也不代表上游没有执行，是否产生费用应以实际用量记录为准。对具有业务副作用的操作，应另设去重机制。
选择 API 中转与 Token 批发时核查什么
使用 openmagic.ai 等 API 中转接入方式时，应先核对模型映射、计费口径、并发限制、余额查询方式和错误透传能力。中转可以统一接入与管理，但不等于绕过上游限制。采购前应询问限制按密钥、账户还是模型计算，失败请求如何记账，以及能否按项目设置消费上限。
上线前用真实上下文长度进行阶梯压测，观察吞吐、429 比例、延迟和单任务成本，再确定运行阈值。预算接近上限时，优先暂停低优先级任务、缩短非必要输出或排队处理。只有在日志确认瓶颈来自可调整的限额后，再评估额度申请或中转资源扩容，避免把充值当作万能解决方案。