AI API 429 限流怎么处理？从并发控制到 Retry-After 的实战配置

调用 AI API 时出现 HTTP 429，通常表示请求频率、并发数或账户额度触发了限制。它不一定代表服务商故障，也不等于继续疯狂重试就能解决。正确做法是先判断限制类型，再根据响应头安排重试，并在客户端加入并发控制。

先看响应，不要立即重试

先记录状态码、错误码、Retry-After、请求 ID 和模型名称，但不要记录完整 API Key 或用户原文。不同服务商的错误字段名称可能不同，下面是常见响应：

{
  "error": {
    "type": "rate_limit_error",
    "message": "Too many requests"
  }
}

如果余额不足、模型额度用尽或账户被暂停，重试不会产生效果；如果只是短时并发超限，等待后再试才有意义。先到服务商控制台确认余额、单分钟请求数（RPM）、Token 数（TPM）和并发上限。

Retry-After 优先，指数退避兜底

响应带有 Retry-After 时，应优先按照它等待。该值可能是秒数，也可能是 HTTP 日期。没有这个响应头时，可使用 1、2、4、8 秒的指数退避，并加入 20% 左右的随机抖动，避免大量客户端在同一秒再次发起请求。

async function waitForRetry(attempt, retryAfter) {
  const headerSeconds = Number(retryAfter)
  const base = Number.isFinite(headerSeconds) && headerSeconds > 0
    ? headerSeconds * 1000
    : Math.min(8000, 1000 * 2 ** attempt)
  const jitter = Math.random() * base * 0.2
  await new Promise(resolve => setTimeout(resolve, base + jitter))
}

单个请求最多重试 2～3 次，并设置总耗时上限。流式输出已经返回部分内容后，不要无条件重放整条请求，否则可能产生重复回复和重复扣费；应把已收到的内容保存下来，再提示用户继续或重新提交。

用队列限制并发

在业务入口设置全局并发数，例如先从 5～10 个并发开始，根据服务商的实际上限逐步调整。超过上限的请求进入队列，队列等待时间过长则返回明确提示。每个用户或项目还可以设置独立配额，避免一个任务占满全部通道。

如果同时使用多个模型或中转站，应该分别维护限流桶，因为每个模型、渠道和账户的 RPM/TPM 可能不同。切换备用服务商前，确认模型 ID、计费单位和权限一致，避免把限流错误误判成备用渠道可用。

一份实用排查清单

查看余额、RPM、TPM 和并发限制是否已用尽；
检查请求是否在循环中重复发送，尤其是前端重复点击；
确认重试只针对临时 429，余额或权限错误直接停止；
读取并遵守 Retry-After，没有时使用退避和抖动；
记录请求 ID、等待时间和最终状态，方便与服务商核对；
流式响应中断时避免整单重放，先判断是否已经产生扣费。

结语

429 的核心处理原则是“降低请求压力、等待正确时间、限制重试次数”。完成基础改造后，再根据一周的 RPM、TPM、成功率和平均等待时间调整并发参数。不同 API 中转站的限制和计费规则可能不同，最终以服务商当前公告和控制台数据为准。

延伸阅读：AI API 流式输出中断怎么办？ · AI API 正式上线前检查清单