模型 API 现已成为 Tier 0 级别。在状态页变红之前，请先设计好降级模式

询问基础设施团队，如果主数据库宕机会发生什么，你会得到一个演练过的答案：副本、故障转移运行手册、某人签字确认的 RTO 和 RPO 指标。询问同一个团队，如果模型 API 宕机会发生什么，你通常只会得到一个耸肩和指向供应商状态页面的链接。这种不对称性在 2023 年是有道理的，那时 LLM 只是驱动一个实验性的侧边栏。但在你的支持流程、搜索排名、代码审查机器人和入职助手都开始通过单一供应商的推理端点路由的那天起，这种不对称就不再合理了。

模型 API 现在是许多产品的 Tier-0 依赖项——对营收至关重要，且与数据库一样位于请求路径中——但大多数灾难恢复计划仍将其视为可有可无的集成。其结果是一种熟悉的故障形态：供应商服务降级，产品中的每个 AI 功能都显示相同的加载图标，值班人员盯着一个他们无法影响的状态页面，没人能回答唯一重要的问题：这个产品现在应该做什么？

这个问题必须在架构评审中回答，而不是在故障期间。这篇文章将探讨 AI 依赖项真正的降级模式是什么样的，为什么显而易见的答案——“直接故障转移到另一个供应商”——远比听起来要难，以及在状态页面变红之前需要做哪些决定。

你继承了一类你无法控制的依赖项

数据库故障的方式是你的团队可以调试的。模型 API 的故障方式是你只能观察到的。2025 年 11 月，Cloudflare 机器人管理系统中的一个配置错误导致互联网的大部分区域瘫痪了约三个小时，随之而去的是 ChatGPT、Perplexity 和 Claude，基本上所有主要的托管 AI 助手都同时瘫痪了。这些供应商都没有做错任何事。他们的共同边缘依赖项失败了，下游的所有产品也随之失败，这种失败是传递性的、不可见的且同步发生的。

这种事件暴露了依赖图的不安现状：你的产品依赖于模型供应商，而模型供应商又依赖于 CDN、云区域以及分布在不同硬件平台上的若干推理集群。Anthropic 对其 2025 年 8 月至 9 月事件的事后复盘描述了三个重叠的基础设施错误，这些错误间歇性地降低了为 Claude 提供服务的不同硬件后端的响应 质量——而非可用性。这种故障模式值得关注：API 全程返回 200 状态码。你的健康检查通过了。但你的用户得到了更糟糕的答案。

因此，一个 Tier-0 级别的 AI 依赖实际上有三种不同的故障模式，你的降级模式设计必须涵盖所有这些情况：

• 硬故障 (Hard down)：5xx 错误、超时、状态页变红的情况。容易检测，虽然痛苦但很诚实。
• 亚健康 (Brownout)：延迟升高和错误率增加，间歇性的 429 和 529 错误。检测是一个阈值设定问题，而盲目的重试会使情况恶化。
• 静默退化 (Silent degradation)：API 处于在线状态，延迟正常，但输出微妙地变差。传统的监控无法捕捉到这一点；只有在生产环境中采样的输出质量评估 (evals) 才能发现。

传统的灾难恢复 (DR) 规划假设故障是二元且可检测的。模型 API 不提供这两种保证。

多供应商故障转移并非多区域故障转移

对此的本能反应是使用带有回退链的网关：主模型，然后是同一供应商的更便宜的同门模型，接着是竞争对手，最后可能是自托管的开放权重模型作为最后手段。网关和路由器的出现使这种机制变得异常简单——健康检查、在几次失败后跳闸并在冷却后再次探测的熔断器，以及以毫秒计而非等待超时的自动重新路由。

机制是简单的部分。困难的部分在于，数据库故障转移和模型故障转移在语义上是不同的操作。当你将 Postgres 主库故障转移到副本时，副本运行相同的 SQL，持有相同的数据，并返回相同的行。当你将 GPT 故障转移到 Claude，或者将 Claude 故障转移到 Llama 时，你会得到一个接受相同请求格式但返回 不同 结果的系统。

任何真正在生产环境中更换过模型的人都知道，更换并非即插即用。提示词会与它们所针对的模型产生共同适应：工程师为解决边缘案例而对系统提示词所做的每一次修改，都编码了该特定模型的解释癖好。同一个提示词，在一个模型中可以产生干净的结构化 JSON，在另一个模型中可能产生被 Markdown 包裹的 JSON，而在第三个模型中则会产生多余的评论。工具调用规范、拒绝边界以及长上下文下的指令遵循能力各不相同。

一个从未经过评估的回退路径并不是回退——它是一个在没人关注质量时激活的、完全不同的产品。

对话中途的故障转移甚至更难，这正是多区域类比完全失效的地方。数据库副本通过复制与主库共享状态。模型供应商之间则毫无共享。如果一个用户在与智能体进行到第 12 轮对话时主模型宕机了，故障转移意味着需要将积累的上下文——对话历史、工具执行结果、缓存的系统提示词——重新输入到一个解释方式略有不同的模型中。

提示词缓存 (Prompt caches) 无法转移。微调 (Fine-tunes) 无法转移。新模型可能会重新审议旧模型已经做出的决定，反驳其先前的答案，或在工作流中途采取不同的工具路径。不存在“模型现在有了不同的个性”这种“复制延迟”指标。

这并不意味着多供应商故障转移毫无价值。它意味着必须将其视为一个 具有自身质量标准的预评估降级模式，而不是一个透明的冗余层。具体来说：维护一套针对每个任务的评估方案，定期针对回退链运行它，并在故障发生前知晓哪些任务可以接受故障转移，而哪些任务应该直接禁用而不是降级运行。

降级模式是披着基础设施外衣的产品决策

最有用的重新定义是：降级模式不是一个系统范围的开关，而是针对每个功能做出的关于当推理不可用或不可信时产品该如何表现的决策。对于每个 AI 驱动的界面，大致有四种选择，按雄心程度递减排列：

• 从缓存中提供服务。 很大一部分真实流量集中在重复的意图上，这就是为什么语义缓存（通过嵌入相似度而非精确文本将新查询与先前的答案匹配）在生产部署中通常能吸收大量请求。周二帮你省钱的缓存，也是在周四发生故障时让 FAQ 类查询保持有问必答的关键。但作为回退方案使用的缓存需要比作为优化手段使用的缓存更严格的规则：设置置信度阈值，使边缘匹配进入错误状态而不是给出错误答案；设置 TTL，以免你面不改色地提供过时的政策或价格信息。
• 回退到前 LLM 时代的实现。 RAG 流水线取代的关键词搜索，分类器取代的基于规则的分流，或者是草拟助手取代的模板。团队如果删除这些前身系统，后果自负。在平均情况下，旧系统确实不如模型，但它比加载动画（spinner）好上无数倍。如果前身系统已经不存在了，那么运行一个自托管的小型模型来处理简化版的任务也能起到同样的作用：作为没有外部依赖的最后保底方案。
• 将工作排队。 并非所有 AI 任务都是交互式的。摘要、富化、分类、报告生成——如果架构将它们视为有截止日期的队列任务而非同步调用，它们可以隐形地消化掉供应商数小时的停机时间。异步工作的降级模式仅仅是一个更长的队列，这是有史以来设计出的最廉价的降级模式。在停机期间，这也是进行负载削减（load-shedding）的地方：批处理和后台流量停止与交互式流量争夺仅存的容量。
• 诚实地告知。 对于那些真正无法替代的功能，正确的降级模式是一个显式的状态：“助手暂时不可用；这里是手动操作路径。” 一个诚实的不可用状态，并附上非 AI 工作流的链接，比一个挂起 90 秒然后通过一个从未经过评估的小型模型胡言乱语的聊天机器人更能维护信任。用户会原谅停机，但他们不会原谅被欺骗。

让这一切变得具体的练习是：盘点产品中所有的 AI 调用点，并为每个点分配这四种模式之一，外加一个等级。你通常会发现，只有极少数调用点是真正的 0 级（Tier-0）交互式调用——而对于几个“关键” AI 功能，诚实的标签应该是排队或关闭。这种盘点将真正的故障转移问题缩小到了一个可控的范围，使上一节中预先评估的回退链变得可行：你只需要在少数几个真正无法等待的界面上实现跨供应商的质量对等。

事故发生前需要回答的业务连续性问题

经典的业务连续性计划（BCP）会对每个依赖项询问两个数字：我们可以停机多久（RTO），以及我们可以丢失多少数据（RPO）。对于模型依赖，数据丢失通常不是问题——供应商不持有任何你无法重建的状态。真正重要的问题则不同，它们是工程部门无法独立回答的业务问题：

哪条收入路径会断裂，多久之后断裂？ 一个模型 API 宕机的 AI 编程产品就等于没有产品。一个 AI 摘要器宕机的 CRM 则只是让人烦恼。大多数产品介于两者之间，假装所有情况都是第一种会导致故障转移的过度工程，而假装所有情况都是第二种则会导致“全功能转圈等待”事故。0 级（Tier-0）定义本应预留给收入或安全关键路径；AI 功能在没有任何人重新运行分类的情况下，就被默认列入了产品中。

在红色横幅（警示状态）下，我们愿意提供的质量底线是什么？ 故障转移到较弱的模型是一种决定，即在你的品牌下提供较差的答案。对于一个自动回复机器人，在三小时停机期间质量的小幅下降是不可察觉的。但对于任何涉及金钱、健康或法律风险的功能，降级模式可能应该是关闭，而且业务部门必须有人预先同意这一点——因为在事故期间，压力都会指向“在任何有响应的模型上维持运行”。

谁为备用容量买单？ 真正的降级模式在事故发生前就需要真金白银：为了持续衡量质量而通过少量流量维持热度的第二个供应商合同、在第二个区域预留的容量或部署、以及每次提示词更改时针对回退链运行的评估套件。供应商的 SLA（如果存在的话）只退还支出的一定比例——它们不退还你损失的收入。这两个数字之间的差距就是备用容量的预算论据，这个论据是可以赢的，但前提是有人在停机前而不是在复盘时提出它。

然后进行演练。成熟的连续性计划每年会对 0 级系统运行一到两次故障转移演习；几乎没有人针对模型依赖这样做。在预发环境中模拟屏蔽主要供应商端点的“演练日”（Game day），在两小时内教给你的东西比本文还要多——通常从发现熔断器（circuit breaker）起作用但用于禁用非关键 AI 界面的功能开关（feature flags）不存在开始，导致回退供应商立即被 100% 的本应被削减的流量淹没。

状态页不是一种策略

这种故事还有另一种版本，即此处描述的一切都没有被构建，而且对某些产品来说，这确实是站得住脚的：如果你的 AI 功能纯粹是装饰性的，那么“干等着”这种降级模式也没问题，2025 年 11 月的停机也只不过是三小时的不便。但这种辩护必须被明确提出，因为默认的发展轨迹正朝着相反的方向发展。每个季度，产品中会有更多的核心循环通过推理（Inference）来实现。这种依赖关系悄然地从“锦上添花”升级为 Tier-0 级别，而由于没有哪次单一的发布让人觉得是发生质变的时刻，因此没有人会去重新进行灾备审查。

所以，趁现在成本还低，赶快进行审查。清查所有的调用点。为每个调用点分配一种降级模式 —— 缓存、前代模型、队列，或者干脆缺失。在少数值得投入的界面上，预先评估其回退链（Fallback chain）。在主服务上增加质量评估，而不只是运行状态检查，因为最糟糕的失败模式往往是返回 200 状态码。并且，要在事故发生前，而不是发生时，让业务负责人签字确认质量底线和备用预算。

模型 API 还会再次宕机。那不是你能控制的。但你的产品是否能回答“我们现在该怎么办” —— 这部分始终掌握在你手中。