调用 OpenAI API 频繁遇到 429，直接增加并发或不停重试，往往会让失败请求、等待时间和预算压力一起上升。要做好 OpenAI API rate limit 解决，关键是先识别限制来源，再把 Token 消耗、请求队列与费用上限放进同一套控制机制。通过 API 中转接入时，还要区分上游模型限制与中转侧套餐限制，不能只看账户余额。
先判断：速率限制，还是额度不足？
遇到 429，应查看响应中的错误类型、消息、请求标识，以及可用的限流响应头。429 不等于余额不足，也不一定能靠重试恢复。请求频率超限、Token 吞吐受限与额度相关错误，需要分别处理；具体字段以实际接口返回为准。
- 请求速率受限：检查每分钟请求量、突发流量及多个服务是否共用额度。
- Token 吞吐受限：检查长上下文、大批量输入和输出长度设置。
- 额度或计费异常：核对项目预算、账户计费状态；走中转时再查中转余额。
- 中转侧限制：确认模型映射、套餐并发及上游配额是否存在独立约束。
排查日志应保留时间、模型、状态码、错误类型和请求标识，避免记录密钥或完整敏感提示词。只有定位到具体限制层，调整参数才有意义。
用队列与退避稳住请求，避免重试放大
限制并发不等于限制请求速率。请求响应很快时，即便同时只有少量连接，每分钟请求数仍可能超标。建议同时设置并发信号量、请求速率限制器和 Token 预算器；多实例部署时共享计数，避免每个实例各自判断“未超限”。
对于可重试的限流错误，优先参考服务返回的等待提示，否则采用带随机抖动的指数退避，并设置最大次数、总等待时间与队列长度。不要对额度不足、鉴权失败等错误机械重试。SDK 已启用自动重试时，业务层应避免叠加多轮重试，否则一次用户操作可能触发多次上游调用。
超时也不能简单视为未执行。涉及工具调用或业务写入时，应使用业务去重机制，防止重试产生重复操作；是否计费及如何计费，则以实际用量记录和服务说明为准。
Token 消耗和预算如何一起控制？
先按任务统计输入、输出 Token 与成功率，再定位成本最高的环节。长对话可裁剪历史或生成摘要，检索任务只提交相关片段，结构化任务限制不必要的解释输出。输出上限应贴合任务需求，过高可能影响部分接口的容量估算，过低则可能导致截断和补充请求。
预算控制应覆盖单次任务、用户和项目三个层级。调用前估算本次最大支出，调用后用实际 usage 校正，并给并发中的未结算请求预留预算。模型单价、中转计费单位、汇率及附加费用应按当前账单规则配置，不要把余额直接换算成固定请求次数。
选 API 中转时，核对哪些成本与稳定性指标？
评估中转服务时，应核对支持的模型标识、SDK 兼容范围、并发与速率口径、Token 统计方式、失败请求计费规则，以及错误信息是否保留。不要只比较单价：重试率、长尾延迟和排队时间同样影响任务总成本。
中转并不意味着可以绕过上游限制。上线前用真实请求长度做渐进压测，记录成功率、延迟和单任务费用；触及阈值时优先排队、降低非关键任务优先级或提示稍后重试。这样才能把限流处理变成可衡量的成本与稳定性管理。