最近读到Switchcraft这篇论文，核心思路其实很直接：现有的模型路由选择器（如RouteLLM、SGLang的router）都是为对话补全设计的，它们假设任务就是续写或生成文本，但工具调用场景下的路由逻辑完全不同——你需要判断的不是语义相似度，而是任务是否可被小模型正确完成，比如调用API、执行代码或查询数据库。Switchcraft的关键创新在于“内联式”路由：它在推理过程中实时分析工具调用的输入和预期输出格式，而不是像传统路由那样靠离线分类器或阈值。从实验数据看，它在保持GPT-4级正确率的前提下，将推理成本降低了40%-60%，这在实际部署中意义重大。
我个人经验是，去年在做企业内部Agent系统时，我们尝试过用Mixtral 8x7B做默认模型，但遇到复杂SQL查询或多步工具链时，小模型频繁出错，最后不得不全量切回GPT-4，成本翻了三倍。Switchcraft的方案如果成熟，其实能解决这一痛点：它本质上是一个轻量级的“任务复杂度预判器”，而不是简单的模型选择器。不过，我也有一个疑问：论文中测试的工具调用场景是否覆盖了多轮交互中的状态依赖？比如当Agent需要维护对话历史或中间变量时，路由决策会变得非常复杂，因为小模型可能在局部正确，但全局上下文丢失。
从行业视野看，我认为工具调用路由将成为LLM推理优化的下一个热点。目前大家的目光都集中在KV Cache量化、投机解码等通用技术，但实际企业部署中，80%的高成本都来自那些本可以被小模型完成的简单工具调用。Switchcraft的意义在于它把路由粒度从“会话级”降到了“函数调用级”，这可能会推动MaaS平台（如Anyscale、Replicate）提供更细粒度的计费策略。
抛个问题：如果路由选择器本身也面临延迟开销和误判风险，你们认为在实时性要求高的场景（比如客服对话中的数据库查询），这种内联路由是否真的能落地？还是说更适合离线批处理场景？