Claude 多个模型报错：Fable 5.1、Sonnet 5.5、Haiku 5.5 故障复盘

一次持续不到 20 分钟的线上故障

据官方状态页 RSS 推送，Anthropic 在 UTC 时间 23:37 开始调查 Claude Fable 5.1 的请求错误率异常升高，两分钟后将影响范围扩大到 Sonnet 5.5、Haiku 5.5，以及 Opus 5.5 的 fast mode 请求。23:39 官方表示已定位根因并着手修复，23:54 宣布受影响模型的成功率恢复至正常水平，并继续观察。从首次通报到恢复，整个过程约 17 分钟。

这条状态更新本身信息量不大，但通报节奏和波及范围值得拆开看：一个模型出问题，为什么会在两分钟内扩散到同代的其他型号？

故障时间线与影响范围

按状态页三次更新梳理：

• 23:37 Investigating：仅提及 Claude Fable 5.1 错误率升高，尚未确认原因。
• 23:39 Identified：影响面扩大到 Sonnet 5.5、Haiku 5.5，以及 Opus 5.5 的 fast mode，官方称已找到原因。
• 23:54 Monitoring：所有受影响模型成功率恢复正常，进入监控阶段。

你可能没注意到，官方在通报中使用了“elevated errors”（错误率升高）而非“服务中断”（outage）。这两个词在状态页语境里有明确区别：前者意味着请求仍能返回，只是失败比例高于基线；后者通常指完全不可用。对依赖 API 的应用来说，前者更隐蔽——重试逻辑可能掩盖问题，但用户会感知到延迟和偶发失败。

另外，Opus 5.5 只有 fast mode 受影响，标准模式未被列入。这一细节说明故障并非某个模型独立部署的问题，更可能与共享的推理路径或调度层相关。

elevated errors 与 outage 的区别

在云服务状态页的通行语义中，elevated errors 指服务整体仍在运转，但特定接口或模型返回失败响应的比例显著高于日常基线，通常对应部分请求 5xx 或超时；outage 则表示服务完全不可用或大面积不可达。多数厂商的状态分级（如 Investigating / Identified / Monitoring / Resolved）与这一措辞体系配套使用：Investigating 表示已收到异常但未定性，Identified 表示根因或故障组件已确认，Monitoring 表示修复已上线、正在观察指标是否稳定。对调用方而言，elevated errors 的隐蔽性在于成功率可能仍有八九成，监控大盘不一定触发红色告警，但尾延迟和重试量会同步抬升，实际用户体验的劣化往往大于错误率数字本身。

为什么一个模型报错会牵连一串模型

官方没有公布技术根因，但通报的时间顺序提供了一个观察角度：Investigating 阶段只点名 Fable 5.1，两分钟后才把 Sonnet 5.5 和 Haiku 5.5 纳入。这符合“先发现异常、再排查扩散面”的典型流程——最初的告警来自单个模型的监控指标，随后工程师确认同一故障源影响了更多型号。

对多模型产品线而言，这种连带效应几乎是结构性的。同一代模型往往共享推理基础设施、路由层、鉴权与限流组件，fast mode 这类低延迟路径还可能复用特定的批处理或缓存策略。任何一层出问题，表现都是“多个模型同时报错”，而不是单点故障。

从运维角度看，这也解释了为什么状态页通报会从“单模型”迅速升级为“多模型”：不是错误在蔓延，而是排查范围在收敛。

多模型共享基础设施的典型分层

同代模型往往复用同一套技术栈，典型分层包括：接入层（API 网关、鉴权、配额与限流）、路由与调度层（按模型、区域、负载把请求分发到推理集群）、推理运行时（批处理调度、KV Cache 管理、显存分配）以及可观测性组件（指标采集、日志管道）。其中任一层的共享组件出现劣化——例如限流配置错误、路由表异常、批处理队列积压或缓存击穿——都会让所有经过该组件的模型同时表现为错误率上升，而故障表象与模型本身的权重、能力无关。fast mode 这类低延迟通道通常另有独立的调度策略（更激进的批处理窗口、更短的排队超时、专用缓存），因此它可能成为与标准模式不同的失败域，这也是本次只有 Opus 5.5 fast mode 被波及的合理解释。

对开发者的实际影响

17 分钟的故障窗口对大多数应用来说属于短时抖动，但影响程度取决于架构设计：

• 无重试逻辑的应用会直接把错误抛给终端用户，表现为对话中断或任务失败。
• 有指数退避重试的应用可能只是延迟上升，用户感知为“变慢”。
• 硬编码单一模型的管线在故障期间没有退路，而配置了模型降级（例如从 Sonnet 切到 Haiku，或切到其他供应商）的系统可以把影响降到最低。

这次故障还暴露了一个常被忽略的点：fast mode 是独立于标准模式的失败域。依赖低延迟路径做实时交互的产品，需要单独为 fast mode 准备降级方案，而不是假设“Opus 可用就等于一切正常”。

指数退避与模型降级

指数退避（exponential backoff）指重试间隔按指数增长（如 1s、2s、4s、8s），并通常叠加随机抖动（jitter）以避免大量客户端在同一时刻集中重试造成二次雪崩。它适合应对瞬时性错误，但对限流类（429）错误效果有限，反而可能延长请求占用时间。模型降级则是预先定义一条能力递减的模型链（如 Sonnet → Haiku → 其他供应商），在检测到主模型错误率超阈值或延迟超标时自动切换，并把降级事件计入可观测性指标。工程上常见的组合是：对 5xx 与超时做有限次指数退避重试，对 429 与持续 elevated errors 直接触发降级，同时为 fast mode 单独维护一条降级路径，避免与标准模式共用同一套熔断判断。

从这次事件能学到什么

状态页订阅应进入告警链路。 这次通报完全通过状态页 RSS 发布，官方没有其他渠道的主动通知。把 RSS 或状态页 API 接入内部告警系统，比等用户投诉再排查要快得多。

模型降级别只配一个备胎。 故障同时波及三个主力型号，说明“主模型挂了下游模型顶上”的策略在同代模型间可能失效。跨供应商或跨代际的降级路径更稳。

区分“报错”和“不可用”。 elevated errors 场景下，盲目重试可能加剧限流压力。合理的做法是结合错误码决定重试策略，对 5xx 类错误做有限次退避，对限流类错误直接降级。

关注官方通报的用词。 Investigating、Identified、Monitoring 三个阶段对应不同的应对动作：进入 Monitoring 意味着主故障已解除，但余波（如队列积压、缓存冷启动）可能仍在，此时不宜立即恢复全量流量。

小结

这是一次典型的短时区域性故障：起点是单模型错误率异常，波及同代多个型号与 fast mode 路径，17 分钟内完成定位与恢复。官方未披露根因，但从通报节奏看，问题出在共享基础设施层的可能性高于单个模型。对开发者而言，真正有价值的不是故障本身，而是它提醒我们：多模型冗余不等于多供应商冗余，状态页订阅和分级降级策略应当成为 API 依赖的标配。