让AI编程自动切换大小模型！一张RTX 3090扛下88%的请求

一张RTX 3090，外加两台NVIDIA GX10，如何才能让它们高效地协同工作？

最近，Techno Tim把一款300亿参数的模型部署在RTX 3090上，又在两台GX10上运行DeepSeek V4 Flash，试图让AI编程助手自行决定什么时候调用哪个模型。这背后有个很现实的问题：如果一个AI Agent需要连续工作几个小时，其中有多少任务真正需要大模型参与？

简单的文件读取、代码修改、测试执行，和复杂的错误排查，显然有着不同的推理需求。如果全部交给能力最强的模型，既会增加硬件负担，也可能拖慢执行速度。为此，Tim找到了NVIDIA开源的模型路由工具Switchyard，并围绕它展开了一系列测试。

一张3090，把300亿参数模型跑到198 tokens/s

Tim首先搭建了两套本地AI环境。一边是NVIDIA Nemotron 3.5 Lightning，这是一款采用混合MoE架构的模型，总参数量约300亿，但每次推理只激活约30亿参数。他把模型部署在一张24GB显存的RTX 3090上。另一边是DeepSeek V4 Flash，运行在两台NVIDIA GX10上，负责处理相对复杂的任务。

在这套系统里，Nemotron被定义为高效率模型，DeepSeek则承担高能力模型的角色。

然而，第一次性能测试就出了问题。Nemotron Lightning的生成速度只有44 tokens/s。考虑到这款模型的设计重点之一就是高速推理，这样的结果显然不符合Tim的预期。经过排查，他发现自己在vLLM启动配置中启用了`--enforce-eager`参数，导致推理无法利用CUDA Graphs优化。

移除参数后，Nemotron的生成速度直接达到198 tokens/s。作为对比，他测试的一款Qwen 27B Dense模型，生成速度只有43.5 tokens/s。这意味着，在他的测试环境中，Nemotron Lightning的Decode速度达到后者的约4.6倍，Prefill速度也超过5倍。

速度问题解决后，Tim又拿出20项Agent任务检验模型能力。Nemotron完成了11项，DeepSeek完成了7项。虽然Nemotron完成的任务更多，但DeepSeek也解决了部分Nemotron无法处理的问题。这种能力差异，恰好给模型动态调度留下了空间。

模型路由连续翻车，问题竟然出在32K上下文

接下来，Tim将NVIDIA Switchyard接入GitHub Copilot。Switchyard位于AI客户端和模型服务之间，对外提供统一的API接口，可以根据配置把不同请求分配给不同模型。它支持多种路由策略。例如，Escalation可以在小模型遇到困难后升级到更强模型；Advisor允许强模型参与计划和结果审核；Stage Routing则可以根据Agent当前的执行状态动态切换模型。

Tim选择了Stage Routing。他将Nemotron设为默认模型，置信度阈值设置为0.5，并让路由系统参考最近3次工具结果。这样一来，当Agent正常读取文件、修改代码时，请求可以继续交给Nemotron；一旦测试失败、出现异常，系统就有机会调用DeepSeek介入。

听起来很合理，但实测结果却让人大跌眼镜。第一轮10项编程任务中，有6项超时。随后他调整了路由阈值和分类器设置，结果更糟，10项任务中有9项超时。Tim开始检查模型的实际调用记录。其中一项任务，直接交给DeepSeek需要276秒就能完成，但通过Switchyard执行却在300秒时超时。

进一步查看遥测数据后，他终于发现问题，Nemotron的上下文窗口被限制在32K，而一些编程任务的请求长度已经超过这一限制。在一次包含48次路由决策的测试中，22次请求最终进入DeepSeek，但真正由Stage Routing主动选择DeepSeek的只有6次，其余16次都是因为Nemotron装不下上下文而触发回退。

随着Agent工作时间延长，对话历史、工具输出和代码信息不断累积，这个问题会越来越明显。于是，Tim分别测试了32K、64K和128K上下文配置。结果显示，三种配置下的生成速度分别约为183、184和174 tokens/s。即使扩展至128K，速度下降也相当有限。调整之后，同一类任务中，原本48次决策有22次落到DeepSeek的情况，变成了35次决策中只有3次交给DeepSeek。而且，这3次全部来自路由系统的主动判断，再没有出现上下文不足引发的回退。

两个多小时，88%的请求留在RTX 3090

解决路由问题后，Tim决定把测试搬进真实项目。他选择了自己编写的开源应用Little Server。这是一个基于TypeScript、Node.js和Next.js的项目，可以通过Docker部署个人链接页面。

为了避免Agent直接参考现有答案，他删除了项目中的全部测试文件和Git历史，要求Agent自行编写单元测试，并实现至少80%的代码覆盖率。他还额外开发了一套自动化测试框架，让一个外层Agent监控代码Agent的执行，记录模型调用、任务进度和运行结果。整个测试过程中，RTX 3090不断进入满负载状态，而运行DeepSeek的两台GX10大部分时间都在等待任务。

第四轮实验运行了约1小时50分钟。Agent编写了153项测试，涉及19个文件，构建、类型检查、Lint和所有测试全部通过。但部分源文件仍缺少测试，整体覆盖率未达到要求。这一轮共进行了936次模型路由决策，其中779次交给Nemotron，占比约83%。

第五轮实验取得了更好的结果。这一次，Agent连续运行约2小时20分钟，编写了约334项测试，分布在20个测试文件中，所有源文件都得到了测试覆盖。构建、类型检查、Lint和单元测试全部通过，覆盖率也达到了要求。

更值得注意的是模型调度情况，全部1338次路由决策中，1173次交给Nemotron，只有165次调用DeepSeek。也就是说，约87.7%的模型请求都留在RTX 3090上，两台GX10只在必要时参与工作。

不过，这次实验还有一个小插曲。Tim编写的反作弊检测器误判了部分测试代码，导致基准测试最终将任务标记为失败。经过人工检查，他确认Agent实际上已经完成工作，问题出在检测程序自身。

第六轮实验则没那么顺利。Agent一度把语句和行覆盖率提升至74%左右，随后却陷入停滞，覆盖率下降到约50%，最终任务失败。这也暴露了模型路由能力的边界：即使模型调度正常，Agent本身仍可能在长时间执行中失去进展。

经过多轮测试，Tim决定继续保留Switchyard。在他的本地环境里，DeepSeek无需按Token付费，但如果把高能力模型替换成云端Frontier Model，大量简单请求就有机会留在本地完成，减少昂贵模型的调用需求。

当然，88%的请求路由占比并不意味着能够节省88%的费用，具体效果仍取决于Token消耗、模型定价和任务成功率。接下来，他还准备把这套路由机制扩展到Home Assistant、Open WebUI等应用，并尝试利用闲置GPU甚至NPU承担更多AI工作。

对于已经拥有多张显卡、多台AI设备的用户来说，这项实验提供了一个值得继续探索的方向：让不同能力的模型根据任务进展参与协作，充分利用已有硬件，也让长时间运行的Agent拥有更加灵活的算力调度方式。