大模型应用上线后，很快会遇到一个现实问题：所有请求都用最强模型，效果可能不错，但成本高、延迟长；全部换成小模型，成本下来了，复杂任务质量又不稳定。模型路由就是在这个矛盾里出现的。
不过，模型路由不是单纯省钱技巧。真正成熟的路由，要同时考虑任务难度、风险等级、用户体验、成本预算和失败兜底。
先按任务分层
不是所有请求都需要大模型。规则能稳定解决的，就不必调用模型；小模型能完成的分类、改写、简单抽取，也不必动用强模型；需要复杂推理、多轮上下文、专业判断或高质量生成时，再使用更强模型。
比如意图识别可以先走规则和小模型，简历深度诊断再走强模型；知识库问答可以先判断是否能从检索资料直接回答，证据不足时拒答或追问，而不是盲目升级模型编一个答案。
风险比难度更重要
任务难不难是一回事，风险高不高是另一回事。一个文本润色任务可能难度不高，风险也低；一个订单取消或合同解释任务，即使模型能理解，也应该更谨慎。高风险任务需要权限校验、二次确认、审计日志，甚至人工介入。
所以模型路由不能只看 prompt 长度或分类标签，还要看业务后果。会产生真实操作、影响财务结果、涉及隐私数据或可能误导用户决策的请求，必须走更严格路径。
缓存和复用是路由的一部分
很多请求并不需要每次重新生成。高频问答、固定解释、公共知识摘要可以缓存；长对话可以摘要历史状态；重复检索结果可以复用。缓存命中不仅省成本，也能降低延迟。
但缓存也有边界。个性化强、权限相关、知识库刚更新、用户状态变化的回答不能随便复用旧结果。缓存键要包含必要的上下文和版本信息，否则省下的成本会换来错误答案。
降级路径要提前设计
模型调用失败时，路由系统要知道怎么退。是换一个模型，返回结构化要点，展示检索资料，提示稍后重试，还是转人工？不同场景答案不同。面试里如果只说“失败就重试”，会显得很粗。
重试也要有成本上限。模型服务抖动时，所有请求都升级到强模型或连续重试，可能让成本和延迟一起失控。更稳的做法是按错误类型和业务价值决定是否重试、是否降级、是否直接停止。
更像生产系统的表达
可以这样总结：我会把模型路由设计成任务分层系统。规则、小模型、强模型、缓存和人工兜底各自负责不同风险和难度的请求；路由决策会考虑质量、延迟、成本、权限和业务后果；每条路径都记录效果和成本，后续根据坏例和指标调整。这样模型路由才不是“便宜优先”，而是产品体验和工程可持续之间的平衡。
模型路由还需要灰度。新模型上线、提示词调整、路由规则变化，都可能影响质量。更稳的做法是先让小部分流量进入新路径，同时比较成功率、人工反馈、延迟、成本和坏例数量。指标稳定后再扩大范围。
这类回答能体现平台工程思维。模型选择不是一次配置，而是持续运营：不同模型价格会变，能力会变，业务问题也会变，路由系统必须能根据数据继续调整。