供应商可靠性陷阱：你的 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 的客户支持机器人可能仍然可以使用基于规则的分类器将工单路由到正确的队列。用户体验到的是降级质量，而不是故障。

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

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

多供应商架构

对于"必须保持运行"类别的功能，工程答案是多供应商故障转移。这个模式在原则上很简单：

顺序故障转移在 429（速率限制）、503（服务不可用）和 5xx 错误时触发。关键是，它不应该在 400 级用户错误时触发——这些表示在任何供应商处都会失败的错误请求，级联它们会浪费积分和延迟。路由器在单个请求生命周期内检测供应商 A 的失败并重新路由到供应商 B。

对冲请求在供应商 A 没有在阈值延迟内响应时触发对供应商 B 的请求。返回最先响应的那个。这处理的是降级（慢速）供应商，而不仅仅是失败的供应商。

熔断器跟踪时间窗口内的滚动错误率。当比率超过阈值——比如 60 秒内 20% 的错误——熔断器打开，所有流量在冷却期间路由到备用供应商。这防止了对失败供应商的雷鸣群重试。

负载分流持续以 70/30 之类的比例在供应商之间运行流量，而不是将供应商 B 纯粹视为故障转移目标。这使你的备用路径保持热状态，用真实流量验证其行为，并在供应商 A 失败时减少爆炸半径，因为 30% 的用户已经从 B 获得服务。

LiteLLM 的 Router 类在开源中实现了这些模式。Portkey 和类似的 AI 网关提供带有治理和可观测性层的托管版本。自己构建很简单，但需要在故障测试方面有更多的操作纪律。

一位在开源社区构建 AI 驱动工具的开发者使用的真实生产配置：Anthropic Claude 作为主要 → OpenAI 作为次要 → OpenRouter 作为兜底。这个模式正在成为企业默认：2025 年的企业支出数据显示，横跨 Anthropic（40% 的企业 AI 支出）和 OpenAI（27%）的多供应商架构是主导模式，反映了不将所有工作负载放在一个供应商上的显性偏好。

提示词兼容性是隐藏的代价

供应商故障转移听起来很干净，直到你遇到实际问题：提示语法、工具调用模式、分词器行为和模型响应模式在供应商之间有显著差异。为 Claude 3.7 Sonnet 调优的提示可能在 GPT-4o 上产生不同的输出——这种差异可能对你的用例有影响，也可能没有，但你在测试之前不会知道。

需要的操作纪律：将你的备用供应商视为一等生产路径，而不是冷备件。对其运行相同的评估套件。监控其输出。当你针对主要供应商调整提示时，检查这些变更是否在你的备用供应商上保持有效。这不是免费的工作，这也是为什么很多团队将备用供应商添加到配置中但从未验证它是否真正有效的原因。

最低限度的测试：每周一次针对供应商 B 在合成负载下运行你最常见的 50 种请求类型。在你的评估管道中呈现行为偏差。这不会捕捉所有问题，但会在用户在事故中遇到它们之前捕捉最严重的回归。

上线清单的依赖风险计算

问题不在于你的团队是否为每个 LLM 功能构建了优雅降级。对于第一年的产品来说，这通常是错误的投资水平。问题在于你是否明确了这个计算。

对于上线前的每个 AI 功能：

1. 分类它。 可缓存、可轻量模型降级，还是硬失败。这决定了你可以提供的诚实 SLA。
2. 做串行依赖数学。 将你自己的基础设施可用性乘以供应商公布的 SLA。如果你在没有公布 SLA 的标准层上，将其视为 99.5% 进行保守规划。
3. 与你的承诺比较。 如果你向客户提供 99.9%，而数学给出的是 99.4%，你需要回退架构或与企业客户就"正常运行时间"包含什么进行一次对话。
4. 构建失败模式。 对于硬失败功能，现在就写失败消息。"AI 功能暂时不可用"——配合回退到静态帮助内容或人工路由——比没有解释的损坏 UI 要好。

被供应商中断伤害的团队通常不是那些无法构建回退的团队——而是那些从未做过告诉他们需要回退的数学的团队。供应商可靠性陷阱之所以是陷阱，正是因为你对用户承诺的和你的依赖项可以交付的之间的差距，在事故将其变得具体之前是不可见的。

你实际上提供的 SLA

当你的 LLM 供应商宕机时，你与客户的服务协议中有什么内容并不重要。重要的是他们是否能完成工作。目睹 33 小时 AI 功能停机滚动过去的 Zendesk 工程师，没有任何合同义务可以恢复服务——在任何事故发生之前，数学就已经错了。

正确的心理模型：你的产品可靠性是你自己的基础设施和关键路径中每个串行依赖项的最小值。你添加的每个没有回退架构的 LLM 供应商都是一个设定你上限的依赖项。这个上限比大多数团队认为的要低，在产品发布和高流量时刻——可靠性最重要的时候——它会进一步下降。

在差距找到你之前，为差距进行设计。