调用 OpenAI API 时频繁遇到 rate limit，增加余额未必能解决。限流可能来自请求频率、Token 吞吐、项目配额，或中转网关自身的并发限制。对通过 openmagic.ai 等中转服务接入的业务，应先定位限制发生在哪一层，再调整队列、输出长度与预算，避免把限流问题变成重试账单。
先区分限流、额度不足和网关拥堵
HTTP 429 不能单独说明原因。应结合响应中的错误类型、错误消息、请求标识及限流相关响应头判断；中转服务可能转换上游错误，因此还需核对网关日志。余额不足或配额耗尽，应检查对应账户与项目；频率超限则需要降低发送速度。两者不能用同一套无限重试处理。
- RPM：单位时间请求数，短请求集中到达也可能触发。
- TPM：单位时间 Token 吞吐，长上下文与大输出更容易占满。
- 并发：同时处理的请求数，限制可能来自应用或中转网关。
- 余额与预算：区分上游项目预算、中转账户余额和应用自设上限。
余额、速率和并发是不同维度。购买更多 Token 或充值前，先确认限制归属；提高账户余额通常不等于提高可用吞吐。
用队列和退避降低重试成本
把请求放入有界队列，按模型与业务优先级设置并发上限，再用令牌桶等方式平滑发出。交互请求和后台批处理应分队列，避免批量任务挤占实时业务。队列超过等待阈值时，返回明确提示或转为异步处理，不要持续堆积。
对于可重试的限流错误，采用带随机抖动的指数退避；若响应提供 Retry-After，则按其指示等待。设置最大重试次数与总超时，并检查 SDK、网关和业务代码是否重复重试。重试必须有上限，不能假设失败请求完全不消耗资源。发生超时或流式中断时，也不要默认上游尚未执行；涉及工具调用的流程还应避免重复操作。
控制 Token，而不是只压低请求数量
先统计每类任务的输入、输出及总 Token 分布，找出长尾请求。裁剪无关历史消息、限制检索片段、压缩重复指令，并为任务设置合理的输出上限。输出预留过大可能影响部分接口的速率预算估算，具体以接口说明为准；不要把输出长度参数当成费用封顶器。
简单分类、字段提取可在质量验证后选择更经济的模型，复杂推理再使用能力更强的模型。缓存适合复用的结果时，要处理权限、时效与敏感信息；提示缓存是否生效、如何计费，需核对实际模型和接入服务规则。
中转接入如何设置预算和验收稳定性
接入前核对 Base URL、模型名称、SDK 兼容范围、错误透传和用量查询方式。尤其要确认中转侧的 Token 统计、计费单位、失败请求处理及余额告警规则，不能直接套用其他渠道的价格或限制。
预算可按“请求量 × 单次平均输入输出用量 × 对应单价”估算，并单列重试与异常长请求余量。应用侧应设置日预算、单任务用量上限和分级告警；硬停止会影响业务，应预先确定降级策略。用小流量逐步压测，记录成功率、429 比例、排队时间、延迟和单位成功任务成本。解决 rate limit 的目标不是不断换线路，而是在可核验的额度与预算内获得稳定吞吐。