一張主視覺標題卡寫著「LFM3-Omni-2B」,副標題為「能看、能聽、能回話」,規格標籤寫著 2.17B 參數、32K 上下文、24 kHz 語音與 LFM Open License v1.0,另有四個分別標示為文字、圖像、影片與音訊的圖塊,流入一張寫著「一個模型:輸出文字與語音」的卡片。OrcaRouter 標誌位於右下角。
Guides & Insights

LFM3-Omni-2B:會說話的全能模型,以及聲稱它不會說話的外洩

作者

Magnus Corvin

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

LFM3-Omni-2B以語音回答。這一句話本身就是新聞,因為一週前最有力的公開證據顯示的正好相反。當 LFM3 系列透過一個尚未合併的 SGLang 提取要求曝光時,其檢查點僅配置為文字輸出,而我們自己針對那次外洩所寫的報導在當時正確地得出結論:「LFM3 會說話」尚未獲得證實。2026 年 10 月 27 日,Liquid AI 發布了該系列的公告與模型卡,而模型卡一錘定音:24 kHz 語音輸出,透過名為 LiquidCodec 的元件生成,並以快於即時的速度串流。 未經證實的模型不應在第一天就成為關鍵支撐。 自動容錯移轉 流量可依規則轉移,且故障路徑無需修改程式碼即可容錯移轉。

這次發布的其他一切,都比那則更正所暗示的更為低調。Liquid 的公告涵蓋六個模型,而 LFM3-Omni-2B 在裡面只佔了三句話——沒有基準測試表、沒有上下文長度、沒有參數量。量化記錄完全存在於 Hugging Face 卡片中,下文每一個數字都來自那裡。在圍繞這個模型做規劃之前,值得先理解這種拆分:定位是行銷,數字是儲存庫,而兩者之中沒有任何一項經過獨立測試。

實際發布了什麼,以及何時發布

此儲存庫建立於 2026 年 10 月 21 日 16:58 UTC。這張卡片最後修改於 10 月 27 日 17:25 UTC,與家族貼文同一天。撰寫本文時,Hugging Face 顯示 83 次下載與 17 個讚——這樣的數字不算多,符合它是以六模型家族其中一個分支的形式發布的檢查點,而非作為重點發布。同系列的其他儲存庫也說明同樣的情況:LFM3-VL-2B 建立於 10 月 19 日,LFM3-Audio-2B 建立於 9 月 8 日,而它們全都在 10 月 27 日有過異動。

所以,這並不是簡報所暗示的那種未經公布的模型。Liquid 已宣布這個系列、命名了六個分支,並說明了 omni 模型的功能。該公司沒有做的,是單獨以 LFM3-Omni-2B 為主體來發布公告。沒有獨立貼文、沒有發布當天的評測文章、沒有定價頁面,因為沒有託管端點,也沒有獨立基準測試。本文關注的,正是「已宣布」與「已有文件紀錄」之間的落差。

完整卡片

此檢查點是單一的 BF16 建置,具備 2,166,928,384 個參數,模型卡將其四捨五入為 2.17B。它建立在 LFM3-1.7B-Base 主幹上——與家族其他成員相同的三混合骨幹,其中多數層由閘控短卷積承載,全域注意力則僅保留給少數幾層。在此主幹之上,則有視覺編碼器、因果音訊編碼器,以及可將生成符元轉回波形的 LiquidCodec 符元化器。

• 輸入 — 文字、原生解析度的圖片、每秒 2 幀且長度為 4 至 384 幀的影片,以及 16 kHz 音訊。影片輸入可包含其自身的音軌。

• 輸出 — 文字、24 kHz 語音,或於同一回應中同時提供兩者。

• 上下文 — 32,768 個 token,涵蓋輸入與輸出。

• 圖片額度 — 每張圖片最多 2,048 個視覺 token,不論解析度為何。

• 語言 — 卡片列出 16 種文字語言,以及 19 種語音語言或地區設定;儲存庫中繼資料則聲稱有 23 種。這兩個數字在頁面上並不一致。

• 授權 — LFM Open License v1.0,Liquid 自 LFM2 以來一直使用的自訂條款,並非 OSI 授權。

• 推理 — 無。卡片指出不支援思考模式,且無法使用 enable_thinking=True。

其中兩行比其他行更重要。第一項是 32K 上下文,這對 2026 年的多模態模型來說偏小,也是鎖定裝置端目標的直接後果:在手機上,每一個上下文 token 都要耗費記憶體。第二項是授權條款。LFM Open License v1.0 並非 Apache-2.0,其條款帶有營收門檻,決定誰能在無須另行簽署協議的情況下,將權重用於商業用途。如果你正在為某個產品評估這個模型,請先讀授權條款,再讀基準測試結果。

A headless-browser capture of the Hugging Face model card for LiquidAI/LFM3-Omni-2B, showing 83 downloads last month, the sidebar reading 2B params in BF16, a notice that the model is not deployed by any Inference Provider, the architecture diagram, and the specification table listing 2.17B total parameters, text, image, video and 16 kHz audio input, text and 24 kHz speech output, a 32K-token context, a 128,000-token vocabulary, sixteen text languages, nineteen speech languages and the LFM Open License v1.0.

沒有人宣佈的數字

Liquid 的貼文對 LFM3-Omni-2B 提出了一項比較性說法:它在 Daily-Omni、WorldSense 和 AV-SpeakerBench 上勝過參數量最高達 10.7B 的模型,「例如 Qwen2.5-Omni-7B」。該句並未附上分數。模型卡提供了這些分數,而它們是由 Liquid AI 自行測量的——屬於廠商評估,而非獨立評估,而且這是目前唯一存在的評估。

在文章點名的三項基準測試中,模型卡回報 Daily-Omni 70.09、WorldSense 47.10 與 AV-SpeakerBench 46.79。OmniBench 整體為 46.32,語音子集為 48.25。至於口語視覺問答——模型的主打招數,也就是出聲詢問圖片內容——模型卡列出 RealWorldQA 64.68、MMStar 51.79、POPE 83.78、ERQA 39.43 與 EmbSpatial 67.59。音訊項目為英語 ASR 詞錯誤率 6.36、多語言 ASR 6.72、英語語音合成 UTMOSv2 3.80、VoiceBench 64.73,以及音訊理解 MMAR 51.40。為求完整,其純文字視覺分數為 DocVQA 92.47、OCRBench 1,000 分中的 806 分、MMMU 驗證集 42.44 與 MathVista mini 62.50。

整體來看,這些分數描述的是一個樣樣稱職、卻無一項卓越的模型。AV-SpeakerBench 上的 46.79 與 WorldSense 上的 47.10,並不是能登上排行榜榜首的數字;它們表明的是一個 2.2B 模型能在音視覺推理上站得住腳,而不至於崩解。DocVQA 的分數則是反方向的離群值,也是表中最有意思的單一數字——2.2B 全模態模型能拿到 92.47 算高,而這是表中唯一一列,這個 checkpoint 明顯優於 Liquid 自家專門視覺模型所回報的 91.1。

A generated single-column scoreboard titled 'LFM3-Omni-2B — the scoreboard', listing 2.17B dense parameters, inputs of text, image, video and audio, outputs of text and 24 kHz speech, a 32,768-token context, vendor-reported Omni scores of Daily-Omni 70.09, WorldSense 47.10 and AV-SpeakerBench 46.79, and the LFM Open License v1.0, above a footer reading 'All scores self-reported by Liquid AI; no independent evaluation.'

這次外洩消息說對了什麼,以及它唯一說錯的一件事

讓這個模型家族進入公眾視野的 SGLang 拉取請求,對幾乎所有結構性內容的描述都準確。它正確列出了四個檢查點,正確描述了共用的主幹,也正確指出 256 個 token 的滑動視窗是注意力設定,而非上下文上限。它保持謹慎也是對的:該拉取請求尚未合併,三項 CI 檢查失敗,而二十二項 omni 驗證檢查中仍有兩項在與開發檢查點進行 ROUGE 比較時失敗。

它誤導人的地方——也是我們重複它說法的地方——在於輸出模態。它接上的執行時路徑回傳的是文字。那段程式碼裡沒有音訊輸出的分支,而合理的推論是這個系列可能已經捨棄了語音合成,或者第一個執行時版本僅支援文字。實際出貨的模型兩者都能。教訓不是那次洩漏很粗心;而是服務整合描述的是某人實作的路徑,不是其背後檢查點的能力。一個 PR 是關於執行時的證據,而我們卻把它當成關於模型的證據。

還有什麼尚未確認?

三件事,而這三件事正是決定正式環境部署的關鍵。

首先,完全沒有任何形式的獨立評估。上述每一個數字,都是由打造該模型的公司在其自家測試框架上產生的,且未公布方法論。沒有 Artificial Analysis 的收錄項目,沒有 LMArena 的結果,也沒有第三方重現。請把這張基準測試表視為意圖的規格說明,而不是量測結果。

其次,語音服務在廠商自家路徑之外並無文件說明。模型卡表示 SGLang 支援涵蓋文字輸出,卻未說明語音分支如何提供服務。如果你的計畫是「一個模型、口說答案、在我們自己的硬體上」,那麼模型卡並未為這句話的後半段提供任何參考。在撰寫本文時,該儲存庫未列出任何推論供應商。

第三,語言數字彼此不一致。十六種文字語言、十九個語音地區設定、中繼資料裡有二十三種。這大概是同一件事的三種不同定義,但沒有人公布哪一種才是正確的。

為什麼 2.2B 全模態模型是不同的賭注

2026 年打造語音助理的常見做法是管道式流程:ASR 模型將語音轉成文字,語言模型負責思考,視覺模型處理相機影像,TTS 模型則把答案說出來。每個階段都是獨立的檢查點、獨立的延遲預算,以及獨立的故障模式。LFM3-Omni-2B 的賣點在於,這四個部分全都整合進單一 4.3 GB BF16 檔案,能放進手機裡,而且永遠不會離開手機。

那是個真正的架構論證,也正是為什麼基準測試分數不如這東西的整體形態來得重要。由四個小型專用模型組成的管線,通常在個別任務上都會勝過單一通用模型。它做不到的是共享表徵:全模態模型會聽見關於一張圖片的問題的語氣,而答案同時以兩者為條件。這是否會產生更好的答案,正是一直沒有獨立評估測試過的事。

在像這樣的檢查點尚未經過驗證時,實務上的做法是不要把它放在你的關鍵路徑上。OrcaRouter 的 路由 DSL 正是為這種模式而打造——把專家路徑和實驗路徑放在同一個端點後面,讓新模型能依其可靠性比例承接流量,而不是一次全部導入,並在發生錯誤時自動容錯切換。LFM3-Omni-2B 目前不在我們的目錄中,所以這裡沒有任何內容是在聲稱你可以透過我們呼叫它。當這樣的模型真的推出時,那正是它適合的部署形態:可用、可衡量,而且在它證明自身價值之前,不承擔關鍵負載。

看什麼

下一個訊號不是另一張基準測試表,而是 Liquid 之外是否有人發布一張。一個 2.2B 全模態模型若真的能在 Daily-Omni 上維持 70.09,對裝置端工作而言是個值得注意的結果,而獨立重現——即使是部分重現——會比廠商的完整表格更有價值。第二個訊號是 SGLang 合併:當語音路徑在服務堆疊中被記錄下來,模型就不再只是一個儲存庫,而開始成為基礎設施。

在那之前,誠實的總結很有限。LFM3-Omni-2B 確實存在,它比幾乎所有與之競爭的模型都小,接受四種模態輸入、產生兩種輸出,而且是第一個能出聲回答的 Liquid 模型。洩漏消息說它做不到。模型卡說它做得到,而目前模型卡是唯一的見證。

A headless-browser capture of Liquid AI's LFM3 launch post dated October 27, 2026, showing the headline 'Introducing LFM3: Every Modality for Specialized Intelligence', opening paragraphs claiming 22 trillion pre-training tokens and open weights on Hugging Face, and a Highlights box listing six 2B-class models across text, vision, audio, omni and decision, a 256K context window for the text model, and fine-tuning on a single GPU, with no benchmark scores visible.