Nvidia 开源路由框架 NeMo Switchyard：让 Agent 工作流成本降至三分之一

Nvidia 昨天发布了 Nemotron 3.5 Lightning，一款 300 亿参数的开放混合专家模型，实际激活参数为 30 亿。同时发布的还有 NeMo Switchyard——一个开源路由器，用于决定在 Agent 工作流的每一步该由哪个模型来处理。

模型本身很有用。但路由器才是更有意思的部分。

大多数 Agent 技术栈最终都会遇到同样的棘手分歧：你可以把所有请求都发给最好的模型并为此付费，或者写一个小的路由层，把简单的步骤发给更便宜的模型。而这个小小的路由层随后就开始"长出獠牙"——它需要策略、需要降级逻辑、需要评估指标、需要感知何时一个廉价模型正在自信地犯错、需要足够的日志记录来解释为什么一次运行花了 2.40 美元而不是 0.18 美元。

到某个时刻，这个 Agent 不再是一个模型。它变成了一个附带了模型的小型调度系统。

这正是 Nvidia 试图用 Switchyard 产品化的方向。

一个容易记住的核心说法：Nvidia 表示 Switchyard 可以在保持前沿级任务完成率的同时，将任务完成成本削减到单独使用 Claude Opus 4.8 的近三分之一。在 LangChain 内部的 deep-agents 基准测试中，在 Nemotron 3.5 Lightning 和 Opus 4.8 之间进行路由，在 145 个多轮任务中将成本降低了 74%，只有 7% 的调用打到前沿模型，精度代价为 6%。Ramp 表示在其内部 SWE-Bench 上匹配了前沿模型的表现，同时将成本削减 58%、运行时长缩短 33%。

这些是厂商和合作伙伴的数据，所以应该像早期基准测试声明一样对待，而非物理定律。不过大体方向是对的。

Agent 的工作天然是不均匀的。

一次运行可能包含：规划、工具选择、结构清理、检索、代码编辑、文件检查、总结、验证，以及最终答案。其中某些步骤需要贵的模型，但很多步骤并不需要。如果把整个运行都打到前沿模型，你就是在为那些只需要还算可以的解析能力和耐心的活儿购买精细的判断能力。

这就是为什么枯燥的执行层很重要。有效的分割不是"大模型对小模型"，而是：用能思考的模型做规划，用足够便宜可以整天调用的模型做执行，当廉价路径开始出问题时就升级。

这个道理写下来听着显而易见。但当你真正要去维护它的时候，就没那么明显了。

路由层必须在不确定的情况下做决策。如果太激进，它会悄悄降低工作质量来省钱；如果太保守，它就变成了放在同一个昂贵模型前面的装饰性代理。最难的部分不是调用模型 A 还是模型 B，而是判断当前这一步是否对模型 B 仍然安全。

Switchyard 有意思的地方在于，它把这种决策视为基础设施而不是应用胶水代码。

Nvidia 将其描述为一个与提供商无关的 SDK，同时具备免调优和可调优的路由算法。开发者定义一个模型池，然后为质量、延迟和成本调优路由。换句话说，模型阵容变成了一张运行时界面。你不再硬编码"在这里使用 Claude"，而是开始表达你希望系统做出的权衡。

这是一个健康的方向，但有一个 catch：路由器需要评估，否则就变成了"感觉良好但账单吓人"。

成本降低容易测量。延迟容易测量。质量才是陷阱。路由器可能平均看起来很棒，却恰好在工作流最需要昂贵模型的地方失败。这种失败并不总是戏剧性的。它们可能是一次略有偏差的工具选择、一份政策文档中遗漏的一个约束、一次遗漏了一个丑陋边缘情况的总结、一次通过了浅层测试却在人类会注意的地方破坏了系统的代码编辑。

这就是大多数 Agent 演示在不自觉地作弊的地方。它们展示了一条成功路径穿过任务，却省略了本应捕获路由器做了糟糕赌注的核算系统。生产级 Agent 需要那些不光鲜的部分：逐步骤的追踪、可回放的评估用例、不仅仅依赖模型自己说"我很自信"的置信度检查、预算机制、升级规则、熔断开关。

路由器不是神奇的砍价工具。它是一个放置你判断力的地方。

我喜欢 Nvidia 把这个推向开源栈，因为每个正经的 Agent 框架本来也都在自建版本。LiteLLM 路由。LangChain 路由。内部平台路由。人们写 bash 脚本做路由。然后他们加一个异常，再加一个，再加一个表格记录"本周哪个模型'擅长 JSON'"。这事好笑，直到它成为你周三 Agent 账单翻倍的原因。

一个共享路由器不会消除那种混乱，但可以把混乱移到一个有名字、有测试、有旋钮的组件里。

Nvidia 关心的原因也很明显。一款快速的 300 亿模型在有明确定义的工作时更容易卖出去。Nemotron 3.5 Lightning 不需要在所有事情上打败前沿模型。它只需要在那些让 Agent 变得昂贵的重复执行步骤上做到便宜且足够好。Switchyard 给了它一条车道。

这可能是开源模型更诚实的前景。不是"这个本地模型取代最好的闭源模型"，而是"这个模型处理 70% 的运行，这个处理验证，这个处理长上下文规划，昂贵的模型只在那些值得花钱的部分才被调用"。

对于开发者来说，实际的收获很简单。如果你的 Agent 工作流开始变得重要，模型选择就不应该散落在各种 if 语句里。

写下各个步骤。决定哪些步骤允许使用廉价模型。加一种回放失败的方式。按步骤追踪成本，而不只是按运行追踪成本。把升级逻辑放在你可以检查的规则后面。并且假设每一个路由决策都是一个产品决策，因为它确实是。它改变了质量、延迟、可靠性和月度账单。

Nvidia 的发布重要的原因不是一个路由器能解决所有问题。它重要的原因是它把那些大家心照不宣的东西说出口了。

Agent 技术栈正在变成一个调度器。

Sources: Nvidia's Nemotron 3.5 Lightning and Switchyard posts, Nvidia's Switchyard routing technical blog, VentureBeat, The New Stack.