大模型 API 限流（429）与宕机复盘：多厂商容灾架构、重试退避与真实故障成本

2025 年 3 月 14 日，某金融科技公司的客服机器人突然全站不可用 47 分钟，4.2 万日活用户受到影响。事后复盘（johal 的 Azure OpenAI 故障复盘）显示：当时 p99 延迟飙到 12.4 秒，89% 的对话请求直接返回 429 限流错误。他们当时用 LangChain 0.3 的默认重试逻辑——失败后只重试一次，结果反而把更多并发请求砸向已经过载的端点。这次故障的代价是：月度 SLA 罚没约 4.7 万美元，7 天用户流失率 18%。

修复方式很朴素：关掉默认重试（maxRetries 设 0），换成带抖动的指数退避（最多 5 次、1 秒基准、500 毫秒抖动），再加一个连续 5 次 429 就熔断的断路器，以及一道提前校验配额的反向代理。改完之后，429 失败率从 89% 掉到 0.7%，p99 降到 2.1 秒，月度 SLA 罚没降到 1200 美元，流失率降到 2.1%。一次架构层面的最小改动，每月直接省下 4.5 万美元。下面把这件事拆开，看清"限流/宕机"到底是怎么把钱烧掉的。

一、为什么"同一厂商重试"在容量事件里会越重试越糟

重试之所以能救命，前提假设是：每次失败相互独立。如果单次失败率 0.5%，重试 3 次，独立假设下复合失败概率是 0.005 的三次方 ≈ 八百万分之一，几乎不可能。但容量事件里的失败是"相关"的：你的每一次重试都打在同一个已经饱和的队列上，重试成功的条件概率仍然贴近 80% 的失败率，而且每一次重试还在往那个你想排空的水池里继续灌水。你以为在抢救，其实是对自己的依赖发动了一场小型 DDoS。

多厂商冗余研究（thetokenmart）把这件事算得很清楚：健康端点失败率 0.5% 时，3 次重试几乎必胜；但当供应商撞上容量墙、失败率跳到 80%，如果失败是相关的（共享同一饱和队列），重试 3 次的成功率不是独立情况下的 51%，而是贴着 80% 的失败率往下掉。结论很直接——同一厂商重试，救不了容量事件，只能放大它。

二、把韧性拆成三阶：重试 → 故障转移 → 自愈

把"抗故障能力"当成一条进阶路线来看，会更清楚每一层能挡住什么、挡不住什么：

L1 重试（人人都做）。只在同一个供应商内部重试。能覆盖瞬时 429、短暂抖动，约覆盖 20% 的故障；一旦供应商整体宕机，它就无能为力。

L2 故障转移 failover（聪明的团队在做）。检测到失败后切到备用供应商。能覆盖供应商宕机、计划内维护，约覆盖 50% 的故障；代价是不同模型的输出格式可能不一致，需要一层输出契约校验。

L3 自愈（还很少有人做）。检测失败 → 定位根因 → 用正确方式修复 → 验证恢复。涵盖限流、宕机、输出漂移、密钥轮转、契约破坏。一项对 2 万次真实调用的监测（DEV Community）显示，约 72% 的故障是可恢复的——前提是你有正确的基础设施；而多数 agent 没有，于是它们"死"了。失败分布里，限流（429）约占 40%、服务端错误（5xx）约占 25%、超时约占 15%、鉴权失败约占 10%，剩下是模型下线或输出漂移。

回到开头的金融客服案例：他们刚开始只有 L1（默认重试），所以 89% 失败；加上熔断（L1 的加固）和配额校验后才止血。而 thetokenmart 记录的另一次 2025 年 6 月的 47 分钟 529 故障，团队用一道跨厂商 fallback 网关一天就修好了，只多了 40 毫秒 p95 延迟——这正是 L2 的价值。

三、真实的故障成本账

先算"可用性"这笔账。托管式大模型的实际可用性大约在 99% 到 99.5%，而主流云基础设施是 99.97%（maxim 的 AI 网关研究）。99% 意味着一年约 3.5 天不可用。对一个有营收、有 SLA、面向客户的 AI 应用来说，这个缺口应用层吸收不了。到了 2025 年中，已经有 40% 的生产级 LLM 团队上了多厂商路由（十个月前只有 23%），背后是一连串头部模型厂的多小时事故在推着大家走。

再算"事故"这笔账。thetokenmart 记录的一次真实事件：某面向客户的助手依赖的单一端点返回 47 分钟 529 错误，团队记录到 1.84 万次失败请求、工单激增，事后估算直接成本约 6.1 万美元。修复只花了一天工程，代价是 +40 毫秒 p95 延迟。换句话说，你为"单厂商依赖"买的保险，出险概率不算低，出险金额却不小。

四、落地清单（今天就能做）

1. 关掉默认 SDK 重试，自己实现退避 + 抖动。几乎所有 LLM 提供商的默认重试都是给开发环境用的，生产上应设 maxRetries=0，再套一层指数退避（基准 1 秒、最多 5 次、加 500 毫秒随机抖动），避免"惊群效应"。Cloudflare 的 AI Gateway 文档也建议用指数退避来吸收限流。

2. 上断路器。连续 5 次失败后打开熔断 60 秒，别让重试把端点砸死。供应商故障时，熔断能让你的请求在配额重置窗口里停下来，而不是一直扇耳光。

3. 配跨厂商 fallback 路由。把 fallback 列表写进请求体（如 openai/gpt-4o-mini → anthropic/claude → deepseek），主供应商 429/5xx 时自动切到独立配额的另一家。把"可靠性"从应用代码里抽出来，交给一道网关统一管。

4. 用 AI 网关收敛多厂商。像 Cloudflare AI Gateway、Bifrost 这类网关用统一 OpenAI 兼容接口屏蔽 20+ 供应商，自动 failover、按 key/厂商负载均衡、按租户限流，应用代码零改动。这正是多厂商冗余从"麻烦"变"配置"的关键一步。去 OpenAI 平台页、Anthropic 平台页、DeepSeek 平台页、Gemini 平台页看各家实时报价与可用性差异。

5. 给每个供应商做健康检查。每 30 秒 ping 一次，配合错误率阈值（大于 5% 就告警），在用户感知之前把坏节点摘掉。

6. 把成本监控和限流报警绑在一起。限流往往和突发流量、批处理任务、agent 循环绑定。在隐藏计费陷阱里我们讲过，突发流量既烧钱又触发限流；把两者放进同一个看板，才能在"又贵又限流"发生时第一时间定位。更系统的省钱打法见成本优化 2026。

五、三个最容易踩的坑

坑 1：迷信默认 SDK 重试。它在开发环境够用，生产上 429 突发时会加重限流。务必关掉，自己实现退避 + 抖动 + 熔断三件套。

坑 2：退避没有抖动。一堆请求在同一时刻重试，会形成"惊群"，把本已脆弱的端点彻底打崩。加随机抖动，把重试时间打散。

坑 3：跨厂商切换后输出格式漂移。Claude 返回 JSON，切到 DeepSeek 可能变成 markdown，这是另一种失败。做 failover 时加一层输出契约校验（同一 prompt 不该返回 5 种格式），失败就回退到缓存答案或默认响应。

结语

大模型 API 不是云基础设施——它的可用性低一个数量级，事故也更频繁。把"多厂商容灾"当成可选项，本质上是把 4.7 万美元 / 6.1 万美元级别的故障概率，押在了"这次不会轮到我"上。先把默认重试去掉、加上退避和熔断（L1 加固），再用一道网关接上跨厂商 fallback（L2），成本可控、改动也不大。和限流一样，故障转移也要算经济账：在语义缓存降本和推理模型思考 Token 计费里我们算过单请求的省钱空间，但省下来的钱，不该被一次 47 分钟的宕机一次性清零。各家模型的可用性与价格随时在变，上 TokenNexus 首页查实时报价与路由建议。

推荐阅读