用最便宜模型加路由实现 100% 有效输出的系统设计

坏掉的校园，第三部分（共三部分）。这正是下降之旅有所回报的地方。（披露：我是 B Torkian，NVIDIA 开发者大使；该测试工具是公开的且可确定性评分，下面的金额表可从代码仓库复现——去验证它，别相信我。）第二部分以一句话收尾——正确答案从来不是模型，而是路由——而这正是那句话兑现的地方。你花了两部分观看每个模型在智能体最不能承受失败的方面栽跟头，没有任何一个模型能全面胜出，而从这一刻起这不再是困境。你不再挑选一个模型，而是开始构建一个模型系统，你得到的是每个团队真正想要的东西：快速、廉价、谨慎，三者兼得。

以下是下降之旅留给我们的结论：英伟达 Nemotron 3.5 Lightning（"Lightning"）是场上最便宜、最快速的模型，但它交换掉了智能体最需要的三样东西——24% 的时间返回格式错误的输出，首次通过时 JSON 正确率仅 17%，而在本应拒绝的问题上它只有 37% 的 Abstain（拒绝回答）率。只选一个模型，没有满意的答案。

这就是转折点。你从来就不应该只选一个。NVIDIA 提供了组合这些组件的工具——开源权重加开源路由器——而当你这样做时，第一和第二部分令人沮丧的数据就不再是一堵墙，而成为一张地图。Lightning 最大的弱点变成了你整个技术栈中最便宜的路由信号。

格式失败是一个无需构建的绊线

当模型返回格式错误的输出时——截断的 JSON、在你要求结构化数据时返回散文、缺少必需字段——你不需要分类器来发现。你的解析器已经发现了。它抛出了异常。这个异常就是一个信号，而且它有一个大多数路由信号求之不得的特性：它是确定性的，而且是免费的。不需要调用第二个模型来判断"这够好吗？"不需要调优置信度阈值。输出要么能按你的 schema 解析，要么不能，你的代码已经知道是哪种情况了。

这就将 Lightning 最大的弱点重新定位为一项资产。Lightning 在 24% 的调用中格式失败——是场上格式失败率最高的模型之一。对于大多数基准测试来说，这是它的减分项。对于路由器来说，这是一个内置的绊线：24% 的时间里，这个便宜的模型会——机械地，以栈跟踪的形式——告诉你"升级我。"其余 76% 的时间里它返回有效输出。而在 Lightning 所有正确答案中，每次正确答案的成本是 Opus 的 1/78（与 gpt-5.5 相比差距较小，大约 39 倍）——这正是第二部分中让它成为主力的成本正确比。

所以策略自己就写出来了。在 Lightning 上运行每个请求。如果输出能解析，就保留它。如果不能，就在一个更大的模型上重新运行该请求。你只升级失败的那一小部分——你从不为主流成功案例支付溢价。

以下是该策略的效果，从实际的 Lightning 逐案例输出重新路由：

仅升级约 24% 的失败案例，就能将有效输出从 76% 提升到接近 100%，而路由系统的每次正确答案成本为 $0.0039——比所有请求都用 gpt-5.5 便宜约 4 倍，或升级到 Opus 为 $0.010，比所有请求都用 Opus 便宜约 3 倍。你在四分之一的请求上承受了升级跳转，因此路由平均延迟落在 3,397ms，大约是 gpt-5.5 全开（5,365ms）的 1.6 倍。（升级到 Opus 的路由行落在约 4,800ms——远低于 Opus 全开的 9,679ms，如果你更愿意升级到 Opus 的话。）你只在便宜模型明显搞砸的那部分请求上召唤昂贵模型。

在你将此作为定论之前，这张表格通过它没有声称的东西赢得信任——两个诚实说明，然后是收益。首先，这里恰好只有一个数字是推算的而非实测的：升级路径是一个插补值，而非全新运行。我重新路由了 Lightning 真实的逐案例输出，对于格式失败的调用，将前沿模型的实测平均格式通过率记入其名下，而不是针对 Lightning 具体失败案例重新运行。那约 18 个失败运行（75 次中的 24%）可能是格式最难处理的切片，而非随机样本，因此前沿模型在这些案例上可能比平均水平略差——这就是为什么路由行读作"~95–100%"，而不是硬性的 100%，而两条基线行则有更干净的"~100%（实测）"（gpt-5.5 和 Opus 每次都在完整运行中达到 0.0% 格式失败，这是实测值，不是推算）。其他所有数据都出自逐案例记录，而非混合 headline 平均值，因此你可以用代码仓库中的路由脚本从冻结的评分卡（results/scorecard_multiseed.json）重新生成它——一个"正确"的路由答案是以有效、可解析输出结束的请求，cost/correct 是总混合成本除以该计数，代码对每个输出评分，而非 LLM 评判。第二，第一部分延续的诚实说明：24% 的升级比例本身就是一个具有宽区间的点估计，因此在这个样本量下，路由系统的行为可能取决于少量独立案例。形状是成立的；精确的盈亏平衡点有待你自己测量。（样本量机制的更多细节在末尾。）

有了这张表格——默认便宜，关键时候谨慎，你不再需要选择。仔细体会一下，因为这就是全部要点：你在第二部分结尾面对的权衡刚刚消解了。不是用更大的模型，不是用更大的预算——而是用一个你一直在丢弃的栈跟踪。

快速、廉价、准确——三者兼得的方案

每个团队都希望从智能体得到同样的三样东西：快速、廉价、准确。第一和第二部分的教训是，没有任何一个模型能三者兼得——你得到两样，为第三样付钱。把每个选项都放到一个简单的三栏测试中——4 秒以内、每次正确答案不到半美分、至少 95% 有效可用输出——只有一种配置全部通过：

阅读各行。Lightning 单独使用时快速且廉价但失去准确性（76% 可用）。GPT-5.5 和 Opus 准确但速度和成本都不合格。路由系统——NVIDIA 的 Lightning 承担 76% 的流量，升级处理其余部分——是唯一全部通过三栏的行：3,397 ms，每次正确答案 $0.0039，约 100% 可用。这是一个模型系统的全部论点，浓缩在一张表格里。而解锁它的是 Lightning：没有真正快速、真正廉价的主力を承担大部分负载，你就根本无法同时达到速度和成本标准——两条前沿全开行证明了这一点，困在 1/3。（这里的"准确"意思是有效、可用的输出——那个打断流水线的确定性轴；在可回答的案例上每个模型已经能在正确事实上达到约 100%。知道何时不回答是第四维度，这就是下一节的内容。）

大多数路由帖子跳过的细节：格式不是判断

你能够信任这个胜利的原因是，我要告诉你它恰恰没有覆盖什么——好消息之所以成立，是因为它没有隐藏不方便的那一半。格式失败升级修复的是格式。它不修复判断。

当 Lightning 为一个它本应拒绝的问题编造出一个似是而非的错误答案时，那个答案是有效的 JSON，有着所有正确的键。它能干净地解析。你的绊线永远不会触发。格式失败路由捕获的是那些broken（损坏）的输出；对于那些confidently wrong（自信地错误）的输出，它在结构上是盲的。Schema 检查看不到一个格式良好但虚假的答案——那些将一个臆造的学生住宿政策或一个捏造的截止日期摆在用户面前的输出，恰恰是它放行的那些。

而这并不是一个可以通过"解析检查"来绕过的缺口，从原理上讲就不行。在"缺失事实"探针上——这是特意设计的切片，测试系统询问知识库中实际不存在的内容——Lightning 仅在约 37% 的情况下选择弃权，格式失败路由也只是将其从约 37% 略微提升到约 52%。它无法做得更多：护栏在输出格式崩坏时触发，而一个自信的过度回答具有完美的格式。那约 15 百分点的移动是一个副作用——Lightning 的部分格式失败恰好落在了缺失事实探针上，因此将它们上报让目标模型在那里选择弃权——而不是护栏本身在发挥作用。在这个样本量下，那约 15 个百分点大约等同于一个案例的翻转；它最多只是指明了一个方向，我不会拿它做赌注。结构性结论依然成立：格式检查无法检测到一个自信的错误答案，因此格式路由并不能有效提升弃权率。

正确评估这个风险：Lightning 在约十分之六的缺失事实探针上过度回答——而格式路由几乎无法削减这个问题——但这是在缺失事实探针这一特定切片上，不是你线上流量的真实构成。它在生产环境中对你造成多大损失，完全取决于你的流量中有多少是真正无法回答的，而这恰恰是"在你的知识库上运行测试工具"所能告诉你的。残余风险是真实存在的；其影响范围取决于你自己的测量。

所以诚实的结论分为两部分：

格式失败 → 利用免费的、确定性的信号进行路由（它能解析吗？）。这是真正产生价值的地方。

弃权关键步骤 —— 任何自信的错误回答代价高昂的地方 —— → 根据任务类型在调用之前就决定路由。你无法事后从输出格式检测出这些，所以你在一开始就把整类请求发送给谨慎模型。

这就是第二条好消息的所在，因为它在本周发生了变化：你不再需要离开开放生态才能获得前沿级别的谨慎。在这次运行中，谨慎层是 Ultra——NVIDIA 更大的开放模型，也是唯一一个在每个缺失探针上都选择弃权的模型（100%，置信区间 83–100%）。在衡量一个 AI 智能体的最重要轴线上——知道何时不回答——Ultra 至少和 Opus 一样安全，而且它是开源权重、可自托管的，享受开放模型的经济效益。请谨慎表述：在这个有效样本量约为 5 的情况下，置信区间重叠，所以把这当作一个待验证的方向，而不是一个定论——Ultra 在这里最多只是和 Opus 一样安全，并非明显更好，而快速的 NVIDIA 模型反而是弃权最少的，不是最多的。但这种 relief 的形态是真实的：你的上报目标由你决定——一个更大的 NVIDIA 开放模型（Super 或 Ultra），或者如果你愿意，也可以是一个闭源前沿模型。你不再被锁定了。

要清楚第二层路由的代价。解析检查是被动的、几乎免费的——你已经跑了 Lightning；只有在那些解析失败的调用上才需要支付目标模型的费用。而任务类型路由则相反：这是一个前瞻性的赌注，在你不知道任何给定请求是否需要它之前，就在一整类流量上花费谨慎层的调用费用。在这次运行中，谨慎层 Ultra 也是场上最慢的模型（13,297ms），其每次调用成本在开发者端点上未记录。所以前瞻性路由并不继承"真正产生价值的地方"的廉价快速光环——这是一个以延迟为代价的安全决策，可能还有成本代价，取决于你的流量中有多少是弃权关键的。在你投入预算之前，先量化这个比例。

一个信号是被动的、几乎免费的。另一个是前瞻性的、且在真正重要时值得付出的。一个真实的系统两者都用，而且有必要坦白地说每个问题分别由哪个方案解决——以及哪个方案有一笔你还没有量化的账单。

两个信号都映射到一个真实的、开放的路由器上

这两个信号正是生产路由器暴露的两种路由模式，这就是 NVIDIA 的 NeMo Switchyard——开源、Apache-2.0 许可——的用武之地：它位于你的提供商前方，作为一个 OpenAI 兼容端点，逐请求决定由哪个目标处理。被动式解析检查是一种级联/上报路由；主动式任务类型标签是一种分类器/分阶段路由。两者都是配置块而非手写的粘合代码——这就是它的核心价值。Broken Campus 可以通过它作为一个普通的 OpenAI 兼容代理来运行，用完全相同的确定性代码评分，逐一比较。（上面的"真正产生价值的地方"是从每个案例的记录中计算得出的，不是从实时路由器上读取的——Switchyard 是将这个形态操作化的方式，而不是这些数字的来源。）

所以退后一步，看看这个路由器实际上为你带来了什么——因为它比一个更便宜的基准要大得多。

你实际能部署的收益：更便宜的生产和优势

它使生产成本大幅降低。默认廉价，只在真正重要的地方谨慎：以大约四分之一的前沿模型全面运行成本，获得近 100% 的有效输出。这就是对第一和第二部分中沮丧的解答。你不需要为了 Lightning 的价格而牺牲准确性；你只需要在值得的切片上花费前沿模型的价格。

而且它解锁了前沿模型根本无法触及的部署场景。Lightning 不仅仅是在云端便宜——它是一个 30B 总参数 / 3B 活跃参数的混合专家模型（模型卡），所以每个 token 只有约 3B 参数是活跃的，活跃占用空间小到可以瞄准单个现代 GPU 或边缘级硬件，而不是数据中心。这是一类用例，不是我测量的一个基准数字，但它是这里最重要的：因为你路由设计中默认模型可以放在设备上，完全相同的架构可以服务于对延迟敏感的、设备端的和机器人/边缘工作负载——不仅仅是数据中心。工厂车间里的机器人、没有可靠上行链路的自助服务终端、不能将每个按键都发送到云 API 的应用：它们都能获得同样的待遇——快速、廉价、本地的 Lightning 处理大部分请求，只有当解析检查触发或任务类型需要谨慎时，才通过网络上报给更大的开放模型或前沿模型。默认廉价的设计和设备端的故事是同一个设计。你不需要为了从云端迁移到边缘而重建它。

这就是这个系列一直在走向的答案。不是"一个模型终于赢了"——没有一个赢了，我不会假装它们赢了。胜利在于系统本身：路由，你就同时获得了快速、廉价和谨慎，在云端和边缘都是如此。

一次声明、意在长存的警告

以上一切都是方向性的，不是确定性的，我宁愿你知道原因而不是盲目信任我。基准测试的种子几乎是确定性的，所以有效样本更接近约 5 个不同案例，而不是 75 次运行每个模型的头条数字所暗示的那样；置信区间很宽，而且说实话还是乐观的。这就是这篇文章中每一个对冲背后的机制——宽格式失败区间、估算的上报分支、噪声内的弃权差异都追本溯源于此。知识库是一个小的合成领域。延迟数据来自 NVIDIA 的免费开发者端点，不是付费的生产层级。

我会坚定站队的方向：成本、速度和格式纪律是大、干净、测量良好的效应——表格的形态是真实的。我只能指向一个方向的地方：细粒度可靠性排名（谁比谁多弃权几个百分点）都在重叠的区间内——把"Lightning < Super < Ultra"当作一个假设，而不是裁决，并注意 Ultra 最多只是和 Opus 一样安全，并非明显更好。路由的形态——默认廉价、按信号上报——是持久的收获。你的系统里确切的盈亏平衡点取决于你的流量构成，而这正是测试工具的用途。

在你自己的 AI 智能体上运行它

先获取各个组件——全部免费/开源：在 build.nvidia.com 上试用托管模型（免费 NVIDIA API 密钥），从 huggingface.co/nvidia 获取开放权重来自托管，路由器是 NeMo Switchyard（Apache-2.0）。然后 Broken Campus 是开源的，可以在你自己的密钥上运行：

git clone https://github.com/torkian/broken-campus
cd broken-campus
pip install -r requirements.txt
cp .env.example .env        # 粘贴你的 NVIDIA / OpenAI / Anthropic 密钥
python list_models.py       # 你的密钥可以调用的确切模型 ID
python run.py               # 完整基准测试 → results/ + 评分卡

你只需要为你想要测试的提供商准备 API 密钥；其余的会被跳过。所有模型使用相同的提示词、相同的工具、相同的评分代码——一个最小化的测试框架，真正做到同类比较。替换成你自己的知识库和事实，你就能得到你自己的过度回答率、格式化失败率，以及关于何时该升级（escalation）胜过一味跑 frontier 模型的成本平衡点——还有每个案例的转录记录，让你看到它是怎么失败的，而不只是知道它失败了。

要通过 Switchyard 运行路由变体，添加 BC_SWITCHYARD=1 python run.py——但那路径是 operationalization 路线，不是头条数据的来源。那些数据来自冻结的记分卡和逐案例路由脚本，两者都完全不经过代理。在接线代理时有两个现场笔记坑了我，所以别重蹈我浪费的那个下午：

分类器目标必须是 NIM，不能是 OpenAI 模型。Switchyard 向每个分类器调用注入一个 vLLM 特定的提示（chat_template_kwargs={enable_thinking: false}），而 OpenAI 端点会返回 400 错误。将分类器指向一个快速的 NIM，比如 meta/llama-3.1-8b-instruct，它会接受并忽略这个参数。

一个"高效"的模型只有在快速模式下才高效。在一次接线测试中，我把 Nemotron reasoning 层级留在了思考模式，结果它通过代理的回答速度比 Opus 慢了约 10 倍——目标模型的基准延迟是 ~13 秒，而不是我看到的 ~23 秒，所以这是配置问题，不是模型本身的属性。我追查了一下午后才发现这个"便宜"模型在每次调用时都在悄悄消耗 reasoning 预算。这个教训仍然成立，即使通过代理的数字是轶事证据：如果目标的快速模式实际上没有开启，路由到便宜模型什么也买不到。务必确认。

然后去打破它。PR 添加模型、领域和新的案例分类正是重点所在——我宁愿你证伪我的数字，也不希望你盲目接受。

而这才是我想留给你的一个笔记，因为这是答案存在的真正原因。回到第 1 部分开头，我请你接受一些令人沮丧的数据，并承诺它会有所回报——作为一个发现而非一个承诺，目的地会更有冲击力。这就是那个发现，而这是我一直藏在心里的部分：让这个系统工作的各个部分——可以放在桌上的小模型、无需租用闭源模型就能达到 frontier 级谨慎的更大开源模型、以及将它们绑在一起的 Apache-2.0 路由器——都是开源的，NVIDIA 在同一周内以开源权重和开源工具的形式发布了它们。这就是那些丑陋的数据一直指向的方向：不是某个最终获胜的单一模型，而是一个能够用自己真正拥有的组件组装出快速、便宜、谨慎的开发者。这是目前推动生成式 AI 前进的最大的开源贡献之一，这就是为什么这个系列诚实的结局不是警告——而是一个邀请。带上你自己的知识库，路由它，然后交付那个曾经是权衡的东西。

整个系列用来测量的数字从来不是你模型在排行榜上的名次。它比那更安静：下一次你的 AI 智能体不知道答案时，它会不会说出来——还是它会给你一个干净、格式良好、自信满满的废话，完美地绕过你的解析器？现在你有了一个可以诚实回答这个问题的系统，在你的硬件上，用你自己的方式。

B Torkian 是 NVIDIA Developer Champion。Broken Campus 是开源的，位于 github.com/torkian/broken-campus。所有数据来自 8 模型 × 5 seed 的审计加固运行，置信区间采用 Wilson 95%，基于合成领域——方向性结论，非确定性结论；seed 接近确定性，所以实际样本更接近 ~5 个不同案例，而非标题中的 75 次运行。