你搭的应用稳了一个月今天突然日志里全是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推荐看哪个监控面板OpenAIRPM TPM 双管齐下免费用户 RPM 不高具体以官网为准通常有OpenAI Dashboard阿里通义千问主要是 TPM部分模型有 RPM免费用户 TPM 大概几十万因模型而异部分响应有阿里云控制台监控百度文心RPM TPM还分模型版本免费版 RPM 比较低通常有 Retry-After百度智能云监控腾讯混元并发限制 TPM免费版并发数不高比较标准腾讯云监控Moonshot / KimiRPM TPM注册用户有基础额度有 Retry-After控制台注意上面这些默认配额是公开信息但经常变还是以各厂商官网最新说明为准。开发时最好硬编码一个“最低保证值”免得配额一更新代码就废了。常规武器优雅的代码级防御3.1 指数退避 抖动必做最简单的重试逻辑往往是灾难——所有客户端同时等 1 秒再重试等于把限速压力变成了脉冲式的 DDoS。正确的做法是指数退避 随机抖动。Python用tenacity库示例fromtenacityimportretry,stop_after_attempt,wait_exponential,retry_if_exception_typefromopenaiimportRateLimitErrorimporttime,randomretry(stopstop_after_attempt(5),# 最多重试5次waitwait_exponential(multiplier1,min1,max60),# 等待时间: 1s, 2s, 4s, 8s, 16s… 上限60sretryretry_if_exception_type(RateLimitError),before_sleeplambdaretry_state:time.sleep(min(60,(2**retry_state.attempt_number)random.uniform(0,1))))defcall_model(prompt):returnopenai.ChatCompletion.create(...)Java用resilience4j关键配置RetryConfigconfigRetryConfig.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_retrysleep_and_retrylimits(calls30,period60)# 每分钟最多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,keylambdax:x[priority]):try:resultcall_model(prompt,modelm[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是你的应用在告诉你“该做架构设计了”。把这些方法用起来你不仅能搞定限速还能让你的应用在面对波动时更皮实。