这样的场景，几乎每个接大模型的团队都经历过。凌晨两点,告警群炸了。用户反馈 AI 功能全部超时,值班同学排查半小时,最后发现:不是我们的问题,是模型厂商的 API 挂了。而我们,什么也做不了,只能等。

很多人默认大模型 API 有 99.9% 的可用性,现实却远没这么乐观。据 Uptime Institute 2025 年的监测,主流大模型 API 的可用性普遍不足 99%——换算下来每年宕机超过 3.5 天,而同期三大云厂商仅约 2.5 小时。过去一年,几乎所有主流厂商——无论国产还是海外——都出现过不同程度的可用性事故:接口超时、限流收紧、区域性不可用、甚至账号风控误伤。对模型厂商来说,这是一次中等级别的事故;但对把核心功能压在单一模型上的你来说,这就是全线瘫痪。
这篇文章讲清楚一件事:如何用最小的改造成本,让你的服务在任何一家模型挂掉时,依然稳定可用。

一、先想清楚:你的依赖有多脆弱?
自查三个问题:
1. 你的核心链路是否只依赖一家模型厂商?
2. 如果这家厂商现在开始返回 429(限流)或 5xx,你的代码会发生什么?是优雅降级,还是直接把错误抛给用户?
3. 从"发现故障"到"切换到备用方案",你们需要多久?是秒级自动切换,还是需要工程师改代码、发版本?

如果第 1 题答"是"、第 3 题答"要发版",那你的 AI 功能可用性上限,就是这家模型厂商的可用性——而且是打折后的,因为你还要叠加自己的故障率。

二、容灾的四个层次

多模型容灾不是一步到位的,按投入从低到高分四层:
第一层:重试 + 超时控制(及格线)
最基础的防护。对可重试错误(超时、5xx、429)做指数退避重试,同时设置合理的整体超时,避免请求无限挂起拖垮自己的服务。
注意一个坑:429 限流时盲目重试会雪上加霜,要识别厂商返回的 retry-after,或者直接触发下一层的切换逻辑。
第二层:同厂商多 Key / 多区域
准备多个 API Key 做负载均衡,或者接入同一厂商的不同区域节点。能扛住单 Key 被风控、单区域抖动的情况,但厂商级故障(整体服务不可用)依然扛不住。
第三层:跨厂商 Failover(真正的容灾)
这是本文的重点。准备至少两家能力相近的模型作为主备,主模型连续失败达到阈值时,自动把流量切到备用模型。
关键设计点:

• 熔断器模式:不要每个请求都先打主模型、失败再切备用——这会让每个请求都承担一次超时等待。正确做法是引入熔断器:主模型错误率超过阈值后"跳闸",后续请求直接走备用模型,一段时间后放少量探测流量验证主模型是否恢复。
• 模型能力对齐:主备模型的上下文长度、函数调用支持、输出格式要提前对齐测试,别等切换了才发现备用模型不支持你依赖的特性。
• Prompt 兼容性:同一套 prompt 在不同模型上表现可能有差异,核心场景要对备用模型做过回归测试。
• 第四层:智能路由(锦上添花)

在容灾之上,按请求特征动态选择模型:简单任务走便宜快速的模型,复杂任务走能力强的模型,顺便把成本也优化了。这一层不是容灾必需,但架构上和第三层是同一套东西。

三、实操:代码怎么写
反面教材:直连厂商 SDK

问题在于:模型厂商的 SDK、鉴权、请求格式全部散落在业务代码里。想加一个备用模型?每个调用点都要改。

正确姿势:先收拢,再容灾
第一步,把所有模型调用收拢到一个统一入口(大部分厂商都兼容 OpenAI 格式,这一步成本很低):

第二步,在这个入口内部实现熔断和切换:

上面是简化示意,生产环境还要补上:并发安全、半开状态的探测流量控制、按错误类型区分计数(业务错误不应触发熔断)、以及最重要的——切换事件的告警和看板。静默切换很危险,你需要知道现在流量跑在哪个模型上、成本发生了什么变化。

别忘了演练

容灾方案没演练过等于没有。上线后至少做一次故障注入:人为把主模型的 Key 换成无效 Key,观察流量是否在预期时间内切到备用模型、告警是否触发、恢复后是否自动切回。

四、自研还是用现成方案?
看到这里你可能在想:这套东西自己写要多久?
诚实的答案是:demo 一天,生产可用一到两周,长期维护无限期。因为除了上面的核心逻辑,你还会陆续遇到:各厂商接口差异的适配、流式响应下的失败切换、新模型接入、Key 池管理、分业务的用量统计和限额……这些活不难,但琐碎且持续。
三种路线的取舍:

方案	适合谁	代价
自研网关层	有富余后端人力、定制需求重的团队	持续的开发维护投入
开源自建(如 OneAPI 等)	愿意自己运维、对数据经过第三方敏感的团队	部署运维成本,升级踩坑自己扛
托管模型网关	想把精力留给业务的中小团队	按用量付费,需评估服务方的稳定性

判断标准很简单:模型调度是不是你的核心竞争力? 如果不是,它就是典型的该外包的脏活。

五、落地 Checklist
最后送一份自查清单,逐条打勾:
☐  所有模型调用已收拢到统一入口,业务代码不直连厂商 SDK
☐  至少接入两家能力对齐的模型厂商,备用模型跑过核心场景回归
☐  有超时控制 + 区分错误类型的重试策略
☐  有熔断机制,主模型故障时秒级自动切换,无需发版
☐  切换事件有告警,当前流量分布有看板
☐  分业务/分环境的 Key 管理和用量统计
☐  做过至少一次故障注入演练

大模型正在成为和数据库、消息队列同级别的基础依赖。数据库我们讲主从、讲多活,模型 API 凭什么可以裸奔?
希望这篇文章能帮你在下一次"厂商挂了"的凌晨,睡个好觉。

U-Eval 是友盟+推出的模型网关服务，一站式接入多家主流大模型，内置故障切换、Key 管理与成本看板，帮助企业以最小改造成本获得多模型容灾能力。上面 Checklist 里的能力接入即得，首次使用限时赠送500万+tokens，活动截止至9月30日。官网地址：https://aihub.umeng.com/ai-eval