调用 OpenAI API 时遇到 rate limit，盲目增加并发或反复重试，往往会放大排队压力与预算风险。真正有效的解决方式，是先区分请求频率、Token 吞吐和额度问题，再调整流量与成本策略。通过 API 中转接入时，还要核对中转层与上游的限制，避免把所有 429 都当成同一种故障。
先定位：429 是限流还是额度不足？
HTTP 状态码只是入口，错误正文才是排查依据。保存错误类型、请求 ID、模型名、发生时间以及响应中的限流提示；不要在日志中记录完整密钥或敏感输入。不同接口、模型和账户的限制可能不同，应以实际响应和账户配置为准。
- 请求频率受限：短时间请求过密，需要降低发送速率并平滑突发流量。
- Token 吞吐受限：长上下文或较高输出上限压缩了可用吞吐，应减少单次负载。
- 额度或计费异常：检查余额、预算配置及错误说明，单纯等待或重试通常无法解决。
- 中转层限制：核对网关并发、渠道配额与上游错误映射，确认限制发生在哪一层。
控制 Token：先减少无效输入，再管理输出
成本优化应从可观测数据开始：记录每次调用的输入、输出 Token、模型、延迟和业务结果。用实际用量与适用计费规则核算成本，不要把字符数直接当作 Token 数，也不要假设失败请求全部免费。
减少重复上下文，通常比机械缩短回答更有价值。多轮对话可保留近期内容并压缩历史，检索任务只传入相关片段，固定说明避免无意义重复。为任务设置合理的输出上限，但过低可能造成截断和二次调用；上限也可能影响限流计算，具体以接口说明为准。缓存收益需结合模型支持、命中条件与实际账单验证。
稳定性方案：限速、队列与有边界的重试
在客户端或模型网关中统一管理请求速率、Token 预算和并发数。并发只代表同时在途的请求量，不等于每分钟可用额度；长请求增多时，即使并发不高，也可能触发 Token 限制。设置有容量和超时的队列，避免流量高峰变成无限积压。
对于可重试的限流错误，可采用带随机抖动的指数退避；若响应提供有效的等待提示，应优先参考。同时设置最大次数、总等待时长和请求截止时间。重试必须消耗独立预算，不能无限循环。额度不足、认证失败或参数错误，应先修复原因；涉及外部写入的业务还需防止重复执行。
选择 API 中转时，如何评估成本与限制？
评估 Token 批发或 API 中转服务，不应只比较单价。应核对目标模型计费、余额扣减记录、并发约束、错误透传、用量统计及预算告警能力。接入 openmagic.ai 前，也应根据实际服务说明确认这些条件，而不是默认中转即可突破上游限制。
上线前用接近真实业务的输入长度和流量进行压测，观察成功率、尾延迟、重试比例与单任务成本。为日预算设置告警和应用侧停用阈值，高峰时对非关键任务排队或降级。解决 rate limit 的目标不是请求越多越好，而是在可核算的预算内获得可预测的吞吐。