处理 OpenAI API rate limit，不能只增加重试次数。请求过密、Token 吞吐超限、账户额度不足以及中转层限流，都可能表现为调用失败。对使用 API 中转的团队，目标应是：先定位限制来源，再让并发、Token 消耗和预算匹配，避免重试进一步放大拥堵与成本。
先识别 429：速率限制还是额度问题
遇到 HTTP 429，应检查响应正文中的错误类型、错误码和请求 ID，并结合控制台用量与账单判断。速率限制通常需要降低请求频率或 Token 吞吐；额度或计费状态异常则需要核对余额、项目预算及账户设置，不能靠连续重试解决。具体错误含义以实际响应和服务文档为准。
使用中转服务时，还应确认错误来自上游模型、网关还是本地应用。中转余额不等于上游可用额度，购买 Token 也不等于获得更高并发。排查时记录模型、时间、状态码及脱敏后的错误信息，不要在日志中保存 API Key。
按请求数与 Token 吞吐设置并发
限流可能同时涉及每分钟请求数与 Token 数。大量短请求可能触及请求数限制，长上下文任务则可能先耗尽 Token 吞吐。只减少线程数量未必有效，还需要控制输入长度和输出上限。
- 为每个模型建立独立队列，限制并发和单位时间请求量。
- 按输入 Token 与预计输出预留吞吐空间，完成后用实际 usage 校正。
- 对临时速率限制采用带随机抖动的指数退避；若响应提供重试提示，应优先参考。
- 设置最大重试次数与总等待时长，失败后进入延迟队列或返回可解释提示。
重试应有预算，而不是无限循环。连接超时或流式中断并不代表上游未处理请求，立即重发可能产生重复结果或额外消耗。应用应使用业务任务 ID 去重，并核对请求状态与账单记录。
让 Token 预算参与调用决策
可按“输入 Token×输入单价＋输出 Token×输出单价”估算基础费用；缓存、工具调用等项目需按实际计费规则另行核对。中转采购还应明确计价单位、模型映射、倍率及账单明细，不能只比较展示单价。
预算控制可分为单次、用户和项目三层：限制单次上下文与输出长度，为用户设置用量配额，为项目设置日预算预警和停止阈值。预警不等于硬性止损，若服务端没有硬限额，应用仍需自行拦截新任务，并为正在执行的请求预留成本空间。
降低消耗时，优先删除重复提示词、裁剪无关历史、用检索片段替代整篇文档。简单任务可在评测通过后使用成本更合适的模型；不依赖即时响应的任务可错峰执行。缓存是否降低费用，取决于模型及服务的实际支持，不能默认生效。
选择 API 中转前核对哪些能力
评估 openmagic.ai 等中转接入方案时，应核对目标模型、SDK 兼容方式、限流口径、余额查询和用量明细。重点询问：并发与 Token 吞吐是否分别限制，错误信息是否保留，是否存在自动重试及额外消耗，以及故障切换会否改变模型或计费口径。
上线前用接近真实输入长度的小流量压测，观察成功率、延迟、429 比例和单任务费用。解决 rate limit 的关键是可观测与可控：找到瓶颈后再调整采购、队列和预算，而不是把更换入口当作绕过上游限制的保证。