LLM 服务商故障手册：当 AI 基础设施宕机时如何保持服务在线

2024 年 12 月，OpenAI 整个平台宕机超过四个小时。一项新部署的遥测服务配置错误，导致大规模集群中的每个节点同时猛攻 Kubernetes API。DNS 崩溃，控制平面瘫痪，所有服务随之倒下。恢复耗时如此之久，部分原因在于团队缺乏他们后来所说的"破防工具"——那些在常规流程失效时可以立即调用的预建应急机制。

如果那天你正在运营一款 AI 驱动的产品，你必须在压力下快速做出决策。多服务商路由？优雅降级？缓存响应？还是只能祈祷，然后挂出一个状态页面？

这就是你应该在那个电话打来之前就已经写好的应急手册。

LLM 服务商的目标可用性通常在 99% 到 99.5% 之间，听起来尚可——但算一下就会发现：这比你自己云基础设施 SLA 差 6 到 14 倍。而且，降级现象——无声的输出质量下降、延迟升高、部分可用——发生的频率远超完全宕机。2025 年对主要服务商 792 起事故的实证分析发现，故障模式差异显著：OpenAI 的架构倾向于隔离性故障，而 Anthropic 的服务相互依赖则导致更多跨服务级联影响。

工程启示：你不能把 LLM 服务商的可靠性当作别人的问题。你必须为此做好建设。

三类故障（以及它们为何需要不同的应对方式）

在编写任何手册之前，你需要先搞清楚故障究竟长什么样。故障分为三类，它们需要截然不同的应对方式。

硬故障是最显而易见的：503 错误、超时、服务商状态页面变红。你的监控系统会在几秒内捕捉到这些。应对方式是路由：将流量转移到别处。

软故障更危险。服务商返回 200 OK，但响应是错误的——质量更低、被截断、语义退化。Anthropic 2025 年 8 月的事后分析正好记录了这一点：三个重叠的基础设施 bug 导致 16% 的 Claude Sonnet 请求在数周内被无声地错误路由或降级。标准的 HTTP 可用性监控没有发现任何异常，标准 APM 工具也没有。只有输出质量监控——对模型响应进行采样和评估——才能早期发现问题。

延迟故障介于两者之间。服务商技术上是可用的，但 p99 延迟飙升了三倍。你的流式响应感觉像出了问题。用户在完成之前就放弃了。这个特别棘手，因为很难归因：到底是服务商的问题、你的网络、你的提示词长度，还是下游某个环节？

你的应急手册需要为这三类故障制定独立的检测路径和响应协议。只为硬故障做计划的团队，对那些往往是其前兆的条件视而不见。

检测：事故发生前你应该监测什么

大多数团队检测 LLM 调用的方式和检测普通 API 一样：请求数、错误率、p50 延迟。这是必要的，但还不够。

在事故中真正有用的指标：

• 按服务商和模型划分的 p99 延迟，而非平均值。平均值会掩盖用户切实感受到的尾部降级。
• 按错误类型划分的错误率：429（限速）、503（不可用）以及服务商特定的失败代码，各有其含义，需要不同的应对方式。429 激增意味着你达到了配额上限；503 激增意味着服务商在苦苦挣扎。
• TPM 消耗与限额的对比，而非仅仅是 RPM。运行 Agent 或 RAG 管道的团队经常忽视每分钟 token 限额，直到事故揭示他们的长提示词早在触及请求上限之前就已达到 TPM 上限。
• 故障切换激活率：你的路由层切换到备用服务商的频率。这里的逐渐上升往往是主服务商正在发生事故的第一个信号。
• 输出质量信号：对一定比例的生产响应进行采样并运行轻量级评估。你不需要完美的质量评分——你需要的是一个异常检测器，当输出长度、结构或与预期模式的语义相似度发生显著偏移时能够触发告警。

告警应基于组合条件触发，而非单一指标。p99 延迟单独飙升可能只是偶发抖动。但如果 p99 飙升的同时错误率也在攀升，且故障切换激活率也在上涨，那就是一起事故。

路由层：构建在压力下有效的故障切换

路由层是你弹性策略的核心。以下是从结构上思考这个问题的方式。

在故障切换前进行带抖动的重试。 瞬时错误——网络抖动、短暂负载峰值——往往在几秒内自行恢复。简单的指数退避加随机抖动可以吸收大多数此类错误，而无需触碰备用服务商。抖动至关重要：没有抖动，所有客户端会同时重试，造成重试风暴，这会放大约 40% 的级联故障。

针对持续故障使用断路器。 当服务商的错误率超过阈值（比如 60 秒窗口内 40% 的请求失败），停止发送流量并触发断路器。路由到备用服务商。定期用少量流量探测主服务商以检测其是否恢复。这将故障切换延迟从等待超时的 10 秒以上缩短到毫秒级的主动检测。

模型等价映射。 对于你在生产中使用的每个模型，在任何事故发生之前就定义好降级映射。GPT-4o 对应 Claude Sonnet 或 Gemini 1.5 Pro。对于每个映射，记录已知的行为差异——响应详细程度、JSON 遵从度、指令遵循能力——这样当切换在凌晨 2 点自动发生时，你知道会发生什么。

避免流中途切换。 如果你在流式传输响应，尝试在生成过程中切换服务商会产生令人不安且往往破损的用户体验。在第一个 token 返回之前触发故障切换，而非之后。这要求你的断路器在上游就做出路由决策。

一个团队通过全栈方式实现了 99.97% 的有效可用性：主服务商加断路器 → 同等模型类的次级服务商 → 简化版降级模型 → 缓存响应。代价是评估工作量增加了 20-30%，以便在整个降级链的每个节点保持质量保障。

优雅降级：当 AI 不可用时你的产品该怎么做

切换到另一个服务商是最优情况。但如果没有任何服务商可用，或者任务需要备用服务商无法匹配的特定能力呢？你需要一套降级策略。

语义缓存通常是你的第一道防线。基于语义相似度（而非精确字符串匹配）进行缓存，可以为近似历史查询的请求提供之前的响应。根据用例的重复性，缓存命中率可达 30-70%。对于高流量的支持或问答应用，这意味着大多数用户查询可以在 LLM 中断期间无感切换。

基于规则的降级以准确性换取可靠性。对于结构化任务——分类、路由、简单提取——你往往有一个被模型取代但从未删除的基于规则的实现。这些实现毫秒级响应，100% 可靠。将它们保留为降级路径成本极低，但价值极高。

功能标志（而非硬编码的路由逻辑）应该控制降级何时激活。这让你无需部署即可切换行为，在生产环境中测试降级路径，并在降级行为出现意外后果时快速回滚。

禁用是一种有效的降级状态。 对于真正非关键的 AI 功能——摘要、建议、增强——什么都不显示好过显示错误内容。缺少"AI 摘要"是缺少一个功能。在事故期间出现一个自信但错误的 AI 摘要，则是信任危机。

每个 AI 功能的决策树应该是明确的：如果主服务商失败，我们是尝试备用模型、提供缓存响应、应用规则，还是禁用？这个决策应该提前做出并编码到配置中，而不是在事故中临时拍脑袋。

手册本身：前三十分钟该做什么

当告警触发时，前三十分钟决定了事故是被控制住还是进一步扩大。以下是你需要提前写好的最小结构。

分诊（前 5 分钟）：

1. 检查服务商的状态页面。记录时间和状态以备事故日志使用。
2. 查看实时仪表盘：错误率、p99 延迟、故障切换激活率。
3. 分类故障类型：硬故障、软降级还是延迟故障。
4. 确认断路器已正确触发。如果没有，手动触发。

遏制（5-15 分钟）： 5. 确认流量正在路由到备用服务商。检查消费速率——如果备用服务商定价不同，无约束的故障切换可能导致成本意外飙升。 6. 如果降级影响的是输出质量而非可用性，决定是禁用该功能还是继续使用降级输出。这个决策应该为每个功能提前做出。 7. 更新内部状态频道。即使只是"正在调查"，第一条消息也应在 10-15 分钟内发出。

沟通（15-30 分钟）： 8. 如果确认了对用户的影响，发布到外部状态页面。具体胜过模糊："由于服务商基础设施问题，AI 功能正在经历响应质量降级"好过"部分功能可能受到影响"。 9. 不要承诺你无法兑现的解决时间。每 30-60 分钟更新一次，直到恢复。

解决： 10. 在宣布事故解决前，用少量流量探测主服务商至少 10 分钟。等待稳定后再完全恢复流量。 11. 24 小时内发布简短摘要。72 小时内完成完整的事后分析。这不仅仅是透明度——这是你的团队学习的方式。

AI 事故响应中最常见的失败模式，是在前三十分钟做出了本应在事故发生前就已做好的决策。哪些模型是可接受的备用？谁有权限禁用某个功能？成本上限在哪里需要升级？这些问题需要在手册中写好答案，而不是在压力下临场发挥。

无声降级：你的监控可能遗漏的故障模式

Anthropic 2025 年 8 月的事故值得专门研究，因为它揭示了大多数团队可观测性体系中的一个盲点。

三个基础设施 bug 在数周内叠加恶化。在峰值时，16% 的请求被错误路由或由配置错误的服务器提供服务。这一切没有产生任何 HTTP 错误。标准监控显示系统一切正常。大约 30% 的 Claude Code 用户在问题被识别之前至少经历过一次降级交互。

这就是标准可用性监控无法检测到的故障模式：语义输出降级。服务在运行，API 返回 200，响应只是错的，或者有些偏差，而要发现这一点需要理解一个好的响应应该长什么样。

防御这种情况需要输出质量监控：对生产响应进行采样和评估。评估不需要复杂——长度异常、结构违规（预期的 JSON 但实际不是 JSON）、与一小组已知良好响应的语义相似度——但它需要存在。在需要它之前就把它建好。一旦你进入事故状态，你需要知道降级是一小时前开始的还是三周前开始的。

成本作为事故指标

一个被讨论不足的故障模式：在事故期间，你的成本结构可能在你察觉之前就已崩溃。

一个金融服务团队记录了他们的 Agent 在主服务商开始返回格式错误的响应时进入递归循环的情况。他们的 LLM 周支出从 127 美元涨到 47,000 美元，告警才触发。断路器逻辑是为可用性实现的，不是为成本。每个服务商的成本上限从未设置过。

将成本纳入你的事故监控：

• 当任意 15 分钟窗口内单个服务商的消费速率增加超过 3 倍时触发告警。
• 设置带有自动断路器行为的硬上限——不只是软告警——这样失控的 Agent 循环会自我终止。
• 将服务商切换与成本一起记录，这样你就能在事后回顾中重建成本峰值发生的确切时间和原因。

以可用性事件开始的事故，仅通过故障切换本身就可能变成成本事件。在主服务商上花费 0.01 美元的请求，在备用服务商上可能花费 0.08 美元。在规模上，这不是背景噪音。

结语：在需要它之前写好手册

LLM 服务商比两年前更可靠了，但比你的数据库还差得远。这个差距不会完全消失——基础设施太复杂，需求太不可预测，硬件生态系统太过异质。

那些在 OpenAI 2024 年 12 月中断和 Anthropic 2025 年 8 月降级期间没有遭受显著用户影响的团队有一个共同点：他们提前做好了准备。多服务商路由已经在运行。备用模型已经完成映射。成本告警已经配置好。功能降级决策已经记录在案。

手册不是你在事故期间写的文档，而是让事故变得可管控的那份文档。现在就写，趁你还有时间冷静思考。然后测试它——周四下午的一次计划故障切换演练，会暴露出凌晨 2 点的事故不会让你平静发现的那些漏洞。

你的 LLM 服务商终将宕机。唯一的问题是你是否已经准备好了。