2.6GB。不到一部高畫質電影的大小。裝進手機，它會自己規劃步驟、呼叫工具、把一件多步驟的事做完——而且跑一次、跑一萬次，成本都是零。
一句話結論：LFM2.5-2.6B 是 Liquid AI 在 2026 年 8 月 4 日開放權重的端側 agent 模型，2.6B 參數、記憶體佔用低於 2.5GB，手機上約每秒 30 字，12 項官方 benchmark 贏 8 項——但寫程式和最貼近真實工作的那一項，它都不是最好的選擇。
本文數據截至 2026 年 8 月 9 日，全部取自 Liquid AI 官方部落格與模型頁；benchmark 為廠商自報，第三方獨立複測目前仍有限。
LFM2.5-2.6B 到底是什麼？
是一個 26 億參數的「agent 模型」——重點在 agent 這個字。它不是拿來聊天的，是拿來派工作的：給它一個目標，它自己拆步驟、決定要用哪個工具、呼叫、看結果、再決定下一步。
過去這種事只有雲端大模型做得動。LFM2.5-2.6B 的賣點是把它壓到能在手機、筆電、甚至樹莓派上跑完，資料一步都不離開你的裝置。
| 項目 | 內容 |
|---|---|
| 發布日 | 2026 年 8 月 4 日（官方部落格標示；8 月 7 日有修訂） |
| 參數量 | 2.6B（另有 LFM2.5-2.6B-Base 未微調版） |
| 權重 | Open weights，Hugging Face LiquidAI/LFM2.5-2.6B |
| 上下文 | 128K tokens |
| 預訓練量 | 約 34T tokens |
| 詞表 | 擴到 128K（原地擴充，沒有重頭訓練） |
| 記憶體 | 低於 2.5 GB |
| Day-one 支援 | llama.cpp、MLX、vLLM、SGLang、ONNX |
詞表這件事值得多講一句：他們把詞表從 64K 擴到 128K，用的是「在原有 tokenizer 上原地擴充」的做法，而不是重新訓練一個模型。這對中文、日文、韓文這類非拉丁文字的使用者是實質差別——同一句中文，切出來的 token 數會少，等於同樣的 128K 上下文能塞進更多實際內容。
「跑在自己機器上」跟「省錢」，其實不是同一件事
大多數人看到本機模型，第一反應是「省 API 費」。官方部落格講的是另一件事，而且我認為那件事更重要。
把每個 token 的成本拿掉之後，開發者的建構方式會改變：agent 可以在本地硬體上大規模平行化，跑那些會燒掉數百萬 token 的背景任務，而邊際成本是零。當 token 花費不再是限制，agent 就能全天候到處跑。
Liquid AI 官方部落格，2026 年 8 月 4 日
差別在這裡。用雲端 API 的時候，你會下意識地精簡 prompt、減少重試、不敢讓 agent 反覆試錯——因為每一次都在扣錢。這種節制會直接壓低 agent 的能力上限，因為 agent 最有效的用法本來就是「多試幾次、自己驗證、錯了重來」。
成本歸零之後，你才會開始做那些以前捨不得做的事：讓它在背景整晚整理你的檔案、每封新郵件都跑一次分類、每次存檔都跑一遍檢查。不是省了幾百塊，是解鎖了一整類原本不成立的用法。
它真的贏過大它 4 倍的模型嗎？
部分是真的。官方拿它跟四個更大的模型比，12 項裡面它拿下 8 項第一。以下是完整表格，粗體是該項最高分：
| Benchmark | LFM2.5-2.6B (2.6B) | gemma-4-E2B-it (5.1B) | gemma-4-E4B-it (8B) | Qwen3.5-4B (4.7B) | Qwen3.5-9B (9.7B) |
|---|---|---|---|---|---|
| AA-Omniscience-Public | -29.50 | -74.47 | -49.03 | -54.30 | -50.43 |
| AIME25（數學） | 51.87 | 26.33 | 34.27 | 49.33 | 56.07 |
| LiveCodeBenchv6（寫程式） | 59.41 | 54.92 | 63.77 | 60.85 | 69.86 |
| IFBench（指令遵循） | 59.17 | 34.08 | 39.24 | 48.40 | 56.47 |
| Multi-IF（多輪指令） | 80.07 | 69.44 | 77.35 | 55.67 | 62.55 |
| IFStruct（結構化輸出） | 85.49 | 64.85 | 76.65 | 36.25 | 78.50 |
| BFCLv4（函式呼叫） | 56.88 | 36.98 | 46.39 | 50.56 | 60.13 |
| ToolSandbox（工具使用） | 77.83 | 52.40 | 65.00 | 75.55 | 76.44 |
| τ³-Bench Banking | 5.67 | 3.35 | 4.12 | 5.45 | 5.15 |
| Claw-Eval average (EN) | 62.85 | 53.14 | 58.02 | 62.28 | 66.53 |
| PinchBench | 68.22 | 44.24 | 55.09 | 71.26 | 71.45 |
| BrowseComp+（OpenClaw） | 26.89 | 8.31 | 15.90 | 24.46 | 27.23 |
看 ToolSandbox 這一行：LFM2.5-2.6B 拿 77.83，Qwen3.5-9B 拿 76.44。一個 2.6B 的模型，在最核心的工具使用測驗上，贏了一個大它將近 4 倍的模型。指令遵循那三項（IFBench、Multi-IF、IFStruct）它更是全部第一，IFStruct 85.49 對 gemma-4-E4B 的 76.65，差距接近 9 分。
指令遵循聽起來很抽象，實際上是 agent 能不能用的分水嶺。你叫它「只回傳 JSON，不要加任何解釋」，它加了一句「好的，以下是結果：」，你整條流程就掛掉。85.49 跟 76.65 的差別，就是每 10 次少炸一次。
那它輸在哪？
輸在四個地方，而且官方自己寫了出來：
- 寫程式（LiveCodeBenchv6 59.41）：不只輸 Qwen3.5-9B 的 69.86，連 8B 的 gemma-4-E4B（63.77）和 4.7B 的 Qwen3.5-4B（60.85）都贏它。這是它唯一連小一號的對手都輸的項目。
- 函式呼叫 BFCLv4（56.88）：輸 Qwen3.5-9B 的 60.13。跟 ToolSandbox 的結果相反，代表「工具用得好」在不同測法下不是一致的結論。
- PinchBench（68.22）：輸 Qwen3.5-4B（71.26）和 Qwen3.5-9B（71.45）。
- BrowseComp+ 網頁瀏覽（26.89）：輸 Qwen3.5-9B 的 27.23，差距很小，但沒贏。
官方原文的講法是：對更複雜的 agentic 任務或偏重寫程式的工作，大模型可能仍然是比較好的選擇。這句話請照字面理解，不要當客套話。
為什麼有一項，五個模型全部不到 6 分？
這是整張表最該被討論、卻最少人講的一行。
τ³-Bench Banking 這一項，最高分是 LFM2.5-2.6B 的 5.67。第二名 Qwen3.5-4B 是 5.45，Qwen3.5-9B 是 5.15，兩個 gemma 分別是 4.12 和 3.35。五個模型，全部在個位數。
τ³-Bench 測的是什麼？模擬真實客服／銀行情境的多輪對話任務——使用者講話含糊、中途改主意、要求你查資料再回頭處理、還要遵守一堆業務規則。也就是說：越接近真人交辦工作的樣子，分數掉得越誇張。
ToolSandbox 拿 77 分，是「照著劇本呼叫工具」的能力。τ³-Bench 拿 5 分，是「聽懂人到底要什麼」的能力。這兩件事之間的落差，就是目前所有小模型 agent 的真實距離。
所以請不要因為看到「贏過大它 4 倍的模型」就以為端側 agent 已經成熟。它成熟的部分是：你把任務拆得夠清楚、工具介面定義得夠明確、輸出格式規定得夠死，它做得又快又便宜又不外洩。它還不成熟的部分是：你像對真人一樣含糊地交代一件事，它會塌。
順帶解釋另一個容易誤讀的數字：AA-Omniscience-Public 是 -29.50，負的。這不是 bug。這項測驗會對答錯扣分、對「我不知道」給零分，所以負數代表模型答錯的次數多過答對。LFM2.5-2.6B 的 -29.50 是五個模型裡最好的（gemma-4-E2B 是 -74.47），但最好也還是負的——五個模型全部處於「亂答比不答多」的狀態。這是一個 2.6B 模型該有的知識量，不是缺陷，但你要知道：別拿它當百科全書用。
在你的裝置上，實際會有多快？省多少？
官方公布的三個實測數字：Apple M5 Max 220 tokens/s、AMD Ryzen AI Max+ 395 113 tokens/s、手機約 30 tokens/s，全部維持在 2.5 GB 記憶體以下。GPU 端在單張 H100 SXM5 上，高併發可以到接近每秒 15,000 output tokens，官方換算約等於單卡一天 13 億 tokens。
下面這個試算機把兩件事一起算給你看：你的裝置大概多快，以及同樣的用量走雲端 API 一年要付多少。
把用量拉到「重度」以上再看那個雲端數字，你會比較懂官方為什麼強調「邊際成本歸零」——那不是省錢，那是把一整類用法從不可能變成可能。
怎麼在自己電腦上跑起來？
官方講法是兩步。實際操作大概是這樣：
- 選一個推論引擎。Mac 用 MLX 或 llama.cpp；Windows／Linux 一般用 llama.cpp 的 GGUF 版；有 GPU 想跑高併發服務就用 vLLM 或 SGLang；要跨平台部署到各種加速器則有 ONNX。這幾個都是 day-one 支援，不用等社群移植。
- 把模型架成一個 OpenAI 相容的端點。這是關鍵一步——大部分 agent 工具都認 OpenAI 的 API 格式，只要你的本機服務長得像它，接什麼都通。
- 把 agent harness 指向那個端點。官方明講開箱即用支援 Hermes Agent、OpenClaw 和 Pi。改一行 base URL 就完成。
- 先用小任務驗證。建議第一個測試選「結構化輸出」類的任務（例如把一段文字整理成固定欄位的 JSON），因為那正是它最強的一項，可以確認整條路是通的。
如果你完全沒跑過本機模型，先從圖形介面工具入門會輕鬆很多，我之前寫過一篇 LM Studio 本機跑大模型的完整教學，那條路不用碰指令列。想理解「小硬體跑大模型」這件事到底能推到多極端，也可以看看 把 744B 模型塞進 25GB 舊電腦的 colibrì——兩篇的思路正好相反：一個是把模型做小，一個是把大模型硬塞進小機器。
一個很少人提的細節：它是在那些 harness 裡面「長大」的
官方揭露的訓練流程分四階段：監督式微調、教師專家特化、多領域 on-policy 蒸餾，最後是 agentic 強化學習。前三段是常規操作，最後一段值得留意。
他們在最後階段，是把模型直接放進 Hermes Agent、OpenClaw 等真實 harness 裡面做多輪強化學習——每次抽一個任務、隨機配一個 harness，在獨立沙箱裡實際跑，用「LLM 當評審 + 程式化檢查 + 安全硬閘」組成的獎勵去優化。
所以「開箱即用支援 Hermes Agent、OpenClaw」這句話要這樣讀：它在那些環境裡表現好，有一部分原因是它就在那些環境裡訓練出來的。它見過那些工具、那些 system prompt、那些互動模式。
這不是黑它——這是很聰明的做法，也是它 agent 能力強的直接原因。但推論是：如果你把它接到一個完全不同的自製 harness 上，不要預期能複製 benchmark 的表現。先小規模測，別一次全押。順帶一提，OpenClaw 站內有完整拆解，想先了解 harness 這層在幹嘛的可以看 OpenClaw 是什麼。
誰該裝，誰不該裝？
| 你的情況 | 建議 | 理由 |
|---|---|---|
| 要處理不能外流的資料（客戶名單、病歷、合約、內部文件） | 值得裝 | 資料完全不離開裝置，這是雲端方案給不了的 |
| 要跑大量重複的小任務（分類、抽取、格式轉換） | 值得裝 | 結構化輸出 85.49 全場最高，且邊際成本零 |
| 做 App／硬體，要把 AI 塞進裝置端出貨 | 值得評估 | 開放權重可自行微調部署，GGUF／ONNX 涵蓋主流硬體 |
| 主要拿來寫程式 | 先別 | LiveCodeBench 59.41，連 4.7B 的 Qwen3.5-4B 都比它高 |
| 想拿它當知識庫、問事實問題 | 不建議 | AA-Omniscience 為負分，2.6B 塞不下那麼多知識 |
| 要處理含糊、多輪、會中途改需求的真人對話 | 還不行 | τ³-Bench 只有 5.67，這一項所有模型都還沒過關 |
如果不用它，還有什麼選擇？
- Qwen3.5-4B（4.7B）——體積接近、寫程式和 PinchBench 比它強，但指令遵循差一大截（IFStruct 只有 36.25），做 agent 會比較容易炸。
- Qwen3.5-9B（9.7B）——綜合最強，寫程式、函式呼叫、網頁瀏覽都領先，代價是體積大約 3.7 倍，手機基本上不用想。
- gemma-4-E4B-it（8B）——這次比較中全項落後，在這個用途上很難找到選它的理由。
- 先用雲端 API——如果你的用量本來就小（每天幾萬 token），一年成本可能不到一頓飯，本機部署的折騰不見得划算。用上面的試算機自己按一次就知道。
常見問題
LFM2.5-2.6B 免費嗎？可以商用嗎？
模型權重公開在 Hugging Face 上，官方描述為 open-weight，可下載、微調、部署。具體授權條款請以 Hugging Face 模型頁上的 licence 欄位為準——商用之前一定要自己看一次，這點不要聽任何二手說法。
我的手機真的跑得動嗎？
官方數字是手機約每秒 30 tokens、記憶體低於 2.5 GB。實務上要看你的機器有多少可用記憶體、跑的是哪個量化版本。30 tokens/s 大致等於「比你讀字的速度快一點」，聊天夠用，但你不會想用它跑需要輸出好幾千字的任務。
2.6B 的模型，跟 ChatGPT 差多遠？
不是同一個量級，也不該這樣比。它的定位是「在你裝置上、大量、廉價地執行定義清楚的任務」，不是「什麼都能回答的通用助手」。知識廣度、複雜推理、長文寫作這些，雲端旗艦模型仍然遠遠領先。
那些 benchmark 數字可信嗎？
全部是廠商自報，官方有公開評測設定（用 vLLM、各項的 temperature 與輸出上限都列了出來），透明度算高。但廠商自報就是廠商自報，等第三方複測出來之前，建議當作參考值而不是定論。順帶一提，他們把自己輸的四項也照樣列出來了，這在自報 benchmark 裡不算常見。
它跟 LFM2.5-8B-A1B 是什麼關係？
同一個系列的不同尺寸。官方提到 2.6B 這版沿用了 8B-A1B 的詞表擴充做法，而後訓練資料量約為 8B-A1B 那次的七倍，並且更偏重 agent 類任務（工具使用、網頁搜尋、軟體工程、agent 軌跡）。簡單說：更小，但為了 agent 訓得更專。
結論：它證明的事，比它本身更重要
LFM2.5-2.6B 最有價值的一點，不是它跑得多快，而是它示範了一條路：與其把通用模型縮小，不如針對一種工作型態從頭訓一個小模型。ToolSandbox 贏 Qwen3.5-9B、IFStruct 領先 9 分，靠的不是參數，是整條後訓練流程都對著 agent 這件事在打磨。
同一個星期，市場的另一端在做完全相反的事：阿里的 Qwen3.8-Max 是 2.4 兆參數，走的是規模路線。兩條路都在往前跑，但對一般人來說，能裝進口袋的那條，落地得比較快。
而那個 5.67 分提醒我們現在在哪：定義清楚的任務，它已經做得又快又便宜又安全；模糊的、需要揣摩意圖的任務，離「能交給它」還有一段距離。知道界線在哪，比知道它能跑多快更值錢。
免責聲明：本文為技術資訊整理，非投資建議，也不構成對任何產品的背書。文中 benchmark 數據與規格均取自 Liquid AI 官方部落格（2026 年 8 月 4 日發布、8 月 7 日修訂），屬廠商自報，未經第三方獨立驗證。AI 模型與授權條款更新極快，實際使用前請以官方頁面最新資訊為準。商用部署前請自行確認授權條款。
發表迴響