路由策略与引擎可替换性

同一套业务代码dev 环境用本地 Ollama 跑小模型prod 环境用阿里百炼的 Qwen 大模型怎么零改动切换答案是业务不该知道后端是谁——这个决策由网关一层统一完成。核心论点网关按模型名把流量分到不同后端业务只认一套 OpenAI 兼容接口。后端分三层本地推理Ollama/自托管 GPUvLLM/托管云 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。全挂时绝不返回降级空壳冒充成功——比直接报错更危险。