先这样答
落地多模型分级路由，主要从策略分流、陷阱防范和持续迭代三个维度来考虑。核心是通过合理的调度机制，在推理成本和生成质量之间找到平衡。
在策略设计上，通常按照任务类型、模型置信度或问题复杂度来进行分流。对于简单的抽取或判定任务，直接交由小模型处理；当遇到复杂推理任务，或者小模型给出结果的置信度较低时，触发升级机制，将请求转交给参数量更大的模型。整个升级链路中必须设置回退兜底逻辑，以应对大模型侧偶发的超时或服务不可用情况，防止任务直接中断。
落地过程中最容易踩中两个陷阱。第一个是路由误判产生的隐性成本，如果该升级的任务没有升级，会直接损害业务的生成质量；如果不该升级的任务被错误升级，则会白白消耗算力资金。第二个是延迟叠加问题，路由器本身的判断耗时会叠加在主链路的推理耗时之上，对响应速度要求高的场景影响明显。此外，在灰度上线期间，需要对成本和质量的指标口径进行严格对齐，防止评估失真。
在后续迭代中，通常会把线上运行积累的真实日志抽样，用来训练或微调专门的路由分类器。工程团队需要定期回测路由的准确率，并监控整体的成本与质量曲线变化。总体而言，分级路由的设计重在动态演进，靠真实数据驱动路由策略的调优。
面试官会怎么追问
-
「如果路由误判导致成本超标，你会怎么排查和调整？」 首先检查灰度发布期间的指标统计口径是否一致，确认成本计算没有出现偏差。然后提取线上日志中被错误升级的请求样本，分析这些样本的复杂度特征，将它们加入训练集重新微调路由分类器，并再次回测整体的成本与质量曲线。
-
「升级链路中的回退兜底具体怎么做？」 当请求因为置信度低而升级到大模型后，如果大模型发生超时或返回格式错误，系统需要自动降级调用备用的稳定模型。这种兜底机制可以保证业务主链路的可用性，防止大模型侧的波动直接导致用户端的任务中断。
-
「路由器的延迟叠加对主链路影响很大，有什么优化方向？」 路由判断的耗时会直接增加用户的等待时间。通常可以把复杂的路由逻辑替换为轻量的分类器，或者仅针对特定任务类型进行试探性调用，通过精简路由本身的计算量来控制整体的延迟时间。
回答的坑
- 误以为分级路由只要接上大模型和小模型就能自动省钱，忽略了路由误判既会伤质量又会白花钱的风险。
- 只谈初始的路由规则设计，没有提到利用线上日志训练分类器和定期回测成本曲线的持续迭代过程。
同系列的题