2026 年 8 月 11 日，NVIDIA 发布了 Nemotron 3.5 Lightning，并把权重直接扔上了 Hugging Face。这个发布有个不寻常的地方：大多数模型发布只给一个 checkpoint，NVIDIA 这次还同场发布了 NeMo Switchyard——一个开源的模型路由库，用来决定 Agent 循环里的下一次调用该发给哪个模型。
这个组合透露了 NVIDIA 的意图：Lightning 不是要跟 Claude、GPT 正面比智力，而是给长时运行的 Agent 当「执行层」。一个跑几小时的编程 Agent，烧掉的 token 大头不是规划和决策，而是无数次 git status、读文件、解析工具输出这类高频低难度调用。每一步都用旗舰推理模型，账单和延迟会一起爆炸。Lightning 就是 NVIDIA 给这一层开出的开源答案。这篇文章走通三件事：规格怎么看、本地怎么跑、Agent 工作流怎么接。
一、关键规格先摊开看
| 规格 | 数值 | 实操含义 |
|---|---|---|
| 架构 | 混合 MoE（Mamba-2 + MoE + Attention） | 长上下文下 KV 缓存压力比纯 Transformer 小 |
| 总参数 / 激活参数 | 30B / 约 3B（A3B） | 每次前向只动用 1/10 参数，速度快、显存占用友好 |
| 上下文窗口 | 1M token | 整个代码库、长日志可以一次塞入 |
| 权重 | Hugging Face 上提供 BF16 与 NVFP4 两个版本 | NVFP4 量化版显存需求大约只有 BF16 的 1/4 |
| 部署目标 | 单张 H100 或 DGX Spark | 消费级高端显卡跑 NVFP4 版也有机会 |
| 配套组件 | NeMo Switchyard 路由库（同日开源） | 在 Agent 循环里按质量/延迟/成本分发请求 |
官方自测基准挑几个有代表性的（NVIDIA 自家测试口径，横向对比需谨慎）：MMLU Pro 81.94，GPQA Diamond 75.44，SWE-bench Verified 51.56，Terminal-Bench 2.1 24.58，BrowseComp 36.97。NVIDIA 声称其输出速度最高可达同体量模型的 4 倍，并在 1 万个任务的批量测试中比 Qwen3.6-35B 快 30% 且准确率相当。
注意一个事实边界：发布初期社区流传「Lightning 在 Agent 任务上超过 Claude Sonnet 5」的说法，NVIDIA 自己的模型卡并没有这么讲。它的定位是够快、够便宜、够用的执行层，而不是旗舰替代品。
二、想清楚它在你架构里的位置
把 Agent 的调用分成两层，是这套玩法成立的前提：
- 规划层：拆任务、做决策、 review 最终产出。调用次数少、难度高，继续用旗舰模型（Claude、GPT 系列）。
- 执行层：读文件、跑命令、解析输出、格式转换、简单改写。调用次数占 80% 以上、单步难度低，切到 Lightning 这类本地开源模型。
一个直观的账本：假设一个长任务 Agent 一晚上跑 500 次工具调用，平均每次 2 万输入 token、2 千输出 token。全部走旗舰 API，输入侧就是 1000 万 token；把执行层切到本地模型后，这部分成本直接变成电费，API 账单只剩下规划层的几十次调用。Switchyard 这类路由库存在的意义，就是把「这次调用该去哪一层」的判断自动化，而不是靠你手写 if-else。
三、本地部署：vLLM 一条命令起服务
Lightning 是 30B 总参数的 MoE，BF16 版权重大约需要 60GB 显存，适合单张 H100 或 128GB 统一内存的 DGX Spark；NVFP4 量化版把权重压到 15GB 量级，24GB 级别的消费级显卡也有机会跑起来（但要给 KV 缓存留空间，别指望开满 1M 上下文）。
部署用 vLLM，注意升级到新版本——Mamba 混合架构需要较新的推理引擎支持：
pip install -U vllm
# NVFP4 量化版（显存有限时选这个）
vllm serve nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 \
--max-model-len 131072 \
--port 8000
# 显存充足（H100 / DGX Spark）可以上 BF16 全精度版
# vllm serve nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16 \
# --max-model-len 1000000 --port 8000
起服务后是一个 OpenAI 兼容接口，先用 curl 验证：
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4",
"messages": [{"role": "user", "content": "用一句话解释什么是 MoE 模型"}]
}'
--max-model-len 建议按显存实际余量从小到大试：先 128K 跑通，再逐步往上加。上下文开得越长，KV 缓存吃得越狠，Mamba 混合架构能缓解但不可能豁免。
四、把 Agent 的执行层切过去
有了 OpenAI 兼容端点，接入主流 Agent 工具就是改环境变量的事。以 Claude Code 为例，它支持把后端指到任意兼容端点：
export ANTHROPIC_BASE_URL=http://localhost:8000/v1
export ANTHROPIC_MODEL=nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4
更实用的姿势是分层混跑：规划与最终审查仍走云端旗舰模型，把批量、重复的执行型任务（日志清洗、单测修复、格式化改写、文档生成）发给本地 Lightning。想做得精细，就上 NeMo Switchyard 这类路由层，按任务类型、延迟预算和成本阈值自动分发，而不是手动切换环境变量。
一个合理的落地顺序：
- 先拿一个真实的长跑任务（比如给老项目补单测）全程本地跑一遍，记录完成率和翻车点；
- 把翻车的任务类型记下来，这些保留给旗舰模型；
- 跑顺的任务类型固化到路由规则里，逐步扩大本地模型的承接比例。
五、注意事项与常见问题
- 基准是 NVIDIA 自测口径：SWE-bench Verified 51.56 这类数字与同体量模型比较有意义，和旗舰模型比较没有。别用它替代规划层。
- 量化有代价：NVFP4 在大多数执行任务上够用，但涉及精确计算、长链推理的任务建议用 BF16 或回退到云端模型。
- 1M 上下文是上限不是标配：本地部署时上下文开多大取决于显存，盲目开满会直接 OOM。
- 工具调用格式要实测：不同 Agent 框架对 function calling 的格式要求不同，接入后先用几个简单工具调用验证解析是否正常，再跑长任务。
- 新模型生态在爬坡：发布才 10 天，Ollama、llama.cpp 等更轻量的运行方式支持情况请以官方模型卡和社区最新动态为准，vLLM 是目前最稳的路径。
小结
Nemotron 3.5 Lightning 的价值不在榜单，而在于它把「Agent 执行层」这个角色产品化了：30B 参数只激活 3B 的速度、百万级上下文、开放权重、单卡可跑，再配一个同日发布的路由库。如果你正在跑长时 Agent 任务且对 API 账单敏感，值得花一个下午把它在本地跑起来，先把最重复的那批调用切过去——省下来的钱，比你想象的多。