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 Requests | 529 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 Jitter：
sleep = random(0, base * 2^n)，完全随机，分散效果最好，但可能退避时间偏短。 - Equal Jitter：
sleep = base * 2^n / 2 + random(0, base * 2^n / 2)，保证一半固定、一半随机。 - Decorrelated Jitter：
sleep = min(cap, random(base, prev * 3))，基于上次退避时间随机，适合长尾场景。
实测下来，Full Jitter 对 529 的缓解效果最明显，因为它把重试时间彻底打散。代价是平均等待时间可能偏短，偶尔会撞上还没恢复的服务端，但多试几次总能成功。对于 429，Equal 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(f"max retries exceeded, last error: {last_exc}")这段代码有几个设计点值得展开说：
第一，Retry-After优先。服务端如果明确告诉你要等多久，就听它的，别自作聪明用自己算的退避时间。服务端最清楚自己什么时候能恢复。
第二，429 用 Equal Jitter，529 用 Full Jitter。前面解释过原因，这里不再重复。你可以根据实测调整，如果发现 529 恢复特别慢，可以把base_529调到 3 秒甚至 5 秒。
第三，成功衰减而不是清零。on_success里是减一，不是归零。这个细节在高峰期特别有用。
第四，非 429/529 错误直接抛。不要把所有错误都重试，比如 400 参数错误、401 鉴权失败，重试一万次也没用，只会浪费时间。
5.1 参数怎么调：一份实测参考
不同业务场景下，退避参数需要微调。下面是我在几个项目里实测下来比较稳的一组值：
| 场景 | base_429 | cap_429 | base_529 | cap_529 | max_retries |
|---|---|---|---|---|---|
| 实时对话（低延迟） | 0.5s | 10s | 1s | 30s | 5 |
| 批量内容生成 | 1s | 30s | 2s | 120s | 8 |
| 后台离线任务 | 2s | 60s | 5s | 300s | 10 |
实时对话场景对延迟敏感，退避上限要压低，宁可快速失败让用户重试，也不要让用户干等 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，分桶退避，该降级就降级，别硬刚。
