供应商可靠性陷阱：你的 LLM 供应商 SLA 已成为你用户的 SLA

2024 年 12 月，Zendesk 发布了一份正式事故报告，称从 2025 年 6 月 10 日到 11 日，客户无法访问所有 Zendesk AI 功能，持续时间超过 33 个连续小时。工程团队的修复措施栏是空的——什么都做不了。此次故障完全由其上游 LLM 供应商宕机引起，而 Zendesk 没有任何在没有该供应商的情况下恢复服务的架构路径。

这就是供应商可靠性陷阱最清晰的体现：你发布了一个功能，让它成为用户工作流程的一部分，通过隐性或显性的 SLA 承诺保证可用性，然后发现你整个可靠性状态受限于一个你无法控制、无法修复、甚至可能在上线前从未正式评估过的依赖项。

这个陷阱是结构性的。你无法在事故发生时通过工程手段摆脱它。真正重要的决策发生在任何具体故障的数月之前，在架构和产品设计阶段。大多数团队在这些决策上犯错——不是因为粗心，而是因为这些数学关系在它咬到你之前是不可见的。

没有人在上线前做的 SLA 算术​

串行依赖的基本属性是它们的可用性相乘。如果你自己的基础设施运行在 99.9%，而你的 LLM 供应商提供 99.5%，那么你的理论最大可用性是 0.999 × 0.995 = 99.4%。如果关键路径中有一个串行依赖只能保证 99.5%，你就无法向客户提供 99.9%。

随着依赖项的增加，这个数学会变得更糟：

• 3 个各 99.9% 的服务：0.999³ ≈ 99.7%
• 5 个各 99.9% 的服务：0.999⁵ ≈ 99.5%
• 你的基础设施 (99.9%) + LLM 99.5% + 向量数据库 99.9%：≈ 99.3%

这些数字在实践中意味着什么？99.5% 的 SLA 允许每年 43.8 小时的停机时间——大约每月 3.6 小时。99.9% 的 SLA 允许每年 8.76 小时。如果你向企业客户提供 99.9%，而你的 LLM 供应商上限是 99.5%，那么在任何一行应用代码失败之前，你就有 5 倍的差距。

供应商 SLA 的现状使问题更加复杂。Anthropic 的标准层没有公开的 SLA——属于尽力而为的可用性。OpenAI 对标准客户的直接 API 也不提供合同保证。Google 的 Vertex AI 公布了 99.5% 的目标。Azure OpenAI 提供 99.9%，这就是企业专门通过它路由的原因。即使是最好的公开 LLM SLA 也最多 99.9%，而大多数标准层用户没有任何书面保证。

为什么故障偏偏在最糟糕的时候集中发生​

一个常见的心理模型将供应商中断视为均匀分布在时间上的独立事件。这个模型是错误的，基于它来行动会低估你的真实风险。

LLM 推理受 GPU 约束。与可以在几分钟内启动数千个额外实例的基于 CPU 的服务不同，GPU 供应的交付周期以月为单位。当新模型发布或某个病毒式用例带来突然需求时，供应商无法弹性扩展来吸收它。结果是容量压力和基础设施压力与你最关心的使用高峰同时发生。

OpenAI 2024 年 12 月的故障是由一个新的遥测服务压垮 Kubernetes API 服务器引发的——这是随着平台快速演进而部署的基础设施变更。2025 年 3 月的图像生成发布恰逢基础设施压力和随后的故障。多个有据可查的事故显示了这一模式：新功能发布推动使用量激增，为支持增长而部署基础设施变更，随后发生故障。

对 2023–2024 年 LLM 服务遥测数据的学术分析发现，ChatGPT 在此期间仅有 88.85% 的天数完全可访问。关键含义是：如果你运营的是 B2B 产品，客户在工作时间使用你的 AI 功能，而你的供应商故障与高流量时段相关，那么你的用户可见可靠性低于标题可用性数字所暗示的水平。

必须在故障发生前做出的产品决策​

最重要的可靠性工作不是事故响应——而是你应该在上线前做的分类练习。你产品中的每个 AI 功能都属于三类之一：

可以从缓存服务的功能。 如果 LLM 输出对于相似输入是确定性的或缓慢变化的——产品描述、FAQ 回答、内容摘要、推荐解释——你可以缓存响应并在供应商故障期间提供服务。一个有据可查的生产案例通过添加带缓存响应回退的熔断器，将有效正常运行时间从 99.2% 提高到 99.87%。这一类别通常代表了比你预期更多的功能面。

可以降级到更轻量模型或基于规则的回退的功能。 简单意图分类、基本路由、关键词匹配——对于许多任务，更便宜或本地托管的模型提供足够的功能以在降低能力的情况下维持功能。无法访问 Claude 的客户支持机器人可能仍然可以使用基于规则的分类器将工单路由到正确的队列。用户体验到的是降级质量，而不是故障。

硬失败的功能。 新型文档分析、多步骤智能工作流、实时代码生成——这些没有合理的预计算回退。当你的供应商宕机时，这些功能也会宕机。关键问题不是如何防止这种情况，而是你是否已经诚实地告知用户这个依赖关系，并相应地设计了失败消息。

跳过这个分类意味着默认情况下每个功能都会硬失败。提前进行这个分类意味着你可以在事故期间保留产品价值的有意义部分。