LFM3 解析：六款小模型如何分工，約 1 GB 權重之外還要算什麼？（2026）

2026 年 10 月 27 日，Liquid AI 在官網發布了〈Introducing LFM3: Every Modality for Specialized Intelligence〉。這次 LFM3 的主角，是一組約 2B 級、可下載權重的小模型：把文字、看圖、聽說與結構化判斷分成不同成員，讓開發者依任務挑選。值得追問的是：模型變小後，哪些成本真的下降，哪些能力仍要另外驗收？

先看原文如何安排這個家族，再核對模型卡、權重檔與架構設定，最後判斷它適合承接哪一類工作。本文未執行 LFM3 模型推論；下文廠商測試保留原來的歸屬，記憶體算式則明列假設。

LFM3 的核心主張：共同骨幹，依任務分工

Every modality, one backbone

中文：各種模態，共用一個骨幹。

Liquid AI，LFM3 發布公告

原文想推動的，是把通用模型再訓練成特定任務的專家。它把模型架構、預訓練、後訓練與部署放在同一條路徑：先取得共同能力，再加上視覺或音訊元件、調整任務行為，最後放到應用所在的裝置。「同一骨幹」不等於每個下載檔都有相同輸入、輸出或上下文長度。

以下依 2026 年 10 月 31 日查閱的各自模型卡整理。六個應用成員之外，還有作為起點的 LFM3-1.7B-Base；因此，模型集合中出現七個主要 checkpoint，與公告所說的六個應用模型並不矛盾。

成員	主要角色	模型卡的上下文
LFM3-1.7B	文字、工具呼叫與本機 Agent	256K，輸入＋輸出
LFM3-VL-2B	文字、圖片與影片理解	128K，輸入＋輸出
LFM3-Audio-2B	文字／音訊輸入，文字或語音輸出	32K，輸入＋輸出
LFM3-Omni-2B	結合文字、視覺與音訊，輸出文字或語音	32K，輸入＋輸出
d1-2B	由視覺模型延伸，回傳帶機率的型別化答案	128K
d1-Omni-2B	在判斷流程加入音訊輸入	128K

例如，只需把客服工單分流，不一定值得每次生成長篇回答；若需要邊看圖片邊回答口頭問題，才有理由考慮 Omni。Audio 模型卡另把多語轉錄、合成與翻譯，和語音聊天分開描述，並明列目前語音聊天僅支援英文。語言清單有 Chinese，不能直接換成所有模式都能用中文自然對話。

LFM3 為何能小？先看計算如何分配

在公開架構設定中，文字骨幹有 24 層：13 層短卷積、5 層滑動視窗注意力、6 層全域注意力；滑動視窗為 256 token。可以把它想成三種閱讀方式：局部辨識鄰近模式、在有限範圍內對照，以及跨較長距離連結資訊。這是機制比喻，不是三種互不相通的記憶庫。

全域注意力不必佔滿每一層，讓長序列的計算與快取有不同分配空間。Transformers 快取文件也區分了會隨序列成長的快取，與到視窗上限就停止成長的層。這能解釋設計方向；實際速度仍取決於運算核心、硬體、量化與提示長度，不能只從層數宣布勝負。

Liquid AI 把效能進展同時歸因於新架構、資料與後訓練。其技術前史可回看LFM2 技術報告中的硬體導向架構搜尋；這次公告進一步結合短卷積、滑動及全域注意力。品牌名稱裡的 Liquid，不應讓人把它想成不需要注意力或不需要快取的另一種魔法。

原文的後訓練路徑包括監督式微調、混合強化學習、把專項教師能力蒸餾回學生，以及在 Agent 執行環境中訓練。這提醒我們：小參數量描述的是交付給使用者的模型規模，不能據此推算培養它所需的總算力、資料或教師成本。

約 1 GB 的 LFM3：檔案裝得下，任務也跑得動嗎？

the text model fits in about 1 GB at 4-bit precision.

中文：文字模型在四位元精度下，約可放進 1 GB。

Liquid AI，LFM3 發布公告

把這句話對到具體檔案，官方 QAD Q4_0 GGUF的公開檔案大小約為 1.05 GB。這支持的是量化文字模型檔案約 1 GB；應用執行時還有快取、暫存張量、推論引擎與其他元件。量化文件說明的是用較低精度降低模型占用，也要衡量精度與硬體支援。

可以做一個可重算的空間估計。依上述文字模型設定，若單一序列有 131,072 token，只估 6 層全域注意力的 K／V，採每元素 2 bytes、4 個 KV heads、每個 head 128 維，而且不壓縮快取，算式為：6 × 2 × 4 × 128 × 2 × 131,072＝1,610,612,736 bytes，約 1.61 GB。這還沒加模型權重與其他執行占用。

這是指定假設下的理論估算，沒有測量任何裝置的實際 RAM，也不是宣告所有引擎都用同一種快取。它已足以指出關鍵：四位元權重與兩位元組 KV，是兩個可以不同的精度設定。把檔案大小當成整個應用的最低記憶體，會漏掉長上下文的帳。若常在模型間切換，可接著看單卡模型交接教學，理解載入與釋放是另一層工作。

256K 也應當作可接受的序列範圍，與「每個位置、每種問題都能可靠作答」分開。RULER 原始研究早已把簡單找針、跨段追蹤與資訊彙整分開測；那篇研究不是 LFM3 測試，提供的是評估長上下文的問法。把文件塞得進去之後，還要驗答案需要的證據是否真的被使用。

廠商跑分值得看，平均分卻不能替你選任務

Liquid AI 在文字模型卡的評測表中同時列出強項與落差。下面只抽出四列，保留原表的模型與測試名稱；全部是Liquid AI 回報的分數，不是 AlphaLab 或獨立機構重跑的結果。

廠商回報項目	LFM3-1.7B	Qwen3.5-9B
BFCL V4	71.39	62.83
MCP-Atlas	32.57	42.67
SWE-bench Verified（OpenCode）	43.40	51.20
RULER 128K	65.56	87.11

同一張表，LFM3 在 BFCL 較高，在另外三列較低。這足以反駁「小模型全面取代大模型」的讀法，卻不能反過來證明哪一款在你的工單一定更好。工具選擇、長文取證、修程式碼各自需要不同能力；不加權平均會把它們混成一個數字。

模型卡交代品質評測以 BF16、vLLM 等設定進行；裝置端速度比較則使用 Q4_0 GGUF、llama.cpp、32,768 token 上下文、單批次與 100 個輸出 token。品質表與速度表不是同一個執行配置。選四位元版本時，應把該版本的品質一起驗，不能直接把 BF16 的分數與另一張量化速度表拼成保證。

這裡最有力的反方理由，來自模型卡自己：文字模型被定位於本機 Agent、工具呼叫與專項微調，並不推薦拿來做複雜多步推理或 Agent 程式開發。它承認的邊界，比社群「跑贏幾倍大的模型」更適合用來安排第一個試驗。要先寫好合格條件，可參考AI Evals 入門。

d1 的新意：先決定要哪一種答案，再驗它的機率

生成一句流暢答案，與替一筆資料做判斷，並非完全相同的工作。d1-2B 模型卡描述的是一次前向運算回傳型別化結果與機率，可涵蓋分類、抽取欄位、框選物件與數量估計；d1-Omni 再把音訊放進輸入。它們適合拿來研究工單分流或文件檢查這類固定問題，不能直接當一般聊天模型使用。

「已校準」的意義，需要放回實際資料檢查。機率校準文件用同一分數區間的預測與實際命中比例對照，解釋何謂可靠機率。如果你收到一批 0.9 分的判斷，應在有標準答案的資料上檢查，命中比例是否接近那個數字；這是示意，不是本篇替 d1 量到的成績。

例如發票上的金額錯一位，與工單分錯優先順序，代價不同。即使模型回傳機率，也還需要選門檻、設定例外與安排複核。d1-2B 模型卡明列，狀態輸入超過約 64K token 後，答案會變得較不可靠；數量估計對計數與評分較可靠，對自由數量較弱。128K 上下文規格與哪段範圍較可信，官方本來就分開交代。

原文真正的訴求：把小模型訓練成你需要的專家

公告用風機葉片檢查與機器人延伸，示範同一骨幹如何再適配。前者要辨識特定缺陷；後者又分工具協作、導航與直接產生動作等研究方向。這些是團隊提供的案例，不能合併成「下載通用模型就能可靠操控機器人」。

「單張 GPU 可微調」也只交代硬體張數。卡的型號、顯存、資料量、序列長度與訓練方法，仍決定成本與可行性。公告案例用了 A100 或 MI325X 等不同設備；對個人開發者，合理的第一步是挑一個窄任務，確認官方範例與自己現有硬體相容，而非從「單卡」推到「任何顯示卡都能做」。

部署工具也要逐成員確認。文字 GGUF 已有具體本機入口；視覺模型卡查閱版本仍把部分 GPU 推論後端的支援列在整合進度中。家族發布與每個套件正式版本都支援，應分兩張清單。本站的LFM3-VL-2B WebGPU 教學處理的是一個社群瀏覽器示範，與這裡評估整個家族的問題相鄰。

授權方面，這些權重採LFM Open License v1.0。條款設有商用營收限制，並容許在條件下保留私人微調成果；它與標準 Apache 2.0 的授權條件不同。能免費下載，不足以判定特定企業部署已獲商用授權。企業評估時，授權資格應與模型、引擎版本一起先確認。

AlphaLab 的判讀：把能力放到對的地方，才是小模型的價值

一、我同意分工：少做不需要的生成，可能比追總榜更有效

一筆文件只需要「金額在哪」「是否缺欄」，就先定義這兩個答案；若需要解釋，再由生成模型接手。這種分工有機會降低重複工作，也讓錯誤更容易分類。LFM3 同時提供生成與判斷成員，讓選擇有具體起點；省下多少，仍要連同重試與複核一起算。

二、我存疑的是全面替代：容量、可靠性與成本各有一條線

一個小模型能放進裝置，是容量問題；能否穩定做對，是品質問題；整件工作是否更划算，是總成本問題。三條線可能同時改善，也可能只改善其中一條。若一次便宜的錯誤，要靠大模型或人類多次補救，單次推論的優勢就不等於每件合格成果的優勢。

三、本機部署增加控制權，資料邊界仍由整套應用決定

自己保留權重，能選擇在哪裡運算；但一個會查網頁、寄信的 Agent，仍可能透過工具對外連線。模型放在本機，與所有資料始終留在本機，是不同的系統條件。先列出工具、儲存、日誌與網路路徑，才能說清楚哪些資料被誰使用。Agent Harness 白話解說可以補上模型之外的執行責任。

四、值得追蹤的下一步，是專項成果能否以較低總成本重做

這次發布可確定的價值，是多了可下載、可檢查、可再適配的模型選項。較強的下一份證據，會是不同團隊在固定資料、版本與硬體下，重做一個明確任務，公開成功、失敗、延遲、峰值記憶體和人工介入。合作夥伴的好評能說明需求，不能替所有使用者完成這份比較。

下一步：替 LFM3 選一件窄工作，先寫三個問題

挑一件可回復、沒有敏感資料的工作，例如整理自製工單。先問：它需要生成，還是固定判斷？合格答案如何確認？整批跑完用了多少時間與資源？保存模型與量化檔版本、引擎版本、提示、實際輸入長度及失敗案例，再與現行做法比較。

若還沒準備好推論環境，先完成答案本與驗收表即可；有了現成環境，再做小批比較。LFM3 值得看的，不是把最大的模型塞進最小的空間，而是讓一個大小合適的模型，持續完成你定義清楚的工作。下一張成績單，應以合格成果為單位。