行业动态

英伟达在2026年8月11日发布了开放模型 Nemotron 3.5 Lightning。它的定位并不是用更大的参数规模去追逐旗舰模型，而是把重点放在 AI Agent、RAG、代码与工具调用这类高频工作负载上：总参数量30B，但每次推理只激活约3B参数，并支持最高100万 token的上下文窗口。对于需要长期运行、频繁调用模型的智能体系统，这种设计直接瞄准了推理成本、延迟和本地部署门槛。

图片来源：NVIDIA

30B参数，但每次只激活3B

Nemotron 3.5 Lightning采用混合 LatentMoE架构，将 Mamba-2、Mixture-of-Experts和部分 Attention层组合在一起。MoE的核心价值在于，模型虽然拥有300亿总参数，但单个 token推理时只会调用其中约30亿参数，因此能在保留较大模型容量的同时降低实际计算量。

英伟达给出的官方模型卡显示，Nemotron 3.5 Lightning支持最高1M token上下文，并加入 Multi-Token Prediction层，用于一次预测多个后续 token。模型同时提供多种推测解码方案，包括面向低并发数据中心场景的 DFlash，以及针对 DGX Spark本地工作流优化的 DSpark，目标都是进一步压低生成延迟。

面向 Agent、RAG和代码工作负载

英伟达将 Nemotron 3.5 Lightning定位为通用推理与对话模型，但官方列出的重点场景明显偏向智能体系统，包括长期运行的 Agent、子智能体、RAG、聊天机器人、代码任务、工具调用和指令执行。相比把所有请求都交给大型前沿模型，这类3B激活参数的模型更适合承担大量重复、结构化和高频步骤。

从官方基准看，NVFP4版本在 SWE-bench Verified上得分52.80，在 GPQA Diamond上为75.57，IFBench为72.88。英伟达还公开了对应评测配方，便于开发者复现。需要注意的是，这些指标适合用来理解模型能力边界，但并不等于任何实际业务都能获得同样效果，Agent系统仍然需要针对工具链、提示词和领域数据单独测试。

百万上下文是它最实用的卖点之一

Nemotron 3.5 Lightning的最大上下文长度达到1048576 token，也就是通常所说的百万级上下文。这使它更适合长文档聚合、多轮任务历史、代码仓库分析以及持续运行的 Agent工作流。对 RAG系统而言，更大的上下文也意味着可以一次容纳更多检索结果，但是否应该把整个知识库直接塞进上下文，仍然取决于显存、KV Cache和实际延迟要求。

官方资料显示，这个模型在预训练阶段使用了超过20万亿 token，并在后训练阶段覆盖代码、数学、科学、工具调用、结构化输出、指令遵循和长距离检索等任务。预训练数据截止到2025年9月，后训练数据截止到2026年5月。

“16GB显存能跑”需要看量化方式和上下文长度

截图中提到“量化后16GB显存就可以跑”，这在社区量化版本和受限上下文配置下已经有人实现，但不能简单理解为官方 NVFP4版本在任意配置下都只需要16GB显存。官方 BF16模型卡给出的单 GPU部署参考包括 H100 80GB、A100 80GB，以及通过 llama.cpp使用 GGUF Q4_K_M在 RTX 5090上运行；DGX Spark则有专门的 NVFP4与 DSpark配方。

本地部署时，模型权重只是显存占用的一部分。上下文越长，KV Cache占用越高，因此16GB显存能否稳定运行，还取决于具体 GGUF量化等级、上下文长度、KV Cache精度、推理后端以及是否把部分层卸载到系统内存。对普通消费级显卡用户来说，更现实的做法是先从较短上下文和较低量化版本开始，再逐步增加上下文。

英伟达正在把开放模型推向“执行层”

Nemotron 3.5 Lightning的意义不只是又多了一款30B开放模型。英伟达同期还推出了 NeMo Switchyard，用来根据任务复杂度自动把不同步骤路由到更合适的模型。两者放在一起看，思路很清楚：复杂推理交给更强模型，高频、重复、工具型任务则交给更轻量的模型处理。

对于企业 Agent和本地 AI来说，这种模型分工可能比单纯追求更大的参数规模更实用。Nemotron 3.5 Lightning提供开放权重、百万上下文、3B激活参数以及多种推测解码方案，适合开发者拿来做私有化 Agent、RAG、代码助手和领域定制。不过，实际部署时仍应根据显存、上下文长度和并发量选择 BF16、NVFP4或社区 GGUF版本，而不是只看“30B”或“16GB”这两个数字。