判断时关注的线索

客户指出具体时段与失败比例，而不是只说"不好用"
失败带有可读的 HTTP 状态码或错误码，可用于分层
上游状态、自身路由配置与客户端重试记录三者尚未对齐

“晚高峰老是失败，你们这条线路是不是有点问题？”

这句话出现在一个 AI API 中转商的客户群里。看到它的人通常有两种本能反应：先道歉，然后连夜去调路由权重；或者先反问，问到最后客户觉得你在推卸责任。

两种反应共用一个前提，就是都假设自己已经知道”不稳”指的是什么。在下面这个合成场景里，这个前提恰恰是错的。

先说结论：一句”不稳”至少要拆成三件事分别取证：上游返回了什么状态码、你自己的路由与 Key 是怎么配的、客户端有没有在做不带退避的重试。这三件事的取证顺序不能颠倒，因为最容易被误判成上游故障的那一类，来源正好在客户端。

NOTICE：本文中的客户、群组、消息与用量数据均为合成示意，用于演示判断顺序，不代表真实客户、真实故障、合同或成交结果。

一句”不稳”，其实没说明失败发生在哪一层

把上面那句话逐字读一遍，能提取到的事实只有两个：时段是晚高峰，现象是”失败”。至于是哪一层的失败、失败的比例多少、报错长什么样，一个都没有。

客户并没有说不清。只是”稳不稳”这个词本来就从使用感受里长出来，它描述的是结果，不描述原因。往下至少还有三层可能：

上游确实在抖动或过载；你自己的路由、权重或 Key 复用出了配置问题；客户端的重试逻辑把一次正常限流放大成了一场雪崩。这三层可以同时存在，但在任何一次具体故障里，总要有一个是主因。找出主因这件事通常叫归因，它决定了你接下来该动什么，也决定了更关键的一件事：该不该由你来动。

把它拆成能对表的字段

归因的第一步其实是换算，把不可核对的说法换成可核对的字段。下面四个字段在一小时内基本都能拿到，而且不需要客户配合太多：

失败发生在哪个时间窗，具体到分钟
失败请求返回的 HTTP 状态码分布，比如 429 和 503 各占多少
返回体里的错误码与错误类型字符串
同一时间窗内你这边看到的请求总量曲线

其中第三条最容易被跳过。很多人只看状态码，看到 429 就认定是限流，看到 503 就认定是上游挂了。这个判断方式在大部分情况下没错，但会漏掉一类关键情况，而这一类恰好是这行的日常。

429 和 503 指向两个完全不同的方向

按 OpenAI 官方文档的口径，两类错误需要分开处理：

429 配 rate_limit_error 类型，表示触到了速率限制。503 配 service_unavailable_error 类型，表示被请求的模型正处于临时过载状态。前者是额度问题，后者是容量问题。前者你需要调整自己的发请求节奏，后者你能做的事情非常有限，只能按 Retry-After 退避重试，或者切到别的线路。

这一条对归因的意义在于：503 加模型过载，是少数可以直接把责任落到上游的信号。如果你在故障时间窗里看到的主要是 503 而不是 429，那么”线路不稳”这个说法方向大致没错，接下来要谈的是备用线路和降级策略。

反过来，如果时间窗里几乎全是 429，方向就要反过来了。因为 429 有一个很少被认真读过的细分。

slow_down：客户的增速，不是上游的故障

同一份文档里还有一段话，值得逐字看：

A slow_down error can occur even when your traffic is within its requests-per-minute and tokens-per-minute limits. It reflects how quickly traffic increased, not whether you exhausted those limits.

翻译过来是：即使你的流量还在每分钟请求数和每分钟 Token 数的额度之内，也可能收到 slow_down。它反映的是流量增长的速度，而不是你有没有把这些额度用完。

官方给的经验值是：当流量达到每分钟 100 万输入 Token 之后，每 15 分钟的增幅不应超过 50%。超过这个斜率，就会开始收到 slow_down。

这句话几乎改写了对 429 的默认理解。你在晚高峰看到的 429，很可能不是因为谁的额度用完了，而是因为请求量的增长速度超过了上游允许的爬坡斜率。而爬坡速度由发请求的那一方决定，也就是你的客户，或者客户自己写的那段重试代码。

到这里，归因的对象就从”上游稳不稳”变成了”谁在什么斜率上发请求”。

重试放大器：为什么”再发一次”会让事情更糟

接下来这一条，把责任基本锁死在客户端侧。

Azure OpenAI 的配额文档里有一句警告，原文是：Unsuccessful requests still count toward your per-minute rate limit. Continuously resending a request without backing off makes throttling worse.

失败的请求同样计入每分钟限额。不做退避就连续重发，只会让限流更严重。

这句话背后是一个很常见的实现缺陷。一个客户端在收到 429 之后立即重试，重试又失败，再立即重试。如果它同时开着并发，那么每一次失败都会乘以并发数，变成一次自我放大的请求洪峰。你这边看到的现象是”失败率突然升高”，上游看到的是”这个 Key 的请求量在几秒内翻了几倍”，而真正的原因在客户那段没有退避的重试循环里。

判断这件事不需要猜。看你自己的请求量曲线：**如果失败请求数和总请求数在同一个时间窗里一起陡增，而且总请求数的涨幅明显超过正常业务波动，那么重试放大几乎可以确定存在。**正常的额度耗尽是一条平缓爬上去的线，重试放大是一根竖起来的针。

顺带说一个可以立刻建议客户改的地方：多数官方 SDK 自带的重试是带指数退避和抖动的，默认次数通常是 2 次左右。如果客户自己包了一层”失败就立刻再来”的逻辑，反而会把 SDK 的保护覆盖掉。

最常被略过的一层：路由配置与 Key 复用

排除了上游过载和重试放大之后，剩下的问题通常出在自己这边，而且集中在一个地方：多个客户或者多个业务线共用同一个上游 Key。

限流额度是挂在 Key 上的，不是挂在客户身上的。一旦两个客户的流量走的是同一个 Key，你等于把两边的额度、两边的失败重试、两边的业务峰值绑在了一起。A 客户在晚高峰跑批量任务，B 客户在同一时间做实时对话，B 感受到的就是”线路不稳”。

这一层的取证方式也很直接：把故障时间窗内的请求，按上游 Key 分组看曲线。如果某个 Key 的用量等于几条业务线用量之和，那么这一层就是主因。此时该动的是 Key 的隔离粒度。

一次只改一个变量

归因做到这里，手上的证据已经足够形成假设了。接下来的动作有一个硬约束：一次只改一个变量。

同时调路由权重、同时扩容、同时让客户改重试逻辑，是这行最贵的坏习惯。因为一旦指标好转，你并不能知道是哪一项起了作用；一旦继续恶化，你也不知道该回滚哪一项，而客户的耐心正在按小时消耗。

一个更稳妥的顺序是：先让客户停掉不带退避的重试，观察一个时间窗；再处理 Key 隔离；最后才动上游线路。这个顺序的代价是慢，收益是每一次动作都能被验证，而验证过的动作才可复用。

这套分诊法不成立的三种场合

前文所有判断都建立在一个前提上：你拿得到分层的证据。以下几种情况里，这套方法会失效，需要换成别的做法。

第一种，客户只愿意给一句”不好用”，既不提供时段也不提供失败样本。此时没有字段可以拆，只能先做一轮最小复现，不能凭印象承诺。

第二种，上游把错误码做成统一的 500 或者自研的错误体，状态码不再指向明确含义。这种情况下”看状态码分层”这一步直接失效，只能靠请求曲线和上游的公开状态页交叉判断。

第三种，故障窗口太短。几分钟的抖动往往在数据聚合粒度之下，抓不到曲线，只能靠日志里零散的样本判断趋势。这时候做结论是有风险的，把它记成待观察通常比强行归因更诚实。

另外需要说明边界：本文只处理”责任在哪一层”这一个问题，不涉及怎么设计高可用架构，也不涉及是否该换供应商。前者在站内已经有专门的文章讨论，后者是商务决策，不该由一次故障的归因结果直接推出。

延伸阅读

研究与定义

值得关注的潜在线索 Signal 是怎样被发现的

了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。

查看方法论与核心定义

"你们线路不稳"：先分清是上游抖动、自己的配置，还是客户把 429 放大了