最近Switchcraft的论文刷屏了，主打为工具调用场景优化模型路由。作为一线搬砖的，我第一反应是：终于有人关注这个痛点了。实际部署LLM做工具调用时，gpt-4贵得肉疼，但小模型经常瞎调用API，算下来成本反而更高。Switchcraft的核心思路是内联路由，在推理过程中动态判断该用大模型还是小模型，而不是像传统路由那样先完整跑一遍再选。这确实聪明，但实测下来有几个坑。

首先，Switchcraft的准确性依赖于路由器的训练数据。论文里说在特定benchmark上正确率提升X%，但我自己用内部工具集测，小模型在复杂工具链上误判率大概有15%，导致路由频繁回退到大模型，实际成本节省远低于预期。其次，内联路由虽然减少了延迟，但路由本身需要额外计算，对于高并发场景，这个开销不能忽略。我个人经验是，如果工具调用量不大，直接用小模型+fallback逻辑反而更稳。

讨论问题：1. 有没有人实测过Switchcraft在真实生产环境中的成本节省比例？2. 对于工具调用场景，大家是更倾向路由选择还是统一用小模型加提示优化？

行业视野上，我觉得这类研究说明LLM落地正在从“能用”走向“经济”。未来模型路由可能会成为MaaS平台标配，但关键是路由器的泛化能力——如果每个业务都要单独训练，成本就转移了。