LFM2.5-24B-A2B 對比 Nemotron 3.5 Lightning 30B-A3B：兩個執行器，一個獨立數字

這兩款模型的存在都是為了做同一件事，而兩家廠商也都沒有假裝不是如此。LFM2.5-24B-A2B由 Liquid AI 於 2026 年 10 月 13 日發表，是擁有 240 億參數的混合專家模型，每個權杖啟用 2.45B 參數，且部分訓練是在真實的代理執行框架中以強化學習完成。Nemotron 3.5 Lightning 30B-A3B由 NVIDIA 於 2026 年 8 月 11 日發布，是總參數 30B、啟用 3B 的混合架構，將 Mamba-2 狀態空間層與混合專家和注意力機制加以蒸餾，並隨附推測解碼頭，讓小型草擬模型能提出權杖，再由主模型平行驗證。NVIDIA 自家的指引是把它當作執行者而非規劃者來運行。Liquid 對自家模型的指引則是把它指向檢索與工具，而非知識性問題。兩家公司、兩個稀疏的約 30B 檢查點、兩種版本的「讓更大的東西去思考」。

區分它們的不是設計目標，而是你能檢視多少證據。

出現在你的延遲預算中的架構差異

LFM2.5-24B-A2B 維持了 LFM2 的形態：40 層，其中 30 層是雙重閘控短卷積區塊，10 層是分組查詢注意力，每個區塊有 64 個專家並採用 top-4 路由，131,072 個詞元的上下文，以及 128,000 個詞元的詞彙表。Liquid 的發布文章把預訓練規模寫成 33 兆個詞元，而同一次發布的 Hugging Face 模型卡則寫成 36 兆個詞元，這項落差兩份文件都未說明。上下文來自兩階段的中期訓練流程，最後以完整的 131K 完成 3,000 億個詞元，而後訓練則以在 OpenClaw、Hermes Agent、Pi 和 OpenCode 內進行的代理式強化學習作結。

Nemotron 3.5 Lightning 是截然不同的機器系列。混合式 Mamba-2 與注意力堆疊的存在，是為了防止鍵值快取像傳統 transformer 那樣不斷增長；這正是讓 NVIDIA 能宣稱在單張 H100 上達到 256K 上下文、原則上最高可達 1M 的原因。它隨附多詞元預測頭，以及獨立的 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 48.09 對 2.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 自身的揭露也指向與損失欄位相同的方向。該公司發布了一項評估，顯示當 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 公布了一張表，四個欄位，而表中任何地方都沒有第三方那一行。那道缺口，是要靠發布基準測試、而不是靠部落格文章，才能填補的。

在我們的事件檔案中追蹤即時模型中斷與降級情況，並查看哪些路由已順利完成容錯移轉。