英伟达给长任务 Agent 提速：Nemotron 3.5 Lightning 与 NeMo Switchyard 发布

英伟达今天发布 Nemotron 3.5 Lightning，并同步推出 NeMo Switchyard，目标是让需要连续思考、频繁调用工具、运行数小时甚至更久的 Agent 工作流，以更低成本部署在本地 RTX 工作站、DGX 系统和云端 GPU 上。

Nemotron 3.5 Lightning 是一款面向长时间运行 Agent 工作负载的高效率开放模型，核心卖点不是单轮聊天的极限能力，而是多步骤任务中的推理吞吐、工具调用效率和部署成本。 这也是它与传统大模型新品最大的区别：英伟达没有单纯把参数规模继续做大，而是把注意力放在 Agent 每一步都要付出的计算账单上。

这次发布的模型已经在 Hugging Face 上线，公开模型名称为 NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4。从名称可以直接读出三个关键参数：模型总参数规模为 300 亿，单次推理约激活 30 亿参数，并采用 NVFP4 精度格式进行部署优化。

先看模型：30B 参数，但每次只动 3B

Nemotron 3.5 Lightning 是一款采用稀疏激活思路的 30B 级 Agent 模型，30B 表示总参数规模，A3B 表示单次推理大约激活 3B 参数。 这种设计的价值在于，模型可以保留更大的知识容量和专家分工，但不会在每个 token 上都调用全部参数。

对 Agent 来说，这个区别非常重要。一个普通聊天请求可能只需要模型生成几百个 token，但一个软件开发 Agent 往往要经历读取仓库、定位文件、规划修改、执行命令、分析报错、重新修改、运行测试和总结结果等十几个步骤。每一步都可能触发一次或多次模型调用，最终生成的 token 数量也会显著增加。

如果模型每次调用的成本都很高，长任务很快就会从“能不能完成”变成“值不值得完成”。一个需要 30 次工具调用的代码修复任务，哪怕单次延迟只增加几百毫秒，累计等待时间也会被放大；如果每一步都使用完整的大模型，GPU 显存、算力和并发能力也会同时承压。

Nemotron 3.5 Lightning 的路线正是针对这个问题：用更大的总参数空间保留能力，用更少的激活参数控制单步计算量。 这类模型尤其适合代码代理、企业知识库 Agent、浏览器操作 Agent、网络安全分析和多 Agent 协作等需要长链路执行的场景。

不过，3B 激活参数并不等于模型只有 3B 的能力，也不等于它在所有任务上都能击败 30B 或更大规模的稠密模型。稀疏模型的效果取决于专家路由是否准确、训练数据是否覆盖真实工具使用场景，以及模型在多轮错误恢复中的稳定性。对 Agent 来说，少犯一次工具调用错误，有时比在单轮问答基准上多拿几分更重要。

NVFP4 不是简单压缩，而是把部署目标前置

NVFP4 是一种面向 NVIDIA GPU 推理的 4-bit 浮点量化格式，目标是在降低显存和计算开销的同时，尽量保留模型输出质量。 Nemotron 3.5 Lightning 的公开模型名称直接带有 NVFP4，说明它从发布之初就把高效推理作为产品设计的一部分，而不是先训练一个大模型、再交给开发者自行压缩。

相比传统 FP16，4-bit 权重通常可以显著减少模型占用的显存空间。以 300 亿总参数为例，如果只做粗略的权重存储估算，FP16 需要约 60GB 量级的权重空间，而 4-bit 表示理论上可以降至约 15GB，再加上缩放因子、运行时缓存和 KV Cache，实际占用仍会高于这个数字，但部署门槛会明显下降。

这里需要强调，量化降低的是存储和计算表示的精度，不是把模型的参数数量从 30B 直接变成 3B。 3B 激活来自稀疏架构，NVFP4 则是数值表示方式，两者解决的是不同问题：前者减少每个 token 实际参与计算的参数量，后者减少每个参数所需的存储和计算成本。

对于本地开发者，NVFP4 的意义是让更大规模的 Agent 模型有机会进入 RTX 工作站和边缘 GPU 的部署范围；对于云服务商，意义则是同一块 GPU 可以承载更多并发请求，或者在相同并发量下使用更少的 GPU。长任务 Agent 经常不是被峰值算力卡住，而是被持续运行时间和并发成本卡住，因此这种优化可能比单纯追求首 token 延迟更有实际价值。

但 NVFP4 也有现实边界。不同 GPU 架构、推理引擎和算子实现对 4-bit 格式的支持程度并不相同，实际收益不能只看模型文件大小。显存带宽、KV Cache 管理、批处理策略、专家路由开销和工具调用等待时间，都会影响最终吞吐。开发者下载模型后，仍然需要根据目标硬件选择合适的 NVIDIA 推理栈和运行配置。

NeMo Switchyard：英伟达开始补齐 Agent 的系统层

NeMo Switchyard 是英伟达围绕 Agent 工作负载提供的模型路由与推理调度组件，重点解决不同任务阶段如何选择模型、分配计算资源和维持高吞吐的问题。 它的出现说明英伟达关注的已经不是某一个模型的单点性能，而是 Agent 从规划到执行的完整运行链路。

长任务 Agent 通常不需要始终调用同一个模型。复杂任务拆解、关键决策和最终审查可能需要更强的推理模型；文件检索、格式转换、简单分类、工具参数生成和中间结果校验，则更适合成本更低、响应更快的模型。如果所有环节都使用最高规格模型，系统会变慢；如果所有环节都使用小模型，又容易在关键节点失误。

Switchyard 的思路可以理解为给 Agent 系统增加一套“交通调度层”：高难度请求进入更强的推理路径，重复性和高频任务进入轻量路径，模型之间共享统一的部署和监控机制。这样，开发者不必把每一种模型选择逻辑都硬编码在业务代码里，而是可以围绕任务类型、上下文长度、延迟要求和预算做统一调度。

这类系统对多 Agent 架构尤其关键。一个企业级 Agent 可能同时包含规划 Agent、检索 Agent、代码执行 Agent、安全审查 Agent 和总结 Agent。它们的输入长度、工具数量、容错要求和调用频率完全不同。真正影响系统成本的，往往不是某个模型在公开榜单上的分数，而是这些模型如何协作，以及错误是否会在链路中被放大。

英伟达将 Nemotron 3.5 Lightning 与 NeMo Switchyard 放在同一次发布中，传递出的信号很明确：开源 Agent 的竞争正在从“谁的模型更强”转向“谁能把长任务稳定、便宜地跑完”。 模型权重只是起点，路由、缓存、批处理、工具调用、失败重试和运行监控，才决定了它能否进入生产环境。

与 Nemotron 3 家族的关系：Lightning 更像执行层选手

Nemotron 3 家族此前已经覆盖 Nano、Super 和 Ultra 等不同定位。英伟达官方对这几个方向的描述，可以概括为：Nano 面向高效率的专业子 Agent，Super 兼顾准确性、吞吐和工具调用，Ultra 则面向复杂、多步骤和任务关键型工作流。

Nemotron 3.5 Lightning 的定位更接近长任务 Agent 的高效执行层，而不是单纯追求最大规模的总控模型。 它适合承担大量中间步骤，例如读取和整理上下文、调用工具、执行代码、分析局部结果、生成下一步行动，以及对其他 Agent 的输出进行快速验证。

| 模型或路线 | 主要定位 | 计算特点 | 更适合的场景 | 部署关注点 | |---|---|---|---|---| | Nemotron 3 Nano | 高效率专业子 Agent | 更强调低成本和高吞吐 | 分类、摘要、检索、简单工具调用 | 并发、延迟、显存占用 | | Nemotron 3 Super | 综合能力与工具使用 | 在准确性和吞吐之间平衡 | 多 Agent 协作、复杂业务流程 | 工具调用稳定性、上下文管理 | | Nemotron 3 Ultra | 复杂任务编排与深度推理 | 更高总参数和更强推理能力 | 长周期规划、任务关键型应用 | GPU 规模、成本、调度策略 | | Nemotron 3.5 Lightning | 长任务高效执行 | 30B 总参数、约 3B 激活、NVFP4 | 代码 Agent、企业流程、持续工具调用 | 4-bit 推理支持、路由和吞吐 |

这种分工并不意味着 Lightning 可以取代 Ultra 或所有更强模型。更现实的架构是让高能力模型负责制定计划和处理少数关键节点，再让 Lightning 承担大量可并行、可验证的执行步骤。这样做类似软件系统里的“控制面”和“数据面”分离：控制面负责决定做什么，数据面负责高效地把事情做完。

真正的看点：长任务中的单位完成成本

评价 Agent 模型不能只看单轮问答准确率，还要看它完成一个完整任务所消耗的 token、GPU 时间和失败重试次数。 这是 Nemotron 3.5 Lightning 这类产品最值得关注的地方。

一个模型在 10 轮对话中表现优秀，不代表它能稳定完成一项持续 2 小时的自动化任务。长任务会暴露更多问题：上下文是否逐步膨胀、模型是否会遗忘最初目标、工具调用参数是否可靠、遇到异常后能否恢复、是否会重复执行已经完成的步骤，以及能否在不确定时主动请求人工确认。

英伟达在官方介绍中将 Lightning 定位为该级别中面向长时间 Agent 工作负载的高效率模型。这个表述的重点是“效率”，而不是宣布它在所有通用能力上都成为新的最强模型。对开发者而言，更应该关注以下几组指标：

• 端到端任务成功率： Agent 是否最终完成任务，而不是只看某一轮生成质量。
• 每个成功任务的总 token 数： 反映模型是否会反复解释、绕路或重复调用工具。
• 工具调用准确率： 包括函数选择、参数填写和错误恢复能力。
• 长上下文稳定性： 任务进行几十轮后，模型是否仍然遵守约束。
• 单位任务 GPU 成本： 比单纯的每秒 token 更接近生产账单。
• 并发吞吐： 多个长任务同时运行时，系统是否出现排队和延迟抖动。

这也意味着，开发者在评测 Lightning 时，不应该只把它放进聊天窗口里问几个知识问题。更有价值的测试是搭建真实工具环境，例如让它修改一个代码仓库、执行测试、读取日志并提交补丁，或者让它在企业文档中完成检索、核验和审批建议生成。

对本地部署者意味着什么

Nemotron 3.5 Lightning 的开放权重和 NVFP4 版本，降低了开发者验证长任务 Agent 的门槛，但并没有消除硬件和工程要求。 模型可以从 Hugging Face 免费获取，并在符合许可条件的环境中进行研究、修改和生产部署；真正上线时，仍要处理推理框架适配、显存规划、日志审计和安全隔离。

对个人开发者而言，最直接的价值是可以在本地搭建一个不依赖外部闭源服务的代码 Agent 或知识库 Agent。代码、文档和工具调用结果可以留在自己的设备或私有网络中，适合对数据隐私敏感的研发和企业场景。

对企业而言，Lightning 更适合成为大模型系统中的执行模型，而不是直接替换所有已有模型。企业可以让更强模型负责复杂规划，让 Lightning 负责高频执行，再通过 Switchyard 或自建调度层根据任务难度动态分流。这样既能控制成本，也能减少单一模型故障对整个业务链路的影响。

对 GPU 生态而言，这次发布进一步强化了 NVIDIA 的独特优势：英伟达不仅提供模型权重，还把量化格式、推理软件、部署平台和硬件支持放在同一套技术路线中。开发者获得的是更完整的“模型到系统”路径，但代价是生态绑定也更明显。想在 AMD、Intel 或纯 CPU 环境运行，可能需要等待更完整的格式和算子支持，或者自行进行转换与适配。

开源不等于没有门槛

Nemotron 3.5 Lightning 的开放性主要体现在模型权重和生态可获得性上，生产级部署仍然需要专业的系统工程。 英伟达方面表示，Nemotron 系列采用较为宽松的 NVIDIA Open Model License，允许用户在遵守许可条款的前提下使用、修改、分发并进行商业部署；同时，企业还可以通过 NVIDIA NIM 等产品获得更标准化的部署支持。

开发者需要重点确认四件事。第一，当前 NVFP4 模型是否能在目标 GPU 和推理引擎上原生运行；第二，长上下文下的 KV Cache 是否会成为新的显存瓶颈；第三，模型在中文代码、中文企业文档和本地工具链上的表现是否达到要求；第四，Agent 执行 shell 命令、访问文件和调用内部系统时，是否具备足够的权限隔离。

安全问题尤其不能被模型效率掩盖。长任务 Agent 拥有更长的执行时间，也意味着它有更多机会触碰敏感数据、运行高风险操作或陷入错误循环。生产环境中应该加入工具白名单、命令沙箱、预算上限、最大步数、人工审批节点和完整的审计日志。模型更快，并不代表系统可以少做安全控制。

OpenAI、Anthropic 与开源路线的错位竞争

Nemotron 3.5 Lightning 与 GPT、Claude 等闭源模型并不是简单的参数对比关系，而是部署控制权与系统效率之间的路线竞争。 闭源模型通常在通用能力、产品成熟度和托管体验上更有优势，开发者可以快速接入而不必维护 GPU 集群；开放模型则提供权重可见、数据可控、私有化部署和深度定制等能力。

对于一次性问答、内容生成和复杂研究任务，闭源前沿模型仍然可能更省心。对于每天运行数万次、每次包含几十个工具步骤的企业 Agent，模型是否能以较低成本持续运行，就会成为更重要的变量。Lightning 把竞争焦点放到了后者。

| 对比维度 | Nemotron 3.5 Lightning | 闭源前沿模型 | 传统稠密开源模型 | |---|---|---|---| | 权重可得性 | 可从 Hugging Face 获取 | 通常不可见 | 通常可获取 | | 部署方式 | 本地、私有云、公有云 | 主要由厂商托管 | 依赖开发者自建环境 | | 成本控制 | 可通过硬件和量化优化 | 按调用量或 token 计费 | 取决于模型规模和硬件 | | 定制空间 | 可进行系统级适配和微调 | 受厂商接口限制 | 通常较高 | | 长任务优化重点 | 稀疏激活、NVFP4、路由调度 | 模型能力和服务稳定性 | 依赖模型与推理栈优化 | | 主要风险 | 硬件适配和运维复杂度 | 数据、价格和供应商依赖 | 能力、吞吐和上下文稳定性 |

因此，Lightning 的最佳使用方式不是把它当作一个“开源版闭源模型”来比较，而是把它放进一套可观测、可回滚、可分层的 Agent 系统中。只有在真实任务成功率和单位完成成本上体现优势，它才会从模型仓库里的一个 checkpoint，变成企业愿意长期维护的基础设施。

OpenAI Hub 观察：Agent 的下一场竞争是工程效率

Nemotron 3.5 Lightning 和 NeMo Switchyard 释放出的信号是，Agent 模型正在进入第二阶段。第一阶段关注模型能否理解指令、生成答案和调用工具；第二阶段关注模型能否在长时间运行中保持状态、控制成本、恢复错误，并且在不同硬件和部署环境中稳定交付。

英伟达这次发布最有价值的地方，不是又增加了一个模型名字，而是把稀疏激活、低精度推理和任务路由放到了同一条 Agent 工程链路里。 30B 总参数与约 3B 激活参数，解决的是单步计算量；NVFP4 解决的是显存和推理表示；NeMo Switchyard 解决的是多个模型和多个任务阶段如何调度。三者组合起来，才构成面向长任务 Agent 的完整优化方向。

当然，模型是否真的“更聪明、更快、更便宜”，还需要独立评测和真实业务数据验证。尤其是中文场景、复杂代码库、多工具协作和数十轮以上的长链路任务，不能仅凭模型名称或单次演示下结论。英伟达已经把基础组件公开出来，接下来真正有说服力的答案，将来自开发者在本地 GPU、私有云和生产 Agent 中跑出的成功率、吞吐和成本数据。

截至 2026 年 8 月 11 日，Nemotron 3.5 Lightning 适合被看作一个明确面向 Agent 执行效率的开放模型，而 NeMo Switchyard 则代表英伟达从“卖算力和模型”进一步走向“提供 Agent 运行系统”。对于希望把长任务 Agent 部署在自己掌控的硬件和网络中的开发者，这个组合值得尽快下载、压测和验证；对于只需要简单聊天的用户，它未必会带来同等明显的体验变化。