上篇聊了用竞技场模式做模型选型，评论区问得最多的是后续：选出来了，生产怎么接？现实里没人敢把业务绑死在单一模型上——供应商迭代快、偶发故障、价格波动，多供应商接入几乎是标配。但接了三家供应商之后，路由、降级、成本核算的复杂度全来了。这篇给一套轻量的模型网关设计。
模型网关要解决的四个问题
- 统一接口：把不同供应商的 API 差异（参数名、流式事件格式、错误码）收敛成一个内部标准。业务方面向内部 API 开发，换供应商不改代码。
- 智能路由：请求该发给谁？按维度组合决策——模型能力（这个任务要推理强的还是快的）、成本（同档模型谁便宜）、可用性（谁健康）、合规（哪些数据允许出域到哪些供应商）。
- 自动降级：主供应商故障或限流，无缝切备用。关键设计：降级是网关的事，业务方无感知——错误码统一翻译，流式响应的断点语义保持一致。
- 成本核算：多供应商的账单口径不同（有的按字符有的按 token），网关层统一计量，按业务线/应用维度出账。没有这一层，月底财务对账是灾难。
路由策略的三个层级
起步用静态映射：任务类型 → 供应商（客服问答 → 便宜的小模型，复杂推理 → 旗舰模型）。这套规则简单，覆盖 80% 场景。
进阶用分级路由：同一任务按内容复杂度分流——先过一个小分类器（或规则），简单请求走便宜模型，置信度低的走强模型。成本能砍 40% 以上，质量几乎无损。
高级玩法是动态权重：按各供应商的实时错误率、延迟、当日预算余量动态调整流量比例。建议在监控数据稳定运行三个月后再上——没有数据积累的动态路由是玄学。
避坑清单
- 语义对齐测试：换供应商不是配置变更，是行为变更——同一 prompt 在不同模型的输出风格差异很大，网关切换前必须跑自有用例回归（这就是竞技场那套评估的复用）。
- 流式响应的降级陷阱：主模型流式输出到一半挂了，切到备用模型重新生成，用户看到回答「重播」——体验很怪。策略：流式开始后故障就报错，降级只发生在请求初期。
- 别把网关做成黑盒：每次路由决策记录「为什么发给这家」（规则命中/健康度/成本），排查「为什么这个回答变差了」时，路由日志是头号线索。
落地成本估算
一个三人小团队两周可以搭起静态路由版网关（统一接口 + 健康检查 + 基础计量），三个月演进到分级路由。值不值？看你接入的供应商数量：两家以上，网关的投入就开始回本——省下的是每个业务方各写一套适配层的重复劳动，和供应商故障时的应急时间。
模型层的技术选型会一直变，网关的意义是把「变」关在一个盒子里。
（模型工程系列：迁移评估 → 竞技场选型 → 本文：网关路由）
