529 Overloaded 到底意味着什么
它说的是上游此刻容量紧张，不是你的请求有问题。改代码没用，改重试策略才有用。
四个要点
上游拥塞
服务端整体容量紧张时返回，与你的密钥额度、参数、请求体都无关。
你被限流了
这个才是「你超了自己的速率或额度」。529 和 429 的处理方式完全不同，别用同一套逻辑。
唯一有效的客户端应对
指数退避 + 抖动。立刻重试只会加重拥塞，并让你更快撞上限流。
结构性缓解
同一任务能落到不同上游时，单点拥塞才不至于变成停工。代价是要接受模型差异。
529 和 429、503 有什么不同
529 表示服务端此刻整体过载，属于容量问题，通常是暂时的；429 表示你触碰了自己的速率或额度上限，是配额问题；503 一般指服务不可用或正在维护。三者都不代表你的请求写错了，但处理方式不同：529 应当退避重试，429 应当降速或提额，503 应当等待并关注服务状态页。把它们混在一个 catch 分支里，是最常见的错误处理写法。
为什么最近讨论变多
每当有新模型发布或大规模迁移发生，上游容量都会出现阶段性紧张，529 的讨论随之升温。这类波动通常随容量扩充而缓解，但对正在赶工的人来说，等厂商扩容不是可用的答案。
排查顺序
确认状态码确实是 529 而不是 429。两者的响应体不同，日志里要分开统计。
查厂商状态页。若是大范围事件，客户端再怎么改都只是缓解。
检查自己的重试逻辑是否在放大拥塞：无抖动、无上限、失败即刻重试都属于放大。
先别急着重试，先分清楚是哪个码
可以确认的
529 表示上游容量拥塞、与请求内容无关，这是厂商文档中明确的语义。指数退避加抖动是被广泛验证的客户端应对方式。
不要当事实
「529 是厂商在悄悄限制重度用户」这类说法没有证据支持，本页不做断言。529 与 429 的语义区分是公开文档写明的，把两者混为一谈会让你选错处理方式。
两种应对
只在客户端做退避
实现成本低，能显著降低失败率。但上游持续拥塞时，你能做的只有等。
让任务能落到多个上游
单点拥塞不再等于停工。代价是要接受不同模型的习性差异，且任何一路都可能有自己的故障形态。
正确的重试写法
要点有三条。第一，指数退避而不是固定间隔：首次等 1 秒，之后逐次翻倍。第二，加随机抖动：所有客户端同时退避同一时长，会造成同步的重试洪峰，反而延长拥塞。第三，设上限：重试次数和总等待时长都要封顶，否则一次拥塞会让你的任务队列无限堆积。另外，流式请求在中途断开时不要盲目从头重试，先判断已收到的内容是否可续。
QCode 能接住什么、接不住什么
能接住的：同一把密钥可以在拥塞时切到别的模型家族继续干活，不必等单一上游恢复。接不住的：我们不是厂商，改不了上游的容量。而且必须说清楚 —— 我们自己也有失败请求：过去 7 天我方观测到的失败形态主要是 502（网关侧），529 为 0 条。把「不会出问题」当卖点的服务，通常只是没有公开自己的失败数据。我们能提供的是多路可选和可查的失败记录，而不是一份不出故障的承诺。
常见问题
收到 529 要改我的请求参数吗？
不用。529 与请求内容无关，改 max_tokens、换模型参数、精简 prompt 都不会让它消失。要改的是重试策略。
529 和 429 我可以用同一套重试逻辑吗？
不建议。529 应当退避后重试同一请求；429 意味着你需要降低发送速率或提高额度，盲目重试只会持续触发限流。
退避多久合适？
常见做法是首次 1 秒、逐次翻倍，叠加随机抖动，并对重试次数与总等待时长设上限。具体数值取决于你的任务能容忍多长延迟。
流式请求中途 529 了怎么办？
先看已经收到的内容是否可用。能续写就续，不能续再整体重试。盲目从头重试会重复计费，也会加重拥塞。
QCode 会遇到 529 吗？
上游拥塞是客观存在的，我们无法免疫。实际观测中我方过去 7 天的失败以 502 为主、529 为 0；我们能做的是让同一任务可以切到别的模型家族，而不是承诺不出错。
多路可用性是不是就没有单点故障了？
不是。多路降低的是「一路挂了就停工」的概率，但每一路都有自己的故障形态，路由层本身也可能出问题。它是缓解，不是消除。
信息来源
状态码语义以厂商官方 API 文档为准。本页不引用具体的第三方可用性百分比 —— 这类数字随时间波动，且我们没有权威的第三方测量来源。
相关阅读
本页的状态码语义以各厂商官方文档为准，可能随版本调整。页内提到的我方失败率观测来自自有日志的特定时间窗口，不构成可用性承诺。