Nvidia 凭借 NeMo Switchyard 进入模型路由市场

Nvidia 推出 NeMo Switchyard，正式进入模型路由市场，为这个早已聚集网关、代理和定制路由系统的领域增加了新的软件层。该产品与 Nvidia 最新模型发布一同登上 Google News，但其竞争并不止于又一次产品发布。Nvidia 希望影响每一项请求由哪个 AI 模型处理，而不只是提供底层硬件。

Switchyard 是一款开源代理，位于应用程序与多个模型后端之间。它可以转换 API 格式、对请求分类、保持对话亲和性、收集使用数据，并将不同调用发送至不同模型。一个编程智能体可以将高级模型留给规划或错误恢复，再用高效模型执行常规编辑。

这种设计挑战了为整个应用或智能体会话指定单一模型的主流做法。它也让 Nvidia 与模型网关、云平台、开源路由器以及企业已经维护的内部编排系统展开竞争。核心问题在于，Nvidia 能否让自动模型选择足够可靠，从而胜任生产环境工作。

Nvidia 已向模型端点之上延伸

Switchyard 将模型选择从应用配置转变为运行策略。

根据其项目文档，Switchyard 可接受 OpenAI 和 Anthropic API 格式的请求。随后，它会在将每项请求转发给已配置后端之前应用路由策略。后端可以是托管服务提供商、Nvidia NIM 服务、私有端点、vLLM，或 Ollama 等本地服务器。

这一位置至关重要。应用程序通常直接指定模型，而开发者则在代码内部或通过基础代理处理服务提供商之间的差异。Switchyard 在这两层之间插入了一个可编程的决策点。应用继续使用熟悉的 API，而路由器决定请求应发送到何处。

该软件包含多种路由模式。团队可为对比测试随机分配流量，使用 LLM 分类器，创建自定义路由逻辑，或应用阶段感知策略。当确定性路径比优化更重要时，他们也可以绕过路由并选择单一模型。

Switchyard 的阶段路由器是此次发布中最重要的部分。它评估智能体近期活动中的信号，并在高能力与高效率模型层级之间做出选择。Nvidia 的路由指南将探索、复杂推理和错误恢复描述为更适合强模型的工作；更机械化的执行则可交由高效层级处理。

这并不等同于按主题路由每一条用户提示。智能体工作负载在单项任务中包含许多调用，任务推进过程中难度也会变化。一个编程智能体在检查陌生代码库时可能需要更强的推理能力；一旦形成计划，文件更新和结构化转换所需的能力可能就更低。

因此，Switchyard 在会话内部做出路由决策，而不只是在会话开始时决定。它可通过会话亲和性将相关轮次保留在同一后端，同时仍支持配置好的故障切换。这种组合解决了一个实际问题：当不同模型以不同方式理解上下文时，不受限制地切换可能损害连贯性。

该路由器还可在服务商协议之间进行转换。围绕 Anthropic Messages API 设计的客户端，无需重写客户端集成即可访问 OpenAI 兼容后端。Switchyard 会规范化请求、选择目标、转换载荷，并以客户端预期的形式返回响应。

这种转换扩大了 Nvidia 的角色。该公司不再只是提供面向 Nvidia 托管模型的优化端点，也在提供可置于多家服务商模型之上的软件，其中包括与 Nvidia 自身产品组合竞争的模型。

Google News 的报道将此举描述为 Nvidia 进入一个炙手可热的市场。更具影响力的变化在于架构层面：即使由另一家公司提供最终选定的模型，Nvidia 也正试图让其软件参与每一次推理调用之前的决策。

为何模型路由成为成本竞争的战场

智能体工作流让“每个会话使用一个模型”的方式越来越难以自圆其说。

传统聊天机器人通常针对一项用户请求生成一个回答。智能体则可能检查文件、调用工具、修订计划、从错误中恢复、验证输出，并生成最终响应。每一步都可能触发新的模型调用，而对话历史还会持续增长。

对每一步都使用能力最强的可用模型，能够简化工程工作。但这也意味着，可能只是格式化 JSON、总结工具输出或替换已知字符串的任务，同样获得最高级别的推理能力。在大规模场景下，这些重复调用会促使团队将模型能力与实际任务难度相匹配。

相反的做法也会带来问题。团队可以编写手动规则，按任务类型、长度、用户群体或应用状态路由提示。这些规则会变成基础设施；每当模型或工作流变化时，都需要测试、监控和调整。

InfoWorld 对模型路由的分析将这一新兴层描述为一种可根据提示需求改变模型使用方式的方法。其底层逻辑很直接：并非每一项请求都值得使用同一个模型，但必须有人可靠地做出选择。

Switchyard 试图将这种决策封装为可复用的基础设施。其阶段路由器会检查当前对话中与工具相关的信号。团队配置两个目标、设定路由行为，并按模型层级衡量产生的流量。

该系统可对不确定的轮次使用分类器，但分类并非必需。Nvidia 的文档建议先从工具信号开始，因为调用另一个模型来分类每项请求，会引入延迟、成本以及新的故障点。分类器可以仅限于路由器缺乏足够置信度的情况。

这种区别对企业部署而言很重要。一款减少模型消耗、却为每一轮都增加一次模型调用的路由器，可能会丧失部分优势。仅依赖固定规则的路由器或许能保持快速，但可能错过任务难度的变化。

市场早已超越简单的提示分发。AI 网关通常提供速率限制、故障切换、日志记录、策略执行和服务商抽象。CIO 对AI 网关的讨论将模型路由列为更广泛企业控制层的一部分。

这意味着 Nvidia 并非在创造一个空白品类。它正在进入一个竞争激烈的层级，客户可能已经在使用商业网关、云原生控制措施或开源项目。一些组织还围绕自身评估数据和业务规则构建了私有路由系统。

Switchyard 的机会来自多模型应用数量的增长。企业正越来越多地将通用推理模型与更小的模型、私有模型和专用端点结合使用。一旦存在多个选项，选择就成为运营问题，而不再只是开发者的偏好。

它的挑战也来自同样的多样性。每个组织对质量的定义各不相同。对客户支持而言正确的路由，对代码生成、安全分析或合同审查可能并不适用。成本和延迟可以量化，但任务层面的质量往往需要特定领域的评估。

Google News 的关注能够提升认知度，但采用与否将取决于这些衡量结果。买方会希望看到证据，证明路由能在其自身的提示、工具、失败案例和合规边界内产生可接受的结果。

Switchyard 让策略驱动路由与固定模型选择正面交锋

主要竞争并非 Nvidia 对阵某一家网关供应商，而是动态路由与固定模型可预测性之间的较量。

固定模型路径具有明显优势。团队清楚哪家服务商接收其数据、需要评估何种行为、适用哪个上下文窗口，以及应在何处调查故障。模型更新仍会带来变化，但请求路径相对简单。

动态路由则以部分简单性换取效率。应用可以在同一工作流期间调用不同模型。高能力模型处理复杂推理，高效模型处理常规轮次。当某个目标不可用或无法接受当前上下文时，系统还可以进行故障切换。

Switchyard 的架构将请求规范化、路由、执行和响应转换分离。这种分离使开发者无需改变面向客户端的集成，即可替换路由策略。它也让路由决策成为可观测组件，而非隐藏在应用逻辑中。

阶段路由器更进一步，将一次智能体运行视为一连串不断变化的条件。近期工具结果、失败情况和对话信号会影响下一个请求由哪个层级接收。这种方法认识到，难度存在于轮次层面，而不只是应用层面。

以软件维护智能体为例。它可能先探索代码库、定位相关模块，并解读陌生的测试。这些操作受益于更强的推理能力。在识别出狭窄的修复范围后，后续多项编辑和验证步骤可能遵循清晰的模式。

固定模型配置会将两个阶段都发送至同一端点。阶段感知路由器可以将更强的目标留给探索与恢复，再将常规工作转向高效目标。如果验证失败，路由器可以把后续调用重新转回高能力层级。

这种机制比将一个模型分配给“编程”、另一个模型分配给“写作”更灵活。但它也增加了路由错误影响最终结果的途径。过早选中的弱模型可能误解某项约束、产生有缺陷的编辑，或用看似合理的输出掩盖错误。

其后果并不总会在被路由的那一轮显现。一个小错误可能留在上下文中，并影响后续调用。最终答案或许看起来连贯，因为更强的模型修复了呈现方式，却没有发现潜在缺陷。

这正是为何模型路由不能仅按总体 token 使用量或平均延迟来评判。团队需要任务级评估，以检查整个工作流是否成功；还需要追踪记录，将每项路由决策与由此产生的工具调用、输出、重试和最终结果关联起来。

Switchyard 会公开每项请求的延迟、token 消耗和预估成本统计数据。其阶段路由器文档还介绍了按层级划分的统计数据。这些测量可帮助运营人员了解每个模型被选择的频率，以及路由行为在哪些环节发生变化。

然而，可观测性并不会自动证明正确性。仪表盘可以显示高效模型处理了大多数调用，但无法判断一份法律摘要是否遗漏了某项条款。这类判断需要评估集或其他可靠的验收测试。

因此，固定模型方案仍是一个有意义的对照选择。它更容易解释、复现和审计。只有当效率收益超过评估、调试和治理的运营成本时，动态路由才具备优势。

Nvidia 的策略是降低这类运营成本。如果 Switchyard 能提供协议转换、通用路由模式、统计信息和启动器，团队就可以将重心放在策略和评估上。如果这些组件依然难以校准，组织可能会继续在关键工作流中使用固定模型。

路由器的决策可能成为最薄弱的环节

Switchyard 的价值取决于能否选对模型，同时不让选择过程本身变成另一项高成本推理负载。

没有任何通用分类器能够了解每家组织对“简单任务”的定义。简短提示词可能需要专业知识，而很长的提示词也可能只是要求机械式提取。工具调用历史可以揭示工作流状态，但无法保证下一轮任务很简单。

阶段感知信号能够提供有用的上下文。探索、反复失败和恢复尝试通常有理由使用更强的模型。稳定的工具使用和重复性实现可能表明工作处于常规阶段。然而，真实的智能体运行并不总是沿着从推理到执行的清晰路径推进。

看似常规的编辑也可能带来重大后果。修改一条授权规则可能只涉及几行代码，但细微错误就可能导致数据暴露。一项很长的摘要请求，如果输出会经过人工审核，风险则可能较低。

因此，组织需要制定同时考虑影响程度、而非仅预测难度的路由策略。敏感操作可能应始终使用获批准的模型。某些工具可能需要能力更强的层级，而低风险转换则可以继续采用高效路由。

提供商协议转换带来了另一层不确定性。OpenAI、Anthropic 以及兼容 API 并未暴露完全相同的语义。工具调用、推理字段、流式行为、结构化输出和错误响应都可能因提供商而异。

Switchyard 的目标是在与另一后端通信时，保留客户端所预期的响应格式。这种抽象很有用，但团队必须测试其智能体所依赖的具体功能。协议兼容并不代表模型之间的行为等价。

上下文限制也会使路由更加复杂。为效率而选定的模型，可能无法接受已累积的会话上下文。根据其阶段路由器文档，Switchyard 支持为上下文溢出配置回退行为。回退可以维持可用性，但也可能改变成本、延迟和输出特征。

还有分类器本身。可选的 LLM 分类器可以帮助处理不确定请求，但会增加一次网络调用。Nvidia 警告称，若分类器与高效目标模型共享提供商容量，可能会加剧速率限制压力。

分类器同样需要评估。如果它经常将简单请求发送到高能力层级，节省的成本就会缩水。如果它将困难任务发送到高效层级，质量就会下降。阈值能够改变平衡，但没有任何阈值能消除这种权衡。

路由研究一直致力于在降低推理成本的同时保持质量。RouteLLM project 展示了学习型路由器如何利用偏好数据，在更强和更弱的模型之间进行选择。其结果也强调了一个更广泛的观点：路由器性能取决于训练数据、评估设计以及被路由的模型组合。

为某一模型组合校准的策略不会自动迁移到另一组合。提供商会更新模型，提示词会演变，应用也会增加新工具。团队需要持续评估，而不是只在部署前完成一次基准测试。

该项目也仍处于早期阶段。其公开仓库列出了已知问题、活跃开发状态，以及不断扩展的路由组件集合。这种开放性有助于检查和实验，但并不能证明每项功能都已成熟到适用于受监管或高风险工作负载。

Nvidia 将 Switchyard 定位为模型无关的基础设施，但其更广泛的动机依然清晰。更高效的推理能够让智能体部署在经济上变得可行，从而增加对底层计算系统的需求。该路由器可以支持竞争性提供商，同时仍扩大 AI 工作的总体规模。

这种动机并不会否定产品本身。它解释了 Nvidia 为何要进入推理端点之上的软件层。当客户运行更多模型、更多智能体，并在更广泛的硬件上进行更多推理时，公司就会受益。

因此，更审慎的解读应比 Google News 的标题周期更为克制。Switchyard 提供了一套可信的工具包，用于试验多模型流量。它的生产价值仍取决于针对具体工作负载的证据，即路由错误是否保持在可接受范围内。

Nvidia 正在扩展其全栈推理战略

Switchyard 将模型选择与 Nvidia 更广泛的努力连接起来：控制更多推理运营栈环节。

Nvidia 在 AI 领域的地位始于加速器，随后扩展至网络、优化库、模型服务软件、企业套件和开放模型。路由层将这一技术栈延伸至应用边界。

该公司已提供 Nvidia NIM，用于通过标准化端点打包和提供模型服务。Dynamo 则负责分布式推理调度，以及跨工作节点的请求放置。NeMo 支持模型开发和定制。OpenShell 为智能体工作负载提供受控运行时。

这些系统解决的是不同的路由问题。Dynamo 的 KV-aware routing 会在考虑可复用缓存状态和当前负载的同时，选择合适的工作节点。Switchyard 则依据应用层策略选择模型或后端。

这种区别很重要。基础设施路由关注的是请求应在哪里执行，才能实现高效服务。模型路由关注的则是哪一个模型应接收请求。一次部署可以同时使用这两种决策：Switchyard 选择模型，然后服务系统选择工作节点。

由此形成了一条更长的、由 Nvidia 管理的组件链。企业可以使用 NeMo 工具构建智能体，通过 Switchyard 路由其调用，经由 NIM 提供开放模型服务，并在 Nvidia 硬件上使用 Dynamo 调度推理。

要让这一战略成立，Nvidia 并不需要每个请求都使用 Nemotron 模型。如果 Switchyard 成为常见的控制点，Nvidia 就能影响开发者如何评估和运营多模型系统。它还可以将这些路由选择与自己的服务和可观测性技术栈相连接。

这才是此次发布带来的真正竞争压力。网关厂商如今面对的是来自领先 AI 硬件供应商、资金充足的开源新进入者。云服务商必须说明，为何其原生路由和治理层能提供更高价值。模型公司则必须让自己的端点能够在混合部署中被轻松评估。

开源项目面临的是另一种比较。许多项目已经提供统一 API、回退逻辑、负载均衡和模型选择。Switchyard 必须在路由质量、智能体感知能力、协议覆盖范围和运营清晰度上竞争，而不仅仅是具备转发请求的基本能力。

其 Apache 2.0 许可证降低了实验门槛。团队可以检查路由代码、添加自定义策略，并将代理部署在应用附近。这种灵活性可能会吸引不希望托管网关观察每一条提示词的组织。

不过，自托管也意味着责任转移。运营者必须保护凭证、管理更新、保留日志、监控路由行为，并验证提供商集成。开源改变的是谁控制系统，而非安全运行系统所需的工作量。

Nvidia 最强的优势或许在于集成，而不是某一种单独的路由算法。该公司可以将 Switchyard 与模型、推理服务器、智能体运行时和硬件遥测相连接。较小的路由器厂商或许能提供更广泛的提供商中立性，却缺乏这种端到端的工程覆盖能力。

客户面临的风险是技术栈不必要地过度集中。在开发、路由、服务和计算上使用同一家供应商，可以简化支持工作；即使各个组件仍然是开源的，也可能提高切换成本。

Switchyard 对多家提供商的支持有助于缓解这一担忧。其实际价值将取决于这些集成能否在 Nvidia 扩展项目时始终保持一流地位。客户应像测试 Nvidia 托管后端一样仔细测试非 Nvidia 后端。

该公司的举动并未为模型路由器市场盖棺定论。它确认了路由已成为战略性基础设施。由哪个模型回答请求的决定，如今会影响成本、延迟、可靠性、数据处理和提供商议价能力。

Google News 读者接下来应关注什么

三个信号将表明 Switchyard 会成为生产基础设施，还是仅停留在有趣的开发者实验阶段。

第一个信号是工作负载层面的评估。Nvidia 和早期采用者需要公布能够将路由决策与完整任务结果关联起来的结果。只有在智能体仍能正确完成任务时，更低的 token 消耗才有意义。

有价值的证据应包括失败率、恢复行为、延迟分布，以及多个模型组合之间的质量比较。结果还应将路由器开销与将调用迁移至高效模型所带来的节省区分开来。

如果独立测试能够复现强劲的任务级结果，Nvidia 的论点就会更有说服力。如果结果依赖于狭窄的基准测试或精心挑选的模型组合，固定模型部署对关键工作流仍将具有吸引力。

第二个信号是超越 Nvidia 自身服务的集成。Switchyard 已说明支持 OpenAI、Anthropic 和 OpenAI-compatible endpoints。生产用户将测试在这些提供商之间，工具调用、流式传输、结构化响应、上下文处理和错误处理是否仍然可靠。

广泛且维护良好的集成将支持 Nvidia 的模型无关主张。竞争性后端上不均衡的行为则会削弱这一主张，并让中立网关更具吸引力。

第三个信号是企业控制能力。采购方将寻找成熟的策略执行、审计轨迹、凭证隔离、部署指导和评估工作流。他们还需要一种明确方式，将敏感请求固定到获批准的模型上。

强大的治理功能将使路由从开发者优化走向平台工程。控制能力薄弱则会将采用范围限制在实验、内部工具和低风险智能体中。

这些信号比下载量或新闻标题更重要。Google News 可以放大 Nvidia 的入场，但无法证明一次路由决策是否正确。这一证明将来自于在不断变化的模型、工具和业务约束条件下进行的真实智能体运行。

对于开发者而言，眼下的行动很务实：选择一个边界明确的工作流，在对其进行路由前定义成功标准，并将 Switchyard 与固定模型基准进行比较。在追踪延迟和模型使用情况的同时，记录完整的任务结果。

对于企业采购方，应询问谁拥有路由策略，以及组织能多快发现错误决策。一次更便宜的调用，如果导致返工、削弱合规性或掩盖错误，就并不是真的更便宜。

Nvidia 让人更难再把模型路由视为小众的抽象概念。未来几个月将检验 Switchyard 能否让动态模型选择像负载均衡一样成为日常运维流程，还是说路由器本身依然是最难以信任的模型。