1. 503 和 429 到底差在哪先把方向搞对再动手很多人一看到接口报错第一反应就是服务挂了然后开始疯狂重试、换节点、重启客户端折腾半天发现根本没用。问题出在哪出在没搞清楚503 和 429 是两种完全不同性质的错误排查方向南辕北辙。我先把这两个状态码的本质讲清楚这是后面所有排查动作的基础。429 Too Many Requests翻译过来就是请求太多了。它的核心含义是服务端本身是健康的、能正常处理请求的只是你在某个时间窗口内发过来的请求数量超过了它给你分配的配额。换句话说429 是你太快了责任在调用方。触发 429 的典型场景包括单位时间内 QPS 超限、并发数超限、Token 消耗速率超限、免费额度用尽等。503 Service Unavailable翻译过来是服务不可用。它的核心含义是服务端当前无法处理这个请求但这个无法处理的原因非常多样——可能是后端某个依赖挂了、可能是模型实例正在扩容还没就绪、可能是网关到推理集群的路由暂时断了、也可能是整个区域正在做灰度发布。注意503 并不等于服务彻底死了它更多是一种临时性的、可恢复的不可用状态。这两者的区别用生活化的类比来说429 就像你去一家餐厅吃饭餐厅正常营业但今天排队的人太多了服务员告诉你稍等一会儿再来。你等几分钟再来大概率就能进去。503 就像你走到餐厅门口发现卷帘门拉下来了门口贴了张纸写着设备维护中。这时候你在门口反复敲门是没用的得等它维护完或者换一家餐厅。所以排查逻辑完全不一样维度429 Too Many Requests503 Service Unavailable责任方调用方你请求太频繁服务方后端暂时不可用是否可立即重试可以但要退避等待可以但需要更长间隔核心排查方向限流配额、并发控制、请求频率服务健康状态、依赖链路、区域可用性典型解决手段降频、加退避、申请提额切换区域、等待恢复、降级到备用模型重试是否有用有用配合退避策略短期重试基本无效需拉长间隔我见过太多人把 503 当成 429 来处理写了个指数退避的重试逻辑结果 503 持续了十几分钟重试了几百次全部失败白白浪费了配额和日志空间。方向错了努力全白费。还有一个容易被忽略的点503 有时候会伪装成 429。什么意思当后端集群整体过载时网关层可能会先返回 503但如果你的客户端做了自动重试重试请求又打到了另一个已经限流的节点上你就会在日志里同时看到 503 和 429 交替出现。这时候不要慌先看第一个错误是什么那才是根因。理解了这层区别接下来的排查才有意义。下面我按先确认现象、再定位根因、最后给方案的顺序把整个链路拆开讲。2. 拿到 503 之后我通常按这个顺序排查排查 503 最忌讳的就是一上来就改代码。正确的做法是先分层定位把问题缩小到某一个环节再针对性处理。我一般按下面这个顺序走基本能在十分钟内定位到大致方向。2.1 第一步确认是全局 503 还是局部 503先做一件事换一个最简单的请求测一下。不要用你那个复杂的业务请求就用最基础的对话接口发一句你好。如果简单请求也 503说明是服务端整体或区域级问题你这边做什么都没用只能等或者切区域。如果简单请求正常只有你的业务请求 503说明是你的请求特征触发了某种保护机制比如请求体过大、包含敏感内容、触发了风控等。这一步能帮你快速排除掉一半的可能性。我遇到过好几次客户信誓旦旦说接口全挂了结果我一测基础接口好好的最后发现是他的请求里带了一个超长的 system prompt触发了长度限制相关的保护逻辑。2.2 第二步看返回体里的细节字段503 的响应体里通常不是空的会带一些关键信息。你要重点看这几个字段error.type是service_unavailable还是overloaded还是internal_error不同 type 对应不同根因。error.code有些平台会给出更细的错误码比如model_not_ready、capacity_exceeded。request_id这个一定要记下来后面找技术支持或者查日志全靠它。retry_after如果响应头里有这个字段说明服务端明确告诉你等 X 秒后再来这时候你按它说的等就行别自作聪明。我踩过的一个坑有一次 503 响应体里明明写了retry_after: 30但我的重试逻辑是固定 1 秒重试一次结果 30 秒内重试了 30 次全部失败还把日志刷爆了。服务端给了 retry_after 就一定要尊重它这是最省事的做法。2.3 第三步区分是模型未就绪还是集群过载这两种 503 的处理方式完全不同模型未就绪型 503通常发生在你调用一个刚上线的新模型、或者某个模型正在做版本切换的时候。特征是错误信息里会提到模型名称、版本号或者提示model is loading。这种 503 是暂时性的等几分钟就好重试间隔可以设短一点比如 5-10 秒。集群过载型 503特征是错误信息里提到overloaded、capacity、rate limit之类的词或者干脆什么都不说就是一个裸的 503。这种是区域性的可能持续几分钟到几十分钟重试间隔要拉长比如 30 秒起步并且要考虑降级方案。怎么区分看错误信息的措辞以及503 的持续时间。如果 503 只持续了几十秒就恢复大概率是模型未就绪如果持续了好几分钟还在 503那就是集群过载别死磕了赶紧上降级。2.4 第四步检查自己的请求是否异常有时候 503 不是服务端的问题而是你的请求本身有问题被服务端的保护机制拦截了。常见的异常请求特征包括请求体过大比如你塞了几万字的上下文超过了模型的最大输入长度。并发过高你同时开了几十个线程在打同一个接口触发了并发保护。请求频率突变平时 QPS 是 1突然飙到 100触发了流量清洗。参数不合法比如 temperature 设成了 5.0正常范围 0-2或者 max_tokens 设成了负数。这些情况服务端可能不会返回 400而是直接给你一个 503让你误以为是服务挂了。排查时一定要把自己的请求参数打印出来看一眼这个动作花不了 10 秒但能省下大量瞎折腾的时间。2.5 第五步确认网络链路是否正常如果前面几步都排除了那就要看网络链路了。这里不是让你去搞什么特殊网络手段而是检查基础的连通性用curl或ping测一下接口域名的可达性。检查是否有本地代理、防火墙规则拦截了请求。如果你用的是某个客户端工具比如某些代码助手检查它的配置文件里 endpoint 是否写对了。我遇到过好几次用户说接口 503 了结果一查是他本地配了个代理代理转发的时候把请求搞坏了。先把链路理干净再谈服务端问题。把这五步走完你基本就能确定 503 的根因了。接下来就是针对性的重试配置和降级方案。3. 重试配置怎么写才不帮倒忙重试是个双刃剑。配得好能自动扛过短暂的 503配得不好会把一次小抖动放大成一场雪崩。我见过最离谱的重试配置是固定间隔 100ms无限重试。结果服务端 503 了 5 分钟客户端发了 3000 个请求全部失败还把本地的连接池耗尽了。下面我讲一下针对 503 的重试配置应该怎么设计。3.1 指数退避是基础但参数要调对指数退避Exponential Backoff是重试的标准做法核心公式是等待时间 base_delay * (2 ^ retry_count) random_jitter针对 503我推荐的参数是base_delay1 秒不要用 100ms503 不是瞬时抖动max_delay60 秒封顶避免等待时间无限增长max_retries5 次超过 5 次还没成功说明不是短暂问题该降级了jitter0 到 base_delay 之间的随机值避免多个客户端同时重试造成惊群这样算下来5 次重试的总等待时间大约是 1 2 4 8 16 31 秒加上随机抖动大概在 30-45 秒之间。这个时间窗口足够扛过大部分短暂的 503 了。如果你用的是 Python可以直接用tenacity库配置起来很清爽from tenacity import retry, stop_after_attempt, wait_exponential_jitter, retry_if_exception_type class ServiceUnavailableError(Exception): pass retry( stopstop_after_attempt(5), waitwait_exponential_jitter(initial1, max60, jitter1), retryretry_if_exception_type(ServiceUnavailableError), reraiseTrue ) def call_qwen_api(payload): response client.chat.completions.create(**payload) return response注意retry_if_exception_type这里只对 503 相关的异常重试不要对所有异常都重试。像 400参数错误、401鉴权失败这种重试一万次也没用只会浪费资源。3.2 尊重 retry_after别自作聪明如果响应头或响应体里带了retry_after一定要优先用它。很多 SDK 已经内置了这个逻辑但如果你是自己手写 HTTP 请求就要手动处理import time import requests def call_with_retry_after(url, payload, max_retries5): for attempt in range(max_retries): resp requests.post(url, jsonpayload) if resp.status_code 503: retry_after resp.headers.get(Retry-After) if retry_after: wait int(retry_after) else: wait min(2 ** attempt, 60) time.sleep(wait) continue return resp raise Exception(Max retries exceeded)这个逻辑的关键点是服务端说等多久就等多久。它比你拍脑袋算出来的退避时间更准确因为它知道后端什么时候能恢复。3.3 重试要加熔断别无限打光有重试还不够必须配一个熔断器Circuit Breaker。逻辑是如果连续 N 次重试都失败就暂时停止请求等一段时间后再试探性地放一个请求过去成功了再恢复。为什么要加熔断因为如果服务端真的挂了你的重试只会让情况更糟——你的请求会堆积在连接池里占用本地资源还可能触发服务端更严格的限流。一个简单的熔断实现思路class CircuitBreaker: def __init__(self, failure_threshold5, recovery_timeout60): self.failure_count 0 self.failure_threshold failure_threshold self.recovery_timeout recovery_timeout self.last_failure_time None self.state closed # closed / open / half-open def call(self, func, *args, **kwargs): if self.state open: if time.time() - self.last_failure_time self.recovery_timeout: self.state half-open else: raise Exception(Circuit is open, request rejected) try: result func(*args, **kwargs) if self.state half-open: self.state closed self.failure_count 0 return result except ServiceUnavailableError: self.failure_count 1 self.last_failure_time time.time() if self.failure_count self.failure_threshold: self.state open raise这个熔断器的参数5 次失败、60 秒恢复是我实测下来比较稳的配置。你可以根据自己的业务容忍度调整但failure_threshold 不要设得太高否则熔断形同虚设。3.4 重试日志要打全方便事后复盘重试的时候一定要打日志而且要打全。我建议至少记录这几个字段第几次重试本次等待时间错误类型和错误信息request_id时间戳import logging logger logging.getLogger(__name__) def log_retry(attempt, wait, error, request_id): logger.warning( fRetry attempt {attempt}, waiting {wait}s, ferror{error}, request_id{request_id} )别小看这个日志出问题的时候它就是你的黑匣子。我有一次排查一个偶发的 503就是靠日志发现每次 503 都发生在整点附近最后定位到是服务端的定时任务导致的短暂抖动。4. 降级方案503 扛不住的时候怎么办重试能解决的是短暂 503但如果 503 持续了十几分钟甚至更久重试就没意义了这时候必须上降级方案。降级的核心思路是在主模型不可用时用备用方案保证业务不中断。4.1 降级到备用模型最直接的降级方式就是切换到另一个可用的模型。比如你主用的是 Qwen3 旗舰版503 了之后可以降级到 Qwen3 的其他规格版本或者切换到其他厂商的同类模型。这里的关键是提前准备好备用模型的调用封装不要等到 503 了才临时去写代码。我一般会做一个模型路由层class ModelRouter: def __init__(self, primary_client, fallback_clients): self.primary primary_client self.fallbacks fallback_clients def chat(self, payload): try: return self.primary.chat(payload) except ServiceUnavailableError: for fallback in self.fallbacks: try: return fallback.chat(payload) except Exception: continue raise Exception(All models unavailable)这个路由层的逻辑是先打主模型503 了就依次尝试备用模型全挂了才报错。备用模型的选择要考虑能力匹配度别主模型是旗舰版备用模型是个小规格版本输出质量差太多用户一眼就能看出来。4.2 降级到缓存或静态响应如果连备用模型都不可用那就只能降级到更笨的方案了缓存命中如果这个请求之前问过直接返回缓存的结果。静态兜底返回一个预设的友好提示比如当前服务繁忙请稍后再试。排队机制把请求放进队列等主模型恢复了再处理。这几种方案都会损失实时性但至少能保证业务不中断。具体用哪种取决于你的业务场景。如果是客服机器人静态兜底就够了如果是内容生成可能排队机制更合适。4.3 降级要能自动恢复降级不是一降到底要能自动探测主模型是否恢复。我一般会用一个后台任务每隔 30 秒给主模型发一个轻量级的探测请求比如就发一个ping成功了就切回主模型。import threading import time def health_check(router, interval30): while True: try: router.primary.chat({messages: [{role: user, content: ping}]}) router.switch_to_primary() except Exception: pass time.sleep(interval)这个探测请求要足够轻量别用复杂的业务请求去探测否则探测本身就会消耗配额。4.4 降级策略要可配置最后一点降级策略不要写死在代码里要做成可配置的。因为不同时期、不同业务线对降级的容忍度不一样。比如大促期间你可能希望降级更激进一点保证可用性平时你可能希望降级更保守一点保证输出质量。我一般会用一个配置文件来管理降级策略fallback: enabled: true primary_model: qwen3-flagship fallback_models: - qwen3-standard - qwen3-lite cache_enabled: true cache_ttl: 3600 static_response: 当前服务繁忙请稍后再试 health_check_interval: 30这样改策略的时候不用动代码改配置重启就行运维成本低很多。5. 几个我踩过的坑和实测经验前面讲的都是方法论这一节我分享几个实际踩过的坑都是文档里不会写的。5.1 别把 503 和 429 的重试逻辑混用我一开始图省事503 和 429 用了同一套重试逻辑结果发现 429 恢复得很快通常几秒但 503 恢复得慢可能几分钟。用同一套逻辑的后果是429 场景下重试太慢浪费了恢复窗口503 场景下重试太快白白消耗配额。后来我改成了按错误类型区分重试策略错误类型base_delaymax_retries是否熔断4290.5 秒10 次否5032 秒5 次是这个配置是我实测下来比较平衡的你可以根据自己的业务特点微调。5.2 并发控制比重试更重要很多人只关注重试忽略了并发控制。实际上大部分 503 和 429 都是并发过高引起的。如果你能把并发控制在合理范围内很多错误根本不会发生。我一般会用信号量Semaphore来限制并发import threading semaphore threading.Semaphore(10) # 最多 10 个并发 def call_api(payload): with semaphore: return client.chat(payload)这个并发数怎么定我的经验是从 5 开始试逐步往上加直到出现 429 或 503然后回退到上一个稳定值。别一上来就设 100那是给自己找麻烦。5.3 请求 ID 一定要记下来每次请求的 request_id 都要记下来出问题的时候这是你唯一的身份证。我见过太多人排查问题的时候连自己请求的 request_id 都拿不出来只能干瞪眼。建议在日志里把 request_id 和业务 ID 关联起来这样出问题的时候能快速定位到是哪个业务请求出了问题。5.4 别在客户端做太多聪明的事有些客户端会做自动重试、自动切换、自动降级看起来很智能但实际上很容易出问题。比如自动切换的时候如果切换逻辑有 bug可能会在两个模型之间反复横跳造成更大的混乱。我的建议是客户端只做最基础的重试复杂的降级逻辑放在服务端或者网关层。这样出问题的时候好排查也好统一管理。5.5 监控和告警要跟上最后一点503 和 429 都要有监控和告警。我一般会监控这几个指标503 错误率超过 1% 告警429 错误率超过 5% 告警平均重试次数超过 3 次告警熔断器状态打开时告警这些指标能帮你在问题扩大之前就发现苗头。我有一次就是靠 503 错误率的告警提前发现了一个区域性的服务抖动及时切了区域避免了一次线上事故。6. 一套可以直接抄的完整配置讲了这么多最后给一套可以直接用的完整配置。这套配置是我在多个项目里验证过的覆盖了重试、熔断、降级、监控四个环节。import time import random import logging import threading from tenacity import retry, stop_after_attempt, wait_exponential_jitter, retry_if_exception_type logger logging.getLogger(__name__) class ServiceUnavailableError(Exception): pass class RateLimitError(Exception): pass class CircuitBreaker: def __init__(self, failure_threshold5, recovery_timeout60): self.failure_count 0 self.failure_threshold failure_threshold self.recovery_timeout recovery_timeout self.last_failure_time None self.state closed self.lock threading.Lock() def allow_request(self): with self.lock: if self.state open: if time.time() - self.last_failure_time self.recovery_timeout: self.state half-open return True return False return True def record_success(self): with self.lock: self.failure_count 0 self.state closed def record_failure(self): with self.lock: self.failure_count 1 self.last_failure_time time.time() if self.failure_count self.failure_threshold: self.state open class ResilientClient: def __init__(self, primary, fallbacks, max_concurrency10): self.primary primary self.fallbacks fallbacks self.semaphore threading.Semaphore(max_concurrency) self.breaker CircuitBreaker() def chat(self, payload): if not self.breaker.allow_request(): return self._fallback(payload) with self.semaphore: try: result self._call_with_retry(self.primary, payload) self.breaker.record_success() return result except ServiceUnavailableError: self.breaker.record_failure() return self._fallback(payload) retry( stopstop_after_attempt(5), waitwait_exponential_jitter(initial2, max60, jitter1), retryretry_if_exception_type(ServiceUnavailableError), reraiseTrue ) def _call_with_retry(self, client, payload): return client.chat(payload) def _fallback(self, payload): for fallback in self.fallbacks: try: return fallback.chat(payload) except Exception as e: logger.warning(fFallback failed: {e}) continue raise Exception(All models unavailable)这套配置的核心逻辑是信号量控并发 → 熔断器控失败率 → 指数退避重试 → 备用模型降级。四层防护叠加基本能扛住大部分 503 场景。用的时候把primary和fallbacks换成你自己的客户端实例就行。并发数max_concurrency根据你的配额调整一般从 10 开始试。我在实际使用中发现这套配置最大的价值不是能扛住 503而是让 503 变得可观测、可控制。以前 503 来了就是一团乱麻现在至少知道问题出在哪一层该调哪个参数。这比单纯追求不报错重要得多。