1. 529 报错到底在说什么：从错误码到服务端过载的真实链路

第一次看到529 overloaded的时候，我下意识以为是自己的请求参数写错了，或者是 API Key 的额度出了问题。翻了一圈文档才发现，529 根本不是客户端错误，它跟 400、401、429 完全不是一回事。这个状态码在服务端语义里代表的是"当前服务容量已经打满，暂时无法处理新请求"，换句话说，请求本身没毛病，是对方接不住了。

这一点特别关键，因为很多人排查方向一开始就跑偏了。看到报错就去检查自己的 JSON 格式、检查 model 名字拼写、检查 header 里的版本号，折腾半天发现请求完全合法。529 的本质是服务端过载，它和 429（请求频率超限）的区别在于：429 是"你发得太快了，慢点"，529 是"我这边整体压力太大，谁来都接不住"。前者是限流策略，后者是容量问题。

那为什么标题里说claude-opus-5.5一直报 529，而sonnet-5.5同样并发却没事？这是整件事最核心的疑点。我实测下来，原因基本可以归结到模型规格与资源占用的差异上。opus 系列作为旗舰规格，单次推理消耗的算力资源远高于 sonnet，服务端在调度时对 opus 的并发承载能力天然更弱。当整体负载上来时，opus 的队列会先满，sonnet 因为单请求更轻，还能继续吃下流量。

这里有个很多人忽略的点：你看到的"同样并发"其实并不等价。假设你同时开 10 个协程，一个打 opus，一个打 sonnet，从你的客户端看并发数一样，但对服务端来说，10 个 opus 请求占用的资源可能是 10 个 sonnet 请求的三到五倍。所以"同样并发 sonnet 没事"这个现象，恰恰印证了 529 是资源维度的过载，而不是连接数维度的限流。

理解了这个底层逻辑，排查思路就清晰了。你要做的不是去改请求，而是去适配服务端的容量波动。具体来说分三步走：先确认报错确实是 529 而不是被包装过的其他错误；再判断是持续性过载还是偶发性抖动；最后根据判断结果选择退避重试还是降级模型。下面我会把这三步拆开讲，并且给出可以直接抄的指数退避重试代码。

提示：529 是服务端返回的状态码，但很多 SDK 会把它包装成异常抛出，异常信息里可能只显示 "overloaded" 而没有明确的 529。排查时一定要把原始响应体打出来看，别被 SDK 的封装骗了。

2. 为什么 opus 比 sonnet 更容易撞上 529：容量、调度与请求权重的差异

要真正搞懂这个问题，得从服务端的资源调度模型说起。虽然我们看不到内部的实现细节，但从行为表现可以反推出几个关键机制。这部分内容是我结合多次实测和同行交流总结出来的，属于"基于常见实践的合理推断"，不是官方文档的原文，但足够指导你做出正确的工程决策。

2.1 模型规格决定了单请求的资源权重

旗舰模型和轻量模型在服务端的待遇是不一样的。opus 这类高规格模型，单次推理要走更深的网络、更多的参数激活，占用的 GPU 显存和计算时间都显著更高。服务端在做容量规划时，会给不同模型分配不同的资源池，或者在同一资源池里给不同模型设置不同的权重。

这就导致一个直接后果：当整体负载上升时，高权重模型的可用槽位会先耗尽。你可以把它想象成停车场，opus 是那种占两个车位的大车，sonnet 是占一个车位的小车。车位总数固定，大车先停满，小车还有空位。你看到的"并发数一样"，在车位占用上根本不一样。

2.2 请求排队与优先级调度

服务端通常会有请求队列。当瞬时请求超过处理能力时，新请求会进入队列等待。队列满了之后，再来的请求就直接返回 529。这里有个细节：不同模型的队列可能是独立的，也可能共享但优先级不同。

我实测发现一个规律：opus 的 529 往往来得更"突然"。sonnet 在接近过载时，延迟会先明显上升，给你一个缓冲信号；而 opus 经常是延迟还正常，突然就开始批量 529。这说明 opus 的队列可能更短，或者它的调度策略更激进，一旦资源紧张就直接拒绝而不是排队。这对重试策略的设计有直接影响——你不能指望通过观察延迟来判断 opus 是否即将过载。

2.3 时间维度的负载波动

服务端的负载不是恒定的。根据我的观察记录，工作日的白天（尤其是北美时区的工作时间）过载概率明显更高，深夜和凌晨相对宽松。这不是玄学，而是全球用户集中使用导致的自然波动。

下面这张表是我在一周内做的粗略统计，样本量不大，但趋势很明显：

这个规律告诉我们：如果你的任务对时间不敏感，把 opus 的批量任务挪到低峰期跑，能省掉一大半的重试逻辑。这是最省事的优化，比写任何重试代码都有效。

2.4 请求本身的特征也会影响命中率

除了模型规格，请求的 token 数量、是否流式、是否带工具调用，都会影响服务端的资源占用。一个 8K token 的 opus 请求和一个 500 token 的 opus 请求，在服务端眼里完全是两个量级。我做过对比测试，长上下文请求触发 529 的概率明显更高。

所以如果你在用 opus 处理长文档，可以考虑两个优化方向：一是把大请求拆成小请求分批处理，二是对非核心部分降级到 sonnet。这两个手段配合退避重试，基本能把 529 的影响压到可接受范围。

3. 排查链路：从确认错误类型到定位过载模式

遇到 529 别急着上重试代码，先把问题定位清楚。我踩过的坑就是：一看到报错就无脑加重试，结果发现根本不是过载，而是别的问题被误判了。下面是我总结的一套排查链路，按顺序走一遍，基本能定位到根因。

3.1 第一步：确认拿到的确实是 529

很多 SDK 会把 HTTP 状态码包装成自定义异常。比如某些封装库会把所有 5xx 统一抛成一个ServerError，异常信息里只有一句 "overloaded"。这时候你要做的第一件事，是把原始响应打出来。

以 Python 为例，如果你用的是官方 SDK，可以这样拿到原始状态码：

import anthropic client = anthropic.Anthropic(api_key="your-key") try: resp = client.messages.create( model="claude-opus-5.5", max_tokens=1024, messages=[{"role": "user", "content": "hello"}] ) except anthropic.APIStatusError as e: # 关键：把 status_code 和 response body 都打出来 print("status_code:", e.status_code) print("response body:", e.response.text)

如果你用的是裸 HTTP 请求，那就更直接了，看response.status_code就行。Node 环境下类似：

try { const resp = await fetch("https://api.anthropic.com/v1/messages", { method: "POST", headers: { "x-api-key": process.env.ANTHROPIC_API_KEY, "anthropic-version": "2023-06-01", "content-type": "application/json" }, body: JSON.stringify({ model: "claude-opus-5.5", max_tokens: 1024, messages: [{ role: "user", content: "hello" }] }) }); if (!resp.ok) { console.log("status:", resp.status); console.log("body:", await resp.text()); } } catch (err) { console.error("network error:", err); }

注意：一定要区分"HTTP 529"和"网络层超时"。前者是服务端明确告诉你过载了，后者可能是连接问题。两者的处理策略完全不同，超时该重试，但重试间隔和退避逻辑要单独设计。

3.2 第二步：判断是持续过载还是偶发抖动

拿到 529 之后，别急着下结论。你需要观察一段时间内的报错分布。我的做法是记录每次请求的时间戳和结果，跑个几十次，看 529 是连续出现还是零星出现。

• 偶发抖动：几十次里偶尔蹦出一两个 529，其他都正常。这种情况用指数退避重试基本能解决，重试一两次就过了。
• 持续过载：连续多个请求都 529，或者 529 的比例超过 30%。这时候重试也没用，因为服务端是真的没容量，你重试多少次都是撞墙。正确做法是降级到 sonnet，或者把任务推迟到低峰期。

判断方法很简单，写个循环跑 20 次，统计一下：

import time import anthropic client = anthropic.Anthropic(api_key="your-key") results = [] for i in range(20): try: client.messages.create( model="claude-opus-5.5", max_tokens=64, messages=[{"role": "user", "content": "ping"}] ) results.append("ok") except anthropic.APIStatusError as e: results.append(f"err-{e.status_code}") time.sleep(1) print(results) print("529 ratio:", results.count("err-529") / len(results))

如果 529 比例很低，说明是抖动，重试能救。如果比例很高，别浪费时间，直接换策略。

3.3 第三步：对比 sonnet 的表现来验证假设

标题里提到 sonnet 同样并发没事，这个对比本身就是最好的诊断工具。你可以在同一时间、同一并发下，分别打 opus 和 sonnet，看两者的报错率差异。如果 sonnet 几乎不报错而 opus 大量报错，那就坐实了"模型规格导致的容量差异"这个结论。

这个对比实验的价值在于：它能帮你排除"是不是我的网络问题""是不是我的账号被限流了"这些干扰因素。因为如果是你的问题，sonnet 也该报错；只有 opus 报错，说明问题在服务端对 opus 的容量分配上。

3.4 第四步：检查是不是自己的并发策略有问题

虽然 529 是服务端过载，但你的并发策略会放大这个问题。如果你一次性开几百个并发打 opus，那服务端不 529 才怪。这时候要反思的是：你的并发数是不是超过了合理范围。

我的经验值是，opus 的并发控制在个位数到十几个比较稳妥，具体取决于你的请求大小和服务端当时的负载。sonnet 可以开到几十甚至上百。这个数字不是固定的，需要你根据实测调整。核心原则是：从低并发开始，逐步往上加，找到开始出现 529 的临界点，然后停在临界点以下。

4. 指数退避重试的完整实现：Python 与 Node 双版本

定位清楚之后，重试代码就是水到渠成的事。但重试不是简单的while True加sleep，里面有很多细节决定了它是"救命稻草"还是"火上浇油"。这一章我把 Python 和 Node 两个版本的完整实现都给你，并且解释每个参数为什么这么设。

4.1 指数退避的核心参数怎么定

指数退避的基本公式是：delay = base * (2 ** attempt) + jitter。这里面有几个参数需要仔细设计：

• base（基础延迟）：第一次重试等多久。设太小没意义，设太大浪费时间。我一般用 1 秒起步。
• max_delay（最大延迟）：退避的上限，防止延迟无限增长。一般设 30 到 60 秒。
• max_retries（最大重试次数）：重试几次就放弃。设太多会拖长整体耗时，设太少又救不回来。我一般设 5 次。
• jitter（抖动）：在计算出的延迟上加一个随机量，避免多个客户端同时重试造成"惊群效应"。这个特别重要，很多人忽略。

为什么 jitter 这么关键？假设你有 100 个客户端同时遇到 529，如果它们都按固定的 1 秒、2 秒、4 秒重试，那它们会在同一时刻再次集中打向服务端，把刚恢复的容量又打满。加了随机抖动之后，重试时间被打散，服务端压力就平滑了。

4.2 Python 版本：带抖动的指数退避

import time import random import anthropic from anthropic import APIStatusError def call_with_backoff( client, model="claude-opus-5.5", max_retries=5, base_delay=1.0, max_delay=60.0, **kwargs ): """ 带指数退避和抖动的调用封装。 只对 529 和 429 重试，其他错误直接抛出。 """ for attempt in range(max_retries + 1): try: return client.messages.create(model=model, **kwargs) except APIStatusError as e: # 只对可重试的状态码做退避 if e.status_code not in (529, 429, 500, 502, 503): raise if attempt == max_retries: raise # 指数退避 + 全抖动 exp_delay = base_delay * (2 ** attempt) capped = min(exp_delay, max_delay) jitter = random.uniform(0, capped) sleep_time = capped + jitter print(f"[retry] status={e.status_code} attempt={attempt+1} " f"sleep={sleep_time:.2f}s") time.sleep(sleep_time) # 使用示例 client = anthropic.Anthropic(api_key="your-key") resp = call_with_backoff( client, max_tokens=1024, messages=[{"role": "user", "content": "写一段自我介绍"}] ) print(resp.content[0].text)

这段代码有几个设计点值得说明。第一，只对特定状态码重试。529、429、500、502、503 这些是服务端问题，重试有意义；400、401、403 这些是客户端问题，重试一万次也没用，直接抛。第二，抖动用的是全抖动（full jitter），即random.uniform(0, capped)，这是业界比较推荐的策略，比固定抖动更能打散重试时间。第三，最后一次重试失败后直接抛异常，不要无限循环，否则你的程序会卡死。

4.3 Node 版本：异步友好的退避实现

const Anthropic = require("@anthropic-ai/sdk"); const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY }); function sleep(ms) { return new Promise((resolve) => setTimeout(resolve, ms)); } async function callWithBackoff({ model = "claude-opus-5.5", maxRetries = 5, baseDelay = 1000, maxDelay = 60000, ...params }) { for (let attempt = 0; attempt <= maxRetries; attempt++) { try { return await client.messages.create({ model, ...params }); } catch (err) { const status = err.status || err.statusCode; const retryable = [529, 429, 500, 502, 503].includes(status); if (!retryable || attempt === maxRetries) { throw err; } const expDelay = baseDelay * Math.pow(2, attempt); const capped = Math.min(expDelay, maxDelay); const jitter = Math.random() * capped; const sleepTime = capped + jitter; console.log( `[retry] status=${status} attempt=${attempt + 1} sleep=${Math.round(sleepTime)}ms` ); await sleep(sleepTime); } } } // 使用示例 (async () => { const resp = await callWithBackoff({ max_tokens: 1024, messages: [{ role: "user", content: "写一段自我介绍" }] }); console.log(resp.content[0].text); })();

Node 版本和 Python 版本逻辑一致，区别在于用Promise和async/await处理异步。这里有个坑要注意：Node 的 SDK 抛出的错误对象里，状态码字段可能是status也可能是statusCode，不同版本不一样，所以代码里做了兼容处理err.status || err.statusCode。这个细节不处理的话，重试逻辑会失效，因为undefined不在可重试列表里，会直接抛出。

4.4 重试策略的进阶优化

基础的指数退避能解决大部分问题，但如果你追求更稳的表现，可以加几个进阶优化。

第一，区分模型设置不同的重试参数。opus 更容易 529，所以它的重试次数可以设多一点，基础延迟也可以设大一点。sonnet 相对稳定，重试参数可以保守一些。这样能避免 sonnet 因为过度重试而浪费配额。

第二，加一个总超时预算。如果重试累计耗时超过某个阈值（比如 5 分钟），就放弃重试，避免单个请求卡太久影响整体流程。实现方式是在循环里记录开始时间，每次重试前检查是否超预算。

第三，结合降级策略。当 opus 重试 N 次仍然失败时，自动降级到 sonnet 完成请求。这个策略特别适合那些"结果质量要求不是极致，但必须拿到结果"的场景。代码上就是在重试耗尽后，把 model 参数换成 sonnet 再试一次。

def call_with_fallback(client, **kwargs): try: return call_with_backoff(client, model="claude-opus-5.5", **kwargs) except APIStatusError as e: if e.status_code == 529: print("[fallback] opus 持续过载，降级到 sonnet") return call_with_backoff(client, model="claude-sonnet-5.5", **kwargs) raise

这个降级逻辑在实际项目里非常实用。我有个批量处理的任务，用 opus 跑的时候经常因为 529 卡住，加了降级之后，整体吞吐量提升了将近一倍，虽然有一部分结果是用 sonnet 生成的，但对最终效果影响很小。

5. 实测中的意外情况与踩坑记录

代码写完了不代表就万事大吉。我在实际跑这套方案的时候，遇到了几个文档里不会写、但真实存在的情况。这一章把这些坑都摊开讲，帮你少走弯路。

5.1 重试反而加剧了过载

这是最反直觉的一个坑。我一开始给所有请求都加了激进的重试，结果发现 529 的比例不降反升。原因很简单：当服务端已经过载时，大量客户端同时重试，等于给已经满负荷的服务端又加了一波流量。这就是所谓的"重试风暴"。

解决办法有两个。一是加抖动，这个前面讲过了，能把重试时间打散。二是加熔断，当连续多次重试都失败时，暂停一段时间不再发请求，给服务端喘息的机会。熔断的实现可以用一个简单的计数器：连续失败超过阈值就 sleep 一个较长的时间（比如 30 秒），然后再恢复。

class CircuitBreaker: def __init__(self, threshold=5, cooldown=30): self.failures = 0 self.threshold = threshold self.cooldown = cooldown def record_failure(self): self.failures += 1 if self.failures >= self.threshold: print(f"[breaker] 连续失败 {self.failures} 次，冷却 {self.cooldown}s") time.sleep(self.cooldown) self.failures = 0 def record_success(self): self.failures = 0

5.2 流式请求的重试更麻烦

如果你用的是流式输出（streaming），重试会复杂很多。因为流式请求一旦开始返回数据，中途断了，你没法简单地"重试"——已经输出的部分怎么办？重新来一遍会导致内容重复。

我的处理方式是：流式请求只在"连接建立阶段"重试。也就是说，如果请求还没开始返回任何数据就 529 了，可以重试；如果已经开始返回数据了才断，那就记录断点，下次从断点续传（如果业务允许），或者直接放弃这一条。这个逻辑需要在代码里显式判断，不能无脑套用非流式的重试封装。

5.3 并发控制比重试更重要

踩了几次坑之后我才意识到，与其在失败后拼命重试，不如在源头控制好并发。用一个信号量（semaphore）限制同时进行的请求数，让请求平滑地流向服务端，比事后补救有效得多。

Python 里可以用asyncio.Semaphore：

import asyncio sem = asyncio.Semaphore(5) # 最多 5 个并发 async def limited_call(client, **kwargs): async with sem: return await call_with_backoff_async(client, **kwargs)

Node 里可以用p-limit这类库，或者自己实现一个简单的队列。控制好并发之后，你会发现 529 的出现频率明显下降，因为服务端不再被你的突发流量打爆。

5.4 日志要打全，否则排查无从下手

最后一个坑是关于日志的。我一开始只记录了"失败了"，没记录状态码、重试次数、耗时这些信息，结果出问题的时候完全不知道是哪种失败、重试了几次。后来我把日志补全，才发现有一批请求是因为超时而不是 529 失败的，处理策略完全不同。

建议的日志字段包括：请求 ID、模型名、状态码、重试次数、每次重试的等待时间、总耗时。这些信息在排查问题时价值极高，尤其是当你要判断"是服务端问题还是自己的问题"时。

6. 从单点重试到系统性稳定性设计

把重试代码写对只是第一步。如果你的系统里有大量 opus 调用，光靠单点重试是不够的，需要从系统层面做稳定性设计。这一章聊聊我在这方面的实践。

6.1 请求分级：哪些必须用 opus，哪些可以降级

不是所有请求都值得用 opus。我的做法是把请求分成三档：

• 关键档：结果质量直接影响业务，必须用 opus，且必须成功。这类请求配最完整的重试和降级兜底。
• 重要档：希望用 opus，但 sonnet 也能接受。这类请求配重试，重试失败后自动降级。
• 普通档：用 sonnet 就够，或者对质量要求不高。这类请求直接用 sonnet，避开 opus 的过载风险。

这个分级能显著降低 opus 的调用量，从而降低撞上 529 的概率。很多团队一上来所有请求都用 opus，其实是一种资源浪费，也把自己推向了过载的高风险区。

6.2 队列化：把同步调用改成异步任务

如果你的场景允许异步处理（比如批量生成、离线分析），把请求放进队列，由消费者按可控速率处理，是比同步重试更稳的方案。队列的好处是：你可以精确控制消费速率，让请求平滑地流向服务端，而不是一股脑全打出去。

实现上可以用 Redis 做队列，或者用现成的任务队列框架。核心是消费者端的并发控制，配合前面讲的退避重试，基本能做到"过载时自动减速，恢复时自动加速"。

6.3 监控与告警：让问题在爆发前被发现

529 的监控不能只看"有没有报错"，还要看趋势。我建议监控这几个指标：

• 529 比例：单位时间内的 529 请求占总请求的比例。超过 10% 就该关注了。
• 重试成功率：重试后成功的比例。如果这个比例很低，说明服务端是真的持续过载，重试策略需要调整。
• P99 延迟：延迟的尾部指标。529 之前往往伴随延迟上升，这是过载的前兆。
• 降级触发次数：降级到 sonnet 的次数。这个数字上升说明 opus 的可用性在下降。

把这些指标接到监控面板上，设置合理的告警阈值，你就能在问题影响用户之前介入处理。

6.4 一个真实的优化案例

最后分享一个我实际做过的优化。有个批量处理任务，每天要跑几千次 opus 调用，之前经常因为 529 卡住，整体耗时不稳定。我做了三件事：一是把并发从 50 降到 10，二是加了带抖动的指数退避重试，三是把非关键请求降级到 sonnet。

结果：529 的出现频率下降了约 70%，整体任务耗时从平均 40 分钟降到 25 分钟，而且波动明显变小。最关键的是，任务不再因为过载而整体失败，稳定性大幅提升。这个案例说明，解决 529 问题不是靠某一个技巧，而是靠并发控制、重试策略、请求分级这几件事的组合。

提示：优化之前一定要先测量基线。没有基线数据，你根本不知道优化有没有效果。我习惯在优化前跑一周的监控，记录各项指标，优化后再跑一周对比，这样才有说服力。

这套方案不是银弹，服务端的容量波动你控制不了，但你能控制的是自己的请求行为。把请求发得更聪明、更有节奏，就能在服务端过载的大环境下，依然保持自己系统的稳定运行。