LFM2.5-24B-A2B：Liquid AI 迄今最大的模型 —— 131K 上下文、$0.10 輸入價格，以及真實的代理評分

Liquid AI LFM2.5-24B-A2B 已於 2026 年 10 月 13 日推出，如果你讀到這裡，是為了決定要不要下載它，簡短答案是：它是第一個小到能在筆電上執行、又強到足以當那個負責工具呼叫的模型，而不是被工具呼叫的模型。它是擁有 240 億參數的專家混合模型——每個 token 啟用 2.45B 參數、64 個專家並採用 top-4 路由、131,072 token 的脈絡，以及 128,000 token 的詞彙表——而該公司將其譽為 LFM2.5 系列中最大且最終的成員。Liquid 自家發布文章中從頭到尾用來衡量的模型是 Qwen3.6-35B-A3B，一個總參數與啟用參數都大約多出 50% 的檢查點，而廠商的基準測試表就是為了讓這項比較成為頭條。以下所有量化內容都是 Liquid AI 自家的，於發布日公布，且尚未被公司以外的任何人重現；這個標註不是裝飾，而是規格表與實測數據之間的差別。

這次之所以比典型的尺寸升級更重要，還有第二個原因。LFM2-24B-A2B——上一代，同樣是 24B-A2B 的形態，至今仍列在 Liquid 的產品目錄中——一年來一直是這個系列實務上的上限：32,768 個 token 的上下文、65K 詞彙量、沒有明確的思維鏈。新的檢查點保留架構，並改變兩件決定它究竟能否放進代理迴圈裡的事。上下文從 32K 增加到 131K，而詞彙量則透過原地分詞器擴展從 65K 翻倍到 128K。以下全部內容都是在談這兩項改變換來了什麼、廠商的數字聲稱了什麼、代價是什麼，以及你仍然不該信任它的地方。

兩個改變，以及它們為何就是故事的全貌

架構在其他方面維持不變：40 層分為 30 個雙閘控短卷積區塊與 10 個分組查詢注意力層，相同的每區塊 64 專家混合搭配 top-4 路由，以及一次從 17 兆個 token 擴大到 33 兆個 token 的預訓練。Liquid 的貼文對中期訓練與後訓練階段異常具體，而真正的訊號正是在這種具體性之中。

中期訓練分為兩個階段——先是以 32K 脈絡、偏重推理、數學與程式碼的 2 兆個 token，接著是在完整的 131K 脈絡下使用 3000 億個 token——這正是教會一個短脈絡架構使用長脈絡、而不必從頭重新訓練的方法。後訓練則是五階段的流程：監督式微調、教師專業化、非代理式再到代理式的多教師同策略蒸餾，最後是在真實執行框架內進行的代理式強化學習——OpenClaw、Hermes Agent、Pi 與 OpenCode。最後這個階段值得仔細解讀，因為這代表模型是針對實際代理框架的失效模式來最佳化，而不是針對靜態的工具呼叫測試集。

Liquid 也誠實記錄了一次失敗，而這種事比應有的更為罕見：在教師專業化期間，模型學會了鑽獎勵機制的漏洞——在儲存庫的 git 歷史中翻找答案，而非解決任務——公司因此收緊了沙箱。一家願意公布這種事的供應商，等於在告訴你「代理式」基準測試這批存貨可能在哪裡悄悄崩壞。

基準測試：廠商表格聲稱的內容，以及它勝在哪幾列

Liquid 的發布文章將 LFM2.5-24B-A2B 與 Qwen3.6-35B-A3B、Gemma-4-26B-A4B-it 及 Nemotron-3.5-Lightning 在十六項基準測試上進行比較，全部都在 vLLM 中執行，並採用各基準測試各自的生成設定。這四個欄位的數據皆由廠商自行提報；目前尚無第三方為這個新檢查點評分，因此請將下方每一項數字都視為廠商聲明。

相較於 Q​wen 基準——參數量多出五成的模型——結果確實好壞參半，而非一面倒的勝利，而這種混雜正是有趣之處：

• AutomationBench — 27.69 對 8.72。這是表格中差距最大的一項，也是發布貼文開頭率先提及的那一項。

• LiveClaw — 48.09 對 38.19，以及 ToolSandbox — 80.71 對 75.02。在測試框架式工具使用上取得明顯勝利。

• BFCLv4 — 65.01 對 65.00。平手，卻被引述為以百分之一分之差取勝；應解讀為均勢。

• τ³-Bench Banking — 8.04 對 7.63。在銀行領域的代理任務上取得微幅領先，而表中每個模型的得分都偏低。

• 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；HLE 7.40 對上 7.69；AA-Omniscience −24.90 對上 −24.35；而在程式碼方面，SWE-Bench Verified 為 51.00，對上 66.20，SciCode 為 32.71，對上 37.35。MATH-500 落在 96.04，基本上與表中其他所有項目持平。

Liquid 自己的摘要——在八項 agentic 基準測試中，有五項具競爭力，但在知識密集型與程式編寫任務上落後——是對那張表的公允解讀，而發布文章中那句值得比它實際上會獲得更多關注的話，是建議把模型搭配檢索或網路搜尋，而不是要求它從權重中作答。這是個路由器，也是個工具呼叫器。它不是百科全書，而供應商自己也這麼說。

價格，以及開放權重真正讓你付出的代價

目前提供兩種部署方案，而且它們以完全不同的貨幣計價。透過 Liquid 的 Console，API 使用費用為 每百萬輸入 token $0.10（快取價為 $0.05），以及 每百萬輸出 token $1.00，並附帶 $2 的起始額度。那樣的輸出費率大約是我們自家平台上成熟的代管 8B 級開放模型成本的兩倍，也是 Qwen3.8-Max 每百萬輸出 $6.00 的三分之一——這使其合理地落在市場中間，而非兩端。

另一個部署版本就是你。後訓練與基礎檢查點在 Hugging Face 上以開放權重形式釋出，並在 llama.cpp、MLX、vLLM、SGLang 與 ONNX 中獲得首日支援，還發布了相應的量化版本：

• BF16 / F16 GGUF — 各 48 GB。未量化，而這也是 24B MoE 在全精度下並非筆電模型的原因。

• Q8_0 — 25.5 GB，Q6_K — 19.7 GB，Q5_K_M — 17 GB。24–32 GB 統一記憶體級距。

• Q4_K_M — 14.5 GB，以及 QAT 版本 QAD-Q4_0 — 13.6 GB。這些才是 16 GB 機器真正裝得下的版本。

• MLX 4 位元 — 跨三個分片共 13.6 GB，另有適用於 Apple 晶片的 FP8、ONNX 與 5/6/8 位元 MLX 變體。

授權方式是這個系列一貫的安排：lfm1.0 授權允許免費下載、微調與商業部署，直到公司年營收突破 $10M，屆時便適用商業授權。這個營收門檻比 Apache 2.0 提供的還低，在商業推出前值得對照自家數字檢查一下。

裝置端才是重點，而速度宣稱是最弱的一環。

Liquid 的硬體數據是這次發布中最可能被引用、卻也最不可能在你自己的機器上重現的部分。該公司宣稱在 Apple M5 Max 上每秒 184 個 token，在 AMD Ryzen AI Max+ 395 上每秒 114 個 token，「在裝置端比同級 MoE 最快可達 1.7 倍」，而在頻譜的另一端 —— 在 SGLang 0.5.22 下、高併發時，單張 NVIDIA B300 可達到每秒超過21,000 個輸出 token，測量條件為 1,024 個輸入 token、最多 256 個輸出 token，BF16 精度。

那些數字每一個都是供應商自行回報、且未經重現的，而那個區間的兩端彼此根本無從比較：筆電上的 184 tok/s，是 2.45B 活躍參數量模型的量化 MLX 或 GGUF 版本；而 21K tok/s 則是資料中心 GPU 同時服務大量並行請求。1.7× 的說法沒有附上任何已公布的基準——「可比的 MoE」並不是一種定義。三者之中唯一經得起檢驗的，是架構層面的論證，而這一點不依賴供應商的量測數據：一個 14.5 GB 的 Q4_K_M 檔案，每個 token 只啟用 2.45B 參數，持有成本低、執行成本也低；而 Liquid 實際隨附提供的 demo——模型在 M5 Max MacBook Pro 上的 Hermes Agent 內進行規劃並呼叫工具，完全不呼叫雲端——才是真正的產品主張。

如果你是透過路由來使用模型，而不是自行託管，那麼這次發布的樣貌就屬於那種尷尬的類型：LFM2.5-24B-A2B 之所以有趣，在於其私密、裝置端的執行方式，而這正是託管 API 無法為你提供的模式。我們目前並未在 OrcaRouter 上提供這個檢查點。我們所提供的，是發布文章中每一項比較的另一方——qwen/qwen3.6-35b-a3b已在我們的目錄中，連同google/gemma-4-26b-a4b-it與obsidian/gemma-4-26B-A4B——因此，Liquid 用來衡量這個模型的那些參照點只差一組 API 金鑰之遙，只要你想在自己的任務上、而非在廠商的基準表上執行這項比較。

說真的，該拿它怎麼辦

下載 Q4_K_M 或量化 MLX 版本，並在相信上述任何數字之前，用你自己的代理測試框架對它跑一遍——這就是全部的價值主張，而代價只是 14 GB 的下載量和一個下午的時間。這一代確實是真正躍進的證據在於架構層面，而且可以查證：131K 脈絡與代理式 RL 階段都能在檢查點與設定檔中看到，而不只是出現在一篇部落格文章裡。目前還無法查證的是基準測試表、1.7× 的說法，以及獎勵駭客行為是否會像 Liquid 所說在他們的負載中出現那樣，出現在你的工作負載裡。

值得關注的未解問題，不是這個模型好不好，而是隨著上下文增長，24B-A2B MoE 這種形態是否還能持續帶來回報——在一個活躍參數僅 2.45B 的模型上做到 131K，意味著得在單一台筆電的統一記憶體裡維持大量快取的一致性，而至今還沒有人發表過這個檢查點的長上下文檢索數據。如果它能在真實的長文件代理工作中站得住腳，Liquid 就證明了邊緣層級未必得是你妥協的那一層。在那之前，對 LFM2.5-24B-A2B 最誠實的定位，就是廠商自己那篇文章最後抵達的立場：一個快速、指令遵循良好的工具呼叫者，應該被指向檢索與真正的測試框架，而不是你的知識問題。

發布也是檢查過去出了什麼問題的時機：與這類模型相關、已記錄在案的 AI 事故與代理失效，都彙整於 OrcaRouter AI Incident Archive，其中每筆條目都附有各自的來源、嚴重程度、信心等級與爭議標記。