NVIDIA 在 8 月 11 日同时发布了两样东西：一个模型，和一个路由器。模型是 Nemotron 3.5 Lightning——30B MoE 架构、3B 活跃参数、专为 Agent 高频执行任务优化。路由器是 NeMo Switchyard——一个开源 Rust 库，负责在每个 Agent 工作流步骤中把请求导向最合适的模型。
同一天，十家合作伙伴公布了部署数据。但这些数字几乎都在描述路由器的效果，而不是模型本身。NVIDIA 副总裁 Kari Briski 用了大量篇幅介绍模型的可定制性，但 Futurum Group 分析师 Nick Patience 的判断更直接："两个产品中，路由库的战略分量更重。"
因此，除了模型成绩，还需要看 Switchyard 如何进入 Agent 的调用流程。一旦企业按它组织模型选择与成本管理，后续替换可能涉及多个工作流。
Lightning 侧重执行速度，综合能力低于前沿模型
Nemotron 3.5 Lightning 是 Nemotron 3 家族中最小的成员，基于 Hybrid Mamba-Transformer 架构，31.6B 总参数中每次推理仅激活约 3.6B。它从 Nemotron 3 Ultra 蒸馏而来，开发周期约六周。
在 Artificial Analysis 综合智能指数上，Lightning 得分 24。排名表顶端是 Claude Opus 5 的 61-63 分。同一家族的 Nemotron 3 Super 得 26 分，Qwen3.6 35B 得 32 分，Meta 前一天刚发布的 Muse Glimmer 得 35 分。这些成绩说明，Lightning 的定位更侧重执行速度，而非与前沿模型竞争综合推理能力。
NVIDIA 的论点是：Agent 日常工作中，需要"思考"的步骤只占一小部分。大部分调用是工具执行、结果验证、格式化输出——这些任务不需要 Claude Opus 5 的推理能力，但需要够快的吞吐和够低的成本。Lightning 的定位正是这个执行层。它在 Artificial Analysis 上的 Time per Intelligence Index Task 仅约 0.5 分钟，而 Qwen3.6 35B A3B 需要约 3.5 分钟。通过 DeepInfra 的 NVFP4 endpoint，输出速度达到近 670 tokens/秒。
不过，闭源模型在时间效率上仍有优势。Gemini 3.5 Flash-Lite 智力 37 分、完成速度相近；GPT-5.6 Luna 智力 52 分、任务完成不到 2 分钟。Lightning 在 open-weight 赛道里领先的是"智力/速度帕累托前沿"——在较低综合能力区间提供较快速度——而不是绝对的智力或效率。
Agent 能力方面，由 GDPval-AA v2（代理任务）和 Terminal-Bench v2.1（终端操作）衡量，Lightning 较前代 Nano 有显著提升：前者 ELO 从 Nano 的约 490 跃升至 824，超过了 Nemotron 3 Super 和 OpenAI 的 gpt-oss-120b；后者从 7% 提升至 24%。
Switchyard 转换调用协议，并按策略选择模型
NeMo Switchyard 是一个 Rust 代理和库，核心工作很简练：它坐在客户端和模型后端之间，把每个请求解码为不依赖特定服务商的格式后按策略选择模型，再编码为目标模型的格式发出去。它支持 OpenAI Chat、Anthropic Messages 和 OpenAI Responses 三种协议的双向转换，这意味着 Claude Code、Codex、OpenClaw 等工具可以在不修改代码的情况下，由 Switchyard 将请求透明地分发到不同模型。
路由策略从最简单的随机选择一直延伸到利用分类器识别任务阶段后选择模型。开发者可以自定义路由算法，按质量、延迟、成本或领域需求配置。
值得注意的是 Switchyard 的分发策略。OpenRouter、LiteLLM、Kong 等现有网关选择把 Switchyard 接入自己的产品。Kong 将 Switchyard 原生集成到 Kong AI Gateway；LiteLLM 将其作为插件加入代理层；OpenRouter 将其作为路由目标。
这些集成让 Switchyard 在发布时就能触达现有网关用户。若多家网关共享路由组件，它们可能更多通过可观测性、计费和访问控制形成差异，但尚不能认定模型路由已被统一。
合作方报告了降本效果，收益取决于任务和比较基线
NVIDIA 公布的合作伙伴数据集中在路由效率上，而非模型能力。关键数字：
LangChain 在 145 个多轮 Deep Agents 任务中，通过 Switchyard 将仅 7% 的调用路由到 frontier 模型，整体成本降低 74%，准确率下降约 6 个百分点。接近全部的节省来自第一次模型替换——从"全用 Opus 4.8"切换到"Opus + Lightning"。
Ramp 在自有的 SWE-Bench 测试套件中，成本降低 58%、运行时间降低 33%，同时匹配 frontier 模型的性能水平。Cognition 将 Switchyard 的 staged router 集成到 Devin Desktop（供 NVIDIA 内部使用），在 FrontierCode Main 上实现接近 frontier 的准确率，平均成本降低 28%。Boomi 达到 100% 的领域路由准确率，将 59% 流量导向经过微调的小模型，延迟降低 21%。
CodeRabbit 用 NVIDIA 的标准 AutoModel recipe 训练了一个 epoch，花费 85 美元、两小时，将代码审查路由器的准确率提升了 34 个百分点。CrowdStrike 的 benign recall 提升了 45 个百分点。Harvey 在法律任务完成率上提升了 8.3 个百分点。
所有这些数据都有同一个前提：它们来自 NVIDIA 公布的早期接入合作伙伴——这些团队拥有深厚的 ML 工程能力。Futurum Group 指出，对"只有一个数据团队、没有研究职能的组织"来说，定制化效果可能完全不同。
另外，成本对比的基线值得注意。NVIDIA 的核心声称是"以约三分之一的成本维持 frontier 级准确率"，对比对象是"为每一步调用都使用 Opus 4.8"。对于已经用便宜模型处理执行任务的团队，还需要比较引入路由后能额外节省多少——NVIDIA 自己的数据显示，从 Opus+Lightning 双模型池到再加入两个开源模型，成本从约 95 美元降至约 72 美元，任务完成度几乎没有变化。边际收益在第一个替代之后就急剧收窄。
请求导向本地模型，也可能带动 NVIDIA 硬件使用
理解 Switchyard 不能只看路由逻辑，还要看 NVIDIA 为什么要开源它。Futurum Group 分析师的判断直截了当："谁控制模型选择，谁就控制哪块硅片服务哪些 token。NVIDIA 正在把这个能力免费送出去。"
Lightning 的设计从一开始就是为了在 NVIDIA 自有硬件上运行——Jetson、GeForce RTX 5090、DGX Spark、DGX Station——而不是必须通过云端 API。当 Switchyard 将执行层请求路由到 Lightning，而这些 Lightning 实例运行在本地 NVIDIA 硬件上时，这部分推理负载就不会流向 Google 的 TPU、AWS 的 Trainium 或其他竞品加速器。
与 NemoClaw（NVIDIA 的开源 Agent 安全和管理栈）配合，NVIDIA 可以同时提供安全沙箱、模型路由和推理硬件。开源降低了采用门槛，但企业若把这些组件深度集成，后续迁移需要处理更多依赖，切换成本可能上升。
先测任务分布，再判断路由是否值得投入
"大小模型分工"的 Agent 架构不是 NVIDIA 的发明。Anthropic 的 Claude Code 在内部已经在做类似的分层调用；OpenAI 的 Codex 团队也在探索规划模型与执行模型的分离。此次 NVIDIA 将这套架构做成开源组件，并公布了合作伙伴的成本测试数据。
对于开发者，这意味着几件事：
省钱的前提是先知道自己需要什么。 Futurum Group 建议企业先测量自己的 token 分布——如果只有 10%-20% 的调用真正需要 frontier 推理（这是"装备良好的 Agent"的典型水平），路由架构才值得工程投入。如果团队连这个数据都拿不出来，加上路由只会增加复杂度。
从两个模型开始。 NVIDIA 的数据已经表明，大部分节省来自两模型池，再多模型带来的额外收益很小。因此，增加更多模型前应先测量额外收益。
路由带来审计负担。 在受监管行业，每一步具体由哪个模型生成输出是合规问题而非技术偏好。Switchyard 虽内置了指标记录，但在企业部署中仍需要补充逐步骤的归因和调试工具。
深度集成后，替换路由组件需要评估哪些成本
Shashi Bellamkonda 在分析中提出了三个尖锐问题，值得任何考虑采用 Switchyard 的团队思考：路由逻辑是否足够开放，允许企业在不丢失 Kong 和 LiteLLM 集成的情况下替换 NVIDIA 的默认算法？路由器的默认配置在规模扩大后是否会逐渐倾向于 Nemotron 模型？下一批采用者能否复现 Boomi 和 Ramp 那样精确的数据？
Switchyard 是开源的，GitHub 仓库任何人都可以 fork。但一旦它被接入企业的网关层、与几十个 Agent 工作流耦合、成为成本模型和延迟 SLA 的基础，替换它的代价就远高于替换一个模型 checkpoint。开源让企业能够查看和修改代码，而默认配置、网关集成和维护支持，仍可能使企业持续依赖 NVIDIA 提供的实现。
这种依赖是否形成，要看 Switchyard 后续的采用情况，以及企业替换算法和模型时实际付出的成本。
