一个大模型应用从 PoC 走到生产，最容易被低估的不是模型能力，而是控制面：同样一个功能，PoC 只需要证明“能答对一次”，生产要证明它稳定、成本可控、延迟可接受、还能被观测。
模型路由就是这中间绕不开的工程账。把所有请求都打给最强的模型，成本和延迟都扛不住；全用小模型，复杂任务又答不好。你要用路由解决的是“什么请求走什么模型、失败了怎么退”。
一、为什么单模型不够
三个现实压力：
- 成本：长上下文、高频调用下，贵模型的账单会很快超预算。
- 延迟：交互式场景里，用户不愿意为一个简单问题等好几秒（体感上超过 3 秒就明显偏慢）。
- 降级：主模型限流或不可用时，要有退路，而不是直接报错给用户。
二、路由的几个维度
不必一上来就上复杂的判别模型。先用确定性规则兜底，复杂再叠加：
- 任务类型：分类/抽取这类结构化任务用小模型；需要推理、长文生成的走大模型。
- 上下文长度：超过阈值走长上下文模型或先做压缩。
- 失败退避：主模型超时/限流 → 退到备用模型或备用供应商。
function routeModel(req: Request): ModelChoice {
if (req.taskType === "classify" || req.tokens < 1_000) return "fast";
if (req.tokens > CONTEXT_LIMIT) return "long-context";
return "strong";
}
// 失败退避与预算检查在调用层包一层，路由只负责“默认选谁”
三、预算与“静默截断”的坑
给 token/成本设预算是对的，但降级方式很关键。常见的错误是：上下文超了就静默截断到能塞进去为止——结果模型基于不完整的数据作答，还把部分结果当成完整结果返回。
正确做法是分阶段降级并显式告知：
- 优先按字段/优先级压缩上下文，保留“记录总数”等完整性信号；
- 真要截断，明确告诉模型“数据不完整”，让它在回答里体现，而不是假装看全了；
- 预算触顶时降级到更省的模型或返回“需要人工”，而不是继续烧。
四、把路由决策也观测起来
路由本身要可观测：每次请求记下选了哪个模型、为什么、耗时、token、是否发生降级。否则成本异常和质量回退都查不清根因。
flowchart LR
A[请求] --> B{分类/长度判断}
B -->|简单| C[快模型]
B -->|复杂| D[强模型]
B -->|超长| E[长上下文/先压缩]
C --> F{失败?}
D --> F
F -->|是| G[退避到备用模型]
F -->|否| H[返回 + 记录路由指标]
常见问答
Q：路由该用规则还是判别模型？ A：先用规则兜底（长度、任务类型），成本/质量收益明确时再叠加判别模型。一上来就用模型做路由，反而增加了不可观测的环节。
Q：预算超了到底怎么处理？ A：分阶段降级——先压缩、再换省模型、最后转人工或返回明确的不可用，绝不静默截断破坏答案完整性。
Q：多供应商备份值得做吗？ A：对可用性要求高的生产系统值得。主供应商限流/故障时能退到备用，是稳定性的一部分。
模型路由做对了，成本和延迟才可控、质量回退才查得清。这类“从 PoC 到生产”的工程判断，正是生产就绪审查里成本与可观测性两个支柱会逐项对照的地方。想按成本、延迟、降级三条线自查你的路由设计，可以做一次生产就绪自检。