LFM3-Omni-2B 對比 LFM2.5-VL-3B：看得更少的後繼者

Liquid AI 最新的多模態模型在視覺表現上比它所取代的模型還差。在 RealWorldQA 上，LFM3-Omni-2B 得分 66.68，而 LFM2.5-VL-3B 得分 73.1。在 MMStar 上則是 55.67 對上 63.3。在 RefCOCO 指稱表達指向任務上則是 73.55 對上 87.9。在 MMBench 上，73.68 對上 81.0。兩個模型皆有回報的五項基準中，有四項偏向較舊、較大、僅具視覺能力的檢查點，而且差距並非雜訊——依列別不同，差距介於 7 到 14 分之間。 在兩個模型之間進行路由不應增加平台費用。0% 加價 供應商標價原樣傳遞。

那不是什麼醜聞。這是當你要求較小的網路同時承擔更多工作時會發生的情況，而對任何要在這兩個檢查點之間做決定的人來說，這是最有用的一項事實。LFM3-Omni-2B 並不是視覺產品的升級途徑。它是一個恰好共用同一個家族名稱的不同產品。

兩個模型各自負責不同的工作

這種混淆是可以理解的，因為這兩個模型看起來像是同一個構想的連續世代。兩者都來自 Liquid AI，都是為裝置端部署而打造，都是非推理型，也都沿用 LFM Open License v1.0，而且兩者鎖定的記憶體預算大致相同。LFM2.5-VL-3B 於 2026 年 8 月 12 日推出，是一款視覺語言專用模型：由 2.6B 的文字主幹搭配 400M 的 SigLIP2 NaFlex 編碼器，總參數量約 3.1B。

LFM3-Omni-2B 於 2026 年 10 月 27 日發布，是一款可處理任意模態輸入與輸出的模型。它可接收文字、圖像、含或不含音軌的影片，以及 16 kHz 音訊，並輸出文字、24 kHz 語音，或兩者兼具。視覺只是四條輸入路徑之一，而非整體任務。參數預算從 3.1B 降至 2.17B，而任務數量從一項增至四項；視覺分數正是這筆算術展現的地方。

• 參數 — LFM3-Omni-2B 為 2.17B 稠密參數，相較之下 LFM2.5-VL-3B 約為 3.1B，其中 400M 為視覺編碼器。

• 輸入 — 文字、圖像、影片及 16 kHz 音訊，對比文字、圖像及影片。

• 輸出 — 文字與 24 kHz 語音，對比僅文字。

• 上下文 — 32,768 個 token 對 32,768 個 token。完全相同，且兩者都計入輸入加輸出。

• 視覺預算 — 每張圖片 2,048 個視覺 token，原生解析度對比原生解析度 512 像素區塊，並搭配縮圖路徑。

• 定位 — 作為四模型管線的全能替代方案，與專用於 OCR、UI 理解及視覺問答的 VLM 相比。

• 授權 — 兩種情況皆為 LFM Open License v1.0，包括規範商業使用的營收門檻。

數字真正重疊的地方

來自不同實驗室的模型之間的基準測試比較通常並不誠實，因為評測框架各不相同。這個比較比大多數都更乾淨：兩個檢查點都是由同一家公司、在同一種非推理模式下評估的，而且兩者都報告了五個相同的資料集。這並不使這些數字彼此獨立——它們並不獨立——但這確實使它們能以跨實驗室表格很少能做到的方式相互比較。

• RealWorldQA — LFM3-Omni-2B 為 66.68，LFM2.5-VL-3B 為 73.1。在日常場景問題上下降了 6.4 個百分點。

• MMStar — 55.67 對 63.3。在一個旨在抵抗資料汙染的基準測試上下降了 7.6 分。

• MMBench — 73.68 對比 81.0。在廣泛多模態能力上下降 7.3 分。

• RefCOCO 指向 —— 73.55 對 87.9。下降了 14.4 個百分點，是整組中差距最大的，出現在在圖像中定位指定物件的任務上。

• DocVQA — 92.47 對 91.1。例外：LFM3-Omni-2B 在文件問答上領先 1.4 分。

DocVQA 的結果正是讓這件事不至於變成單純「新模型更差」故事的那個關鍵。文件文字是這樣一項任務：統一模型以高解析度讀取頁面，並在一次處理中對其進行推理的能力，可能勝過管線式流程；而它也正是 Liquid 每張影像 2,048 個 token 上限最應該造成傷害的任務。omni 模型在那裡仍然勝出，這表明視覺能力退化並非在各類任務中均勻發生。它集中在空間與指涉任務上，而這正是你會預期專用視覺能力較少的模型苦苦掙扎的地方。

額外模態的成本是多少

音訊路徑並非免費，而這張卡異常清楚地說明了成本落在何處。32K 上下文在所有模態間共用：以每秒 2 幀、共 384 幀的影片，會在你還沒提出問題之前就吃掉視窗的大部分。每張圖片上限為 2,048 個視覺 token，這大致上是在照片中閱讀密集文字的解析度上限。純視覺模型有相同的 32K 上下文，但不必把其中任何一部分花在音訊上。

語音輸出帶來第二個考量，這與基準測試無關。LiquidCodec 能將生成的 token 轉換為 24 kHz 音訊，速度比即時更快，這正是串流語音回覆得以實現的原因。但模型卡只記載了針對文字輸出的 SGLang 服務，並未說明語音分支如何提供服務。若你需要由自家基礎架構提供語音回答，模型那一半的參考實作是缺失的。相較之下，LFM2.5-VL-3B 背後有一年的工具鏈支援——GGUF、MLX、vLLM、SGLang、ONNX，並有報告指出在 M5 Max 上以低於 3.3 GB 的記憶體達到每秒 228 個 token。

成熟度不是基準表上的一列，但它決定部署。今天就能到處跑的模型，勝過明天只能跑單一路徑的模型——除非那額外的模態正是你選擇它的理由。

如何選擇

如果任務是讀取螢幕截圖、解析文件、指向物件，或回答關於攝影機影像串流的問題，LFM2.5-VL-3B 就是更好的模型，而且在關鍵項目上的差距並不小。尤其是 RefCOCO 上 14 點的差距，應該足以終結任何機器人或 UI 自動化用例的討論。當替代方案是一個 2.17B 模型、把三分之一容量花在耳朵和嘴巴上時，擁有 3.1B 參數並不吃虧。

如果工作內容涉及人對裝置說話、裝置也回話——自助服務機、手機助理、雙手忙碌時使用的現場工具——LFM3-Omni-2B 能做到 LFM2.5-VL-3B 無論參數規模多大都做不到的事。你並不是在選擇一個較差的視覺模型；你是在選擇把四個模型整合成一個，並接受視覺能力退化作為這種整合的代價。

基準測試表還明顯指出第三個選項：兩者都用。由視覺專家模型處理影格，由全模態模型處理對話。這需要兩個檢查點，BF16 下約 7.4 GB，仍在一張中階 GPU 的記憶體容量之內。OrcaRouter 的 路由 DSL 正是為這種組合而存在——單一端點，以規則將圖像加文字的請求送往專家模型，並將語音請求送往全模態模型；任一路徑失敗時都會自動容錯切換。目前我們的型錄上沒有這兩個檢查點，所以這是一種模式而非承諾；重點是，「該用哪個模型」這個問題有第三個答案，而兩家廠商的發布文章都沒提到。

裁決

LFM3-Omni-2B 在 2.17B 參數下是一項真正的工程成就，但對於任何以視覺為主的應用來說，都是 LFM2.5-VL-3B 的糟糕替代品。誠實解讀這對模型的方式，是把它們視為 Liquid 自家產品線的一個分叉：一個分支針對「看見」進行最佳化，另一個分支則針對「參與對話」進行最佳化。家族名稱與共用授權讓它們看起來像是一個系列。基準測試表則說它們是兄弟，而年長的兄弟更擅長它當初被打造來做的事。

能改變這項評估的會是獨立評測，因為上述整套比較都建立在 Liquid 針對自家兩個模型所產出的數字上。有可能 omni 模型是在這些資料集的較難變體上受測，或是在對它不利的模式下受測。模型卡中沒有任何內容暗示如此，而且五列中有四列方向一致，也不支持這種說法。在外部人士重現任一張表之前，最安全也最簡單的解讀是：專用模型看得更準，而 omni 模型聽得更準。