同一套业务代码，dev 环境用本地 Ollama 跑小模型，prod 环境用阿里百炼的 Qwen 大模型，怎么零改动切换？答案是：业务不该知道后端是谁------这个决策由网关一层统一完成。
核心论点
网关按模型名把流量分到不同后端，业务只认一套 OpenAI 兼容接口。后端分三层：本地推理 （Ollama）/ 自托管 GPU （vLLM）/ 托管云 LLM（百炼、Azure、Bedrock 都是可替换实例，无特权）。业务对这三层完全无感的前提是流量经网关------若某服务直连供应商，后端切换就够不到它。
路由依据：按模型名分流
网关对 local/* 与本地小模型名走本地推理，其余走云厂商------路由键就是"模型名"。
| 逻辑模型名 | 后端 | 适用场景 |
|---|---|---|
local/* |
Ollama | 高频简单意图（分类/路由预判） |
qwen* |
百炼（阿里） | 通用业务 |
gpt-* |
Azure | 高质量场景 |
claude* |
Bedrock | 特定能力 |
决策：模型名天然携带"该去哪"的语义，比在业务里写 if-else 干净。若在业务里写死后端选择，引擎替换就要改遍所有调用点，零改动契约破灭。模型名还是可扩展维度，后续加租户/成本路由不改动业务。
为什么业务无感：兼容层是关键
网关对外只暴露 OpenAI 兼容接口（/v1/chat/completions），业务用同一套 SDK 调用。背后是 Ollama 还是 vLLM，对业务是黑盒。
兼容层让"推理引擎"变成可插拔组件------这是引擎可替换的技术前提。没有兼容层，换一家厂商就要换一套 SDK，零改动无从谈起。
引擎可替换性 = 架构韧性
| 场景 | 网关配置变更 | 业务改动 |
|---|---|---|
| 无 GPU → 本地推理 | 指向 Ollama | 零 |
| 有 GPU → 自托管 | 指向 vLLM | 零 |
| 换云厂商 | 改后端地址 | 零 |
| 某厂商限流 | 切另一家 | 零 |
引擎选型是"部署适配"，不进架构主线。架构只保证"网关抽象了引擎"这一点。
多后端并存与故障转移
某云厂商限流时，网关切另一家做故障转移，业务侧无感。多后端不是炫技，是对"单点供应商风险"的工程解法------单后端意味着供应商可用性直接等于业务可用性。
但 fallback 有三种情况，处理方式完全不同：
| fallback 类型 | 对业务的影响 | 处理方式 |
|---|---|---|
| 同模型跨厂商（Azure ↔ 百炼的 gpt-4o 类） | 语义差异小 | 透明，metadata 记录 |
| 跨模型降级（大模型 → 本地小模型） | 质量可能明显下降 | 业务侧需感知，触发质量监控/人在回路 |
| 全挂（所有后端不可用） | 服务中断 | 返回结构化错误 fail-closed |
关键决策 ：切换不主动通知调用方------"后端对业务无感"正是引擎可替换的核心收益。但不通知 ≠ 不可见：响应 metadata 带回证据（X-Upstream-Model / X-Fallback: true），调用方按需读取。
跨模型降级的质量风险不靠路由自己解决，而是靠系列其他篇接力：09 监控 golden signal 的"质量退化"、05 自愈闭环把"fallback 比例突增"当异常信号、关键业务检测到走 fallback 模型时强制升级人工。
fallback 分级契约的落地缺口常在这里：全挂时绝不能返回降级模型的空壳或缓存旧答案冒充成功------调用方以为成功、实际是错的，比直接报错更危险。
路由实现：基于 LiteLLM Proxy
路由是通用能力，直接基于 LiteLLM Proxy 的路由配置实现，无需自研。路由策略通过 LiteLLM 的 config.yaml 声明式配置，而非业务代码中的 if-else。
治理耦合层（成本/护栏/缓存）通过 LiteLLM 的 callback hook 二次开发实现（详见 01 篇选型决策）。
核心要点
- 路由的价值不在"会分流量"，在"把推理引擎变成网关身后的可替换零件"。
- 业务无感的前提是流量经网关；引擎可替换性 = 架构韧性。
- fallback 分三级：同模型跨厂商透明、跨模型降级需感知、全挂 fail-closed。
- 全挂时绝不返回降级空壳冒充成功------比直接报错更危险。