大模型网关的容灾设计：多活、降级与那道「最后的防线」

大模型网关（统一接入多模型的路由层）成了 AI 应用的标配中间件。它稳定时没人注意，它抖动时全公司的 AI 功能一起抖。今天聊网关自己的容灾设计——中间件的中间件，更需要高可用。

多活不是「多备几台网关」

网关是多模型的唯一入口，网关自身多活的关键不是实例数，是状态的一致性：路由规则、模型健康度、配额计数、缓存——这些状态在多活实例间如何同步。状态不同步的多活比单活更危险（两个网关认为同一个模型 health 状态相反，流量精神分裂）。

设计原则：状态外置到共享存储（配置中心/Redis），网关实例保持无状态——实例随便挂，状态只有一个真相源。健康度探测结果尤其要共享：一个实例探测到模型 A 挂了，全体实例 5 秒内知道。

降级阶梯：从「最好」到「还活着」

模型不可用时的降级阶梯，要在设计期画好，不能临场发挥：

1. 同质换模型：主模型挂→切同档位备用模型（能力相近，prompt 兼容性要提前验证——不是所有模型对同一 prompt 表现一致）
2. 降档服务：全档位都紧张→切小模型+收窄功能（长文变短文、多轮变单轮），给用户明示「当前为精简模式」比默默降质好
3. 排队+熔断：连降档容量都没有→请求排队（带预计等待）+非核心功能熔断——排队信息透明是保住用户耐心的关键
4. 最后的防线：全链路不可用时的静态兜底（缓存的历史答案+明确的服务状态声明）——这道防线希望永远用不上，但必须存在且每周演练

故障演练：容灾不是设计出来的

纸面容灾和真实容灾的差距，只有演练能暴露。季度演练清单：杀主模型看切换耗时（目标 <30 秒全量切换）、拔网关实例看状态同步（目标无流量精神分裂）、全链路压测看熔断顺序（先熔谁后熔谁和设计一致吗）。

演练发现的每一个「和设计不符」，都是未来的生产事故——提前暴露的成本是几小时，线上暴露的代价是全公司 AI 功能瘫痪。

结语

网关容灾的三句话：状态外置保多活、降级阶梯保体验、故障演练保真实。AI 应用的可用性下限，不取决于最强的模型，取决于网关在最坏时刻的兜底能力。