调用 OpenAI API 时遇到 rate limit，不一定是余额不足，也不一定靠增加重试就能解决。对批量生成、客服机器人和多租户应用而言，真正的问题是：请求速率、Token 吞吐与业务预算没有统一管理。处理限流应先识别瓶颈，再调整并发和请求体，最后评估是否需要 API 中转或额度升级。
先区分限流、额度不足与网关拥堵
收到 429 后，应检查响应中的错误类型、消息及可用的限流响应头，而不是仅凭状态码判断。请求频率过高、Token 速率超限与账户额度问题，需要不同处理方式；如果经过中转，还要确认错误来自上游模型还是中转网关。
- 请求速率受限：降低瞬时并发，用队列平滑流量。
- Token 吞吐受限：缩短上下文，限制输出长度，拆分大任务。
- 额度或计费异常：核对账户余额、项目预算与计费状态，重试通常无效。
- 中转通道拥堵：检查网关日志、超时配置与通道级配额。
余额、并发与速率限制是三个不同指标。余额充足并不代表允许无限并发；购买 Token 额度，也不等于获得对应的上游吞吐能力。
控制 Token 消耗，避免重试放大成本
先记录每次调用的输入 Token、输出 Token、模型、耗时和重试次数，再按业务场景汇总。预算估算应分别计算输入与输出费用，并使用实际接入渠道的有效计费规则；不要只用请求数量推算成本。
长对话可采用摘要和历史裁剪，检索问答应控制召回片段数量，固定格式任务则设置合理的输出上限。缓存可减少重复调用，但要考虑内容时效与租户隔离；应用层缓存与模型侧缓存不是同一机制，不能直接假设享有相同计费待遇。
对可重试的限流使用指数退避与随机抖动，存在 Retry-After 等提示时按其语义处理，同时设置最大重试次数和总等待时间。检查 SDK 是否已自动重试，避免业务层再次叠加。网络超时后的重复提交还可能产生额外消耗，有外部副作用的操作尤其需要业务幂等设计。
用队列与预算阈值保护稳定性
建议按模型、项目或租户设置并发池，并结合请求数与预计 Token 数进行调度。输出上限和请求规模也可能影响速率预算估算，具体以接口说明为准。突发任务进入队列，交互请求保留独立资源，避免批处理挤占在线服务。
预算控制可分为告警、降级与停用三级：接近内部阈值时通知负责人，超出业务预算时暂停低优先级任务，必要时切换经过质量验证的低成本模型。应用自己的预算拦截应独立实现，不要把平台告警默认当作实时硬限额。
选择 API 中转前，核对哪些成本条件？
通过 openmagic.ai 等中转入口评估接入方案时，应核对模型标识、SDK 兼容性、计费单位、失败请求处理、余额查询与日志能力，并确认并发限制作用于账户、密钥还是模型。涉及用户数据时，还需检查转发链路、日志留存和访问权限。
中转可用于集中管理接入与用量，但不能据此推断能够绕过上游限制。采购前用真实上下文长度和目标并发压测，比较成功率、尾延迟及每个成功任务的成本，而非只看 Token 单价。解决 rate limit 的目标，是让请求在可控预算内稳定完成。