AI 灾备方案：供应商宕机怎么办

「我们接入了 GPT-5，业务跑得好好的，直到上周三 OpenAI 美国区突然挂了 47 分钟。」——这是 2026 年企业用户群里实时发生的事。上游模型故障已经从「小概率事件」变成「季度级常态」，不是模型本身的可用性问题，而是集中化服务都躲不开的网络抖动、限流激增、维护窗口、偶尔的 0day 重启。如果你只接了一个供应商、没有降级机制，你的业务也会跟着那 47 分钟一起沉默。

这篇文章不是讲理论，是给你一份从「单供应商裸奔」到「多供应商 Active-Active」的可落地路径。每一层都用最少代码达成最大效果，灾备的复杂度可以梯度递增，不必一步到位。

一、先做风险分类：你的业务经得起多久不动

灾备方案的第一步不是选架构，是搞清楚你能承受多长停机。三类业务差距巨大：

业务类型	RTO（恢复时间目标）	RPO（数据损失目标）	典型代表
面向 C 端的对话类	< 30 秒（用户能感知）	0（对话上下文不能丢）	客服机器人、AI 助手
面向 B 端的批量处理	< 30 分钟	可接受 5-10 分钟的处理积压	批量摘要、文档分析
非实时离线管道	< 4 小时（下个批次前修好）	可重跑上一批次	训练数据生成、报表分析

很明显，对话类业务是降级链必须自动触发的。批量类和离线类只要做好重试 + 队列缓冲，用人工介入就够，不必砸钱做 Active-Active。先把业务排个序，再决定改谁。

二、第一层降级：同供应商内多模型路由

最便宜的灾备是「在同一个供应商内部切模型」。OpenAI 兼容接口的好处就在这里：换模型只需改 model 字段，业务代码不动。

models_fallback = [
    "gpt-5.4",          # 首选：能力最强
    "gpt-5.4-mini",     # 降级 1：更快更稳，能力够
    "gpt-5.2",          # 降级 2：老一代，舵机不会断
    "deepseek-r1",      # 跨供应商降级，下面讲
]

for model in models_fallback:
    try:
        return call(model, messages)
    except (Timeout, RateLimit, ServiceUnavailable) as e:
        log(f"{model} failed: {e}, trying next...")
        continue
raise AllModelsFailed()  # 所有降级链都失败才抛错

这套设计的关键点是：

• 异常类型限制：只对超时、限流、服务不可用做降级；参数错误、内容审核驳回这类确定性错误不降级（降级了也没用，换个模型一样挂）。
• 错误是瞬时的不是永久的：降级链不应该「永久标黑」某个模型，30 秒后让它在下一轮重新尝试，否则一次抖动就把好模型拉黑了。
• 降级链可观测：每次降级触发后必须打日志或告警，让你看到「主模型挂了 N 次」——这是上游出问题的早期信号，比用户投诉早到。

模型级降级链的选型逻辑详见《GPT-5-mini 还是 GPT-5？》，那个讲的是常态路由；这里讲的是异常降级，思路相似但触发条件不同。

三、第二层降级：跨供应商 Active-Active

OpenAI 整体挂掉怎么办？单供应商内部切模型救不了你。这时候要跨供应商 Active-Active：同时接入 2-3 个供应商，流量按权重分配，任何一家挂掉流量立即转移到剩下两家，不让用户感知到。

架构上多供应商路由有两种实现方式：

1. 用聚合网关：DrAI 这类聚合平台已经做了这件事。你在控制台里给同一个模型名配多个渠道（如 gpt-5.4 走 3 个账户），网关自动做渠道级健康检查 + 故障转移。你这边代码不变，网关里改渠道优先级和限流参数即可。详细接入方法见《AI API 入门指南》。
2. 自己实现路由层：在业务代码和 SDK 之间加一层 thin router，自己维护多个供应商的 client 实例 + 健康检查 + 权重。好处是账单结构你完全清楚，坏处是要自己跑渠道签约、合规审计、用量统计——工作量不小。

中小团队强烈推荐前者，灾备的隐性成本远超你能想象的：每个供应商的认证、限流、错误码语义、补偿机制都要熟悉一遍；网关类工具把这些抽象掉了。自建只适合月 50 万人民币以上用量的大客户。

Active-Active 不是 Active-Passive：不要让备供应商闲着到 OpenAI 挂了才被唤醒——它平时没流量就不在你监控视野里，挂了你也不知道。把备供应商也跑 5-15% 的常规流量，一是让它的健康度被你持续监控，二是换过来时延迟、缓存命中、限流参数都已校准，不会突然翻车。

四、第三层降级：模型异质化降级

跨供应商但模型还是同一个家族（都跑 GPT-5 系列或 Claude 系列），上游模型本身的 bug 仍然会传到所有渠道。真正彻底的灾保是模型异质化降级：主走 OpenAI、备走 Anthropic、尾险走 DeepSeek 或国产模型。

异质化降级的难点是能力差异：让你的工具调用、JSON 输出、长上下文处理在三家模型上都跑通，需要做兼容性测试。具体做法：

• 把模型调用全走 OpenAI 兼容接口（《LLM 结构化输出指南》有兼容性要点）；
• Function Calling 的 schema 用通用写法，不要依赖某一家厂商的私有扩展；
• 关键 prompt 在不同模型上做回归测试集，每次升级跑一遍，发现降级后回答质量掉得严重就提示人工介入而非静默降级。

异质化不便宜——有两个供应商的接入成本，但换来的是对应上游模型物理层故障的真正容灾。是否做要看你 RTO 的硬度，腰部以上工具类业务都该做。

五、流量切换的两种模式

故障发生时，切流量的两种方式：

1. fail-fast + 立即降级：检测到主供应商异常（连续 3 个请求 timeout 或 5xx），立刻把当次请求改走备供应商。优点是用户无感，缺点是抖动也触发降级，可能在主供应商短暂抖动时白白消耗备供应商配额。适合 RTO < 30 秒对话场景。
2. fail-over + 退避重试：主供应商失败后先重试 1-2 次（指数退避），仍失败再切到备供应商。容忍 5-10 秒延迟的业务适合这种。避免误判带来的不必要切换。

# 退避重试 + 跨供应商降级示例
def call_with_resilience(messages, timeout=30):
    try:
        # 优先级 1: 主供应商，指数退避重试
        return retry_call(primary, messages, timeout=timeout)
    except AllRetriesFailed:
        log("primary down, switching to backup")
        # 优先级 2: 备供应商，单次请求
        return backup.call(messages, timeout=timeout * 2)
    except BackupFailed:
        # 优先级 3: 异质化降级到国产模型
        log("backup down, switching to deepseek")
        return deepseek.call(messages, timeout=timeout * 2)

代码上的实现成本并不高，真正的成本在测量：你需要一套独立的健康检查探针持续探测每个供应商的状态，否则故障发生时你才知道「备供应商其实也是挂的」，AB 区域都没了用户才知道。健康探针的部署参考《多区域 AI 部署：全球低延迟架构指南》。

六、数据一致性：降级后上下文怎么办

多轮对话场景的降级有个坑：模型 B 接到对话历史但不知道用户原本在跟模型 A 沟通什么。三条对策：

1. 把对话历史记在你自己的层：messages 数组完整存在你的数据库 / Redis，每次请求重新发给当前供应商。模型是无状态的，谁也不在乎上次是不是别家模型接的。
2. 角色设定走 system 提示词：人设、口径、限制不要依赖某一家模型的行为习惯，写死在 system prompt 里，跨模型保持一致。
3. Token 计数差异注意：不同模型对同一句话的 token 计数可能差 20%+，沿用 A 模型的截断阈值可能导致 B 模型溢出。降级时清空边缘对话（最早的几轮），不要粗暴截断。

这套思路和你单模型时状态外置的习惯一致，无状态是 AI 应用的标配，无论灾备与否都该这么设计。详见《10 分钟给你的应用接入 AI 聊天功能》多轮记忆那一节。

七、混沌演练：没有演练的灾备等于没有

装好降级链就以为安全了？请做一次混沌演练：

1. 把主供应商 API Key 主动吊销或在网关层手动标黑，模拟「OpenAI 整体不可达」。
2. 从用户视角验证：客服界面还在响应、对话不卡顿、错误率 < 1%、回复质量无明显下降。
3. 压测降级链容量：在主挂掉时，备供应商的配额够不够吃你的全部流量？你之前的 5-15% 常规流量配额此刻能扩容吗？
4. 演练后回滚：演练结束恢复主供应商，确认流量切回主，而不是卡在备。这一步常常被忽略，演练后你才发现业务一直跑在小供应商。

建议每季度做一次。每次故障后「我们以为有灾备」和「我们演练过灾备」是两个完全不同的信任等级。

八、合规与成本权衡

• 合规：多供应商意味着 PII 数据可能流向多个境外节点，逐一确认数据驻留承诺（详见《AI API SLA 谈判》数据合规章节）。不要因为做灾备反而把数据合规做差了。
• 成本：多供应商意味着多份最低消费（如果你的供应商有最低消费），和**每个供应商的监控告警成本**。算总账：是否比把全部流量跑在一家 +50% 缓冲池还贵？多区域部署细节详见《多区域部署》。
• 罢工性价比：当一个团队只有 3-5 个工程师时，灾备的实施成本可能远超故障损失本身。这时候要做的是找一个稳定的聚合网关（它已经做了多供应商灾备），而不是自己拼。

九、落地清单：按梯度来

1. 本周：在代码里写 model 级降级链（同供应商），加超时重试。一周内有保护。
2. 本月：接入第二家供应商并跑 10% 流量（同一家或异质），做一次主动吊销主供应商 key 的演练。
3. 本季度：把灾备监控接入告警系统，做「连续 3 分钟主供应商错误率 > 30% 自动切备」的自动降级触发。
4. 下季度：异质化降级（不同模型家族），覆盖上游模型本身的 bug 风险。

灾备的核心不是「一次到位的最完美架构」，而是梯度递增、随时可用、跑得到演练。先把第一层做到本周能上线，不要等一个想象中完美的方案。现在就注册 DrAI拿一个 Key，跑通第一个模型级降级链，把你的业务从「单点裸奔」拉出来。