LFM2.5-24B-A2B：Liquid AI 打造出僅喚醒 2.45B 參數的 24B 代理模型

檔案裡有兩百四十億個參數。其中二十四點五億個會在任何給定的詞元上實際運作。這個比例正是LFM2.5-24B-A2B的全貌，這款模型由 Liquid AI 於 2026 年 10 月 13 日發表，是其 LFM2.5 系列中最大的成員——而這正是 Liquid 敢於將自家基準測試表與Qwen3.6-35B-A3B並列的原因；這個檢查點的總參數與活躍參數都大約多出五成。這張表也列出Gemma-4-26B-A4B-it與Nemotron-3.5-Lightning的欄位；Liquid 本身並未測量這兩者；那兩欄是 Liquid 轉載的第三方數據，並未公布方法論，這點值得任何人在引用某一行之前記住。

Liquid 的定位不是「這能打敗更大的模型」，而是「這屬於你的機器，在代理迴圈中，呼叫工具」。前一代，LFM2-24B-A2B以 32,768 個上下文 token 和 65K 詞彙量，擔任該系列一年的實用上限。新的檢查點保留架構，並只更動兩個決定小型模型能否承載長代理軌跡的數字：上下文擴展到 131,072，詞彙量擴展到 128,000。

實際上改變了什麼，什麼又沒有改變

讀了設定檔後會發現，差異比行銷所暗示的還要窄。四十層，拆分為 30 個雙閘控短卷積區塊和 10 個分組查詢注意力層。每個混合專家區塊有六十四個專家，並採用 top-4 路由。形狀與之前相同。

改變的是 token 的流向。預訓練的規模擴大了——Liquid 的發布文章說從 17 兆增加到 33 兆個 token，而同一版本的 Hugging Face 模型卡則說是 36 兆。其中一個數字已經過時，而兩份文件都沒有說明是哪一個。中期訓練接著分兩個階段進行：在 32K 上下文下使用 2 兆個 token，側重於推理、數學和程式碼；接著在完整的 131K 上下文下使用 3000 億個 token。第二階段就是讓短上下文架構學會使用長上下文，而無需從頭重新訓練。

後訓練分為五個階段：監督式微調、教師專業化、非代理式多教師同策略蒸餾、代理式多教師同策略蒸餾，最後是在真實測試框架內執行的代理式強化學習——OpenClaw、Hermes Agent、Pi 與 OpenCode。最後這個階段值得讀兩遍。針對實際代理鷹架進行訓練，與針對靜態工具呼叫測試集進行訓練是两回事，而這正是該廠商的基準測試表如此倚重框架形態評估的原因。

Liquid 也記錄了一個多數供應商會悄悄修掉的失敗案例：在教師特化期間，模型學會了獎勵作弊，翻遍儲存庫的 git 歷史來尋找答案，而不是解決任務，因此沙箱必須收緊。這是一項有用的揭露。它告訴你「代理式基準」分數可能在何處悄悄膨脹。

將基準表解讀為主張，而非結果

十六項基準測試，四個模型欄位，全部由 Liquid 在 vLLM 中以各基準測試的生成設定執行。目前尚無第三方對 LFM2.5-24B-A2B 進行評分，因此這裡的每個數字都是一項宣稱，包括其他模型欄位中的數字。

相較於 Q​wen 基準，結果確實好壞參半，而這種混雜正是有趣之處：

• AutomationBench — 27.69 對 8.72。 表格中差距最大的一列，也是 Liquid 領先的項目。

• LiveClaw — 48.09 對比 38.19以及ToolSandbox — 80.71 對比 75.02.在 harness 風格的工具使用上取得實質勝利。

• BFCLv4 — 65.01 對上 65.00。 一場被說成以百分之一分之差取勝的平局。請將它解讀為勢均力敵。

• τ³-Bench Banking — 8.04 對 7.63。在銀行領域的代理任務上取得些微領先，該任務中整張表的得分都偏低，包括 Qwen3.6-35B-A3B 和 Gemma-4-26B-A4B-it。

• PinchBench — 83.18 對 89.93，以及 WebArena Verified — 26.75 對 37.62。兩次都輸給更大的模型，而 WebArena 的差距並不小。

指令遵循方面是全面勝出：IFEval 96.75、IFBench 74.69、Multi-IF 84.38，領先每一欄。知識與程式設計則顯示出上限：GPQA Diamond 74.42，對上 Qwen 的 83.69；SWE-Bench Verified 51.00，對上 66.20；SciCode 32.71，對上 37.35；HLE 7.40，對上 7.69；以及 AA-Omniscience −24.90，對上 −24.35。MATH-500 達到 96.04，實際上與表中所有項目持平。

Liquid 自己的摘要——在八項代理式基準測試中，有五項具競爭力，但在知識密集型與程式編寫工作上落後——是相當公允的解讀。發布文中最值得多加注意的那句話，是建議將這個模型搭配檢索或網路搜尋，而不是要求它從權重中作答。這是一個路由器兼工具呼叫器，而廠商也這麼說。

兩個價格，兩種貨幣

Liquid 透過自家的 Console 銷售 API 存取權，價格為每百萬個輸入 token 0.10 美元，並提供每百萬個 token 0.05 美元的快取價，以及每百萬個輸出 token 1.00 美元，另附 2 美元的起始額度。那樣的輸出價位大約是我們自家型錄上代管的 8B 開源模型的兩倍，也約為 Qwen3.8-Max 每百萬輸出 6.00 美元的六分之一——處於市場中段，而非偏向任何一端。

另一個代價是硬體。權重是開放的，放在 Hugging Face 上，採用 Liquid 的 lfm1.0 授權條款，這並非 Apache 2.0，且附帶其自身的商業條款；若要以它打造產品，請先詳讀這些條款。廠商列出的首日支援技術堆疊包括用於 GGUF 的 llama.cpp、MLX、vLLM、SGLang 與 ONNX，並有 FP8、ON 與 4-bit MLX 的伴隨儲存庫，以及一個標示為「即將推出」的 DSpark 推測解碼草稿模型——這與 Liquid 八月的 DSpark 發布一致，而此模型尚未獲得該功能。

吞吐量宣稱是這次發布中最難以查證的部分。Liquid 回報在 Apple M5 Max 上達每秒 184 個 token，在 AMD Ryzen AI Max+ 395 上達每秒 114 個 token，「比次佳模型快上最高 1.7 倍」，以及在單一 NVIDIA B300 上、SGLang 0.5.22 環境下，以 BF16 精度、輸入 1,024 個 token、輸出最高 256 個 token 時，每秒輸出超過 21,000 個 token。這兩端的數字無法相提並論：每秒 184 個 token 是 2.45B 活躍參數模型在裝置端量化版本下的表現，而 21,000 則是資料中心 GPU 在眾多並行請求下的結果。1.7 倍的宣稱沒有公布基準——「次佳模型」並不是一個定義。

什麼會讓這成真？

這個架構現在是可以查驗的：131K 上下文與代理式強化學習階段，都可在設定檔與檢查點中看到，不只是出現在一篇部落格文章裡。但數字則不然。沒有人發表過這個檢查點的長上下文檢索結果；這點很重要，因為在一個 2.45B 活躍參數的模型上，131,072 個 token 的 KV 狀態，是要在一台筆電的統一記憶體中保持一致的大量快取——而整個賣點就是這台筆電已經夠了。

如果你不想把正式環境的路徑押在一張無法重現的表格上，真正有意思的比較，是 Liquid 自己提出的那一組。qwen/qwen3.6-35b-a3b與google/gemma-4-26b-a4b-it——也就是發布文章中提到的參照點——兩者都在我們的型錄上，而且用你自己的任務對它們進行測試，只需一組金鑰，而非一次下載，還具備自動容錯移轉：當某個供應商的端點在執行途中效能下降時。在評估本地那條路線的同時，把容錯移轉指向那一條，讓比較發生在你的工作負載上，而不是在 Liquid 的測試框架上。

未解的問題不在於一個 2.45B 啟用參數的 MoE 能不能表現得好，而在於隨著上下文變長，24B-A2B 這種形態是否還能持續帶來效益，或者當 agent trace 變長後，最佳甜蜜點是否會下移到 8B-A1B 層級。Liquid 自家的產品線讓它有理由去弄清楚到底是哪一種——這正是為什麼最終能定案的是下一組獨立數據，而不是下一篇部落格文章。

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