Granite 4.2 30B 对比 Nemotron 3.5 Lightning：思考者与实干者

Granite 4.2 30B 和 Nemotron 3.5 Lightning 是两个 30B 开源权重模型，发布时间相隔十四天，却身负几乎相反的使命。Nemotron 3.5 Lightning 由 NVIDIA 于 2026 年 8 月 11 日发布，是一个总参数 30B / 激活参数 3B 的混合架构 MoE 模型——由 Mamba-2 状态空间层、MoE 和注意力机制组成——旨在充当智能体系统的执行层：快速工具调用、高吞吐循环、子智能体任务，并能运行在单块 GPU 上。Granite 4.2 30B 由 IBM 于 2026 年 8 月 25 日在 Hugging Face 上悄然发布，是一个稠密的 290 亿参数推理模型——一位思考者，具有可选的思考模式和智能体强化学习能力，同样支持自托管。两者均为开源（Apache 2.0，对比 OpenMDW-1.1），都能在团队实际拥有的硬件上运行，且都是 8 月发布的版本，其基准测试结果本质上仍由厂商自行报告。有趣的问题不在于哪个更好，而在于你需要哪一个——规划者、执行者，还是两者都需要。

这种规划器/执行器的划分并非编辑们的主观创造，而是NVIDIA自己的设计。Nemotron 3.5 Lightning是从规模大得多的Nemotron 3 Ultra中蒸馏出来的，目的就是让前沿模型负责规划，而由Lightning运行执行循环。NVIDIA还将它与NeMo Switchyard一同推出，后者是一个路由库，精确实现了这种任务分工。相比之下，Granite 4.2 30B则试图在单个30B模型中充当完整的智能体。

Granite 4.2 30B，思考者

IBM 的旗舰模型 Granite 4.2 是一款密集的仅解码器 Transformer，具有三种推理模式——完全思考（包裹在 think>.../think> 标签中）、低强度思考和无思考——此外还支持兼容 OpenAI 的工具调用和智能体强化学习，后者训练它在沙盒内操作终端、执行代码和搜索网页。其 128K 原生上下文可扩展至 512K。IBM 的模型卡声称在 AIME 2025 上达到 89.17，在 MMLU-Pro 上达到 77.60，在 SWE-Bench Verified（自有评测框架）上达到 57.00——全部由厂商自行报告，均未经独立复现，且目前尚无 Artificial Analysis 条目。简而言之，它是一个被重点指向智能体工作的通用推理模型，提供 BF16 以及 FP8、NVFP4/MXFP4 和 GGUF 量化版本，让团队能够真正运行它。

Nemotron 3.5 Lightning，实干家

NVIDIA 的入局则完全是另一种形态。“30B A3B”这个名称意味着总参数量为 300 亿，而每个 token 只有约 30 亿活跃参数——这是一种融合 Mamba-2、MoE 和注意力机制的混合架构，使其生成速度快且成本低。它内置了推测解码：多 Token 预测头，以及 DFlash 和 DSpark 草稿模型，由小型草稿模型提出候选 token，主模型并行验证。NVIDIA 声称其输出速度最高可达相近规模模型的 4 倍，而且整个模型可以在单个 GPU 上运行——RTX 5090、DGX Spark 或 Jetson——或在单个 H100 上以 256K 上下文运行，该模型原则上支持最高 1M 上下文。其许可证 OpenMDW-1.1 涵盖了权重、训练数据和配方。

NVIDIA自己的定位直白地说明了Lightning不是什么：其随附的一项评估显示，作为主代理，它在Terminal-Bench上的表现疲弱——LLM Stats独立验证了Terminal-Bench 2.1上约24.6的成绩——官方建议将其用作执行者而非规划者。其自行报告的强项为MMLU Pro 81.94、GPQA Diamond 75.44、SWE-Bench Verified 51.56，以及PinchBench上86%的准确率，同时以相近准确率完成任务的速度比Qwen 3.6 35B快约30%。这些每一项都是NVIDIA自己的数字。

记分牌，诚实标注

有用的比较是列的形状，而不是行的数值：

• Granite 4.2 30B — 约290亿稠密参数，所有参数均处于激活状态；Apache 2.0 许可证；原生 128K / 扩展 512K 上下文；可按请求选择的推理模式；供应商报告的 SWE-Bench Verified 得分为 57.00，Terminal-Bench 2.1 得分为 29.24；思考者。

• Nemotron 3.5 Lightning — 30B 总参数 / 3B 激活参数的混合 MoE；OpenMDW-1.1；1M 上下文（单张 H100 上实际 256K）；推测解码（MTP/DFlash/DSpark）；供应商报告的 SWE-Bench Verified 51.56，~24.6 Terminal-Bench 2.1（经 LLM Stats 验证）；实干者。

按 NVIDIA 的本意来解读那些行：Lightning 在 Terminal-Bench 上的短板是其设计特性——它本就不该规划，而是该执行。Granite 的数字则来自一个声称两者兼顾的单一模型。两套数据在发布时均未经独立复现；但数周之内，两者都将得到复现。

技术栈，而不是模型。

这两个模型与其说是竞争对手，不如说是同一系统中相邻的组件。智能体需要规划器来分解任务，也需要执行器来辛苦完成数千次工具调用。Granite 4.2 30B 试图将两者合并为一个稠密模型；Nemotron 3.5 Lightning 则明确是双模型栈中的一半，另一半是前沿模型。NVIDIA 将这种栈称为 NeMo Switchyard；路由层可以对任意托管和自托管模型的混合执行相同的操作。

这才是如实说明路由情况的地方。这两个模型都不在 OrcaRouter 上——我们既不路由 Granite 4.2 30B，也不路由 Nemotron 3.5 Lightning，两者的可用途径都是您自己的硬件或厂商自己的渠道。但他们所指出的双模型模式正是路由 DSL 的用武之地：为推理阶段组合一个自托管的 Granite 端点，为执行循环组合一个自托管的 Lightning 端点，在前面放置一个托管的前沿模型来处理需要更大余量的规划任务，并用一个 API 密钥驱动全部三个，同时支持自动故障转移。您不必在思考者与执行者之间二选一——您可以组装一个让各自发挥所长的技术栈，让路由器来仲裁。

先哪一个？

如果你希望用一个单一模型来承担全部职责，只维护一套代码库和一套服务栈，并愿意让它处理所有的推理和执行工作，那就从 Granite 4.2 30B 开始——但在信任 57.00 SWE-Bench 这个数字之前，先等第一份独立基准测试结果。如果你正在构建一个高吞吐量的智能体，其中大多数调用都是短小的工具步骤，而延迟是主要预算约束，那就从 Nemotron 3.5 Lightning 开始，让前沿模型或 Granite 端点来负责思考。如果你正在构建任何严肃的东西，答案就是两者兼用——而这样的决策，仅靠 30B 模型的对比是永远不会浮出水面的。