1. 从一次线上告警说起529 到底卡在哪凌晨两点多监控面板上一条曲线突然翘起来某个内容生成服务的失败率从 0.3% 直接冲到 40% 以上。翻日志一看清一色的529 Overloaded而且只集中在调用新版本大模型的那条链路上。同一套请求体、同一个 API Key、同一台机器把模型名换成上一代旧模型立刻恢复正常成功率回到 99% 以上。这个现象其实非常典型也是最近很多团队在接入新版本大模型时反复踩到的坑。标题里说的“Claude Opus 4.8 调用一直报 529换旧模型却正常”本质上不是你的代码写错了也不是 Key 失效了而是新模型侧的容量水位和旧模型完全不在一个量级。新模型刚上线算力池还在扩容热门时段请求一拥而上服务端就会主动拒绝一部分流量来保护整体稳定性返回的就是 529。先把概念理清楚避免后面排查时方向跑偏429 Too Many Requests你这边发得太快、太多触发了你自己的配额或速率限制。责任在调用方属于“你超速了”。529 Overloaded服务端整体负载过高跟你发多少关系不大是对方容量不够。责任在服务方属于“路堵了谁都过不去”。这两个错误经常被混为一谈但处理策略完全不同。429 你要做的是降低自己的发送速率529 你要做的是退避重试 分流降级。把 529 当成 429 去处理比如一味地加大重试频率只会让情况更糟——你越重试服务端压力越大529 越密集形成雪崩。这篇文章面向的是正在做 LLM 应用落地、被 529 折磨过的后端和算法同学。我会把 529 的成因、和 429 的区别、双桶退避的完整实现、以及换旧模型为什么能“续命”这套逻辑讲透最后给一份可以直接抄作业的退避代码。看完你应该能做到新模型该用还用但不会再被 529 打崩。2. 为什么换旧模型就正常容量水位与路由机制2.1 新模型和旧模型不在同一个容量池很多人有个误解以为所有模型都跑在同一批机器上只是模型权重不同。实际上不同代际、不同规模的模型往往部署在独立的推理集群上。新版本旗舰模型参数量更大、推理更慢、单卡能承载的并发更低所以它的集群规模、扩容节奏、灰度策略都和旧模型不一样。新模型上线初期通常会经历几个阶段小规模灰度只开放给部分账号容量池很小稍微有点量就 529。逐步放量容量慢慢扩但用户增长更快供需长期处于紧平衡。稳定期容量跟上来了529 概率大幅下降。你遇到“一直报 529”大概率是卡在阶段 1 到阶段 2 之间。而旧模型已经跑了一两年容量池早就扩到位水位平稳所以同样的请求打过去毫无压力。这就是“换旧模型却正常”的根本原因——不是旧模型更聪明而是旧模型更闲。2.2 服务端过载保护是怎么触发的服务端不是等到真的扛不住了才拒绝而是有一套提前量保护机制。常见的触发条件包括队列深度超过阈值请求排队太长新来的直接拒。GPU 利用率持续高位比如连续若干秒超过 90%开始限流。单实例并发数超限每个推理实例能同时处理的请求数是有上限的。全局 QPS 超过容量水位整个集群的入口限流。一旦触发服务端会优先拒绝新到达的请求而不是把已经在处理的请求掐掉。返回 529 的同时通常还会带一个Retry-After头告诉你建议等多久再试。这个头非常关键后面退避算法要用到。注意529 是服务端主动拒绝不是网络错误也不是超时。你的请求可能根本没进推理队列就被挡回来了所以重试成本很低值得重试。2.3 为什么“一直报”而不是“偶尔报”偶尔报 529 是正常的任何大模型服务在高峰期都会有零星过载。但如果持续、密集地报说明你踩中了几个叠加因素你的请求集中在高峰时段和全球用户抢同一批容量。你的并发设置偏高短时间内打过去太多请求。你没有退避失败后立刻重试反而加剧了拥堵。你用的是新模型容量池本来就小。把这几个因素拆开看能优化的空间其实很大。退避代码解决的是“重试策略”问题分流降级解决的是“容量池选择”问题错峰和限流解决的是“发送节奏”问题。三者配合才能把 529 压到可接受范围。3. 429 和 529 的本质区别一张表讲清在写退避代码之前必须先把这两个错误的行为差异搞清楚否则退避参数没法调。维度429 Too Many Requests529 Overloaded责任方调用方你超配额服务方容量不足触发原因超过 RPM/TPM/并发限制服务端整体负载过高是否与你的量有关强相关弱相关重试是否有用有用但要等配额恢复有用但要等服务端降压典型 Retry-After有通常较短有可能较长错误处理策略降速 退避退避 分流降级加剧风险疯狂重试会持续 429疯狂重试会加剧 529 雪崩从表里能看出一个关键点429 是“你太快”529 是“它太忙”。429 你只要把速度降下来就行529 你降速也未必有用因为堵的不是你这一条路。但两者有一个共同点都需要退避重试且都需要区分对待。这就是为什么标题里提到“双桶退避”——把 429 和 529 放进两个独立的退避桶里各自维护自己的退避状态互不干扰。为什么要分桶因为如果共用一个退避计数器会出现一种尴尬情况你因为 429 退避到 30 秒结果这 30 秒里服务端其实已经恢复了你白白等了 30 秒反过来你因为 529 退避但 429 的配额早就恢复了也被一起拖慢。分桶之后两类错误的退避节奏独立演进整体吞吐更优。4. 双桶退避的核心设计思路4.1 什么是“桶”为什么要两个“桶”在这里是一个抽象概念指的是一类错误对应的退避状态机。每个桶里维护自己的当前退避时长backoff duration连续失败次数failure count上次失败时间戳最大退避上限双桶就是 429 一个桶、529 一个桶。请求失败时先判断错误类型丢进对应的桶里计算下次重试时间请求成功时把两个桶都重置或者按策略衰减。这个设计的精妙之处在于不同错误的重试节奏可以完全不同。429 通常恢复快退避可以激进一点比如从 1 秒起步上限 30 秒529 恢复慢退避要保守从 2 秒起步上限 120 秒并且要配合抖动jitter避免惊群。4.2 指数退避 抖动为什么必须加抖动纯指数退避有个致命问题如果一批请求同时失败它们会同时重试。比如 100 个请求在第 1 秒全挂了都退避 2 秒那么第 3 秒这 100 个请求会同时打过去瞬间又触发 529然后一起退避 4 秒第 7 秒再一起打……这就是惊群效应thundering herd。解决办法是加随机抖动。常见的有三种Full Jittersleep random(0, base * 2^n)完全随机分散效果最好但可能退避时间偏短。Equal Jittersleep base * 2^n / 2 random(0, base * 2^n / 2)保证一半固定、一半随机。Decorrelated Jittersleep min(cap, random(base, prev * 3))基于上次退避时间随机适合长尾场景。实测下来Full Jitter 对 529 的缓解效果最明显因为它把重试时间彻底打散。代价是平均等待时间可能偏短偶尔会撞上还没恢复的服务端但多试几次总能成功。对于 429Equal Jitter 更稳因为它保证了最小等待时间不会因为随机到太短而反复触发限流。4.3 退避上限和重置策略退避不能无限增长否则一次故障可能让你等几分钟。通常设一个上限429 桶上限 30 秒因为配额恢复通常很快。529 桶上限 120 秒因为服务端降压需要时间。重置策略也有讲究。有两种常见做法成功后立即重置只要有一次成功就把失败计数清零。简单但对偶发成功敏感可能刚重置又失败。成功后衰减成功一次把失败计数减一而不是清零。更平滑适合波动大的场景。我一般用方案 2因为大模型服务在高峰期经常是“成功一次、失败一次”交替出现立即重置会让退避形同虚设。5. 完整退避代码实现可直接抄下面这份代码是 Python 版本核心是一个DualBucketBackoff类配合一个带重试的调用函数。你可以直接拿去改改就用。import time import random import logging from typing import Callable, Any, Optional logger logging.getLogger(__name__) class DualBucketBackoff: 双桶退避429 和 529 各自维护独立的退避状态。 def __init__( self, base_429: float 1.0, cap_429: float 30.0, base_529: float 2.0, cap_529: float 120.0, ): self.base_429 base_429 self.cap_429 cap_429 self.base_529 base_529 self.cap_529 cap_529 # 每个桶维护失败计数 self.fail_429 0 self.fail_529 0 def _calc_429(self) - float: # Equal Jitter一半固定一半随机 raw min(self.cap_429, self.base_429 * (2 ** self.fail_429)) half raw / 2 return half random.uniform(0, half) def _calc_529(self) - float: # Full Jitter完全随机打散重试 raw min(self.cap_529, self.base_529 * (2 ** self.fail_529)) return random.uniform(0, raw) def on_429(self) - float: self.fail_429 1 wait self._calc_429() logger.warning(429 hit, fail_429%d, sleep%.2fs, self.fail_429, wait) return wait def on_529(self) - float: self.fail_529 1 wait self._calc_529() logger.warning(529 hit, fail_529%d, sleep%.2fs, self.fail_529, wait) return wait def on_success(self): # 衰减式重置成功一次减一而不是清零 if self.fail_429 0: self.fail_429 - 1 if self.fail_529 0: self.fail_529 - 1 def call_with_backoff( func: Callable[[], Any], backoff: DualBucketBackoff, max_retries: int 8, retry_after_header: Optional[Callable[[Exception], Optional[float]]] None, ) - Any: 带双桶退避的调用封装。 func 内部抛出的异常需要能区分 429 / 529。 last_exc None for attempt in range(max_retries): try: result func() backoff.on_success() return result except Exception as e: last_exc e status getattr(e, status_code, None) # 优先使用服务端给的 Retry-After server_wait None if retry_after_header: server_wait retry_after_header(e) if status 429: wait server_wait if server_wait else backoff.on_429() elif status 529: wait server_wait if server_wait else backoff.on_529() else: # 其他错误不重试直接抛 raise time.sleep(wait) raise RuntimeError(fmax retries exceeded, last error: {last_exc})这段代码有几个设计点值得展开说第一Retry-After优先。服务端如果明确告诉你要等多久就听它的别自作聪明用自己算的退避时间。服务端最清楚自己什么时候能恢复。第二429 用 Equal Jitter529 用 Full Jitter。前面解释过原因这里不再重复。你可以根据实测调整如果发现 529 恢复特别慢可以把base_529调到 3 秒甚至 5 秒。第三成功衰减而不是清零。on_success里是减一不是归零。这个细节在高峰期特别有用。第四非 429/529 错误直接抛。不要把所有错误都重试比如 400 参数错误、401 鉴权失败重试一万次也没用只会浪费时间。5.1 参数怎么调一份实测参考不同业务场景下退避参数需要微调。下面是我在几个项目里实测下来比较稳的一组值场景base_429cap_429base_529cap_529max_retries实时对话低延迟0.5s10s1s30s5批量内容生成1s30s2s120s8后台离线任务2s60s5s300s10实时对话场景对延迟敏感退避上限要压低宁可快速失败让用户重试也不要让用户干等 2 分钟。批量生成场景可以容忍长退避因为反正不着急。离线任务最宽松退避上限可以拉到 5 分钟。提示max_retries不要设太大。8 次重试配合指数退避总等待时间可能已经超过 10 分钟再重试意义不大不如直接降级到旧模型。6. 分流降级529 持续时的保命策略退避代码能解决“偶发 529”但如果 529 持续不断光靠退避是不够的——你会在重试上耗掉大量时间用户体验直线下降。这时候需要分流降级。6.1 主备模型切换最直接的做法是准备一个备用模型。当新模型连续 N 次 529 后自动切到旧模型等一段时间再切回来。伪代码逻辑class ModelRouter: def __init__(self, primary, fallback, backoff): self.primary primary self.fallback fallback self.backoff backoff self.primary_fail_streak 0 self.switch_threshold 5 # 连续 5 次 529 就切 def call(self, payload): if self.primary_fail_streak self.switch_threshold: logger.warning(primary degraded, using fallback) return call_with_backoff( lambda: self.fallback(payload), self.backoff ) try: result call_with_backoff( lambda: self.primary(payload), self.backoff ) self.primary_fail_streak 0 return result except Exception as e: if getattr(e, status_code, None) 529: self.primary_fail_streak 1 raise这个路由器的关键参数是switch_threshold。设太小比如 2会频繁切换主模型刚恢复又被切走设太大比如 20降级太慢用户已经等急了。实测 5 到 8 之间比较合适。6.2 按请求优先级分流不是所有请求都值得用新模型。可以把请求分成几档高优先级必须用新模型比如核心付费功能。这类请求走主链路退避参数拉满尽量保证成功。中优先级新模型优先失败降级到旧模型。大部分请求属于这档。低优先级直接用旧模型或者排队等低峰期再处理。这样分流之后新模型的压力会小很多529 概率自然下降。而且高优先级请求因为竞争少了成功率反而更高。6.3 错峰与限流如果你的业务允许把批量任务挪到低峰期跑能避开大部分 529。低峰期通常是目标服务所在时区的深夜到凌晨。另外在客户端做一层令牌桶限流控制发往新模型的 QPS 上限也能显著降低 529。令牌桶的实现很简单每秒往桶里放 N 个令牌请求来了先取令牌取不到就等。N 的值根据你的配额和服务端容量水位来定一般从保守值开始慢慢往上调观察 529 率。7. 常见问题与排查速查表实际排查中除了 529 本身还会遇到一些衍生问题。整理成表方便对照。现象可能原因排查方向解决手段529 持续超过 10 分钟服务端大规模过载查服务状态页、社区反馈切旧模型等恢复529 和 429 交替出现退避参数不合理看两类错误的比例分桶调参429 退避调短重试后仍然 529退避时间太短看日志里的 sleep 值加大 base 和 cap换旧模型后偶发 429旧模型配额也满了查旧模型的 RPM/TPM降速或申请提额退避导致请求超时max_retries 太大算总等待时间减小重试次数加降级高峰期成功率骤降容量池竞争激烈对比不同时段数据错峰 分流单个请求偶发 529正常波动看整体失败率退避重试即可几个排查心得第一先看错误分布再动手改代码。很多人一看到 529 就急着加退避结果发现 429 才是主因。先把日志里 429 和 529 的数量拉出来对比方向才不会错。第二Retry-After一定要读。有些服务端会在 529 时返回这个头告诉你建议等待时间。忽略它自己算退避往往等得太短或太长。第三退避日志要打全。每次退避都记录错误类型、当前失败计数、计算的等待时间、实际等待时间。出问题时这些日志是唯一的线索。第四别在重试里做重活。重试函数应该只负责重新发起请求不要在重试路径里做数据转换、日志上报等耗时操作否则退避时间会被这些操作吃掉。第五降级要有开关。主备切换最好做成配置项出问题时能手动强制走备用而不是只能等自动切换。8. 几个容易踩的坑和实操心得聊完正事说几个我踩过的坑都是文档里不会写的。坑一把 529 当 429 处理。早期我图省事两类错误共用一个退避计数器结果 529 期间退避时间被 429 的短退避带偏重试太频繁反而加剧了服务端压力。分桶之后明显好转。坑二抖动加得太小。一开始我用的是random(0, 0.1 * wait)抖动幅度太小基本等于没加。后来改成 Full Jitter重试打散效果立竿见影。抖动幅度至少要覆盖退避时间的一半才有明显效果。坑三忽略连接池。高并发下如果 HTTP 连接池太小请求会排队等连接看起来像超时实际是连接不够。把连接池调大配合退避整体成功率会提升。坑四重试没有幂等保证。如果请求不是幂等的比如会创建资源重试可能导致重复创建。要么保证接口幂等要么在重试前做去重。大模型调用通常是幂等的但如果你在调用前后有副作用操作要特别注意。坑五监控只看平均值。平均成功率 95% 看起来不错但可能高峰期是 60%、低峰期是 99.9%。要看分时段的 P95、P99 失败率才能发现 529 的真实影响。坑六忘了给退避加超时。如果退避总时长超过上游的超时限制请求会在退避过程中被上游掐断白等一场。退避总时长要留出余量或者把退避逻辑放到上游超时之外。最后分享一个实用技巧给退避状态加个全局视图。如果你的服务是多实例部署每个实例各自维护退避状态可能出现“这个实例在退避、那个实例在猛打”的情况。可以把退避状态放到共享存储比如 Redis所有实例共享失败计数退避节奏更一致。当然这会增加一点复杂度量不大的话单机状态也够用。这套双桶退避加分流降级的组合我在几个项目里跑下来529 导致的失败率能从 40% 压到 2% 以内高峰期也能稳住。核心就一句话分清 429 和 529分桶退避该降级就降级别硬刚。
