API 报 429 / rate limit?AI 接口限流、并发与重试实战(2026)
调 Claude / GPT / DeepSeek API 频繁报 429 Too Many Requests?讲清限流怎么回事(RPM / TPM / 并发)、为什么会撞,以及指数退避、并发控制、排队削峰的实战解法,让你的 agent / 批量任务跑稳。
429 到底在说什么:三种「限流」
API 报 429 Too Many Requests,意思是你在单位时间里请求太多、超了配额。限流通常有三个维度:① RPM(每分钟请求数)—— 一分钟能发多少次;② TPM(每分钟 token 数)—— 一分钟能处理多少 token,长文本尤其容易撞;③ 并发数 —— 同一时刻允许多少个请求在跑。三者任一超了都会 429。先搞清是哪个维度撞了,才好对症。
为什么你会撞限流
常见几种:① 突发流量 —— 用户高峰或活动瞬间涌入;② 批量任务 —— 一次性 for 循环发几百上千条,瞬间打爆 RPM;③ agent / 多轮 —— 一个 agent 任务内部可能连续调几十次;④ 多 worker 并行 —— 你以为并发 10,实际每个 worker 都在发,乘起来远超限额;⑤ 长文本 —— 单条 token 很大,几条就顶满 TPM。生产环境这些叠加,429 就来了。
解法①:指数退避重试(必做)
撞 429 别硬刚、别死循环重发(会更堵)。标准做法是指数退避:第一次等 1s 重试,再撞等 2s、4s、8s……并加一点随机抖动(jitter)避免多个客户端同时重试又撞车。很多官方 SDK 内置了重试,但要确认开启并调好次数上限。核心原则:遇 429 就退一步、等一会儿再来,而不是加倍猛敲。
解法②:客户端主动限速(控并发)
与其被动挨 429,不如主动把请求速率压在配额内。常用两招:① 令牌桶 / 漏桶限速器 —— 控制每秒发出的请求数;② 信号量(semaphore)控并发 —— 比如最多同时 5 个请求在跑,跑完一个再放一个进来。批量任务尤其要用信号量,把「一次性发 1000 条」改成「受控地每次 5 条」,既不撞限流又跑得稳。
解法③:排队削峰 + 分散
流量不均时,加一个队列把请求排起来、按配额匀速消费,削掉突发尖峰。任务不急的话(离线批处理),分散到更长时间窗口跑,天然避开限流。另外把重任务(长文本 / 推理模型)和轻任务分开队列,别让一条大请求堵住一片。
中转层面也有限流:选对中转很关键
除了模型厂商的限流,你用的中转 / 平台自己也可能有并发和额度限制 —— 有些低价中转为了省成本压得很死,你并发一高就被它卡。cocodot 面向生产使用,OpenAI 兼容、支持流式,按量计费不搞隐形并发墙;真要跑高并发批量,建议先小额压测你的真实负载、确认成功率和延迟稳定,再规模化(这也是所有中转都该做的验证)。
排查清单
遇到 429 按这个顺序查:① 看错误响应头(常有 retry-after / 剩余额度提示)确认撞的是 RPM 还是 TPM;② 加指数退避重试;③ 用信号量把并发压到配额内;④ 批量任务改排队匀速;⑤ 长文本拆分或降低单条 token;⑥ 若是中转的并发墙,换面向生产的中转或升配。先小样本验证跑通,再上量。