LFM2.5 規模比較:裝置端 230M、350M 與 1.2B
Liquid AI 的 LFM2.5 提供三種規模。基準資料、匯出體積,以及我們把其中兩種微調成正式產品時學到的事,包括那個所有指標都沒能發現的失敗。
Liquid AI 的 LFM2.5 家族現已進入 Ertas 目錄,共三種規模:230M、350M 與 1.2B。三者皆為開放權重,皆支援 32,768 token 的上下文視窗,執行記憶體都不到 1GB,並且都能在我們的入門 GPU 層級上、於免費方案範圍內完成訓練。
它們都能用。真正有意思的問題是你該選哪一個,而這件事的答案比大多數模型比較都更乾淨。
簡短版本: 如果模型需要維持對話,選 1.2B。如果每次請求彼此獨立,選 350M 或 230M。它們之間的分界線是對話連貫性,而這條線比基準分數所暗示的清晰得多。
| 如果你的模型需要 | 選擇 | Q4_K_M 下載體積 |
|---|---|---|
| 維持多輪對話、執行代理迴圈 | LFM2.5 1.2B | 731 MB |
| 呼叫工具、擷取欄位、輸出 JSON,每次一個請求 | LFM2.5 350M | 229 MB |
| 在瀏覽器分頁或樹莓派裡完成上述這些 | LFM2.5 230M | 153 MB |
| 知道很多世界知識 | 更大的模型 | 不適用 |

這個架構只有一部分是 Transformer
LFM2.5 將雙閘控短程卷積區塊與分組查詢注意力區塊交錯排列。1.2B 與 350M 皆為 16 層,按 10 個卷積區塊比 6 個注意力區塊劃分。230M 為 14 層,按 8 比 6 劃分。
這種劃分就是整個設計的核心。注意力相對序列長度是平方成本,卷積是線性成本。把兩者混合,就能讓長提示詞在小參數量下依然划算,而同等規模的純 Transformer 此時已經開始為自身的注意力矩陣付出代價。這也是為什麼一個 230M 的模型能承載 32,768 token 的上下文,以及為什麼這些模型在 CPU 上仍能維持吞吐,而同等規模的 Transformer 會明顯吃力。
整個家族的詞表為 65,536 token,僅為 Gemma 3 的 256K 詞表的四分之一。在這個參數量級上,嵌入表在檔案體積中占比很大,因此精簡的詞表幾乎完全解釋了為什麼一個 1.17B 的模型匯出後比 Gemma 3 1B 還小。
三種規模並排比較
| LFM2.5 230M | LFM2.5 350M | LFM2.5 1.2B | |
|---|---|---|---|
| 參數量 | 230M | 350M | 1.17B |
| 層數 | 14(8 卷積 + 6 GQA) | 16(10 卷積 + 6 GQA) | 16(10 卷積 + 6 GQA) |
| 預訓練預算 | 19T token | 28T token | 28T token |
| 上下文長度 | 32,768 | 32,768 | 32,768 |
| 語言數 | 10 | 9 | 8 |
| 發布日期 | 2026 年 6 月 25 日 | 2026 年 3 月 31 日 | 2026 年 1 月 5 日 |
| Ertas GPU 層級 | T4 | T4 | T4 |
| 免費方案 | 是 | 是 | 是 |
這張表裡有兩件事值得停下來看看。
350M 拿到了與 1.2B 相同的 28 兆 token 訓練預算。小模型通常相對其容量而言訓練不足,因為算力預算往往跟著參數量走。把一次完整規模的訓練投在 350M 參數上是一個刻意的選擇,而這在分數上體現了出來。
230M 是自 350M 蒸餾而來的,而不是在那個規模上從零訓練,隨後又經過直接偏好最佳化與多領域強化學習精修。它涵蓋的語言也是三者中最多的,多出了義大利語。
基準資料
以下所有數字皆為 Liquid AI 公布的結果,來自 LFM2.5 發布文章、350M 文章 與 230M 文章。1.2B 的比較對象與兩個更小的型號不同,因此兩張表分開呈現。
LFM2.5-1.2B-Instruct 對比 1B 至 1.7B 區間:
| 基準 | LFM2.5 1.2B | Qwen3-1.7B | Granite-4.0-h-1b | Gemma 3 1B | Llama 3.2 1B |
|---|---|---|---|---|---|
| IFEval | 86.23 | 73.68 | 80.08 | 63.25 | 52.37 |
| IFBench | 47.33 | 21.33 | 24.93 | 20.47 | 15.93 |
| MMLU-Pro | 44.35 | 42.91 | 27.64 | 14.04 | 20.80 |
| GPQA | 38.89 | 34.85 | 24.34 | 24.24 | 16.57 |
| AIME25 | 14.00 | 9.33 | 1 | 1 | 0.33 |
LFM2.5-230M 與 350M 對比 1B 以下區間:
| 基準 | LFM2.5 230M | LFM2.5 350M | LFM2-350M | Granite 4.0-H-350M | Qwen3.5-0.8B | Gemma 3 1B IT |
|---|---|---|---|---|---|---|
| IFEval | 71.71 | 76.96 | 64.96 | 61.27 | 59.94 | 63.49 |
| IFBench | 38.40 | 40.69 | 18.20 | 17.22 | 22.87 | 20.33 |
| Multi-IF | 37.70 | 44.92 | 32.92 | 28.70 | 41.68 | 44.25 |
| BFCLv3 | 43.26 | 44.11 | 22.95 | 43.07 | 35.08 | 16.61 |
| BFCLv4 | 21.03 | 21.86 | 12.29 | 13.28 | 18.70 | 7.17 |
| CaseReportBench | 22.51 | 32.45 | 11.67 | 12.44 | 13.83 | 2.28 |
| MMLU-Pro | 20.25 | 20.01 | 19.29 | 13.14 | 37.42 | 14.04 |
| GPQA Diamond | 25.41 | 30.64 | 27.58 | 22.32 | 27.41 | 23.89 |
兩張表的形態是一樣的。指令遵循與函式呼叫的分數對這個參數量而言異常之高,世界知識的分數則平平甚至更差。Qwen3.5-0.8B 以明顯優勢拿下 MMLU-Pro,卻在所有指令遵循的欄位上落後。
這就是整個家族做出的取捨,而對裝置端情境來說這個取捨是對的。一個能可靠照你說的做、事實由提示詞提供的模型,勝過一個知道更多但更不聽話的模型。給它們搭配檢索,讓索引去承擔知識。


另一個值得細看的數字:230M 在 BFCLv3 上取得 43.26,而它 350M 的教師模型為 44.11。蒸餾幾乎原封不動地把函式呼叫能力帶下了整整一個規模級距。參數量約為其四倍的 Gemma 3 1B IT,在同一基準上只有 16.61。
我們真正做過的那場比較
基準把我們縮小到了一份候選名單,但要在 350M 與 1.2B 之間做決定,得真的做一個東西出來。
Chatty Valley 是一個《星露谷物語》模組,用一個在玩家自己 CPU 上執行的微調模型取代了某位村民固定的台詞。我們用同一份角色資料集分別訓練了 350M 與 1.2B,並對兩者跑了同一套評測。
我本來希望 350M 能贏。要一個陌生人下載 229MB 遠比 731MB 容易開口,而且微調後的 350M 把角色的語氣與格式維持得非常好,產出的單句讀起來完全就是那個角色。
然後它就跟丟了。問它一句隨性又略帶混亂的話,你會得到流暢、完全符合人設的胡言亂語:一個針對你沒問過的問題的回答,緊接著同一個想法再重複一遍,深怕你沒看見。1.2B 能跟住對話,所以最終發布的是它,量化後 697MB。
下面這一點值得帶進你自己的專案。所有自動化指標都說 350M 沒問題。 無破折號率、越獄外洩率、句長分布、退化度、數字年齡外洩,在兩種規模上全部乾淨。這個失敗只有靠真正對話才看得見。
所以,如果你要在這個量級上微調任何對話類應用,請寫一套腳本化的多輪探針,重現你真正在意的那種對話形態,並在相信指標面板之前先跑一遍。自動化面向能抓住回歸,卻看不見連貫性。
對於單輪任務,也就是 350M 與 230M 真正的定位,上面這些都不適用。擷取、分類、結構化輸出與工具呼叫都是彼此獨立的請求,兩個較小的規模都處理得很好。
一個能在瀏覽器分頁裡執行的 230M 模型
230M 靠下載體積贏得自己的位置。量化後 153MB,小到可以在一個網頁裡下載完成。
Corporate Goblin 就是我們的展示:LFM2.5-230M 的 LoRA 微調版本,合併後匯出為 q4 ONNX,透過 transformers.js 在 WebGPU 上完全在用戶端執行,並以 WASM 作為後備。沒有伺服器,沒有 API 金鑰,沒有按次呼叫成本,你輸入的任何內容都不會離開訪客的機器。它把每個提示詞都當作一位過度自信的成長大師來回答,並拒絕提供任何有用資訊,而這正是它的用意。
它認真證明的一點是:只要任務夠窄、資料集在這一點上夠一致,一個 230M 的模型守住一個明 確人設的能力遠超參數量給人的印象。當任務夠具體時,小模型是真的能打的。
每種規模的發布成本
下載體積是決定大多數裝置端專案的限制條件,所以這裡給出真實數字,讀取自 Liquid AI 公布的 GGUF 建置,而不是估算。
| 量化 | 230M | 350M | 1.2B |
|---|---|---|---|
| Q4_0 | 149 MB | 219 MB | 696 MB |
| Q4_K_M | 153 MB | 229 MB | 731 MB |
| Q5_K_M | 172 MB | 260 MB | 843 MB |
| Q6_K | 191 MB | 293 MB | 963 MB |
| Q8_0 | 247 MB | 379 MB | 1.25 GB |
| BF16 | 462 MB | 712 MB | 2.34 GB |
在兩個較小的規模上,從 Q4_K_M 提到 Q6_K 分別只多 38MB 與 64MB。這個代價低到值得先測一測額外的品質對你的任務是不是幾乎免費,再決定要不要預設用 Q4。


執行占用,皆為 Liquid AI 在具名硬體上的實測:
| 裝置 | 模型 | 記憶體 | 解碼 |
|---|---|---|---|
| iPhone 13 Mini(Cactus) | 350M | 56 MB | 88 token/秒 |
| Snapdragon 8 Elite NPU | 350M | 169 MB | 15 token/秒 |
| 樹莓派 5 | 230M | 293 MB | 42 token/秒 |
| Galaxy S25 Ultra | 230M | 375 MB | 213 token/秒 |
| AMD Ryzen AI Max 395+ | 350M | 434 MB | 313 token/秒 |
| Galaxy S25 Ultra | 1.2B | 719 MB | 70 token/秒 |
| AMD Ryzen AI 9 HX 370 | 1.2B | 856 MB | 116 token/秒 |
作為對照,在 1.2B 占用 719MB 的同一台 Galaxy S25 Ultra 上,Qwen3-1.7B 需要 1,306MB。
在 Ertas 上微調 LFM2.5
三種規模都在 T4 層級上訓練,這是我們的入門層級,也是免費方案使用的層級。三者都在免費方案的 5B 參數上限之內,因此即便是其中最大的那個,完整訓練也可以零成本開始。權重原生支援 bf16,訓練直接以 bf16 進行,沒有退回 fp32 的效能損失。
適用於 2B 以下基礎模型的配方:
| 設定 | 取值 |
|---|---|
| 學習率 | 3e-4 到 5e-4 |
| 批次大小 | 4 |
| 梯度累積 | 2 |
| 訓練輪次 | 8 到 16 |
相較 7B 模型,小模型需要在小資料集上多走幾遍,行為才會穩定下來,並且能承受更高的學習率而不崩潰。
匯出結果可以是供 llama.cpp、Ollama 與 LM Studio 使用的 GGUF,也可以是 safetensors LoRA 轉接器(若你希望把轉接器單獨保留、自行合併)。若用於瀏覽器部署,請把轉接器合併後轉換為 q4 ONNX,這正是 Corporate Goblin 走的路徑。
有一件事需要提前規劃:這個家族的工具呼叫預設使用包裹在專用 <|tool_call_start|> 與 <|tool_call_end|> token 之間的 Python 式函式呼叫。如果你的執行環境期望 JSON,可以在系統提示詞裡要求。請讓訓練資料與你打算發布的形式保持一致。
發布前關於授權的一個提醒
LFM2.5 依 LFM Open License v1.0 發布,這是 Liquid AI 自有的條款文本。商業使用被允許但附帶條件,其條款與 Apache 2.0 或 MIT 不同。該授權會隨你的微調模型一起傳遞,因此在以這個基礎模型發布商業產品前請先閱讀。Ertas 目錄中的其餘模型大多是 Apache 2.0,很容易讓人以為這個也一樣。
常見問題
LFM2.5 230M、350M 與 1.2B 有什麼差別?
它們共用同一架構與 32,768 token 的上下文視窗,差別在容量。1.2B 能維持多輪對話與代理 迴圈。350M 在函式呼叫與結構化擷取上緊追 1.2B,而下載體積只有三分之一。230M 由 350M 蒸餾而來,在工具呼叫上讓出的很少,同時能塞進 153MB,小到足以放進瀏覽器。
微調聊天機器人該選哪一種 LFM2.5 規模?
1.2B。在我們自己的測試中,微調後的 350M 完美維持了角色的語氣,隨後卻在多輪隨性對話中跟丟了線索,而 1.2B 跟住了。所有自動化指標在兩種規模上都通過了,因此這個差別只有透過腳本化的對話探針才浮現出來。
LFM2.5 能在網頁瀏覽器裡執行嗎?
可以。匯出為 ONNX、量化到 q4,然後透過 transformers.js 在 WebGPU 上執行,並以 WASM 作為後備。153MB 的 230M 是首次載入的實用選擇。playground.ertas.ai 上的 Corporate Goblin 就是一個可用的例子。
在這個規模上 LFM2.5 比 Qwen 或 Gemma 更好嗎?
在指令遵循與函式呼叫上,明顯更好。LFM2.5-1.2B 的 IFEval 為 86.23,Qwen3-1.7B 為 73.68,Gemma 3 1B 為 63.25;LFM2.5-350M 的 BFCLv3 為 44.11,Gemma 3 1B IT 為 16.61。在世界知識上它會輸:Qwen3.5-0.8B 的 MMLU-Pro 為 37.42,而 230M 為 20.25。按你的任務真正需要哪一項來選。
微調 LFM2.5 要花多少錢?
起步不花錢。三種規模都在 Ertas 免費方案的 5B 參數上限之內,並在 T4 層級上訓練。付費層級增加了什麼,請參見價格頁面。
LFM2.5 不擅長什麼?
Liquid AI 不推薦這個家族用於知識密集型任務與程式設計,並針對 230M 額外列出了高階數學與創意寫作。多輪對話是兩個較小規模的另一個邊界。請把事實放進提示詞裡,並給這些模型一個具體的任務。
包含完整規格、基準與硬體需求的模型頁面:LFM2.5 家族、LFM2.5 230M、LFM2.5 350M、LFM2.5 1.2B。
Ship AI that runs on your users' devices.
Free plan with 30 credits/mo, no card required. Paid plans from $10/mo USD.
Keep reading
Chatty Valley:《星露谷物語》裝置端 AI 模組(第一部分)
我如何微調一個 1.2B 裝置端 AI 模型,讓萊納斯在《星露谷物語》裡真的能對話。全程跑在你的 CPU 上,不需要 API 金鑰。這是 Chatty Valley 開發日誌的第一部分。
微調 3B 模型 vs GPT-4:為什麼小型模型在領域任務上勝出
學術研究顯示,微調後的 3B-7B 模型在領域特定任務上持續勝過 GPT-4。以下是證據、模式,以及如何應用在你的應用程式中。
雲端到邊緣 AI 管道:資料準備如何融入訓練與部署之間
完整的雲端到邊緣 AI 管道從原始資料延伸到設備端部署。資料準備是原始企業資料和雲端訓練之間的步驟——也是大多數邊緣 AI 項目失敗的地方。