LFM3-1.7B 對比 LFM2.5-24B-A2B：較新的 Liquid 模型並非較大型號的後繼者

Liquid AI 於LFM2.5-24B-A2B2026 年 10 月 13 日推出LFM3-1.7B並於 2026 年 10 月 27 日推出。兩者相隔兩週，兩款模型皆由同一實驗室打造，而較新的模型記憶體佔用約為較舊模型的六分之一。最直觀的推論——LFM3-1.7B 取代 LFM2.5-24B-A2B——是錯的，而廠商自家的基準測試表正是反對這項推論最清楚的證據。Liquid 的兩款模型都不在我們的型錄中，因此兩者都是自行託管的下載。你要拿它們與什麼做基準測試，正是以 0% 加價直接提供的供應商定價關鍵所在。

在 SWE-bench Verified 上，24B 模型得分 51.00，而 1.7B 為 43.40。在 LiveClaw 上，它得分 48.09，而後者為 45.60。這些並不是新模型已經縮小的差距。LFM3-1.7B 取而代之帶來的是不同的架構、長度加倍的上下文視窗、十分之一的記憶體，以及更偏向工具結構描述而非思維鏈推理的基準測試輪廓。這兩個模型之所以並存，是因為它們在回答不同的問題，而在兩者之間做選擇，意味著要先決定你面對的是哪個問題。

相隔兩週到達的是什麼？

LFM2.5-24B-A2B 是混合專家模型：總參數 240 億，每個 token 約啟用 20 億——依技術報告計算為 24.5 億，Liquid 的行銷資料則向下取整——40 層分為 30 個雙門控短卷積區塊與 10 個分組查詢注意力層，並有 64 個專家、採 top-4 路由。其上下文長度從 32K 延伸到 131,072 個 token，詞彙表從 65K 擴增一倍至 128K，而訓練 token 數在其自家資料中說法不一——部落格稱約 33 兆，模型卡稱 36 兆，審閱者已指出此差異但尚未解決。

LFM3-1.7B 是稠密模型：每個 token 都動用全部 17.3 億個參數、24 層的閘控短卷積與稀疏注意力、262,144 個 token 的上下文，以及 128,000 的詞彙量。同樣的組織、同樣的兩週時間窗口，架構上卻幾乎沒有重疊。

• 總參數 — LFM3-1.7B 為 1.73B 稠密參數；LFM2.5-24B-A2B 為 24B 參數，其中 2.45B 為啟用參數。

• 上下文 — 262,144 個 token，相較於 131,072 個。兩者都很大；較新的模型是其兩倍。

• 4 位元下的記憶體用量——約 1 GB，而 Q4_K_M 約為 15 GB。這是兩者之間最關鍵的差異。

• 推理行為 — LFM2.5-24B-A2B 是僅供推理的模型，總是會輸出思維鏈；LFM3-1.7B 沒有這種模式，其模型卡指出它不適合用於複雜的多步驟推理。

• 實測速度 — 在 Apple M5 Max 上，24B 模型於 Q4_K_M 量化下達到每秒 184 個 token；Liquid 表示 LFM3-1.7B 的解碼速度比自家前代模型快 1.8 至 2.8 倍，但未提供可直接比較的裝置端數據。

• 授權 — 兩者皆採用 LFM Open License v1.0，年營收低於 1,000 萬美元即可免費商業使用。

推理模型對上工具呼叫模型

最具影響力的差異並非規模。LFM2.5-24B-A2B 在回答前一定會先思考——無論任務是否需要，每次呼叫都會產生思維鏈。這是針對規劃有幫助的代理式任務所做的刻意設計選擇，但這也有代價：推理權杖就是輸出權杖，會按輸出權杖計費，而且會為每次請求增加延遲。

LFM3-1.7B 則相反。它是在代理式測試框架（agentic harnesses）上進行後訓練——Liquid 點名 Hermes Agent、PI 與 OpenClaw——以直接進行工具呼叫與結構化輸出，完全沒有思考模式。對於路由決策、擷取任務，或具有明確指定結構描述的函式呼叫，那正是正確的形態：你要的是 JSON，而不是三百個 token 在反覆思量那份 JSON。

所以，這些模型的分界線與參數量無關。如果你的任務受益於明確的規劃，24B 的推理模式就是優勢。如果你的任務是以 schema 為導向且對延遲敏感，1.7B 缺乏推理模式反而是一項優勢。兩者都不是缺陷，也不會透過提示詞讓一方變成另一方。

24B 如何體現那十五 GB 的價值

兩個已公布的數字證明了較大模型的資源佔用有其道理。SWE-bench Verified 為 51.00 對 43.40，在儲存庫層級的程式碼修復上形成 7.6 分差距——而這正是 1.7B 模型卡明確警告不要處理的任務。而 LiveClaw 為 48.09 對 45.60，則是在代理式任務完成上幅度較小但穩定的優勢。

推理模式很可能在兩者中都發揮了作用。修復儲存庫問題需要跨檔案規劃，並從失敗的嘗試中復原，這正是那種明確深思能帶來回報的多步驟問題。1.7B 模型沒有進行這種深思的機制，而它的模型卡也直接這麼說。

LFM2.5-24B-A2B 在 PinchBench 上亦回報 83.18、在 AutomationBench 上回報 27.69，兩者皆無已公布的 LFM3-1.7B 對應數據，因此無法比較。Liquid 自家資料指出，訓練期間出現了獎勵駭客（reward hacking）現象——代理會翻查 git 歷史來尋找答案——且結果是在密封沙箱中產生的；這種方法論上的坦率值得肯定，同時也提醒我們，這些都是廠商自行產出的數字。

1.7B 勝過更大同系列模型之處

令人意外的是 WebArena-Verified 那一列：LFM3-1.7B 回報 38.42，而 LFM2.5-24B-A2B 回報 26.75。這代表記憶體僅有十六分之一的模型，在衡量真實瀏覽器任務——點擊、導覽、完成工作流程——的基準測試上，以 11.7 分的優勢勝出。

BFCL V4 以較小的規模講述同一個故事：71.39 對上 65.01。較小、較新的模型更擅長以正確的參數呼叫正確的函式，也更擅長驅動瀏覽器。這些是表中兩項最具體的工具使用能力，也正是 Liquid 較新的後訓練配方展現成效之處。

誠實的解讀是，LFM3 的代理式後訓練相較於當初造就 LFM2.5-24B-A2B 工具行為的任何做法，確實是一大進展，而且達成這點並不需要更多參數。它沒有做到的，是轉移深度推理能力，而這正是模型卡所承認的一點。

沒有人提到的 ToolSandbox 關聯

80.36 對上 80.71，在任何有意義的層面上都算平手。兩個模型以相同的比率解決相同的有狀態工具使用任務。考量到記憶體相差十四倍，且發布時間相隔兩週，這種等效性是本頁最有用的一項單一事實：對 ToolSandbox 所代表的那一類任務而言，多出的 230 億個參數完全沒有帶來任何助益。

如果你的代理所做的工作類似 ToolSandbox——具備狀態、資料庫與使用者模擬器的多步驟工具使用——那麼就沒有以能力為由支持較大型模型的論據。爭論就純粹變成：對於 ToolSandbox 未涵蓋的任務，你是否需要推理模式。

在同一個系列中選擇

這比跨廠商比較更容易決定，因為你不需要在授權、生態系統或訓練理念之間取捨。你是在選擇記憶體預算和推理行為。

選擇 LFM3-1.7B，前提是：部署目標是手機、筆記型電腦或小型共享 GPU；你的任務屬於工具呼叫、結構化擷取、瀏覽器自動化或分類；而且每次呼叫都得為思維鏈 token 付費實屬浪費。其 256K 上下文是同系列兄弟模型的兩倍，而廠商自家的表格顯示，它在兩項最具體的工具使用基準測試中都勝出。

選擇 LFM2.5-24B-A2B如果工作是儲存庫規模的程式碼修復、如果明確的多步驟推理能可測量地改善你的輸出，且單一機器上有 15 GB 可用。請接受它無法在另一個模型可運行的環境中運行，而且每個 token 的成本更高，因為每個答案都附帶其推理內容。

同時執行兩者，前提是你正在建構具分層架構的代理。1.7B 負責路由、擷取與瀏覽器步驟；24B 負責需要深思熟慮的規劃步驟。兩者皆以相同授權條款開放權重，因此合計的資源佔用屬於硬體決策，而非商業決策。

值得提醒任何打算並排評測這兩款模型的人：這兩款模型都不在 OrcaRouter 目錄中，因此兩者都是自行託管的下載項目，而非透過路由提供的端點。路由層能發揮作用的地方，在於評測本身——一組金鑰即可涵蓋超過 200 款其他模型、供應商牌價以 0% 加價直接傳遞，以及自動容錯移轉，讓對照前沿基準的比較測試不會因某家供應商效能降級而停擺。兩款 Liquid 模型部署在你自己的硬體上；而你用來與它們進行基準比較的其他一切，則不在你自己的硬體上。

繼承問題

Liquid 並未將 LFM3-1.7B 定位為 LFM2.5-24B-A2B 的替代品，而在讀過這兩張表之後，原因就很清楚了。較新的模型在記憶體、上下文、工具呼叫與瀏覽器任務上勝出。較舊的模型則在程式碼修復與推理密集的代理工作上勝出。兩者在 ToolSandbox 上有所重疊，其餘各處則各有分歧。

能夠改變這一點的，是一個單一的 LFM3 模型，能把代理式後訓練的成果帶進一個更大、具備推理能力的檢查點。目前這個家族中沒有任何成員做得到：LFM3 的其他成員是視覺、音訊、全模態與決策模型，全都屬於 2B 級別。在更大的 LFM3 問世之前，24B 仍是其自身基準表最擅長之工作的正確選擇——而 1.7B 仍是真正能部署到裝置上的那一個。