不换模型，换路由：NVIDIA NeMo Switchyard 的模型编排层解构

三组降本读数不在同一张账单上

公开材料里关于 NeMo Switchyard 的降本，至少出现了三组数字。它们经常被放在同一段里相互印证，但拆开看是三次不同条件下的测量：模型对不同、任务集不同、统计单位不同，连「成本」所指的对象也不完全一致。

来源与场景	公开读数	模型对 / 任务集	同时给出的代价
LangChain 内部 deep agents 评测套件	145 个多轮智能体任务、五次运行、74% 成本下降，仅 7% 调用发给前沿模型	Nemotron 3.5 Lightning 与 Claude Opus 4.8；任务取自 τ²-bench airline、BFCL、FRAMES、Nexus 等场景	实测约 6 个百分点准确率代价
Cognition FrontierCode Main	50.6% 成绩、平均每次 3.11 美元、平均成本约低 28%	Opus 5 与 Kimi K2.7 之间做阶段路由；生产级编码任务	比 Opus 5 准确率低 2.8 个百分点
NVIDIA 官方发布稿（内部基准）	保持前沿级准确率，任务完成成本降至 Opus 4.8 单独使用的近三分之一	发布稿未展开任务集、运行次数与模型池明细	未给准确率差值，亦未给置信区间
NVIDIA AI Day Seoul 转述	保持约 80% 任务成功率、成本约为单一高性能模型的三分之一	韩文活动报道转述，未给任务集与基线定义	「80% 成功率」为固定数值阈值，「近三分之一」为相对成本，两者不是同一口径

把「降本 74%」换成剩余成本是 26%，把「降至近三分之一」换成降幅约 66.7%，把「降本 28%」换成剩余成本 72%（原创换算）。三者看起来都在说「便宜了很多」，可 26%、33.3%、72% 是三条不同的剩余成本线。更关键的是，官方开发者博客里明确列出 LangChain 与 Cognition 两组数字并附代价，而「近三分之一」出现在另一份发布稿中，两者不是同一次实验的两种表述。

三份材料的署名性质也不同：LangChain 与 Cognition 的结果由合作方在各自评测套件上产出，NVIDIA 的「近三分之一」是自家内部基准，首尔活动的转述则是第三方报道。本文在后续各节中分别标注来源，不把它们合成一个区间（原创来源分层）。

目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是内部基准的任务构成、运行次数、模型池单价，以及「前沿级准确率」的判定阈值。

路由层解耦：语义模型名、状态与三协议网关

NeMo Switchyard 的设计起点不是「哪个模型更强」，而是「换模型时应用代码要不要跟着改」。官方开发者博客把底层称为 switchyard-libsy，一个 provider 无关的 SDK：它负责表示请求、定义系统里有哪些模型可用、并管理对被选中模型的调用。每个模型目标挂一个语义名，由背后的 client 把这个名字映射到具体的 provider 端点与模型 ID，路由逻辑因此不绑定任何一家供应商（来源：NVIDIA Developer Blog 全文）。

组件	职责	解耦了什么
switchyard-libsy SDK	表示请求、声明模型池、发起对选中模型的调用	路由决策与 provider API 细节
语义模型名 + target client	名称到端点与模型 ID 的映射	升级模型、迁移端点、换供应商时不必改路由集成
routing state	按策略在会话内携带早期轮次的工具结果或亲和决定，供后续路由使用；不需要历史时可保持无状态	有状态与无状态两种运行方式的取舍
调用执行方式	可由 target client 直接发起，也可把调用交回宿主应用	由运行时、推理平台或网关决定请求如何被服务，同时保留同一份路由合约
Switchyard server（参考实现）	接受 OpenAI、Anthropic、Responses 三类请求，翻译为内部格式并按原格式返回；记录选中模型、决策理由、token 用量、延迟与调用结果	把路由做成可模拟 LLM 网关的独立服务，便于审查一条正在跑的路由

这里有两处容易被读漏。其一，语义名解耦的是「调用路径」，不是「能力判断」：换一个端点不需要改路由集成，但换一个能力档位仍然要重做路由策略与回归。其二，routing state 是可选的，官方明确写了「当策略需要时」才跨会话携带；把它理解成所有路由都必须带状态，会误判无状态部署的可行性。

server 记录决策理由与调用结果这一项，工程意义不亚于路由算法本身。模型路由引入了一类新的故障：请求被分给了不合适的模型，但语法与协议全部正常。若没有「选中了谁、为什么选、花了多少 token」的记录，这类问题在常规应用日志里很难定位（原创工程解读）。官方把 server 定位为参考实现，用于通过通用 API 提供路由并模拟网关，并未把它描述为托管服务。

与本站此前解构的架构对照：AWS 11·09 七层可插拔框架把模型选择放在 Model and Inference 层，用 LiteLLM 之类的代理统一接口，重点在层间稳定契约；Switchyard 则把「按什么信号、在什么时机选」单独做成一层可编程组件，重点在决策逻辑本身。两者都提到第三方替换，但替换的对象不同——前者换层内实现，后者换路由算法（内部对照说明）。

目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是 server 在高并发下的开销、routing state 的持久化介质与过期策略，以及决策理由日志的留存周期。

三类免调优路由器的判据与触发时机

官方把不需要用工作量数据训练的路由器归为一类，给出三种：LLM classifier、stage router、escalation router。三者的差别不在于用了什么模型，而在于看什么信号、多久重新决策一次。

路由器	输入信号	何时重新决策	典型适用面
LLM classifier	以 LLM 作 judge 判定请求主题或难度，从候选里选模型	维持会话亲和，任务弧线未实质变化时不再重复分类	无头系统、按领域分流的编码 / 数学 / 医疗任务
Stage router	每一轮检查近期工具活动：严重错误、重复无效工作、长时间探索推向能力更强模型；稳定写改、测试通过后倾向高效模型；信号不明时咨询 LLM judge 再回落到配置默认值	逐轮	阶段特征明显的编码智能体
Escalation router	从低成本模型起步，LLM judge 逐轮监控进度，检测到持续困难（重复错误、循环、漂移）时把会话升到更强模型	逐轮，但只在升级方向变化	多轮任务里常规工作占多数、偶发难点的场景

把三张表并排会看到一个方向上的张力：LLM classifier 明确用会话亲和来减少重复分类，stage 与 escalation 却要求每一轮都重新看信号。这不是互相矛盾的实现，而是把选择权交回给工作负载——官方原文写的是，全请求路由还是逐步路由、共享模型池还是子智能体专用池，取决于用例、部署复杂度、错误容忍度、延迟与吞吐约束。换句话说，库给的是可组合的原语，不是一条推荐流水线（原创结构归纳）。

stage router 的信号来自「近期工具活动」而非请求文本，这一点值得单独记。它把路由判据从「这个题难不难」换成「这个智能体此刻处在解题的哪一段」，因此能识别出「探索期需要更强推理、实现期可以降档」这类沿时间变化的需求。代价是判据与工具调用格式绑定：换一套工具命名或调用约定，阶段判定规则就要重新校准（原创可迁移性评估）。

escalation 是单向的：从低成本起步，检测到持续困难才升级。官方没有描述「难点过去后降回小模型」的回退条件，因此「升级后是否整段会话都留在强模型」属于未明确项。对长会话而言，这一项会直接影响 7% 之类前沿调用占比能否复现（原创缺口标注）。

目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是三类路由器在同一任务集上的横向对照、judge 模型的选择与调用频次，以及信号不明时回落默认值的实际触发比例。

可调优 prefill 路由器：从残差流预测成功率

免调优路由器用的是固定启发式或 LLM 判断；可调优路由器换成从真实工作量数据里学出来的信号。官方描述的 prefill router 走的不是「读一遍请求文本再分类」，而是借模型内部状态估计难度：训练阶段抽取大模型的残差流用来估计查询复杂度，用一个共享主干的多层感知机把这些信号映射到模型池里每个候选模型的准确率标签；推理阶段把 prefill states 作为输入，由共享主干预测每个候选成功完成任务的可能性，再叠加成本、延迟等部署约束打分，把请求交给权衡结果最合适的模型（来源：NVIDIA Developer Blog 全文）。

阶段	输入	产出	与免调优路由的差别
训练	残差流信号 + 每个候选模型的准确率标签	共享主干 MLP 的预测能力	需要工作量数据与标注，不再是零数据即可启用
推理	prefill states	每个候选模型成功可能性	预测的是「这个模型能不能做成」，而非请求属于哪个主题
策略打分	预测准确率 + 成本 / 延迟 / 部署约束	每个候选的综合分，选权衡最合适者	质量目标与成本目标被显式写进同一函数

官方配图给出的结论是：路由不是挑能力更强的模型，而是挑在合适成本上最可能满足所需质量档位的模型。配图对应的任务类型是个人助手类任务，标注为 Pinchbench 与 ClawdQA，并引向 arXiv:2603.20895；该图的逐点数值在提供的正文里没有列出（来源同上）。

从工程落地看，这条路径多出两份长期成本：准确率标签要随模型池变化持续更新，否则换一个端点或升级一版权重，预测就偏离；要拿到残差流或 prefill states，意味着对推理栈有更深的接入要求，与「provider 无关」的口号之间存在实际摩擦。开源 SDK 让团队能自带算法，但也把这两份维护工作接了过来（原创落地评估）。

把 prefill router 与 stage router 放在一起，可以看到两类信号并不冲突：前者估的是「这一步有多难、谁最可能做对」，后者看的是「智能体走到哪一段」。官方把它们列为可组合的库能力，没有给出同时启用时的优先级或冲突消解规则，这属于配置层面的未披露项（原创对照）。

目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是共享主干的规模、标签采集成本、模型池变更后的重训周期，以及配图中各点的具体数值。

Terminal-Bench Hard 分组：整体榜首并非各组最优

官方用 Terminal-Bench Hard 上的一个例子说明为什么需要按任务分工。在 Terminus 智能体的测量里，DeepSeek V4 的整体准确率居前，但并不是每个任务组的最优选择：ML 与 RL 任务组更适配 Kimi K2.6，数学与科学组更适配 Qwen3.5 397B A17B，其余六个任务组仍用 DeepSeek V4（来源：NVIDIA Developer Blog 图 1 说明文字）。

任务组	文中建议的模型	与整体成绩居前者是否一致
ML 与 RL	Kimi K2.6	不一致
数学与科学	Qwen3.5 397B A17B	不一致
其余六个任务组	DeepSeek V4	一致

按「其余六个」反推，这张图里至少涉及八组任务，其中两组被建议不用整体成绩居前的模型，占比约 25%（原创换算；原文未给各组任务数与准确率明细，此处只作结构折算，不做性能推断）。这个例子的价值不在具体模型名，而在它把路由收益的来源说清楚了：增益来自分工，不来自换上一个更强的权重。同一思路还可以下沉到单任务内部，或按解题阶段切分，官方明确列了这两种粒度。

另一张图把准确率与总输入 token、总输出 token 并排，并附标准差柱，用来说明成本与完成时间会让决策变复杂：每个模型不只有单价，还有自己的冗长度特征，而冗长度不只体现在 token 上，也体现在工具调用次数上（来源同上）。这条提示对复现 74% 这类数字很关键——若只按「每次调用单价」估算节省，会漏掉不同模型在工具调用轮次上的差异。

需要标注边界：图 1 与图 2 的逐点数值、各任务组样本量、运行重复次数在提供正文中均未列出，因此本文不引用任何来自这两张图的具体分数，也不据此计算模型间分差（原创引用纪律）。

目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是八组的组名与样本量、逐组准确率、以及分组路由相对全量前沿基线的净成本对照。

六组原创折算与各自的分母

以下六组算式全部由公开读数推导，目的是标出哪些数字可以相除、哪些只能并列。凡涉及不同实验或不同统计单位的，本文一律不合成单一结论。

序号	算式与结果	依赖的假设	能否跨场景使用
一	74% 降本 → 剩余成本 26%；约 28% 降本 → 剩余 72%；降至近三分之一 → 降幅约 66.7%	三者均以各自基线为 100%	不可平均，三条基线不同
二	若假设每次调用 token 量相当、成本比等于调用占比的加权单价，则 0.26 ≈ 0.07 + 0.93 × r，反推小模型单价约为前沿的 20.4%	强假设：忽略 token 量与工具调用轮次差异；实际官方已提示冗长度不同	仅作量级示意，不能当作报价
三	Cognition 的 3.11 美元与约 28% 降本，反推对照基线平均成本约 4.32 美元	3.11 美元为路由后平均成本，28% 相对同一基线	依赖两句读数同源，官方未明示是否同一组运行
四	Terminal-Bench Hard 例子中 2 组换模型、6 组沿用，按 8 组计为 25% 对 75%	「其余六个」即总组数为八，且 ML/RL 与数学/科学各计一组	结构折算，非性能数据
五	145 个任务 × 五次运行 = 725 次任务级运行；其中 7% 前沿调用是调用占比而非运行占比	「五次运行」指整套评测重复五遍	7% 不可与 725 相乘得到「前沿运行次数」
六	官方列出 LangChain、Cognition、Nous Research、Ramp、LiteLLM、Kong、Classmethod、Boomi、Cadence、Siemens 等接入方，其中给出量化结果的为 2 家，占约 20%	以开发者博客正文列出的接入方计数	说明多数为集成说明，不可当性能证据

第二组算式需要多说一句。官方明确写过模型之间存在冗长度差异，且工具调用次数也计入成本，因此「成本比等于调用占比乘单价比」这个模型是不成立的；把它列出来，是为了展示为什么 7% 的前沿调用占比不能直接解释 74% 的降本——中间还有 token 量、工具轮次与单价三项变量（原创反证用途）。

第五组是常见误算。7% 是调用层面的占比，725 是任务层面的运行次数，两者分母不同。若写成「725 次里约 51 次用了前沿模型」，就把调用数偷换成了任务数（原创口径辨析）。

第六组提醒读集成名单的方式：官方对 Boomi、Kong、LiteLLM、Classmethod、Nous Research、Ramp、Cadence、Siemens 的描述主要是接入与工作流说明，没有给量化结果；把它们与 LangChain 的 74% 并列成「多家验证」，属于把集成关系读成性能背书（原创来源分级）。

目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是各次运行的成本分布、方差，以及降本数字在扣除 judge 调用后的净值。

路由自身的开销与两种相反的策略

把前面几节叠起来，路由层的账其实有两栏：一栏是被路由的模型调用成本，另一栏是做出路由决定本身的成本。公开材料把头一栏报得很细，另一栏基本留白。

开销项	出现在哪种路由器	公开材料是否给出量化
LLM judge 分类或选择	LLM classifier、stage router 信号不明时、escalation 逐轮监控	未给
逐轮读取并解析近期工具活动	Stage router	未给
抽取残差流与 prefill states、维护准确率标签	Tunable prefill router	未给
记录选中模型、决策理由、token、延迟与调用结果	Switchyard server 参考实现	未给存储与吞吐开销
跨会话 routing state 的存取	有状态策略	未给

这不是在质疑官方结论，而是在划出可复现的边界。当降本幅度以「相对全量前沿基线」计算时，若基线本身没有 judge、没有逐轮监控，而路由方案有，那么两侧的比较并不是完全对称的。LangChain 与 Cognition 的评测是否把这部分计入总成本，提供正文未说明；本文把净节省列为待验证项，不自行扣减（原创核验设计）。

还有一处与本站旧文呼应的可迁移经验：AWS 七层框架把可插拔的代价写成「跨替换的回归测试由团队承担」，Switchyard 把同一代价推进了一层——不只是换模型要回归，换路由算法、换判据、换 judge 模型同样要回归，而且回归对象是决策分布而非单次输出。目前官方未给回归基线、质量阈值或成本上限的具体数值（内部对照与原创延伸）。

一条可证伪的检验路径是：在同一批 145 个多轮任务上，固定模型池与任务顺序，分别记录「免调优 escalation 路由」与「全量前沿模型」两组的端到端成本，并把 judge 调用、server 日志写入与 routing state 存取全部计入；若计入后降幅显著低于 74%，则差额就是路由开销的实测值。另一条是固定成本预算、比较会话亲和与逐轮升级两种策略的准确率与升级次数。公开材料目前都未给出这两组数据（原创检验设计）。

目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是 judge 模型的规格与调用频次、路由决策的延迟分位数，以及升级后是否允许回退到低成本模型。

可证伪边界与未披露项

把可引用的与不能外推的分开列，是这篇解构的收尾。可引用的是：架构组件与三类免调优路由器的判据、LangChain 与 Cognition 两组带代价的量化结果、Terminal-Bench Hard 分组示例的定性结论、以及官方对收益「取决于工作负载」的限定。不能外推的是：把三组降本数字合成区间、把 7% 调用占比当成任务占比、把集成名单当成性能验证、把「近三分之一成本」与「80% 任务成功率」互相印证。

• 基准未对齐：145 个多轮任务、FrontierCode Main 与官方内部基准是三套不同的任务集，模型对也从 Opus 4.8、Opus 5 到 Kimi K2.7 各不相同。
• 代价必须同行：约 6 个百分点与 2.8 个百分点准确率差值，是两组降本读数的组成部分，不是附注。
• 路由开销缺项：judge、逐轮信号解析、日志与状态存取的净影响未披露。
• 图表数值不可读：Terminal-Bench Hard 两张图与 prefill 配图的逐点数据在提供正文里没有列出，本文不引用其分数。
• 发布方立场：NVIDIA 是模型与路由库的发布方，合作方结果由其评测套件产出；官方博客自身附有「AI 生成摘要可能不完整，请核验重要信息」的提示。

与本站已覆盖的内容划清边界：R-TECH-63 讨论 AWS 七层参考架构中层间契约与横切层，R-TECH-46 讨论 NVIDIA OpenShell 的执行边界，R-BENCH-51 讨论完成率读数本身的盲区。本篇的切口是把「选哪个模型」抽成一层可编程运行时之后，量化读数的口径与开销边界，三者的层级与对象都不同（内部对照说明）。

对准备引入路由层的团队，一条较稳的顺序是：先固定任务集与全量前沿基线并测出端到端成本；再启用免调优路由器，同时把 judge 与日志开销计入；然后才考虑需要标签数据的可调优路由器；每次更换模型池、判据或 judge 都重跑同一批任务，比较决策分布而不只看平均分。这条顺序是从公开材料的缺口倒推出来的实施建议，没有对照实验支持，也不构成效果保证（原创框架说明）。

目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是开源仓库中与三组量化结果对应的可复现配置、长会话下的升级与回退规则，以及按工作负载选择路由器的公开决策表。