Liquid AI d1-omni-600M 對比 LFM2.5-VL-3B：一個負責決策，一個負責描述

Liquid AI d1-omni-600M 與 LFM2.5-VL-3B 都很小，都是多模態，也都由同一個實驗室以相同的 lfm1.0 授權發佈在 Hugging Face 上——而將它們配成一對是個範疇錯誤，結果卻證明這個錯誤很有用。LFM2.5-VL-3B 於 2026 年 8 月 12 日推出，是 Liquid AI 的邊緣視覺語言模型：3.1B 參數、32,768 個 token 的視窗，而輸出是自然語言文字。交給它一頁掃描頁面，它會以文字回傳帶有版面的轉錄內容。Liquid AI d1-omni-600M 於 2026 年 10 月 7 日與其餘開放的 d1 系列一起上傳，對相同輸入做的是相反的事。它是一個 587M 參數的決策模型：你把具名問題附加到某個狀態上，它就會報告自己已經相信的結果——P(yes)、帶有信賴度的選定標籤、在二到十的有序量表上的位置——而且在單次前向傳遞中完成，零輸出 token，下游沒有任何東西需要解析。如果你搜尋的是「那個小型多模態 Liquid 模型」，現在你面前有兩種形態，而形態就是決策。

這一頁呈現的，是兩份模型卡、10 月 7 日的發布貼文，以及這些儲存庫本身實際確立的內容。它也明確說明了它們止步於何處。這份內容中沒有任何部分是在 Liquid AI 內部重現的；而這兩個模型當中，有一個模型的供應商完全沒有發布任何專門針對其自身主打能力的準確度基準。

這兩個檢查點，並排

規格表幾乎在每個面向上都分歧，而這正是兩款從未打算競爭同一位置的機型會令人預期的情況。

• 這是什麼 — LFM2.5-VL-3B 是一款會撰寫文字的生成式視覺語言模型；Liquid AI d1-omni-600M 則是會回傳結構化答案、且不輸出任何 token 的決策模型

• 參數量 — LFM2.5-VL-3B 在 BF16 下為 3.1B，相較之下 Liquid AI d1-omni-600M 為 587M，其本身由 381M 的共享主幹與決策頭，加上 94M 的視覺編碼器與 112M 的音訊編碼器所組成

• 主幹 — LFM2.5-VL-3B 將 LFM2.5-2.6B 語言模型與 SigLIP2 NaFlex 形狀最佳化的 400M 視覺編碼器搭配在一起；Liquid AI d1-omni-600M 則以 LFM2.5-Encoder-350M 這個雙向編碼器為基礎訓練而成，並採用取自 LFM2.5-VL-450M 的 SigLIP2 塔，以及用於音訊的 17 層 FastConformer

• 輸入 — LFM2.5-VL-3B 的文字與圖片；文字加上圖片或文字加上最多 30 秒的語音，供 Liquid AI d1-omni-600M 使用，若圖片與音訊在同一個請求中出現，會引發 ValueError

• 上下文 — LFM2.5-VL-3B 為 32,768 個 token，相較於 Liquid AI d1-omni-600M 的文字、圖像與音訊合併後共 16,384 個位置；其模型卡補充指出，在有圖像的情況下，狀態與問題文字會被裁剪至 896 個 token，以符合訓練設定。

• 詞彙量 — LFM2.5-VL-3B 為 128,000 個詞元，Liquid AI d1-omni-600M 則為 65,536 個

• 執行環境——LFM2.5-VL-3B 可在 transformers 與 vLLM 中執行，並有一個獨立的 DSpark 草稿模型用於推測解碼；Liquid AI d1-omni-600M 隨附自訂程式碼，需要 trust_remote_code=True，而其模型卡建議在 GPU 上使用 float16，同時警告 bfloat16 會改變某些列的最高答案

• 授權條款 — 兩者皆為 lfm1.0，允許微調與部署

那份清單中有一行發揮的作用比其他行都大。Liquid AI d1-omni-600M 是建立在雙向編碼器之上，而非解碼器。那不是 LFM2.5-VL-3B 的規模縮減；它有著不同的血統，而這正是無論怎麼解讀基準測試表，這兩個模型都無法彼此互換的架構層面原因。

輸出合約比基準測試更具決定性。

向 LFM2.5-VL-3B 詢問關於影像的問題，你會得到語言形式的回答。當答案必須由人閱讀、以字串記錄，或餵給期望散文的步驟時，這就有經濟價值。這同時也是你必須在工程上設法處理的隱患：生成的輸出可能漫無邊際，要求 JSON 格式的請求可能回傳與你要求不同的格式，而且每個 token 都要計費、都要等待。這個模型的明確定位是單輪、高吞吐量、低延遲的視覺工作——掃描文件的批次 OCR、車輛中的即時偵測、標誌的裝置端翻譯——並明確被引導避開長上下文、需要大量推理的問題，例如「這張藍圖有什麼問題」。

L1-omni-600M 針對一個嚴格更狹窄的問題，在一個嚴格更可靠的範圍內給出答案。其介面是一個狀態——文字、JSON、一或多張圖片，或最多 30 秒的語音——再加上一組具名問題，每個問題各自宣告其類型。一個 noul 問題是是/否題，並以 0 到 1 之間的 P(yes) 回傳。一個 choice 問題會從你指定的一組標籤中選出一個標籤，並回傳該標籤、一個信心值，以及每個選項的機率。一個 score 問題會把該狀態放在二到十個層級的有序尺度上，並回傳期望層級及其分布。多個問題可以掛在同一個狀態上，並在一次傳遞中讀取，因此模型卡的用量計數器會回報 output_tokens: 0。沒有生成步驟，這意味著不存在無法解析的輸出這種事。

你放棄的是生成式答案所承載、而它者所不具備的一切：推理過程、模糊保留的措辭、能直接貼進工單的語句，以及在同一次對話中追問的能力。Liquid 說得很明白——這個模型不是聊天模型，也不會撰寫文字。如果你的管線需要在判定結果旁附上解釋，Liquid AI d1-omni-600M 就是這對組合中錯誤的那一半，而誠實的答案是兩者都跑：LFM2.5-VL-3B 負責產生對它的解讀，Liquid AI d1-omni-600M 負責產生關於它的決策。

沒有直接比較的視力數值，而這就是這項發現。

直覺上的下一步，就是把視覺基準測試一字排開。你辦不到。在 LFM2.5-VL-3B 上，廠商公布了一整套——RefCOCO Macro Precision@1 為 87.9、ScreenSpot-v2 為 80.7、ChartQA 為 81.3、POPE 為 88.7、MMStar 為 63.3、BLINK 為 61.5、MuirBench 為 58.3、ToolSandBox 為 59.5、OCRBench v2 English 為 47.5，以及 RealWorldQA 的 73.1，略勝前一版 LFM2-VL-3B 的 71.1。這些全都是廠商自行回報的，沒有任何一項經過獨立重新執行；儘管如此，它們仍是針對特定能力的具體宣稱，讀者可以拿來要求該實驗室負責。

對於 Liquid AI d1-omni-600M，發布文章表示 Decision Index v0.3 包含一個未公開的視覺拆分，「我們不會在本次發布中報告」，而 Liquid 改為驗證 600M 檢查點「能處理全部三種模態」，並將證據放在 playground 示範中。這就是已公布的視覺紀錄的全部。無論是在其模型卡還是發布文章中，都沒有這個檢查點的影像基準測試數值。同一篇文章更直接地證實了音訊方面缺少什麼：專用的音訊決策基準測試，用廠商自己的話來說，「目前是一個未解決的問題」。

所以這場對決的解讀是不對稱的，而且應該如此明說。LFM2.5-VL-3B 已展現出有數據佐證的視覺能力。Liquid AI d1-omni-600M 則有一個借自同系列模型的視覺編碼器、一個在凍結主幹下訓練的適配器、一個展示，以及一個承諾。如果你的部署需要模型在這個月就能正確判斷影像，那麼 3B 是兩者中唯一有立足依據的那一個。

速度：其中只有一項已被測量

因為決策模型不會生成任何內容，延遲才是真正重要的數字，而且同樣地，只有單方面的資料有被記錄下來。LFM2.5-VL-3B 在 Apple M5 Max 上標稱每秒 228 個 token，在 AMD Ryzen AI Max+ 395 上為每秒 116 個 token，兩者都在 3.3 GB 記憶體以內；在 Galaxy S26 Ultra 上約為每秒 20 個 token，而在 vLLM 下單張 H100 上約為每秒 11,000 個 token。這些數字描述的是解碼吞吐量，對一個會產出文字的模型來說，這才是正確的衡量方式。

對於 Liquid AI d1-omni-600M，模型卡指出未公布推論數據，因為該模型是早期研究版本，且仍在積極開發中。同一家族中的 d1-3B 則確實有延遲表格——在 RTX 4090 上回答一個問題為 8 毫秒，在 Jetson AGX Thor 上為 16 毫秒，在 Jetson AGX Orin 64 GB 上為 26 毫秒，在 Orin Nano 上為 50 毫秒；而在同一個狀態下詢問三個問題，所需時間約為一個問題的 1.3 倍。那些數據屬於 3B 決策模型，不應直接套用到 600M。對於 Liquid AI d1-omni-600M，誠實的說法是：其架構意味著這是個小巧、快速的模型，而實驗室之外尚未有人發表任何毫秒級數據。

權重佔用量至少可以估算。在模型卡建議的 float16 精度下，587M 個參數大約是 1.2 GB 的權重（尚未計入活化值）——這是根據已公開參數數量所做的算術推算，而非廠商實測——相較之下，Liquid 回報 LFM2.5-VL-3B 低於 3.3 GB。在一個以 MB 為限制條件的裝置上，這樣的差距就是支持 600M 的理由。

如何在它們之間做選擇

一旦將輸出契約視為固定而非可協商，這個選擇便能乾淨俐落地解決。

選擇LFM2.5-VL-3B，當交付成果是文字時：帶有版面註釋的全頁 OCR、從自然語言查詢進行定位與偵測、在...上的標牌翻譯，以及任何人類或下游語言模型使用答案的步驟。它還具有 32,768 個權杖的更大上下文，以及實際上更深入的語言涵蓋範圍，因為它的答案是語言，而不是標籤。

當交付成果是一項決策時，就該選用 Liquid AI d1-omni-600M：分派工單、初步篩檢畫面、審核影片片段、為護欄把關、以二到十分的量表為回覆評分——而且在這一對之中，唯有它在輸入為語音時也能派上用場。它是這兩者中唯一能接收音訊的模型，每次請求最多 30 秒，不過其模型卡註明，該音訊是以英語使用者與助理之間的往來對話訓練而成，而這對於你的呼叫所將來自的世界而言，是一種狹隘的描述。

兩者都別選，改用通用視覺語言模型——如果任務需要的是對圖像進行推理，而不是對它進行解讀或下判斷。這兩款模型都與該使用情境相去甚遠，而 Liquid AI d1-omni-600M 也沒有任何機制可以嘗試。

試用一個實驗性檢查點，但不把整條管線押在它身上

Liquid AI d1-omni-600M 依廠商自身的標示，屬於早期研究版本，其視覺與音訊行為尚未經過基準測試。這正是那種你會想在備援機制後面、而不是在客戶面前評估的模型類型。OrcaRouter 透過單一 API 金鑰即可路由 200 多個模型，跨供應商自動容錯移轉，這是把這類檢查點放上實際運作路徑的省錢做法：若實驗性路由效能下降或供應商服務中斷，請求會落到備援上，完全不需修改程式碼。同一把金鑰可承載管線交接的每一個模型，並以各供應商的定價原價轉嫁、零加成，因此廠商降價當天就是你的價格。

有一點必須先說明，因為這點至關重要：開放式 d1 模型與 LFM2.5-VL 系列目前並不在我們的目錄中。自行託管權重是供應商對兩者建議的途徑，並在 Apple、AMD、Qualcomm 與 NVIDIA 硬體上提供首日 llama.cpp 支援，而在託管端點上執行它們則意味著使用供應商自家的 API 或第三方平台。將本頁解讀為供應情況的聲明會是個錯誤。

看什麼

有趣的問題不是 600M 最終是否會在任何事情上勝過 3B——它不會，而且它本來就不是為了這個而打造。而是 Liquid AI 是否會公開它扣住不發的私有視覺分割資料，以及是否有人會打造該實驗室說目前還不存在的音訊決策基準。在這些事情之一實現之前，Liquid AI d1-omni-600M 與 LFM2.5-VL-3B 之間的比較，就是一場已受測模型與看似合理模型之間的比較。對於尚未被量測的工作——語音輸入、判定輸出，小到足以放在裝置上——600M 是這個系列中唯一嘗試它的開放權重檢查點，而在沒有計分板的情況下成為第一，仍然是第一。

OrcaRouter 透過一組 API 金鑰即可路由 200+ 個模型，並以 0% 加成直接反映各供應商的定價，因此供應商一降價，你的價格當天就會同步調降。