遇到 OpenAI API rate limit，不应立即增加重试或购买更多额度。限流可能来自请求频率、Token 吞吐、共享配额，也可能与余额或消费上限有关。对通过 API 中转接入的业务，还要区分上游限制与网关限制。解决目标不是让请求无限发送，而是在预算内保持可预测的成功率与延迟。
先判断：频率限制还是额度问题？
收到 429 时，先记录响应中的错误类型、错误码、请求 ID，以及可用的限流响应头。HTTP 状态码相同，不代表处理方法相同：请求过密适合排队与退避；额度不足则需核对计费状态、消费上限和中转账户余额，持续重试通常不能解决。
- RPM：每分钟请求数。短时间突发流量可能触发限制，即使平均流量不高。
- TPM：每分钟 Token 吞吐。长上下文、批量输入和较高输出上限都可能增加压力，具体统计以接口规则为准。
- 并发限制：同时处理中的请求过多，可能触发网关排队、拒绝或超时。
- 额度限制：检查账户余额、项目预算和渠道配额，不要将充值等同于提升速率。
用队列和退避减少无效 Token 消耗
在应用端设置有界队列与并发上限，比让所有客户端同时重试更可靠。按模型、项目或渠道分别管理请求，避免一个批量任务挤占在线对话资源。对暂时性限流，采用带随机抖动的指数退避；如响应提供 Retry-After，可按其提示安排下一次尝试。
重试必须有次数上限和总耗时预算。鉴权失败、参数错误和明确的额度不足，应进入对应处理流程，而不是套用统一重试。请求超时后，还需考虑上游可能已处理的情况，尤其是流式响应已开始时；不要盲目重放，否则可能出现重复输出与额外费用。
Token 预算如何与限流治理联动？
先按业务统计输入、输出 Token 和成功请求成本，再确定每个用户、任务与项目的消费阈值。请求前做估算，响应后用接口返回的 usage 校准；中转账单与本地记录如存在差异，应核对模型映射、计费单位及重试记录。
- 缩短重复系统提示与历史对话，保留必要上下文；摘要压缩后需检查关键信息是否丢失。
- 根据任务设置输出长度上限，避免简单分类任务生成冗长解释。
- 为可复用结果设置合适缓存，并隔离用户权限与敏感数据。
- 将非实时任务移到低峰执行；若采用批处理，先确认接口支持情况与对应计费规则。
预算告警不等于硬性止损。如需严格控费，应在业务网关执行余额预检、用量预留和结算回补，并为并发请求预留安全余量，防止多个请求同时通过检查后超支。
购买 API 中转服务前，核对哪些条件？
评估 openmagic.ai 或其他接入方案时，应核对目标模型的 RPM、TPM、并发规则、共享或独立配额、失败请求计费方式，以及余额查询和用量导出能力。不要只比较每 Token 单价，还要计算排队延迟、失败重试和上下文浪费带来的总成本。
上线前用逐步加压测试验证峰值承载，观察 429 比例、队列长度、成功率与每次成功调用成本。API 中转不能自动消除上游限流；清晰的配额规则、可观测日志与可控重试，才是成本和稳定性兼顾的基础。