直接答案
429 不等于简单“多试几次”；先读取错误类型和限流头，判断是短时速率限制、并发限制还是账户配额问题。
这篇内容解决什么问题
解决 rate_limit_exceeded、insufficient_quota、请求过快和并发过高导致的 HTTP 429。
OpenAI 兼容 API批处理与流式请求Python 与 Node.js SDKCI 并发任务
01
先确认症状与影响范围
请求返回 429 Too Many Requests、rate_limit_exceeded 或配额相关错误。短时限流可能在等待后恢复；余额、账户或项目配额不足通常不会因立即重试而恢复。
单次手动请求成功而批量任务失败，通常说明请求速率、Token 速率或并发数超过当前限制。
- 保存错误体中的 code/type，以及响应中的限流或 Retry-After 信息。
- 统计每分钟请求数、Token 量和同时进行的流式连接数。
- 核对余额、项目配额和目标模型是否使用独立限制。
02
常见原因与责任边界
429 至少包含速率、Token、并发和账户配额四类原因。重试策略只适合可恢复的短时限制，不适合余额不足或明确的权限限制。
- 请求或 Token 在短窗口内超过模型或账号限制。
- 大量 worker 同时重试形成重试风暴。
- 余额、项目预算或上游配额不足。
- 长时间流式请求占满并发槽位。
03
按层执行最小诊断
先暂停自动重试并记录一分钟内的请求、Token 和并发。读取服务返回的错误 code；若提示 quota 或 billing，直接检查账户状态，不要继续压测。
如果只有并发任务触发，逐步降低 worker 数并加入全局限速器，验证触发阈值。
- 01读取错误类型区分 rate limit、quota、billing 和并发限制。
- 02记录负载统计 RPM、TPM、并发和平均上下文长度。
- 03单请求对照停止 worker 后发送一个最小请求，判断账户是否仍被拒绝。
- 04逐步恢复从低并发开始增加，观察响应头和失败率。
保留 429 响应头与时间语言：bash
date -u
curl -sS -D /tmp/rate-headers.txt -o /tmp/rate-body.json 'https://<your-api-host>/v1/models' -H "Authorization: Bearer ${API_KEY:?set API_KEY first}"
sed -n '1,30p' /tmp/rate-headers.txt
04
针对根因完成修复
可恢复限流使用有上限的指数退避并加入随机抖动，同时限制全局并发。配额或余额问题应调整预算、充值或选择可用模型，不能靠重试解决。
- 01限制并发为所有 worker 使用共享队列或信号量，而不是各自无限发送。
- 02指数退避尊重 Retry-After；否则使用递增等待、随机抖动和最大尝试次数。
- 03削减 Token缩短无关上下文、限制最大输出并避免重复请求。
- 04处理配额余额或预算不足时停止任务并通知人类处理。
带上限与抖动的重试伪代码语言：text
for attempt in 0..4:
response = request()
if response.status != 429: return response
if response.error is quota_or_billing: stop_and_alert()
wait = retry_after ?? min(30s, 2^attempt + random_jitter)
sleep(wait)
raise rate_limit_exhausted05
验证修复而不是只看一次成功
在可控负载下运行一段持续测试，确认没有同步重试尖峰，429 比例降低且失败请求能在达到上限后明确退出。
- 客户端尊重 Retry-After 或使用带抖动的指数退避。
- 并发、RPM 与 TPM 有可观测指标和硬上限。
- 余额或配额不足会停止任务，而不是无限消耗重试。
06
安全边界与升级证据
不要为绕过限流轮换账号、Key 或来源 IP。监控中记录状态码与计数即可，不要记录请求正文、Authorization 或用户隐私内容。
- 重试仅用于幂等或可安全重放的请求。
- 设置最大尝试次数、总时限和熔断。
- 批处理任务可暂停、恢复并避免重复计费。
官方来源与核验范围
本文以协议规范和客户端官方文档为事实依据。错误文案、重试头和配置字段可能随服务或客户端版本变化；执行前请核对来源，并对日志与请求样例脱敏。
查看技术核验方法