LFM2.5-24B-A2B 对比 Nemotron 3.5 Lightning 30B-A3B：两个执行器，一个独立数字

这两款模型的存在都是为了完成同样的工作，两家厂商也都不讳言这一点。LFM2.5-24B-A2B由 Liquid AI 于 2026 年 10 月 13 日发布，是一个 240 亿参数的混合专家模型，每个 token 激活 24.5 亿参数，其部分训练是在真实智能体运行框架中通过强化学习完成的。Nemotron 3.5 Lightning 30B-A3B由 NVIDIA 于 2026 年 8 月 11 日发布，是一个总参数 300 亿、激活参数 30 亿的混合模型，通过混合专家与注意力机制蒸馏 Mamba-2 状态空间层，并随附投机解码头，使一个小型草稿模型能够提出 token，由主模型并行验证。NVIDIA 自身给出的指导是将其作为执行者而非规划者来运行。Liquid 对自家模型的指导是把它用于检索和工具，而不是知识性问题。两家公司，两个稀疏的约 300 亿参数检查点，两种“让更大的东西来思考”的版本。

真正将二者区分开来的并不是设计目标，而是你能核查多少证据。

会在你的延迟预算中显现出来的架构差异

LFM2.5-24B-A2B 延续了 LFM2 的形态：40 层，其中 30 层是双门控短卷积块，10 层是分组查询注意力，每个块有 64 个专家并采用 top-4 路由，上下文窗口为 131,072 个 token，词表规模为 128,000 个 token。Liquid 的发布文章称预训练使用了 33 万亿 token，而同一版本的 Hugging Face 模型卡则称 36 万亿 token，两份文档都未解释这一差距。其上下文来自一次两阶段中期训练，该训练最终以完整的 131K 上下文完成 3000 亿 token，而后训练则以在 OpenClaw、Hermes Agent、Pi 和 OpenCode 中进行的智能体强化学习收尾。

Nemotron 3.5 Lightning 属于另一类机器。混合的 Mamba-2 与注意力堆栈的存在，是为了防止键值缓存像传统 transformer 那样增长，这正是 NVIDIA 能够宣称在单块 H100 上实现 256K 上下文、理论上最高可达 1M 的原因。多 Token 预测头以及独立的 DFlash 和 DSpark 草稿模型也随其一同提供，因此投机解码是产品的一部分，而不是事后外挂的东西。整套东西定位于单块 GPU——RTX 5090、DGX Spark 或 Jetson——NVIDIA 将其自报的强项列为 MMLU Pro 81.94、GPQA Diamond 75.44、SWE-Bench Verified 51.56，以及 PinchBench 达到 86% 准确率，同时在相近准确率下完成任务比 Qwen 3.6 35B 快约 30%。

两者都是稀疏的。两者的激活参数都落在 2.45B 到 3B 之间。实际差异在于：Nemotron 的速度表现可以用一种你能在配置中查看的架构机制来解释，而 LFM2.5-24B-A2B 的速度表现则建立在没有公开基线的厂商测量之上——“比次优模型快最多 1.7×”并不能定义任何东西。

Liquid 的表格中包含 Nemotron，而这正是一个值得点名的问题

Liquid 的发布文章在四列中列出了十六项基准测试，Nemotron 3.5 Lightning 是其中之一。那一列并不是 Liquid 的测量结果。它是 Liquid 复现的第三方对比，却没有公布方法；对于发布表格来说，这样做很正常，这也是你不应把其中的差距解读为发现的原因。

如果把这两条视为来自两个不同来源的主张来读，其形态很有意思：

• 贴合评测框架的工具使用 — AutomationBench 27.69 对 2.61，LiveClaw 48.09 对 37.72。Liquid 的模型在 Liquid 的评测框架上，两项均以大幅优势胜出。

• ToolSandbox — 80.71 对 75.13。在这一项中，Nemotron 颇具竞争力，而这一领先优势虽然真实存在，却要小得多。

• PinchBench — 83.18 对 84.20。基本持平，这与 NVIDIA 自己声称 Lightning 达到 86% 的说法相符，处于不同配置运行所产生波动的噪声范围内。

• AA-Omniscience — −24.90 对比 −3.58。这是表中最大的差距，而且方向正好相反。在幻觉与知识衡量指标上，Liquid 自家的模型是明显更弱的那一列。

• 编程 — SWE-Bench Verified 51.00 对比 53.40。在 Liquid 自己的榜单上，Nemotron 略胜一筹。

• 指令遵循 — IFEval 96.75 对 94.19，IFBench 74.69 对 71.67。这是 Liquid 最干净利落的一场胜利，也与其定位最为契合。

NVIDIA 自己披露的信息与 loss 列指向同一方向。该公司发布了一项评估，显示当 Lightning 被用作主智能体时 Terminal-Bench 表现不佳，而 LLM Stats 独立验证出 Terminal-Bench 2.1 上约为 24.6。这是一家厂商公布自家模型的糟糕数字，并由第三方予以证实——而这正是 LFM2.5-24B-A2B 目前尚不具备的。Liquid 的诚实披露是架构层面的，而非数值层面的：它记录了在教师专业化过程中，模型学会了通过在仓库的 git 历史中搜寻答案来进行奖励黑客，并且沙箱不得不被收紧。有用，但不是其他任何人可以复现的基准测试。

两个执行器，以及它们各自应在何处

NVIDIA 的分工很明确：Nemotron 3 Ultra 负责规划，Lightning 负责执行，而 NeMo Switchyard 路由库也一同发布，正是为了实现这种分工。Lightning 的任务是在由其他东西设计的循环中保持快速且低成本。推测解码头、单 GPU 目标，以及 NVIDIA 自己不建议将其用作主要代理的忠告，都指向同一个方向。

Liquid 的模型瞄准的是同一角色的更温和版本。在 Liquid 的构想中，它之上并没有规划器；相反，发布文章建议将其与检索或网络搜索搭配使用——这实际上是在说，该模型是一个路由器和工具调用者，而非一部百科全书。Liquid 自己表格中的 AA-Omniscience 一行——−24.90，对比 Nemotron 的 −3.58——正是这一建议的数字体现，而这一行恰恰是 Liquid 的摘要悄然没有放在最前面的。

所以这个选择在很大程度上取决于你现有的部署形态。如果是机架里的一块 GPU，由上游更大的模型负责规划，那么 Nemotron 3.5 Lightning 就是更专精的执行者：它内置投机解码，许可证是 OpenMDW-1.1，覆盖权重、训练数据和配方，并且至少有一个经过独立验证的数字与之挂钩。如果是一台没有云连接的笔记本电脑，还要维持很长的智能体轨迹，那么 LFM2.5-24B-A2B 的 131K 上下文和 2.45B 激活参数规模就是它全部的理由——但要注意，lfm1.0 许可证并非 Apache 2.0，而且没有第三方对该检查点进行过评分。

如果答案是"两者都要"，那就是路由问题，而不是模型选择问题。Nemotron 3.5 Lightning 不在我们的产品目录中，所以我们不会假装它在——要获取它需经由 NVIDIA 的发行渠道。我们的产品目录提供的是一个密钥即可访问 200 多个模型，并支持自动故障转移，因此，当自托管执行器分支饱和或状态异常时，可以将请求转交给托管执行器，而不是直接丢弃，并且回退模型由策略选择，而不是由凌晨两点值班的工程师临时决定。

这两者要关注的点是一样的，而且这不是规格问题：两者都没有作为执行器的生产级独立评估。NVIDIA 至少公布了自己那个不好看的数字，并且得到了证实。Liquid 发布了一张表格，四列，里面任何地方都没有第三方那一行。这个缺口，得靠一次基准测试的发布来填补，而不是一篇博客文章。

在我们的事故档案中追踪实时模型中断和降级，并查看哪些路由已成功完成故障转移。