遇到 OpenAI API rate limit，盲目增加重试次数，往往会让请求队列更长，也让预算更难预测。对通过 API 中转或模型网关接入的业务，排障应同时检查上游限制、中转配额和本地调度。限流不等于余额不足，充值也不一定能解除限流。先识别瓶颈，再决定调整并发、压缩 Token，还是评估额度方案。
先判断：429 是速率限制，还是额度问题？
不要只凭 HTTP 429 判断原因，应读取响应中的错误类型、错误信息与请求标识。速率限制可能涉及每分钟请求数（RPM）、每分钟 Token 数（TPM）等维度，具体以账户、模型及实际接口返回为准。额度耗尽或预算相关问题，也需要依据错误内容单独处理。
使用中转服务时，还要确认错误来自上游模型，还是中转层自身的并发、余额或路由规则。若响应提供限额、剩余量或重置时间等头信息，可用于调度；若未提供，应结合日志和服务说明排查，不要假设中转一定原样透传。
控制 Token 消耗，比无限重试更有效
- 缩短输入：删除重复系统提示、无关历史消息和低相关检索片段；长对话可采用摘要加近期消息，保留必要事实。
- 约束输出：按任务设置合理的输出上限，使用所选模型支持的参数，避免短问答占用过大的生成预算。
- 分级路由：分类、提取等简单任务使用经验证满足要求的低成本模型，复杂推理再调用更强模型。
- 复用结果：对允许缓存、内容稳定的请求设置业务缓存；模型侧缓存优惠是否适用，应另行核对计费规则。
Token 优化要同时看质量与实际账单。记录输入、输出及接口返回的其他计费相关用量，再按当前价格估算成本。部分接口的限流计算可能参考预估用量或请求参数，不能简单把账单 Token 当作全部限流依据。
用队列、退避和预算闸门提升稳定性
在应用入口设置有界队列，按模型和路由管理并发，并分别控制请求速率与 Token 预算。并发数不是 RPM 的同义词：请求耗时变长时，同样并发也可能造成积压。批量任务应错峰执行，交互请求则应设置等待上限，避免后台任务挤占体验。
对可重试的限流错误采用带随机抖动的指数退避；如服务返回有效的 Retry-After，应纳入等待策略。设置最大重试次数和总耗时，额度不足、认证失败等问题不要反复重试。重试不能视为免费流量：失败请求可能占用速率窗口，重复成功的生成也可能产生额外费用，具体以用量和账单记录为准。
预算侧可设置日预算预警、单任务成本上限和异常熔断。达到阈值后，暂停低优先级任务或切换到经过验证的降级路径，而不是静默丢失请求。
采购 API 中转额度时，要核对哪些成本？
评估 Token 批发或 API 中转方案，不能只比较单价。还应核对模型名称与版本映射、计费单位、用量查询、余额预警、并发规则、失败请求计费说明，以及日志排障能力。多路由可能提高调度弹性，但不代表自动绕过上游限制，也不保证输出行为完全一致。
可先在 openmagic.ai 接入评估中列出业务峰值、平均输入输出长度和可接受延迟，再通过小流量压测核验。重点观察成功率、P95 延迟、每次成功任务成本和重试比例，用数据决定是否调整额度或路由，而非单凭“高并发”描述采购。