大模型 API 被限速，其实一点都不罕见。只要你的业务开始面对真实用户，不管是聊天机器人、RAG 问答、Agent 自动化、批量生成，还是智能客服，都有可能撞上限流。很多开发者一看到 429 Too Many Requests，第一反应就是“那我多重试几次”“再加几个 Key 不就好了”。但说实话，这通常不是最稳的办法，有时候还会把问题越搞越严重。

更靠谱的思路应该是：先弄清楚到底是哪种限流，再决定接下来是等待、降级、排队、切模型、走批处理，还是申请扩容。大模型 API 的限流并不只是看 QPS，它还可能同时受 RPM、TPM、并发连接数、模型类型、地域、账号额度、组织配额等多种因素影响。

下面这篇文章会按照“排查问题—临时止血—长期优化—企业治理”的顺序，聊清楚 API 被限流后该怎么办，以及不同场景下应该怎么选解决方案。

先给结论：大模型 API 被限流时应该怎么处理？

如果线上已经出现大模型 API 限速，建议先按这个顺序处理：

1. 先停掉那种无脑高频重试，避免把系统拖进重试风暴。
2. 看清楚错误码、错误信息、响应头里的 Retry-After，以及平台返回的剩余额度、重置时间等信息。
3. 临时把并发数和请求频率降下来，先保证核心业务还能用。
4. 缩短 prompt、减少历史上下文、限制 max_tokens，看看是不是 TPM 超了。
5. 实时业务可以用指数退避加随机抖动，必要时快速失败，或者切到降级模型。
6. 批量任务不要硬打接口，先进入队列削峰；如果平台支持，也可以考虑 Batch API。
7. 如果长期来看容量就是不够，那再申请官方提额、升级套餐，或者引入统一网关、多模型路由、多供应商容灾。

这里有个关键点：不是所有 429 都值得一直重试，也不是所有限流都能靠多 Key 解决。如果本来就是长期超额，重试只会增加请求量；如果问题出在 Token 超限，单纯限制 QPS 也解决不了。

大模型 API 限流到底限制了什么？

很多人一听“限流”，就理解成“每秒请求太多”。但在大模型 API 里，事情往往没这么简单。常见的限制维度大概有这些：

• RPM：每分钟请求数。它主要用来限制“请求太频繁”的情况。
• RPS/QPS：每秒请求数。更偏向控制瞬时流量突刺。
• TPM：每分钟 Token 数。哪怕请求次数不多，只要上下文很长，也可能被卡在这里。
• RPD/TPD：每日请求数或每日 Token 数，常见于免费额度、套餐额度、预算限制。
• 并发数：同时进行中的请求、流式连接或者后台任务太多，也可能触发限制。
• 模型级限额：同一个账号下，不同模型的请求额度和 Token 额度可能完全不一样。
• 地域级限额：不同 region、国内站、国际站，限制也可能不同。
• 账户级、组织级、Key 级限额：多 Key 有没有用，取决于限额到底绑定在哪一层。
• 动态限流：服务商资源紧张时，就算你看起来没超过公开额度，也可能出现临时拥塞或限流。

所以排查大模型 API 限流时，不能只盯着“请求次数”。Token、并发、模型、账号层级，这些都要一起看。

如何判断自己是哪一种限流？

比较实用的判断方式是：先看错误信息，再看现象，最后去平台控制台对照额度和调用记录。

现象	可能原因	优先处理
短时间出现大量 429	RPM/QPS 超限	降低频率、用令牌桶、进队列
请求数量不多但还是被限流	TPM 超限	缩短上下文、限制输出长度
流式输出经常失败	并发连接超限	控制连接数、清理闲置连接
只有某个模型失败	模型级额度低，或者模型本身拥塞	切备用模型、申请提额
只有高峰期失败	峰值容量不够	削峰、扩容、加监控
重试越多失败越多	重试风暴	指数退避加 jitter
返回 quota、balance、billing 相关错误	额度或账单问题	检查余额、套餐、账单状态
返回 503、overloaded	服务端拥塞	降低频率，别密集重试
超时但没有明确 429	网络、排队或模型响应慢	设置超时，排查链路和队列

一些常见错误也要分清楚：

• 429 Too Many Requests：最典型的速率限制。
• rate_limit_exceeded：一般表示请求频率或 Token 速率超了。
• insufficient_quota：更像是额度、账单或套餐问题，不是简单的“请求太快”。
• 503、overloaded：多数是服务端繁忙，这时候频繁重试并不合适。
• timeout：不一定是限流，也可能是模型响应慢、网络不稳定，或者请求在队列里排太久。
• Retry-After：如果响应头里有这个字段，优先按照它给出的时间等待。

临时止血方案：已经被限流了，马上怎么恢复？

线上已经被限流时，目标不是把每个请求都“硬怼成功”，而是先让系统回到可控状态。尤其是用户还在等响应的时候，盲目重试往往会让延迟和失败率一起上升。

1. 按 Retry-After 等待

如果服务商返回了 Retry-After，说明平台已经告诉你建议等待多久。这时就应该按这个时间暂停或延迟重试，而不是简单粗暴地固定 sleep 1 秒。

如果没有这个字段，可以用指数退避，比如 1 秒、2 秒、4 秒、8 秒这样逐步增加。但一定要设置最大重试次数和最大等待时间，不要无限等、无限试。

2. 加随机抖动，避免同时重试

多实例服务或者大量用户同时失败时，如果所有请求都在同一时间点重新发起，很容易再次把接口打爆。

所以重试等待时间最好加一点随机抖动，也就是常说的 jitter。比如在基础等待时间上增加一个随机偏移，让请求分散开来，这样系统会稳定很多。

3. 快速降低并发

如果是实时业务，可以先临时降低 worker 数量、线程池大小、异步并发数，或者在网关层降低放行速率。

对低优先级任务，不一定要立刻处理，可以直接放进队列，或者返回“正在排队，请稍后查看结果”。这比所有请求一起失败要好得多。

4. 缩短上下文和输出

如果请求量看起来并不大，但还是被限流，优先怀疑 Token。

可以马上做几件事：减少历史对话轮数、裁剪 RAG 召回片段、限制 max_tokens，避免单次请求消耗太多 TPM。很多时候，问题不是请求太多，而是每次请求太“重”。

5. 切换备用模型或降级能力

如果是某个模型限额低，或者模型临时拥塞，可以切到备用模型。这个办法适合临时止血，但要注意质量、价格、上下文长度、工具调用能力和延迟都可能发生变化。

最好在日志里记录每次实际使用的模型。否则后面出现回答质量下降时，很难定位到底是模型切换造成的，还是业务本身出了问题。

长期解决方案一：在客户端做限速和重试

如果项目规模还不算太大，比如中小型应用、脚本任务、单实例服务，在客户端做限速和重试就已经能解决不少问题。

常见方案可以这样选：

方案	适合场景	优点	风险
固定间隔 sleep	简单脚本	实现很快	吞吐低，不适合并发
指数退避 + jitter	偶发限流、服务拥塞	能避免重试风暴	不适合长期超额
令牌桶	控制 QPS/RPM	允许短时间突发	单机方案不适合多实例
漏桶	稳定匀速发送请求	流量比较平滑	对突发流量不友好
队列削峰	批量任务、异步任务	成功率高	延迟会增加
分布式限流	多实例服务	全局更可控	实现和维护成本更高
多模型/多供应商路由	高可用业务	容灾能力强	成本和一致性更复杂

在生产环境里，重试逻辑至少要区分三类错误：

• 可以重试：偶发 429、503、网络抖动、超时。
• 谨慎重试：服务端 overloaded、长时间排队、模型响应很慢。
• 不要重试：余额不足、权限错误、参数错误、模型不存在。

另外，请求超时、最大重试次数、最大队列长度、熔断策略都要有。没有上限的重试和队列，表面上是在“提升成功率”，实际很可能把一个限流问题放大成系统故障。

长期解决方案二：用队列和 Batch 处理高吞吐任务

像批量内容生成、批量摘要、批量分类、批量质检这类任务，不太适合直接用高并发循环去打 API。看起来简单，实际很容易把平台限额打满，也不利于失败恢复。

更稳的方式是用消息队列削峰。常见做法包括：

• 用 Redis Stream、RabbitMQ、Kafka、SQS 等队列承接任务。
• 根据平台的 RPM、TPM 和并发限制来设置 worker 数量。
• 失败任务进入延迟重试队列，不要马上重新打接口。
• 支持断点续跑，避免长任务中断后全部重来。
• 给任务设置过期时间，防止队列无限增长。
• 区分高优先级和低优先级任务，优先保障核心链路。

如果平台支持 Batch API，可以把离线生成、批量分析、批量标注这些任务迁移过去。Batch 通常更适合高吞吐、低实时性的场景，但不适合强实时对话，也不适合用户正在页面上等待结果的交互。

长期解决方案三：减少 Token 消耗，避免 TPM 超限

不少大模型 API 的限流，并不是因为请求次数太多，而是 Token 消耗太高。尤其是 RAG、Agent、长对话、文档处理这些场景，TPM 往往比 RPM 更早成为瓶颈。

可以从下面几个方向优化：

• 控制 max_tokens，不要默认允许模型输出很长内容。
• 压缩历史对话，只保留和当前问题真正相关的信息。
• 裁剪 RAG 检索片段，别把大量无关文本塞进上下文。
• 工具调用结果先做摘要，再交给模型继续处理。
• 缓存高频问题、系统提示词处理结果和中间结果。
• 合并相似请求，减少重复调用。
• 简单任务用轻量模型，不要所有请求都打最高级模型。
• 减少 Agent 的无效轮次，能用规则判断的，就没必要都交给模型推理。

这里还要注意一个常见误区：把大任务拆得过碎。拆分确实可以降低单次 Token 消耗，但如果拆得太细，请求数会明显增加，最后可能反过来触发 RPM 超限。比较合理的做法，是同时评估请求数和 Token 数，不要只看其中一个指标。

长期解决方案四：多模型、多 Key、多供应商怎么用才安全？

多 Key、多账号经常被拿来当作大模型 API 限流的解决办法，但它们并不是万能药，更不应该用来规避平台规则。

使用时需要注意这些问题：

• 如果限额绑定在组织或账户层，多 Key 可能根本没有效果。
• 如果平台不允许用多账号绕过限制，滥用可能触发风控。
• Key 必须加密存储，不能明文写在代码、配置文件或前端里。
• 不同 Key 的调用量、错误率、账单都要能追踪。
• 要设置预算上限和告警，避免某个 Key 异常消耗。
• 更稳妥的扩容方式，是申请官方提额、企业套餐，或者做合规的多供应商容灾。

多模型路由比较适合高可用业务。比如主模型被限流时切到备用模型，复杂任务走能力更强的模型，简单任务走轻量模型。切换时不能只看“能不能返回结果”，还要评估回答质量、价格、上下文长度、函数调用能力和延迟。

如果使用第三方兼容接入平台，比如 ClaudeAPI 这类第三方 Claude API 兼容接入服务，也要明确它并不是 Anthropic 官方服务。可以关注它是否提供兼容接入、多线路选择、中文支持、企业充值、开票和基础技术协助。至于具体额度、价格和可用性，还是要以平台最新说明为准，不要默认认为“绝对稳定”或者“绝对不限速”。

企业级方案：统一网关、租户限额和监控告警

当多个业务线、多个团队、多个模型共用 API 时，只在每个应用里单独写限速逻辑就不太够了。这个时候，更适合搭一个统一的大模型网关。

网关层可以承担不少关键能力：

• 按用户、租户、业务线、模型、Key、IP、Header 等维度做限流。
• 给核心业务更高优先级，低优先级任务排队或降级。
• 统一管理模型、供应商、Key 和调用日志。
• 对 429、503、超时等错误做熔断和降级。
• 统一记录成本、Token、延迟和失败原因。
• 做密钥隔离、审计日志和权限控制。

监控指标也很重要，至少应该包含：

• 429 的次数和占比。
• 每分钟请求数、输入 Token、输出 Token、总 Token。
• 平均延迟、P95、P99 延迟。
• 当前队列长度和等待时间。
• 重试次数、重试成功率。
• 不同模型、Key、租户、业务线的调用量。
• 降级次数和备用模型命中率。
• 余额、预算、每日额度消耗。

没有监控的限流治理，说白了就是靠猜。特别是在多实例部署时，每个实例看起来都没超过限制，但所有实例加起来，可能早就超过平台额度了。

容量估算：提前知道会不会被限流

上线前可以先做一个粗略估算，判断当前额度能不能扛住业务峰值。

• 预计 RPM = 峰值用户数 × 人均每分钟请求数 × 单次业务模型调用次数。
• 预计 TPM = 预计 RPM × 单次平均 Token 数。
• 单次平均 Token 数 = 输入 Token + 输出 Token。
• Agent 实际调用量 = 用户请求数 × 平均模型轮次。

举个例子：如果峰值时有 100 个用户同时使用，每人每分钟 2 次请求，每次业务平均调用 3 次模型，那么大约需要 600 RPM。如果每次平均消耗 3000 Token，那就需要大约 180 万 TPM。

这个估算当然不代表任何平台承诺，它只是帮你判断当前额度和业务峰值是否匹配。具体限额还是要以服务商控制台和官方文档为准。

常见错误做法

处理 API 限流时，下面这些做法很容易埋坑：

• 429 后立刻无限重试，最后引发重试风暴。
• 只限制 QPS，却完全不管 Token 消耗。
• 多实例各自限速，但没有全局限速。
• 队列无限增长，没有超时、丢弃和优先级策略。
• 所有请求都打最高级、最贵，或者限额最低的模型。
• 多 Key 明文写在代码里，没有轮换和审计。
• 不区分实时任务和批量任务，全部一视同仁。
• 不看平台控制台，直接照搬别人文章里的限额数字。
• 降级模型后不记录，后续质量问题无法追踪。

总结：不同情况应该选哪种解决办法？

情况	优先方案
偶发 429	指数退避 + jitter
持续 429	本地限速 + 队列
请求不多但仍被限	检查 TPM，减少 Token
流式连接失败	控制并发连接，清理闲置连接
批量任务慢或失败多	Batch API 或异步任务队列
高峰期失败	削峰、扩容、申请提额
单模型限额低	备用模型或模型路由
多实例部署	分布式限流或统一网关
企业多业务共用	租户限额、优先级队列、监控告警
关键业务不能失败	多供应商容灾 + 降级策略

大模型 API 限速本身并不可怕，真正麻烦的是没搞清原因就盲目重试。比较可靠的做法，是先读懂错误信息和额度情况，再结合 RPM、TPM、并发、模型和业务场景来选方案。

简单说，偶发限流用退避，持续限流做限速和队列，Token 超限就优化上下文，批量任务走 Batch 或异步队列。至于长期容量不足，再考虑提额、多模型路由和统一网关治理。这样处理，系统才会越来越稳，而不是在限流和重试之间反复拉扯。