LFM3 外洩：Liquid AI 的下一代系列是四款小型 Omni 模型

一個於 2026 年 10 月 27 日在 GitHub 上開啟的拉取請求，想教 SGLang 如何服務一個尚未公開存在的模型系列。它列出四個檢查點——LFM3-1.7B、LFM3-VL-2B、LFM3-Audio-2B 和 LFM3-Omni-2B——並對照已推出的 LFM2.5-2.6B 與 LFM2.5-24B-A2B 來讀，宛如 Liquid AI 下一步要打造什麼的藍圖。該 PR 尚未合併。它的三項 CI 檢查全都失敗。Liquid AI 完全沒有宣布任何相關消息。截至今日，那份未合併的 diff 就是 LFM3 全部的公開紀錄，而且它比大多數發布貼文更有資訊量——只要你按它的本質來讀。

所以，讓我們把證據說清楚，因為它在一個方向上很薄弱，在另一個方向上卻異常詳盡。這裡沒有任何東西是發佈日期、價格、授權條款或基準測試分數。沒有 LFM3 模型卡，沒有 Hugging Face 儲存庫，沒有部落格文章，沒有 API 清單。存在的是來自 tugot17——Piotr Mazurek 的貢獻，他在過去兩個月內將 LFM 執行階段支援送進 SGLang、llama.cpp 與 mlx-vlm——再加上 Liquid 自己已發佈、關於它即將取代的 LFM2.5 世代的資料。以下所有內容都會據此標示。

這個 Pull Request 實際上提出了什麼

PR 標題是 [Feat] lfm3：新增文字、視覺、音訊與 Omni 支援，並帶有兩個標籤，說明這是哪種類型的變更：jit-kernel 與 Multi-modal。它為四個模型組成的系列新增原生文字生成，每個模型都有各自的 checkpoint 路徑：

• LFM3-1.7B — 文字進、文字出，是這個系列最基礎的純語言模型

• LFM3-VL-2B — 輸入文字、圖片與影片，輸出文字

• LFM3-Audio-2B — 可輸入文字與音訊、輸出文字，並且也已串接到 /v1/audio/transcriptions 端點

• LFM3-Omni-2B — 可輸入文字、圖像、音訊與影片（包含影片本身的音軌），輸出文字

那份清單中有一個細節值得停下來想一想。每個變體都會輸出文字。整個 PR 裡完全沒有任何音訊輸出路徑，而音訊模型的非聊天介面就是轉錄——語音進、文字出。這比 Liquid 目前的音訊產品線更窄；在該產品線中，LFM2.5-Audio-1.5B 被記載為能在單一模型內處理 ASR、TTS 與交錯式語音聊天。要嘛 SGLang 的首個版本只涵蓋 LFM3-Audio 負責生成文字的那一半，要嘛這個 omni 系列真的捨棄了語音合成。這份 PR 無法判定是哪一種，任何告訴你可以的人都是在猜。請把「LFM3 會說話」視為未經證實。

其餘的差異內容屬於實作細節，但仍透露出這項工作的年代。視覺與音訊編碼器及其投影器、共享主幹、混合快取整合、具 PyTorch 後備方案的 CuTe DSL 卷積核心，以及一項註記：FlashInfer 預設採用分頁預填充，讓滑動視窗注意力能正常運作。驗證是在 H100 上以 FP16 執行，使用描述所稱的 開發檢查點——這四個字之後會很重要。

架構那句話，以及人們會誤讀的數字

PR 將 LFM3 描述為由門控短卷積構成的共享主幹，並搭配完整注意力與滑動視窗注意力。這是 LFM2 血脈的延續，而非取代：LFM2.5-24B-A2B 被記載為橫跨 40 層、結合門控短卷積與分組查詢注意力的混合架構。外洩內容中看似新穎之處，在於明確的滑動視窗元件與完整注意力並存。

驗證說明提到某個提示超出 256 個 token 的滑動視窗，而這個數字接下來會整整一週被斷章取義地引用。那不是 LFM3 的上下文長度。在混合式設計中，注意力層只需要看局部，因為卷積層承載了長距離訊號——這正是該架構的整個前提，也是為什麼這個系列能在 LFM2.5-24B-A2B 上容納 131,072 個 token 的上下文，而其大多數層完全不做二次方注意力。256 個 token 的注意力視窗說明的是模型在單一層內查看的範圍，而不是它能接受多少文字。PR 並未說明 LFM3 的總上下文長度，而 Liquid 以外的人目前也還不知道。

為什麼執行階段的提取請求是訊號，而非雜訊

對於從基礎架構的差異來推敲產品策略抱持懷疑，是合理的。但在這個具體案例中，這個模式一致得讓人無法忽視，因為 Liquid 是與權重同步推出引擎支援，而不是在權重之後才補上。LFM2.5-2.6B 將 llama.cpp、MLX、vLLM、SGLang、ONNX 與 Transformers 5.0+ 列為首日支援目標。LFM2.5-24B-A2B 在發布時就已支援 llama.cpp、MLX、vLLM、SGLang 與 ONNX。一個登場時就備妥五個執行環境的模型家族，其核心必然是在發表之前就寫好的，這意味著 PR 會先合併，部落格文章隨後才跟上。

作者完全符合那個時間順序。Mazurek 的公開紀錄是一連串 LFM 整合工作：九月在 SGLang 為 LFM2-VL 進行 DSpark 推測解碼；同月在 llama.cpp 進行 LFM2.5-VL-3B 與 DSpark 草稿模型修正；在 mlx-vlm 沿用文字模型的推測解碼；以及 10 月 13 日在 SGLang 重用 LFM2-MoE 組態。LFM3 是該序列中的下一項，於這個系列改名的那個週末提交。

兩個缺席與存在同樣能說明問題。Hugging Face Transformers 中沒有針對 LFM3 的對應 pull request——在該儲存庫中搜尋一無所獲——而 SGLang 的 PR 則是透過標準版 Transformers 5.19.0 搭配 --trust-remote-code 載入其檢查點，這正是當該架構尚未原生支援於該函式庫時會採用的做法。還有一個 commit 明確拒絕為 LFM3 採用推測性解碼，因此為 2.5 世代推出的 DSpark 工作尚未延續過來。尚早，且刻意不完整。

沒有人回答過的尺寸問題

在此，洩漏的內容與所宣稱的雄心背道而馳，而這種張力正是這份文件中最有意思的地方。

Maxime Labonne，Liquid 的預訓練負責人，將 LFM3 的目標描述為：測試在 3.5 億至 12 億參數規模下行之有效的短卷積方法，能否在超過 100 億參數的規模下依然成立——而這個規模區間正是注意力架構歷來佔有優勢的領域。這是一個規模化問題，也意味著需要一個大型模型。

外洩的檢查點有一個是 1.7B，另外三個是 2B。它們之中沒有任何一個高於那個問題所說的門檻。

有兩種解讀仍站得住腳。第一種是：這些是精簡的第一波——在大型同類產品問世前，先針對手機與汽車推出的全模態家族；這符合 Liquid 一向以小模型打頭陣的做法，也符合 PR 將它們描述為開發檢查點、而非最終版本的方式。第二種是：1.7B 與 2B 只是方便用來驗證 kernel 的尺寸，對於最後實際出貨什麼毫無說明。誠實的立場是：這次外洩證明這個家族存在，也證明它的輪廓；但未證明它的上限。如果你正在等一款 >10B 的 Liquid 模型，這份 PR 既沒有承諾，也沒有排除。

LFM3 所繼承的，無論好壞

它必須超越的基準是近期且文檔記錄完善的。LFM2.5-24B-A2B 於 2026 年 10 月 13 日推出，總參數為 24B、啟用參數 2B、40 層、64 個專家與 top-4 路由、131,072 個 token 的上下文、128K 詞彙表，以及 33T 預訓練 token。LFM2.5-2.6B 於八月初推出，僅需不到 2.5GB，並具備 128K 上下文。LFM2.5-VL-3B 將 2.6B 基底模型與 SigLIP2 視覺編碼器搭配。

值得直說的是：Liquid 針對這些模型公布的所有基準測試成績，都是廠商在 Liquid 自家測試框架上跑出來的，並未附上任何獨立評測。LFM2.5-24B-A2B 的主要宣傳數字——AutomationBench 27.69、BFCLv4 65.01、ToolSandbox 80.71、IFEval 96.75——都是 Liquid 自己的數據，而同一張表也顯示它在 WebArena Verified（26.75 對 37.62）、GPQA Diamond 與 SWE-Bench Verified 上輸給 Qwen3.6-35B-A3B。願意把敗績一併列出的廠商表格，比不列出的更可信，但可信並不等於經過驗證。目前完全沒有任何 LFM3 的數字，因此尚無從比較。

授權也會一併延續。Liquid 最近在 Hugging Face 上發布的 LFM 檢查點，每一個都標註為 license: other——這是量身打造的 LFM 授權，並非 Apache-2.0 或 MIT。無論 LFM3 以何種授權發布，在模型卡另有說明之前，都應假定沿用相同的自訂條款，並且在以這些權重打造產品之前先詳閱條款。

當它可能真正落地的時候

沒有人握有確切日期，包括那些專業做猜測的人。Manifold Markets 上一個關於 LiquidAI LFM3 何時發布的問題，把 Q4 2026 設在 40%、Q1 2027 為 21%、Q2 2027 為 21%、Q3 2026 為 11%、Q2 2026 為 7%——總成交量約 Ṁ160，這個量小到足以讓這些百分比反映的是少數幾名交易者，而非共識。把它解讀為「大概會在接下來兩季內的某個時候」，不要比這更精確。

從技術機制來看，宜早不宜遲。kernel 工作要進入主流 runtime，屬於後期而非前期的工程——不會為一個還要一年才推出的模型撰寫 CuTe 卷積 kernel，並接入混合快取。家族名稱已在四個變體與四個 checkpoint 路徑上穩定為 LFM3。但該 PR 尚未合併，三項檢查全數紅燈，還缺一個它目前沒有的核准審查；而且 22 項 omni 驗證檢查中有 2 項、16 項視覺檢查中有 2 項仍未通過其 ROUGE 比對。那是進行中的分支，不是候選發行版。

如果你這週要挑選模型，這代表什麼

LFM3 的任何資訊都不應改變你今天的任何決定。它尚未推出、尚未定價、尚未公開評測，也未公開授權。如果你現在需要一個小型多模態模型，LFM2.5 世代才是真正的答案，而它的限制——廠商自報的分數、自訂授權，以及 Liquid 自家表格與外部報導都標為弱點的程式編寫表現——正是你該衡量的重點。

這份外洩內容真正有用之處在於規劃。它告訴你，一個緊湊的全模態家族即將推出，很可能會同時橫跨多個執行環境登場，而其音訊版本可能不會合成語音。如果你的路線圖假設 Liquid 的下一步是更大的文字模型，那麼迄今的證據並不支持這個假設。

執行階段碎片化是這個系列將造成的實際問題。Liquid 同時發布到 llama.cpp、MLX、vLLM、SGLang 和 ONNX 的習慣，對可攜性有好處，但對任何想要單一端點的人來說很麻煩：五個引擎意味著五種部署形態、五套預處理特殊行為，以及五個不同的修復到位日期。OrcaRouter 的 超過 200 個模型的目錄目前不包含任何 LFM checkpoint，因此無法透過它呼叫 LFM3，而這裡的任何內容都不應被解讀為承諾未來會有。在這種情況下，路由層真正的作用是未經證實的模型與生產路徑之間的接縫——將一部分流量送到某個新東西，同時讓已知模型留在其後，並由容錯移轉接住缺口，這就是你在不把面向客戶的功能押注於 40% 預測市場的情況下，評估尚未發布系列之繼任者的方式。

值得關注的未解問題

有四件事能比任何進一步的臆測更快解決這件事。四個檢查點路徑是否會成為真實、可下載的 Hugging Face 儲存庫——目前搜尋 LiquidAI 組織時，LFM3 底下查不到任何結果，而 PR 中點名的儲存庫也無法公開解析。是否會出現一個 Transformers PR，這將意味著該架構正被妥善上游化，而不是透過遠端程式碼來執行。失敗的驗證檢查是否會關閉，因為 22 個 omni 失敗中的 2 個，正是展示與合併之間的差別。以及該系列是否會出現一個 >10B 的成員，而這正是 Labonne 所說 LFM3 存在所要回答的問題。

在那之前，任何人能寫出關於 LFM3 最準確的一句話，就是本文開頭的那一句：有一個 pull request 存在、尚未合併，而且它點名了四個 Liquid AI 尚未宣布的小型 omni 模型。那是一個真實的訊號——只是還很早，而早期訊號就該被如實地當作早期訊號來解讀。