模型路由：把简单请求分给小模型的收益与风险

同一批请求的难度差别很大。有的是格式化改写、简单问答，需要的能力较轻；有的涉及多步推理或长上下文，难度高得多。如果全部按最高难度配置处理，浪费明显；按难度分流，让轻量请求走小模型，整体开销会下降。这个思路并不新，难点全在分流判断本身。

常见的判断方式有三类。规则式依靠关键词与长度，简单可靠但覆盖不全；分类式用小模型先做一次意图与难度判别，速度快但会引入额外一次调用；置信式根据输出质量指标回退，先按轻量方案跑，效果不达标再升级处理，代价是响应时间不确定。

风险主要来自误判的分布。把困难请求当成简单请求，用户直接感受到答案质量下降；把简单请求当成困难请求，损失的是成本，但用户察觉不到。这两种错误的业务影响不对称，所以阈值通常偏保守，宁多花一些成本也要确保体验下限。

工程上还有一项容易忽略的工作是可观测性。分流决策必须被记录下来：这条请求走了哪条路径、依据什么判断、有没有触发回退。没有这份数据，就无法验证阈值是否合理，也只能靠用户投诉来发现误判。日志收集与成本之间要做取舍，常见做法是保留全量指标、抽样原始文本。

对小团队而言，落地顺序可以很清楚：先把请求按类型分桶，用最简单的规则做粗分流；跑一段时间后统计各桶的实际处理质量与成本，再考虑引入判别模型。一上来就做复杂路由，往往会把系统调试难度推高到自己控制不了的程度。