LangChain测试英伟达Switchyard：智能体仅 7% 调用需前沿模型，成本降 74%
LangChain在 145 个智能体任务上评测了英伟达开源路由库NeMo Switchyard。结果显示，仅 7% 的调用真正需要前沿模型，路由使总成本降低 74%，但准确率下降 6 个百分点。
AI解读：智能体的每次工具调用都消耗模型费用，而大多数任务其实并不需要最贵、最强的模型。LangChain通过测试英伟达的NeMo Switchyard路由库证实了这一点：在 145 个模拟客服、运维和流程自动化的任务里，路由器只用 7% 的调用请求前沿模型（Claude Opus 4.8），其余 93% 交给 30B参数的Nemotron 3.5 Lightning处理。结果是总成本比全部使用Opus降低 74%，但准确率从 86% 降到 80%。为什么准确率会降？因为廉价的闪电模型处理了绝大多数简单任务，只有当它连续两次出错时才升级到Opus。这种设计对需要前沿模型能力但无法预先判断请求难易的团队最有价值。不过LangChain也提醒，测试场景相对简单（模型间准确率差距只有 8 个百分点），真实工作负载可能更难。一个关键数字是：路由中的裁判模型占了 21.2% 的开销，想进一步省钱应该换更便宜的裁判。如果你的任务模型间价格差距不大，路由可能不划算；但如果廉价的本地模型几乎免费，路由又变得有利。普通用户不需要做任何事，这只是智能体开发者的成本核算工具；开发者可以用文中给出的公式判断路由是否省钱，再在自己的数据上跑一遍验证。
LangChain在其Deep Agents评估套件上测试了英伟达的开源模型路由库Switchyard，结果显示，在 145 个多步智能体任务中，仅 7% 的模型调用真正需要前沿模型；约 93% 的调用可由 30B参数的NVIDIA Nemotron 3.5 Lightning处理。路由方案对比单独使用Opus，总成本降低 74%，准确率从 86.0% 降至 80.0%。
所有评估均在受控场景下运行，LangChain表示任务相对简单，模型间准确率差异只有 8 个百分点，路由的优势可能被低估。
评估设置与成本数据
LangChain使用 145 个多步智能体任务，平均每个任务调用 6.3 次模型。任务涵盖受策略约束的客服对话、值班事件调查、跨消息/工单/邮件的多步工作流自动化；场景来自 τ²-bench airline、伯克利函数调用排行榜、FRAMES和Nexus。
三组对照的成本与准确率如下（缓存输入按缓存价计费）：
Opus 4.8单独运行：准确率 86.0%，每次运行成本 11.45 美元，每个完成任务成本 0.092 美元。
Opus + Nemotron 3.5 Lightning（经Switchyard路由）：准确率 80.0%，每次运行成本 3.00 美元，每个完成任务成本 0.026 美元。
Nemotron 3.5 Lightning单独运行：准确率 77.7%，每次运行成本 0.72 美元，每个完成任务成本 0.006 美元。
路由方案中，Nemotron 3.5 Lightning处理了 93% 的调用，占支出 10.4%；Opus仅处理 7% 的调用，却占支出 68.4%。LangChain指出，最后 6 个百分点的准确率，每个完成任务的成本是 3.5 倍。
- 法官模型（judge）占路由方案支出的 21.2%，是仅次于Opus的第二大成本项；它每次在弱模型回合后运行，且无法利用提示缓存。LangChain建议，若要削减路由成本，优化法官模型比调整升级率更有效。
- 准确率差距在单次运行的波动范围（约 ±2.7 点）之外，LangChain认为 6 个点的下降是真实存在，并非噪声。
- 成本节省主要来自将简单任务转向廉价模型：将Opus用于廉价模型失败的任务，比全用廉价模型高 2.3 点，但低于单次运行的波动，因此无法得出结论。
成本波动范围与公式
在五次运行中，送往前沿模型的流量比例介于 4.1% 至 9.1%，平均 6.9%，最重的一次比最轻的多升级了一倍以上。Opus单次调用成本 0.0324 美元，而Nemotron 3.5 Lightning为 0.00037 美元，相差约 87 倍；这导致每次运行成本在 2.16 至 3.61 美元之间波动，尽管除路由决策外没有其他变化。LangChain建议按范围上限做预算，并指出“连续确认次数（confirmations）”是调整升级频率的关键设置。
LangChain给出了一个判断路由是否划算的公式：当廉价模型承担的比例高于“法官成本 /（昂贵模型成本 – 廉价模型成本）”时，路由才是划算的。在本次配对中，法官模型每次运行成本 0.64 美元，价格差为 10.73 美元，所需最低卸载比例为 5.9%；实际卸载了 93%，超过门槛 16 倍。
当两个模型价格接近时，公式可能要求卸载比例超过 100%，意味着路由不划算；但如果廉价模型是本地部署（如NVIDIA DGX Spark），推理成本近乎为零，路由又可能变得划算。LangChain提醒，公式只能判断成本是否划算，不能保证路由在特定流量上的决策质量，需要用自己的工作负载验证。
- 单次运行的节省幅度在 68.5% 到 81.1% 之间，主要因升级频率而异。
- Opus单独运行的每次成本在三次运行中仅波动 1.5%，因此 74% 的降幅基于稳定基线。
何时不应使用路由
LangChain列出了两种不适合路由的场景：对延迟敏感时，因为法官模型是每回合额外的模型调用，大约 700 毫秒；任务较短时，因为升级机制需要长对话轨迹作为判断依据。
对于研究性的开关，LangChain提到“prefill-activation MLP”路由方法仍处于研究阶段，而“阶段路由器”（启发式）不增加额外调用但对流量信号有依赖，未纳入本次基准测试。
- 本次测试配置为升级模式（type = "llm_classifier"，mode = "escalation"），默认连续两次负面评判后触发升级；LangChain未单独测试单次确认的情况。
- 法官模型使用Gemini 3.1 Flash Lite作为示例客户端，但文中未指定具体型号。
运行两种方式与未来测试
LangChain描述了两种运行Switchyard的方式：一是作为服务器运行，客户端的base_url指向其代理，代理可使用统一配置（含OpenAI与Anthropic接口模型）；二是作为Deep Agents的中间件运行，在进程内路由，无需独立服务器。中间件目前处于实验阶段，尚未以包形式发布，需要克隆代码并在Python 3.12和deepagents 0.7.4或更新版本上安装。
LangChain表示，如果最小成本是优先考虑项，且工作负载与本次测试类似，单独使用Nemotron 3.5 Lightning是更优选择；路由适合无法预先知道哪些请求简单或困难的团队。
- LangChain下一步计划测试更便宜或本地部署的法官模型，以及更困难的工作负载来验证路由的价值。