频繁触发限速？大模型 API 429 错误的处理思路
你搭的应用稳了一个月，今天突然日志里全是429 Too Many Requests。用户跑来吐槽“机器人没反应”，老板也在群里@你。别慌，这其实不算什么大事——大模型 API 限速说白了，就是每个做 AI 开发的都会碰上的“成人礼”。这篇文章会从怎么快速定位问题、怎么写代码防御、怎么降级兜底，一直到架构怎么选，给你一整套能直接拿来用的429 错误处理方案。
紧急抢救：应用已经崩了，现在该做什么
碰上大范围的 429，第一件事就是先止血，再找原因。下面这几个操作，一分钟内就能让雪崩停下来：
- 暂停所有请求流：在应用层搞个全局开关（比如 Redis 里设个 flag），先拒绝所有新请求，别让重试把服务压垮。
- 把完整的错误响应体打印出来：别光捕获异常，得把 HTTP 响应头里的关键字段都输出来：
Retry-After：服务端建议你等几秒，这个往往比你瞎猜的准。X-RateLimit-Remaining：当前还剩多少配额（如果厂商给了的话）。X-RateLimit-Reset：配额什么时候重置。
- 查查账户欠费了没：很多 429 其实不是限速，而是你账户没钱了，服务商直接拒绝请求。去厂商控制台看一眼余额，比分析日志快多了。
这一阶段的目标就是让应用别崩，宁可暂时牺牲一点可用性，也要保住数据完整性。
破案：你的 429 到底是哪种
同样都是 429，背后的原因可能完全不一样。判断错了，改代码也白搭。建议按下面三步来诊断：
3.1 阶梯式诊断流程图
收到 429 ├─ 响应头里有 Retry-After 吗？ │ └─ 有 → 按建议时间等一会儿再重试，多半是临时限速 ├─ 响应头里有 X-RateLimit-* 字段吗？ │ ├─ remaining 是 0 → 配额用完了（可能是 RPM 也可能是 TPM） │ ├─ remaining 是正数但还报 429 → 可能是并发限制，或者账户级配额 │ └─ 没有这些头 → 检查一下请求格式、网络层有没有丢包或者代理重试 └─ 啥限速头都没有 → 优先怀疑账户欠费了，或者 API Key 被撤了3.2 三大限速类型详解
| 限速类型 | 啥意思 | 啥时候容易触发 | 典型例子 |
|---|---|---|---|
| RPM（每分钟请求数） | 一分钟内最多能发多少个请求 | 并发调用特别密，每个请求消耗不大 | OpenAI 部分模型、阿里百炼基础版 |
| TPM（每分钟 Token 数） | 一分钟内最多消耗多少 Token | 单个请求输出特别长（比如长篇生成、多轮对话） | GPT-4、通义千问-max |
| 并发数 | 同一时刻最多能建立多少个连接 | 服务器资源有限，中小厂商常见 | 某些国产模型的早期版本 |
怎么区分？先拿少量短请求试试：如果短请求经常 429，长请求反而很少，那多半是 RPM 的锅；反过来短请求正常、长请求容易 429，那 TPM 就是瓶颈。
3.3 主流厂商限速特征对比
| 厂商 | 主要限速维度 | 默认配额（免费/入门）大概多少 | 响应头里有没有 Retry-After | 推荐看哪个监控面板 |
|---|---|---|---|---|
| OpenAI | RPM + TPM 双管齐下 | 免费用户 RPM 不高（具体以官网为准） | 通常有 | OpenAI Dashboard |
| 阿里通义千问 | 主要是 TPM，部分模型有 RPM | 免费用户 TPM 大概几十万（因模型而异） | 部分响应有 | 阿里云控制台监控 |
| 百度文心 | RPM + TPM，还分模型版本 | 免费版 RPM 比较低 | 通常有 Retry-After | 百度智能云监控 |
| 腾讯混元 | 并发限制 + TPM | 免费版并发数不高 | 比较标准 | 腾讯云监控 |
| Moonshot / Kimi | RPM + TPM | 注册用户有基础额度 | 有 Retry-After | 控制台 |
注意：上面这些默认配额是公开信息，但经常变，还是以各厂商官网最新说明为准。开发时最好硬编码一个“最低保证值”，免得配额一更新代码就废了。
常规武器：优雅的代码级防御
3.1 指数退避 + 抖动（必做）
最简单的重试逻辑往往是灾难——所有客户端同时等 1 秒再重试，等于把限速压力变成了脉冲式的 DDoS。正确的做法是指数退避 + 随机抖动。
Python（用tenacity库）示例：
fromtenacityimportretry,stop_after_attempt,wait_exponential,retry_if_exception_typefromopenaiimportRateLimitErrorimporttime,random@retry(stop=stop_after_attempt(5),# 最多重试5次wait=wait_exponential(multiplier=1,min=1,max=60),# 等待时间: 1s, 2s, 4s, 8s, 16s… 上限60sretry=retry_if_exception_type(RateLimitError),before_sleep=lambdaretry_state:time.sleep(min(60,(2**retry_state.attempt_number)+random.uniform(0,1))))defcall_model(prompt):returnopenai.ChatCompletion.create(...)Java（用resilience4j）关键配置：
RetryConfigconfig=RetryConfig.custom().maxAttempts(5).waitDuration(Duration.ofSeconds(1)).retryExceptions(RateLimitException.class).intervalFunction(IntervalFunction.ofExponentialBackoff(Duration.ofSeconds(1),2.0,Duration.ofSeconds(60))).build();关键点：抖动（Jitter）能防止多个实例在同一个时间点重试。如果用了tenacity自带的wait_exponential没有抖动，就得手动加个随机偏移。
3.2 客户端本地限流：从源头“不犯错”
与其等服务端返回 429 再重试，不如在客户端主动控制发送频率。这对高并发场景特别有用。
- 令牌桶算法：设定一个速率（比如 30 请求/分钟），每秒补充 0.5 个令牌。请求前拿令牌，拿不到就排队或者丢掉。
- 漏桶算法：固定速率处理请求，超出部分直接丢掉。
Python 的ratelimit库、Java 的Guava RateLimiter都是现成实现。比如：
fromratelimitimportlimits,sleep_and_retry@sleep_and_retry@limits(calls=30,period=60)# 每分钟最多30次deflimited_call(prompt):returncall_model(prompt)注意：客户端限流的值要比服务端配额低一点，留出余量（比如服务端配额 35，客户端设 30）。
3.3 请求批处理与缓存
- 批处理（Batching）：把多个独立的短请求合并成一个 batch 接口调用（如果厂商支持的话）。OpenAI 和部分国产模型都支持 batch API，能大幅降低 RPM 消耗。
- 结果缓存：对于相同或相似的输入，直接缓存模型输出结果。比如“请你写一封会议邀请邮件”这种高频 Prompt，可以用 Redis 缓存 1 小时。缓存命中率每提升 10%，429 概率就能下降一个量级。
高端战术：降级与兜底
当常规重试解决不了问题（比如账户总配额用完了），你需要优雅降级，保证核心功能还能用。
4.1 模型降级
准备一组“主模型 + 备模型”的配置列表。主模型用高智能但成本高的模型（比如 GPT-4、通义千问-max），一旦连续 3 次收到 429，自动降级到成本更低、限额更宽松的模型（比如 GPT-4o-mini、千问-plus）。
降级代码模式（伪代码）：
models=[{"model":"gpt-4","priority":1,"consecutive_failures":0},{"model":"gpt-4o-mini","priority":2,"consecutive_failures":0},]defcall_with_fallback(prompt):forminsorted(models,key=lambdax:x["priority"]):try:result=call_model(prompt,model=m["model"])m["consecutive_failures"]=0returnresultexceptRateLimitException:m["consecutive_failures"]+=1ifm["consecutive_failures"]>=3:# 降级到下一个优先级的模型continueraise4.2 功能降级
有些场景下，你可以放弃非核心功能。举个例子，一个 AI 写作助手，当限速时：
- 核心功能（必须）：用户编辑区的实时续写 → 正常调用。
- 非核心功能（可降级）：侧栏的“智能摘要” → 关掉，显示“摘要服务暂不可用”。
实现方式：在配置中心里为每个功能设一个“阈值”，当这个功能调用失败率超过 20% 时自动关闭，失败率恢复后再开启。
4.3 架构兜底：引入消息队列
对于削峰填谷，消息队列（比如 RabbitMQ、Kafka）是终极方案。请求先进队列，后端 worker 以稳定速率拉取消费，超出限速的部分自动排队。
用户请求 → API 网关 → 消息队列 → 消费 Worker → 大模型 API ↑ 限速调度器（控制消费速率）这样做的好处是：就算大模型 API 暂时完全挂了，用户请求也不会丢，队列会等调度器恢复后继续处理。代价就是响应延迟从秒级变成分钟级，适合对延迟不敏感的场景（比如后台批处理、报告生成）。
战略抉择：什么时候该用什么方案
不同团队、不同阶段，没有银弹。下面给个场景化推荐表：
| 场景 | 推荐策略组合 | 理由 |
|---|---|---|
| 个人开发者 / 内部工具 | 客户端限流 + 指数退避重试 | 实现成本低，够用就行 |
| 小型创业团队（日活 <1k） | 模型降级 + 缓存 | 保证用户体验不崩，还能省钱 |
| 中大型应用（日活 >10k） | 消息队列 + 自适应限流 + 多模型轮询 | 需要高可用，还得控制成本 |
| 需要跨厂商容灾 | 自建 API 代理 + 动态路由 | 防止被一家供应商绑死 |
什么时候该考虑“中转服务”？如果你需要同时接入多个模型厂商，又不想分别对接各自的限速策略，或者想把海外的模型（比如 OpenAI 的 GPT-4）通过国内兼容服务调用以减少延迟，第三方 ClaudeAPI 兼容接入服务确实是个选择。这类服务通常提供多线路选择、国内服务器转发、企业充值开票，还有基础的技术支持。但得提醒一句：中转服务不是官方渠道，没法保证绝对不限速或者绝对稳定；引入它会增加延迟，还可能带来数据安全风险，甚至被供应商绑定。建议只在你自己确实搞不定多厂商对接、对稳定性要求又不高的时候，才去评估要不要用。
总结：一份可执行的攻防清单
遇到 429 时，按下面的顺序处理：
- 紧急止血：暂停所有请求 → 检查 Retry-After → 确认账户余额。
- 诊断根因：看响应头判断是 RPM 还是 TPM 限制 → 登录监控面板核实。
- 实施基础防御：加入指数退避 + 抖动重试 → 客户端本地限流 → 开启缓存。
- 启用降级方案：配置主备模型轮换 → 非核心功能自动熔断 → 考虑消息队列削峰。
- 长期战略：统计各模型成功率和成本 → 动态调整降级阈值 → 按需评估要不要引入更高级的架构，比如自适应限流。
记住，429 不是 bug，是你的应用在告诉你“该做架构设计了”。把这些方法用起来，你不仅能搞定限速，还能让你的应用在面对波动时更皮实。