LFM2.5-24B-A2B 對比 Granite 4.2 30B：稀疏筆電模型還是稠密工作站模型

「開放權重」在LFM2.5-24B-A2B與Granite 4.2 30B身上扮演著兩種不同的角色。Liquid AI 的模型於 2026 年 10 月 13 日發布，是擁有 240 億參數的專家混合模型，每個 token 會喚醒 24.5 億個參數，並以廠商自家的 lfm1.0 授權條款發布。IBM 的 Granite 4.2 30B 於 2026 年 8 月 25 日在 Hugging Face 上發布，是稠密、僅解碼器的推理模型——其 BF16 safetensors 中約有 290 億個參數，每一個在每個 token 上都會啟用——並以 Apache 2.0 授權發布。其中一種授權是標準的 Apache 授權，沒有任何附帶條件。另一種則不是，而這個差異在你可能針對這兩者展開的任何基準測試爭論中都不會消失。

第二個差異是任何評測都無法掩蓋的算術問題。2.45B 活躍參數的 MoE 是為你已經擁有的機器而設計。稠密的 29B 模型需要一張記憶體足以容納它的 GPU，這讓比較與其說是「哪個更聰明」，不如說是「這兩個之中哪個能真的在你眼前的硬體上跑起來」。

參數的放置位置

LFM2.5-24B-A2B 共有 40 層，分為 30 個雙閘控短卷積區塊與 10 個分組查詢注意力層，每個區塊有 64 位專家，並採用 top-4 路由。Liquid 依發布文章的計算，以 33 兆個 token 對其進行訓練——或者依同一版本的 Hugging Face 模型卡計算，則為 36 兆個 token，這個差異兩份文件都未加以解決——接著分兩階段進行中期訓練，最後完成五階段後訓練流程，最終在真實代理框架內進行代理式強化學習。它有 131,072 個 token 的上下文與 128,000 個 token 的詞彙表。

Granite 4.2 30B 是單一稠密堆疊，無需進行路由，建構於 Granite-4.1-30B-Base 檢查點之上，並以三種可選的推理模式訓練：以 <think> 標籤包覆的完整思考、低投入思考，以及完全不思考。它具備 128K 原生上下文，並有文件記載可延伸至 512K 的長上下文，支援十二種經測試的語言，而其模型卡建議在各項任務中採用 temperature 1.0 與 top_p 0.95。

實際後果是吞吐量形態，而不僅僅是吞吐量。稀疏路由意味著 LFM2.5-24B-A2B 讀取 24B 權重檔案，以對每個 token 進行 2.45B 的算術運算——對記憶體頻寬有利，但沒有特別的壞處。密集路由則意味著 Granite 4.2 30B 對其輸出的每個 token 執行完整的 29B 工作量。如果你的工作負載是包含許多短回合的長代理迴圈，這種差異會不斷疊加。

廠商編號，並列呈現，並附上但書

沒有人把這兩者放在一起對比測試過。IBM 的數據來自 Granite 4.2 的模型卡；Liquid 的數據則來自其發表當日的 vLLM 表格，而 Granite 在該表格中並未列為一個欄位。因此，下方各列只是兩家廠商各自的說法並列呈現，而非正面對決的比較。四項基準測試中有兩項所用的測試框架雖有重疊，但並不完全相同。

• 參數 — 總計 24.0B，其中 2.45B 為啟用參數，相較之下稠密模型約 29B，且全部啟用。決定你硬體配置的唯一關鍵數字。

• 上下文 — 131,072 個詞元，對比原生 128K 與擴充 512K。 在原生視窗下大致旗鼓相當；若有需要，Granite 還能再往前推進。

• 授權條款 — lfm1.0 與 Apache 2.0 之比較。 Apache 2.0 沒有營收觸發條件，也沒有使用領域的問題。請拿 Liquid 的條款對照你自己的數字。

• 代理式工具使用 — BFCLv4 65.01 對 BFCL v4 61.39。Liquid 的數字來自其自家測試框架；IBM 的數字則來自 4.2 模型卡。兩者近到讓測試框架比差距本身更重要。

• 程式設計 — SWE-Bench Verified 51.00 對 57.00。Granite 的領先優勢，而這也符合這個模式：LFM2.5-24B-A2B 是工具呼叫模型，Granite 4.2 30B 則是也會呼叫工具的推理模型。

• 指令遵循 — IFEval 96.75 與 IFBench 74.69，對比 IFBench 77.17。兩者皆強；由於兩家廠商採用不同的列對，因此請比較共用的那一列。

在 Granite 的模型卡補充了 Liquid 未公布細節之處，就把它當作推理模型的論據：AIME 2025 為 89.17，GPQA 為 66.41，LiveCodeBench v6 為 75.77，MMLU-Pro 為 77.60，SciCode 為 38.76，而 RULER 在 64K 為 89.96、在 128K 為 81.38。最後這一對正是 LFM2.5-24B-A2B 目前根本還沒有的那種長上下文證據——Liquid 並未公布其 131K 視窗在任何上下文長度下的檢索數據。

持有每一個要讓你付出多少成本

Liquid 的 API 存取定價為每百萬輸入 token $0.10——快取 $0.05——每百萬輸出 token $1，可在自家 Console 上使用，並附贈 $2 起始額度。但託管端點其實算不上真正的產品；真正的產品是 24B-A2B 檔案本身，而廠商的輸送量宣稱全都著眼於裝置端：在 Apple M5 Max 上每秒 184 個 token，在 AMD Ryzen AI Max+ 395 上每秒 114 個 token。兩者皆為廠商自行回報且未經重現，而無論這些數字是否成立，架構上的論點都站得住腳：2.45B 作用中參數的 MoE 能以稠密 29B 模型做不到的方式在統一記憶體上運行。

IBM 並未在模型卡上公布每 token 價格——Granite 4.2 30B 的定位是自託管檢查點，以 BF16 加上 FP8、NVFP4/MXFP4 與 GGUF 量化等形式散布。總成本就是你得為了承載約 29B 稠密權重而購買或租用的 GPU，而以 FP8 運行的稠密 30B 所需記憶體，遠比量化後僅 2.45B 活躍參數的 MoE 多得多。若以每服務一個 token 計算，稀疏模型的運作成本較低；若就冷啟動與最差情況延遲而言，稠密模型則沒有需要預熱的路由。你究竟在意哪一點，完全取決於該端點是否全天候開啟。

如果你想測試其中任何一個，又不想對任何一方做出承諾，兩條路都行得通。Granite 4.2 30B 採用 Apache 2.0 授權、可自行架設，且沒有營收上限；而上述每一個數字所對應的服務端——qwen/qwen3.6-35b-a3b與google/gemma-4-26b-a4b-it等都在其中——全都收錄在我們的目錄裡，只要一組金鑰即可取用，對照各供應商自家牌價零加成，因此供應商一旦調整價格，公布當天端點就會反映，不必等到下一個帳單週期。

該選哪一個

如果機器是限制條件，而工作負載是工具呼叫，就選 LFM2.5-24B-A2B。它在以測試框架形態衡量工作的地方勝出，能在筆電可承載的佔用空間中保有 131K 上下文，而且 Liquid 是拿真實的代理 scaffold 來訓練它，而不是靜態測試集——這個細節對路由器比對推理器更重要。這麼做時要接受兩件事：lfm1.0 授權不是 Apache 2.0，而且 Liquid 之外還沒有人為這個檢查點評分過。

如果你有相應的硬體、需要一個會先推理再行動的模型，或需要授權條款是自家法務團隊已經熟悉的，就選 Granite 4.2 30B。它在編碼方面領先，是兩者之中唯一公布長上下文檢索數字的，而且它的 512K 擴充是真實的文件說明，而非行銷話術。它的代理能力數字較為單薄——在 BFCL v4 上為 61.39，對上 Liquid 的 65.01——這正好與參數量所暗示的相反，也提醒我們：密度買到的是推理能力，未必自動買到工具運用紀律。

誠實的總結是：這兩者並不是替代品。LFM2.5-24B-A2B 的定位，是在沒有雲端連線的裝置上跑完整個迴圈的模型。Granite 4.2 30B 的定位，則是深入思考問題、並被賦予證明自己能夠交付的許可的模型。如果你兩者都有，那麼路由的問題就在於該由哪一個接收請求——而這是要靠路由層來做的決定，不是基準測試表能回答的。

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