Model Routing 与 Fallback 架构

比较 Static Alias、Policy Router、Quality Cascade 与 Race / Ensemble 四种模型路由拓扑：选模型的决定在哪个节点做、读的是什么状态、什么时候允许换模型、选错之后波及多远。

「主模型失败就换另一个」不是一个完整的 fallback 设计。不同模型的 output schema、tool support、context window、data region 和 safety 行为都可能不同，换错一次就是一次没人通知的行为变更。四个问题决定了架构：选模型的决定在哪个节点做、它读的是什么状态、什么时候允许换模型、选错之后波及多远、怎么收住。

想亲手走一遍四种拓扑、注入故障再恢复，打开互动 Lab：/system-design-lab/model-routing-fallback-architectures。

四种 Model routing 与 fallback 架构

有约束的设计问题

一个多租户的 AI 产品有四类需求：只用一个默认模型、要能安全升级版本、配额用完时能切到另一份配额；租户在数据区域、允许的模型、预算和是否需要工具调用上各不相同；请求量很大、大多简单、少数很难、成本敏感；少量面向客户的关键请求，一次答错代价很大、一个部署满足不了延迟和可用性目标、成本可以多付几倍。每一类该用哪种路由架构？

四种 topology signature

架构	决策点	State owner	允许换模型吗	适合	主要代价
Static Alias	网关按带版本的配置解析别名	routing config（alias → model@version → deployments）	不允许；只在同一模型同一版本的部署之间故障转移	一个默认模型、安全发版、容量故障转移	别名配错或版本一升级，全部流量同时受影响
Policy Router	调用前的规则引擎	tenant policy + usage meter	允许，在调用前、在租户允许的集合内	租户在区域、能力、预算上各不相同	策略漏洞把租户送到禁用的模型或吃光预算
Quality Cascade	便宜模型答完后的打分器	attempt record	允许，只向上升级，且必须经过打分	大部分请求简单、少数很难	打分器放过差草稿；升级率一高比直接用强模型还贵
Race / Ensemble	并行候选之上的裁判	request + candidate set	允许，每个请求都比一次	高价值、延迟敏感或可靠性关键的请求	成本乘以并发数；裁判会错；并行调用一起触发限流

1. Static Alias：别名指向一个版本，只在同版本部署间切换

应用只认一个别名，例如 chat-default。网关从带版本的路由配置里把它解析成一个模型版本和这个版本的几个部署，正常调用部署 A；A 返回 429 时，网关按响应里的 Retry-After 把 A 暂时移出轮换，再把同一个请求换到部署 B。B 和 A 是同一模型同一版本，只是另一份配额，所以回答的行为不会变。

Microsoft 的网关指南把这条规则写得很直接：无论是轮询还是故障转移，包括 provisioned 容量溢出到 standard 部署，所有端点都必须运行同一模型的同一版本，不能从版本 X 切到版本 Y。没有网关的时候，重试、退避和熔断要每个客户端自己写，改一次配置要逐个客户端发版；有了网关，这些都收敛到一处，蓝绿或金丝雀换版本也在网关里做。

代价是路由配置成了单点：别名被改到新版本，所有客户端在同一秒开始得到另一个版本的回答。所以配置要版本化，改别名当作一次发版，先给一小部分流量试，出问题回滚别名。

2. Policy Router：按租户策略和用量选模型

路由器在调用前先读这个租户的策略：允许哪些模型、数据必须留在哪个区域、还剩多少预算、这次请求需要什么能力（工具调用、上下文长度、视觉输入）；再到用量表检查并扣一次这分钟的 token；然后把请求送到策略允许的那个模型。不同租户会落到不同模型，每一次选择都能从策略里解释出来，回答里带上命中的规则编号，审计时能查到是谁放行的。

LiteLLM 的 router 就是这套结构的开源实现：预检先排除上下文窗口不够或区域不对的部署，再在剩下的部署里按最少繁忙、延迟、用量或成本挑选；失败太多的部署进入冷却期。网关按租户设每分钟 token 限额和优先级，是客户端之间互相协调做不到的事。

代价在策略本身。区域规则有漏洞，EU 租户的 prompt 就在美国被处理，系统还不报错；预算不限，一个租户的批处理就把共享配额吃光，别的租户跟着收 429；预算规则把一个需要工具调用的请求送到不支持工具的模型，用户拿到一个看起来完成了、其实什么都没做的回答。修法对应三条：区域默认拒绝、显式放行；按租户限额和分级；能力过滤先于预算规则。

3. Quality Cascade：先便宜后强，打分决定升级

控制器先把请求交给便宜的模型拿一份草稿，再让打分器（verifier）按阈值评估草稿够不够好；够好就直接返回，不够才升级到强模型再答一次。每一次尝试、打分结果和各自的 token 花费都记进尝试记录（attempt record），事后能算出升级率。

FrugalGPT 把这个想法叫 LLM cascade：先问便宜的模型，并学习对不同的查询该用哪些模型组合；作者在自己的基准上报告了在匹配最好单一模型表现的同时大幅降低成本，这是论文的实验结果，不是设计目标。云厂商把同样的取舍打包进一个端点：Azure model router 对每个 prompt 实时选模型，Balanced 模式在质量带宽内选最省钱的，Cost 和 Quality 模式放宽或忽略这条带宽，有效上下文窗口是最小那个底层模型的；Amazon Bedrock 的 intelligent prompt routing 预测每个模型的回答质量，只有另一个模型的预测质量超过设定的质量差阈值才离开 fallback 模型，并在响应里返回实际用的模型。

代价有两个。打分器放过一份差草稿，用户拿到便宜模型的错误回答，还被标记为「通过」；升级率一高，每个请求都花两级的钱，级联反而比直接用强模型贵。所以要用带标准答案的数据校准打分器和阈值，定期从尝试记录里抽样人工复核「通过」的草稿，对合同、金额这类关键任务收紧阈值或直接跳过级联；按任务类型监控升级率，超过某个比例就把这类任务直接路由到强模型。升级前还要确认强模型支持同样的输出格式和工具约定，否则回答换了模型也换了形状。

4. Race / Ensemble：并行问几个模型，裁判挑一个

控制器把同一个 prompt 同时发给几个模型，各自的回答连同来源和耗时落进候选集合（candidate set）；裁判（judge）按正确性、格式、是否引用证据的标准挑出最好的一份，或者把几份合并成一份，并给出理由。竞速时裁判只等最快的一两份，延迟接近最快一路；投票或合并时要等全部候选，延迟接近最慢一路。

用几倍的成本换更低的尾延迟、更高的可用性或更好的质量，只有请求的价值配得上这个价才值得。并行调用同时消耗每一路的配额，一批高价值请求同时扇出，三个模型的配额一起被打满，连不参与竞速的普通请求也一起收到 429；所以要在网关按客户端限流、给扇出设上限、配额紧张时降级为单路调用并在回答里说明。裁判也是一个会犯错的组件：候选集合里明明有正确的一份，裁判挑了措辞更自信的那份。给裁判明确的标准并要求核对引用和数字，没有把握时退回到排名最高的模型的回答，把候选留给人工复核。

换模型之前先过四道检查

四种架构里只有一条共同规则：只有当目标模型支持同一 output schema、tool contract、data region 和 safety policy 时才能切换。OpenRouter 的 model fallbacks 会在上下文长度错误、内容审核、限流和宕机时按优先级试下一个模型，并按实际回答的模型计费；这个列表里放什么模型，仍然要由你按上面四条决定。对产生外部副作用的工具调用，模型重试不能重复执行，执行层需要独立的幂等键。有状态的交互（会话、assistant）要钉在一个后端上，中途故障转移会丢状态。流式回答经过网关不能缓冲，故障转移要拿流式响应测过。

故障与恢复

架构	故障	用户看到什么	恢复
Static Alias	别名被改到新版本，全量流量瞬间换模型	所有人同一秒拿到另一个版本的回答，下游解析可能整体失败	配置版本化并走金丝雀；回滚别名；回答里带实际版本
Static Alias	两个部署同时限流	请求变慢或失败，来回重试给过载的部署添压	按每个部署的 `Retry-After` 熔断；低优先级排队；同版本再加一份配额池溢出
Policy Router	策略漏洞把 EU 租户路由到美国部署	没有报错，但数据离开了允许的区域，无法收回	区域默认拒绝、显式放行；每个租户策略有测试；每次路由记录规则编号
Policy Router	一个租户吃光共享配额	其他租户全部收到 429	按租户每分钟 token 限额；高优先级留配额；批处理排到空闲时段
Policy Router	选中的模型缺这次需要的能力	回答看起来完成了，其实没有调用任何工具	预检先按能力过滤；只在满足同样约定的模型间切换
Quality Cascade	打分器放过一份差草稿	便宜模型的错误回答被标记为「通过」	用标准答案校准阈值；抽样复核通过的草稿；关键任务收紧或跳过级联
Quality Cascade	升级率太高	延迟翻倍，成本超过直接用强模型	按任务类型监控升级率；已知难任务直接路由到强模型；前置便宜的任务分类
Race / Ensemble	并行调用一起触发限流	三家配额同时打满，普通请求也收到 429	网关按客户端限流；扇出设上限；降级为单路并说明
Race / Ensemble	裁判选中了错误的候选	付了三份成本，拿到错误的金额	裁判带标准并核对引用；没把握退回排名最高的模型；候选留给人工复核

怎么选

一个默认模型，需要安全发版和容量故障转移：Static Alias，别名后面的每个部署都在同一版本。
租户在区域、允许模型、预算或能力需求上各不相同：Policy Router，策略是唯一的决策依据，默认拒绝并记录每次路由的原因。
大部分请求简单、少数很难、有办法给草稿打分：Quality Cascade，先校准打分器，再持续监控升级率。
高价值请求，延迟和可靠性优先、成本其次，一个部署满足不了目标：Race / Ensemble，扇出设上限，裁判要有标准。
无论哪种拓扑，每次路由记录原因、每次尝试、实际回答的模型和版本、token 和成本；只记最终 provider 的响应无法审计。

回到开头的多租户产品：单一默认模型的产品线走 Static Alias；租户差异走 Policy Router；成本敏感的大流量走 Quality Cascade；面向客户的关键请求走 Race / Ensemble。

面试时这样回答

先复述约束：一个模型还是多个租户、成本敏感还是价值优先、能不能给回答打分。
说路由路径：点名图上的边，例如「别名解析后只在同版本部署间故障转移」「先读租户策略再扣用量」「便宜模型的草稿送去打分」「扇出后候选交给裁判」。
说决策依据存在哪：路由配置、租户策略、尝试记录，还是候选集合。
说代价与一个故障：例如打分器放过差草稿，修法是用标准答案校准阈值并抽样复核通过的草稿。