NVIDIA Nemotron 3.5 Lightning：给 AI Agent 配上的高效执行引擎

NVIDIA Nemotron 3.5 Lightning 最值得关注的地方，不是它有“300 亿参数”这个醒目的数字，而是它没有把所有参数都用于每一次生成。

这款模型于 2026 年 8 月 11 日发布，是面向自主 AI Agent 的专用执行模型：当 Agent 已经完成任务规划，接下来需要反复调用工具、提取字段、检查规则、转换数据或整理输出时，Lightning 负责把这些步骤更快地完成。

它到底是什么模型？

Nemotron 3.5 Lightning 是一个开源的 30B 混合专家模型（Mixture of Experts，MoE），面向长期在线运行、需要持续处理大量专门任务的 Agent。NVIDIA 将 Nemotron 系列定义为开放模型，开发者可以获得模型权重、训练数据和训练配方，并在部署前进行评估和定制。

模型同时提供 BF16 和 NVFP4 版本。相关模型资料将其描述为结合状态空间或 Mamba 风格处理、注意力机制与路由专家的混合架构，目标是在保留较大模型容量的同时，避免每个 token 都激活完整网络。

“30B 总参数”和“约 3B 激活参数”并不是同一个指标：

• **30B 总参数：**模型中全部可学习参数的规模。
• **约 3B 激活参数：**生成每个 token 时实际参与计算的参数规模。

这种稀疏计算让 Lightning 可以拥有更大的参数池，同时争取接近小型活动网络的单 token 推理成本。不过，稀疏激活并不意味着完全不需要存储或管理完整模型；它主要减少的是每一步生成所需的计算量。

为什么它要做 Agent 的“执行层”？

一个长期运行的 AI Agent，往往不是只调用一次模型。完成一个看似简单的任务，可能需要多次选择工具、读取文档、抽取结构化信息、验证结果，并按照固定格式返回答案。

如果每一步都交给面向前沿推理的大模型，延迟和运营成本可能随调用次数快速上升。Lightning 的设计思路，是接管工作流中相对可预测、调用频率最高的部分，而把真正模糊、复杂的决策留给能力更强的模型。

典型的双层架构可以这样运行：

1. 大型推理模型理解目标并制定计划。
2. Lightning 针对工具、文档或结构化数据执行常规步骤。
3. 遇到不确定性、异常情况或需要深度推理的节点时，再调用大型模型。

NVIDIA 将 Nemotron 3 Ultra 定位为前沿推理和 Agent 编排模型。Ultra 拥有 550B 总参数、55B 激活参数，这也清楚地体现了它与 Lightning 之间的分工差异。

NeMo Switchyard 负责“派谁上场”

双层模型架构能否发挥作用，关键在于路由：系统必须判断每一步任务该交给哪个模型，而不是把所有请求发送到同一个接口。

NVIDIA 的 NeMo Switchyard 提供了与具体服务商无关的路由 SDK，可用于描述请求、定义可用模型，并管理向指定服务商或模型 ID 发起的调用。

换句话说，开发者可以建立一套模型层级：Lightning 处理大多数例行请求，大型模型则接手高风险或高难度任务。因此，Lightning 最有价值的产品形态并不是一个孤立的聊天机器人，而是路由式、多模型 Agent 系统中的一名高效“执行员工”。

100 万 token 上下文与部署选择

Lightning 宣传的上下文容量最高可达 100 万 token，这对需要维护长对话、处理大型文档或持续保存任务状态的 Agent 很有吸引力。不过，实际可用上下文和性能仍取决于推理服务栈及具体配置。

NVFP4 检查点面向推理部署，并使用适配 NVIDIA GPU 的专用内核。NVIDIA 将其部署范围覆盖本地基础设施、工作站、数据中心和云环境；模型也可通过 Hugging Face 及托管服务使用。

在云端，AWS 表示 Nemotron 3.5 Lightning 已进入 SageMaker JumpStart，用户可以通过 SageMaker 控制台或 Python SDK 部署。 NVIDIA 的 NIM 文档则提供了另一条容器化部署路径，并列出了操作系统、CUDA、驱动程序和 Docker 等要求。

但“能否单卡运行”不能只看 3B 激活参数。实际可行性还受到 GPU 显存、完整模型存储需求、上下文长度、量化方式、批处理规模和推理软件的共同影响。对于具体笔记本或台式机是否适用，仍应以当前模型卡和官方部署配方为准，不能将个别硬件测试结果直接推广到所有设备。

NVIDIA 的速度数据，必须放回具体工作负载中看

NVIDIA 和 AWS 宣传称，Lightning 在目标 Agent 工作负载上可实现最高 4 倍吞吐量，并将任务完成速度提升最高 30%。 这些是厂商或平台给出的特定场景数据，不等同于模型智能水平，也不代表所有生产环境都能获得相同结果。

实际表现可能受到以下因素影响：

• 对比基准模型是什么；
• GPU 代际与显存配置；
• 批大小和并发量；
• 输入提示与上下文长度；
• 工具调用及网络延迟；
• 解码参数；
• 任务允许的错误率。

因此，评估 Lightning 时，不应只盯着每秒生成 token 数。更有价值的指标包括信息抽取准确率、工具调用可靠性、结构化输出合规率，以及从请求开始到任务完成的端到端耗时。

价格有吸引力，但取决于服务商

托管推理价格可能是 Lightning 适合高频调用的重要原因之一。DeepInfra 列出的价格为每 100 万输入 token 0.05 美元、每 100 万输出 token 0.20 美元，采用按使用量计费，开发者无需自行管理 GPU 基础设施。

不过，这不是模型固有的永久价格。不同服务商的报价可能不同，精度、缓存策略、路由和服务形态也会改变实际成本。

因此，团队在比较 Lightning 与更大模型时，应计算完整工作流成本，包括重试、工具调用、模型路由，以及那些仍然必须交给高能力模型处理的请求。

结论：它是“工兵”，不是“总指挥”

Nemotron 3.5 Lightning 更适合被理解为 AI Agent 系统中的快速、可定制工作模型。当应用会产生大量相似请求，而且任务可以被约束、专门化或进一步训练时，它的设计就很有意义。

它并不是大型编排模型的通用替代品。复杂规划、不确定判断，以及错误代价很高的任务，仍可能需要 Nemotron 3 Ultra 或其他前沿系统。

实际判断并不复杂：如果你的 Agent 需要一个低延迟、低成本的执行层，Lightning 值得测试。它的 30B 总容量、约 3B 激活参数、开放模型材料、量化推理选项和多种部署路径，都是为了让重复性 Agent 工作变得更快、更便宜。至于厂商宣称的性能提升，最终仍应放到具体业务流程中验证，而不能直接当作生产结果。