LFM2.5-24B-A2B 發表：2B 活躍參數背後，速度、容量與隱私怎麼讀？（2026）

2026 年 10 月 13 日，Liquid AI 在官方部落格發布了〈LFM2.5-24B-A2B: Built for Fast On-Device Agents〉，把這款開放權重模型定位為能在自己裝置上推理、呼叫工具的助手。LFM2.5-24B-A2B 最值得追問的，是它如何把每一步的計算量、整套權重的容量，以及完成工作的時間分開處理。

先看發布改了哪些能力，再核對速度與榜單的測量口徑，最後判斷它是否值得進入你的本機模型候選。這是一篇來源分析；以下效能成績保留測量者與條件，本文未執行這款模型的推論或重測。

LFM2.5-24B-A2B 的核心：把容量與活躍計算拆開

2B active parameters

中文：20 億活躍參數。

Liquid AI 發布文的規模描述片語

這個說法需要多看一格。官方模型卡的詳細規格列出24.0B 總參數、2.45B 活躍參數；「2B」是發布文的簡稱，不宜當成精確的 2.00B。它也不是只需保存 2B 權重的模型。

MoE（混合專家）像一間擁有多個小組的工作室，每一步選部分小組處理。這份 checkpoint 設定列出每個 MoE 區塊 64 個專家、每 token 路由至其中 4 個，以及 40 層；其中 30 層是短卷積、10 層是注意力。Transformers 的架構文件也把專家總數與每 token 路由數分成不同欄位，並說明這條架構混合卷積與 GQA。這支持稀疏計算的機制，沒有替新模型的速度榜單完成獨立認證。

容量最直接的檢查，是實際檔案。查核至 2026 年 10 月 14 日，官方 Q4_K_M GGUF為 14,526,258,464 bytes，約 14.53 GB（十進位）。這是權重檔大小，還須另外預留上下文快取、執行工作區與作業系統空間；它不能直接變成最低 RAM 或顯存建議。若你正為自己的機器選檔案，可接著讀本機 LLM 記憶體規劃。

這一代的變化：長上下文，和在工具迴圈裡訓練

官方模型卡把支援的上下文從前代 LFM2-24B-A2B 標示的 32,768 tokens 提升至 131,072 tokens，詞彙表增為 128,000；模型採推理模式，聊天模板在回答起點加入 <think>。新 checkpoint 設定檔可交叉核對其上下文與詞彙表數字，但容納更多文字，和在長任務中持續用對文字，是不同的驗收。工具歷史變長後，仍要測它是否保留約束、找到錯誤與知道何時停止。

訓練方向也更貼近工作迴圈。模型卡描述擴大的預訓練、長上下文中期訓練，以及下圖的後訓練流程；最後一段把模型放入 OpenClaw、Hermes Agent、Pi、OpenCode 等 Harness 的工具與互動環境。這是發布方對訓練的說明，表示它刻意學習這些工作模式，不能推成任何工具組合都能可靠完成。

原文還揭露，教師專門化期間曾出現從 Git 歷史與外部平台找答案的 reward hacking，並稱收緊沙箱後，在封閉評估環境取得文中成績。這是一項發布方自述，值得追問的是：評分獎勵的行為，是否就是使用者想要的解題？封住某條取巧路徑，是測量設計的改進；新任務遇到另一條路徑時，仍需有可查的行為紀錄。

LFM2.5-24B-A2B 的速度：184 tok/s 測的是哪一段？

模型卡的 Edge Inference 註腳給出條件：Liquid AI 在自家 Pipette 基礎設施，以 llama.cpp、Q4_K_M 量化、4K-token 輸入測量；Apple M5 Max 的 decode 為 184 tokens／秒，AMD Ryzen AI Max+ 395 為 114。這是廠商在指定配置下的生成吞吐，不是所有筆電的承諾，也不是 131K 上下文滿載的成績。

推理模型會先產生思考內容，再給最後答案。假設某次請求需要生成 1,840 個 tokens，即使整段都能維持 184 tok/s，單看生成也約需 10 秒；這只是算式例子，尚未加入讀提示、工具等待或重試。模型思考得更長，可能提高答案品質，也可能把每 token 的速度收益用掉。要判斷互動感，應同時量第一個回應、第一次工具動作與最終驗收完成。

原文另展示 M5 Max MacBook Pro 上的 Hermes Agent 晨間摘要任務，並聲稱每次工具 dispatch 可在遠低於一秒的時間內完成。這是該示範的互動主張，值得另列一欄驗；派出一個工具動作、工具執行結束、整份摘要驗收完成，仍是三個不同時間點，不能用其中一個代替另外兩個。

資料中心數字又是另一張帳。模型卡報告單張 NVIDIA B300 在 SGLang 0.5.22、BF16、1,024 輸入 tokens、最多 256 輸出 tokens 的持續負載下，高並發總輸出吞吐超過 21K tokens／秒。多個請求的總吞吐不能讀成一個人在聊天時每秒得到 21,000 tokens；也不能拿它和筆電單流生成直接算倍率。

榜單有亮點，能力輪廓仍是混合的

下面摘錄的是 Liquid AI 在發布文與模型卡中的同一組比較，並非 AlphaLab 或外部機構重跑的成績。選擇同表中的亮點與落後項目，才能看見它的取捨。

測項	LFM2.5-24B-A2B	Qwen3.6-35B-A3B	這一列提醒什麼
AutomationBench	27.69	8.72	廠商表中的明顯領先項
LiveClaw	48.09	38.19	代理任務值得進一步評估
BFCLv4	65.01	65.00	0.01 分差距，先視為相近
PinchBench	83.18	89.93	代理測項也有落後
WebArena Verified	26.75	37.62	不能由工具榜單推成所有瀏覽工作領先
SWE-Bench Verified（OpenCode）	51.00	66.20	程式修補仍有明顯差距

同表的另一組亮點是指令遵循：IFEval 96.75、IFBench 74.69、Multi-IF 84.38，均高於表內其他三款模型。這補足了工具列之外的能力輪廓，仍屬 Liquid AI 報告的比較。

這些分數使用不同測項的尺度，不能跨列平均成「整體成功率」。模型卡列出逐項採樣與輸出限制，例如 BFCLv4 最多 4,096 輸出 tokens，LiveClaw 最多 8,192；AutomationBench 最多 50 輪。比較新模型時，應連同 Harness、工具菜單與預算保存，而不是只抄得分。原文對知識密集工作建議加入檢索或網頁搜尋；這也把採用問題從「模型背了多少」移向「它能否取得並正確使用材料」。

AlphaLab 的判讀：本機價值，應落在三張收據上

一、我同意稀疏計算的方向，容量仍要實算

把較大的表示容量放進較短的活躍計算路徑，是值得評估的設計。你可能在每一步少做一些工作，同時保有更多專家可選；代價是那些專家仍要有保存與取得的位置。實際部署要分別看權重檔、常駐記憶體、快取與搬運，不能讓一個 A2B 名字替機器做容量決定。長上下文尤其應循序增加，確認完整工作可接受之後，再決定多留多少歷史。

二、我存疑的是把生成速度當成交付速度

如果工作大多卡在模型生成，較快 decode 有實際價值；若時間花在讀長文件、等網站或修正錯誤，它就只改善其中一段。更有用的單位是完成一件通過驗收的工作，總共等了多久。失敗輪、思考長度、工具時間與人工修正都留在帳裡。可用AI Evals 的固定驗收方法先定答案，再讓自己的任務決定哪種速度值得保留。

三、本機推理與資料流向，要分開畫

your data never leaving the device

中文：你的資料始終留在裝置上。

Liquid AI 原文對本機代理示範的描述片語

我肯定把模型推論留在自己裝置上的選項；要把上面這句延伸到完整 Agent，還得看工具送出了什麼。Hermes 的官方搜尋文件列出不同搜尋與擷取供應者；工具程式也把 query 交給選定的 backend。查詢若含私人文字，那份文字便進入該搜尋路徑。這不是對原文示範流量的抓包結論，而是部署者應另外檢查的資料通道。

「推論用本機模型」「搜尋會對外發出請求」「私人文件是否被加入請求」可以同時成立，也可以藉配置改變。先畫出模型端點、工具目的地、查詢內容與日誌位置；私人資料的路線先限於本機工具，公開網頁研究另用公開材料驗收。Agent Harness 的分工解釋的是誰真正控制這些動作，模型的工具能力分數則回答它多會提出動作。

四、開放權重，還有具體的使用條件

這款 checkpoint 採 LFM Open License v1.0。第 5 節把商業使用權與年營收門檻連在一起：超過門檻的法律實體，其商業使用未由這份協議授權；定義段把 Threshold 寫為年營收 1,000 萬美元或以上。條文在「達門檻」與「超過門檻」的措辭並不完全一致，因此接近門檻的組織應取得授權範圍的明確確認。再散布也有附授權與保留聲明等條件，不能把可下載寫成無限制商用。

下一步：讓一個小任務替採用決策作答

原文最值得對帳的主張，是較少活躍計算能讓本機代理更有互動感。已有可承載的機器與相容環境的人，可以先選一個可回復任務，例如讀自己的三份假文件，輸出有來源位置的摘要；同時保留目前模型作對照。先讓工具只能讀這個測試資料夾，別在首次比較就加入寄信、刪檔或正式資料。

固定 checkpoint、量化、runtime、模板、工具與停止預算；把上下文長度選成任務真的需要的值。每次留下三張收據：容量記檔案與程序峰值；交付記完整耗時、重試與驗收；資料流記實際目的地與送出內容。再安排一次缺檔情境，看它是否如實停止，而不是把猜測當讀取結果。這是一份建議測試設計，不是本篇已跑出的模型成績。

較短等待如果伴隨正確交付、合理容量與可控資料流，就先把那一類工作交給它；如果只看到 tok/s 漂亮，卻增加修正或對外傳輸，繼續保留原路線。LFM2.5-24B-A2B 值得成為候選，採用的理由應能寫在自己的任務紀錄上。