2 篇博文 含有标签「model-cascades」

部署在 Web 集群前的负载均衡器之所以有效，是因为每台机器都会上报信息：CPU、队列深度、错误率、延迟。均衡器根据这些负载信息进行路由。模型路由器（Model Router）则拿不到这些遥测数据。它在模型执行任何操作之前，仅凭查询内容就决定由哪个模型来处理。路由器根据提示词（Prompt）预测难度。但真正的难度只有在生成答案时才会显现。当信号产生时，路由决策已经过去三秒钟了，而廉价模型可能已经向你的用户发送了一个自信但错误的回复。

这是模型路由核心的结构性缺陷，但大多数团队在发布路由器时从未这样审视过它。他们将其视为一个分类器——训练一个模型将查询标记为“简单”或“困难”，在预留集上进行验证，当准确率超过 90% 时就发布。分类器的隐喻在关键之处是错误的。分类器预测的是一个已经存在的标签。而路由器预测的是一个尚不存在、直到被路由的模型给出答案后才会存在、且可能永远不会以足够干净的形式存在以便学习的标签。

我上个季度交流过的一个团队发布了一个模型路由（model router），在离线基准测试中获得了 96% 的路由准确率，并使平均推理成本降低了 58%。但在运行三周后，支持工单开始集中在特定的用户群体中——即那些通过 API 运行脚本化批量查询的企业管理员。低成本路径向这些用户发送了大量垃圾回复。路由完全按照设计运行，但设计本身错了。

这个故事代表了常态，而非特例。“能用小模型就用小模型，必须用大模型时才用大模型”的架构是生产环境下 LLM 系统中最可靠的成本杠杆之一，在标准基准测试中记录的成本降幅在 45% 到 85% 之间。但每个路由演示中引用的节省数字都假设了基准测试的分布。生产流量并不具备这种形态，而两者之间的差距正是质量回退（quality regressions）存在的地方——这些回退集中在你的离线评估（eval）从未设计覆盖的细分领域。