Liquid AI d1-omni-600M 與 Liquid AI d1-3B：d1 系列中，你真正需要的是哪一半？

Liquid AI d1-omni-600M 與 Liquid AI d1-3B 在 2026 年 10 月 5 日相隔八小時內上傳至 Hugging Face，並在 10 月 7 日同一則公告中一起發布，這使得那個常見問題——哪個較新、哪個較好——成了問錯的問題。它們是同一項刻意取捨的兩端。Liquid AI d1-3B 是完成品：3.12B 參數、在廠商評分的 Decision Index 0.2.1 上得到 48.57、附有基準測試表、延遲量測一路下探到 Jetson Orin Nano，以及在發布文中被描述為其規模下最高決策品質的地位。Liquid AI d1-omni-600M 則是實驗品：587M 參數、在同一指數上得到 15.95、具備 3B 所沒有的音訊輸入，而模型卡直言它是早期研究釋出，沒有推論數據，因為它仍處於積極開發中。在兩者之間做選擇並不是在決定品質高低。它是在決定你需要的是家族底層的額外模態，還是頂端的額外準確度，而數字支持這道分野，而不是模糊它。

以下所有內容皆來自這兩份模型卡與 10 月 7 日的發布文章，並尊重發布文章本身的標示：Decision Index 上的 d1 列是由 Liquid AI 以官方評分器評分，而非提交至公開排行榜；此處沒有任何內容經過獨立重現。

兩條注定不會匯聚的骨幹

d1 系列並非將單一配方縮小而成。這兩個檢查點分別從 Liquid 模型目錄的兩端出發，並在中間會合。

Liquid AI d1-3B是建構在 LFM2.5-VL-3B 之上，這是該廠商於 2026 年 8 月推出的僅解碼器視覺語言模型。它的基礎是將 LFM2.5-2.6B 的權重與 LFM2.5-VL-3B 的文字主幹平均，然後在不同隨機種子與資料混合下微調檢查點，再將它們合併。它搭載 SigLIP2 NaFlex 形狀最佳化的 400M 視覺編碼器、32,768 個詞元的上下文、128,000 個詞元的詞彙表，以及十六種有文件記載的語言。

Liquid AI d1-omni-600M則是從另一個方向而來。它的主幹是 LFM2.5-Encoder-350M，一個雙向編碼器，先針對決策任務進行微調，再分階段擴充——一個 17 層的 FastConformer 編碼器加上音訊適配器，之後音訊編碼器再對照凍結的文字骨幹進行微調，接著從 LFM2.5-VL-450M 取來 SigLIP2 塔，加上一個適配器，並對骨幹進行 LoRA 更新以支援視覺。最終模型由 LoRA 更新合併而成，並與先前的檢查點取平均。它總計有 587M 個參數：381M 的共享主幹與決策頭、94M 的視覺編碼器，以及 112M 的音訊編碼器。

僅解碼器與雙向的差異，是必須牢牢記住的一點。3B 讀取狀態並產生決策，就像語言模型一次一個方向地產生詞元序列。600M 則一次讀取整個狀態並做出決定，這正是你對一個從未被打造來生成的編碼器所會預期的表現。兩者都被訓練成以零輸出詞元回報模型分布中的答案，但底層機制並非同一類模型，而下方顯示的準確率差距，就是這個較小、編碼器形狀設計的可見代價。

Decision Index 的差距很大，而且子分數比總分更有趣。

在 Decision Index 0.2.1 上，Liquid 回報 Liquid AI d1-3B 為 48.57，Liquid AI d1-omni-600M 為 15.95，相較於 Winnow-12B 的 50.02。這是同一個實驗室在同一天發布的兩個檢查點之間 32 分的差距，而閱讀五個子分數便能解釋這個差距從何而來。

• 知識 — Liquid AI d1-3B 為 23.8，Liquid AI d1-omni-600M 則為 8.3

• 語言 — 56.4 對 12.9

• 檢索 — 52.8 對比 35.0

• 工具 — 74.5 對 15.1

• 藝術 — 36.3 對 6.8

檢索是這個小模型唯一站得住腳的地方，它在這裡的落差不到 3B 分數的三分之一，而在其他四個類別中則會失去 60% 到 80%。這種模式與 600M 的本質相符：一個受過訓練的編碼器，具備真正的表徵能力，能將狀態與內容匹配，而 3B 從一個在遠更多語言上預訓練的解碼器繼承來的分層能力則少得多。如果你的工作負載是檢索型決策——這段文字是否回答了這個問題、這些文件中哪些相關——那麼 600M 的表現輪廓就沒有它的總分看起來那麼糟。如果你的工作負載是工具路由決策，那麼該欄中 51 分的差距就是你要緊盯的數字。

文字基準測試表比指數講述了一個更溫和的故事，這在任一個數字被用來立論之前值得了解。在七個公開基準測試中，3B 以平均 82.9 領先，而 600M 達到 78.4。600M 實際上在 SQuAD 2.0 上以些微差距落後（74.0 對 85.3）、在 PubMedQA 上（61.3 對 66.0）、在 BoolQ 上（77.7 對 86.7）以及在 XNLI 上（74.7 對 85.0），但它在 Civil Comments 毒性偵測（95.8 對 93.0）和 PAWS-X 釋義識別（79.5 對 76.9）上勝出。Liquid 自己的說法是，600M 以四分之一的參數擊敗了 Decider 2B 的 77.1 平均值。兩套基準測試套件，兩種不同的表面結論，兩者皆由廠商報告——這就是證據所支持的全部，不多也不少。

600M 有什麼是 3B 沒有的

容忍 32 點指數差距的原因在於，Liquid AI d1-omni-600M 能做到一件 Liquid AI d1-3B 做不到的事，而這並非保真度差異。

• 音訊 — Liquid AI d1-omni-600M 透過其 FastConformer 編碼器，每筆請求最多可處理 30 秒的語音；Liquid AI d1-3B 則不接受任何音訊

• 模態混合 — 600M 接受文字搭配圖像或文字搭配音訊，若兩者同時傳入會引發 ValueError；3B 則接受文字與圖像

• 上下文視窗 — 600M 在文字、圖像與音訊位置上共 16,384 個詞元，當有圖像時文字會縮減至 896 個詞元；3B 則為 32,768 個詞元

• 詞彙量 — 600M 為 65,536，3B 為 128,000

• 精度 — 600M 模型卡建議在 GPU 上使用 float16，並警告 bfloat16 會在某些資料列上改變最佳答案；3B 提供 15 種量化，包括 w8a8

• 語言——600M 列出 16 種語言，與 3B 的 16 種是不同的組合，而且其音訊被描述為是根據英語使用者與助理之間的交流訓練而成，而這只是正式音訊來源所含內容的一小部分

音訊訓練備註很容易被略過，但不該如此。一個以英語講者與助理互動訓練出的模型，只看過一種講者幾何、一種輪次結構，以及一種口音分佈。把它部署到客服中心音訊或實地錄音上，等於要求它展現模型卡未宣稱的行為；而發布文章也坦承，目前沒有可用來對照檢查它的音訊決策基準——Liquid 稱之為「目前的一個開放問題」，並邀請社群打造一個。

延遲：其中一個手足有那些表格，另一個則有註腳。

對決策模型而言，值得關注的數字是端到端延遲，因為沒有解碼需要計時。Liquid 為 3B 發布了完整的數據集，而 600M 則完全沒有。

• 一個問題 —— 在 RTX 4090 上為 8 ms，在 MI325X 上為 9 ms，在 Jetson AGX Thor 上為 16 ms，在 Jetson AGX Orin 64 GB 上為 26 ms，在 Orin Nano 上為 50 ms，在 Apple M5 Pro 上為 30 ms

• 在同一個狀態上提出三個問題——在 RTX 4090 上為 21 毫秒，在 AGX Thor 上為 20 毫秒，成本大約是單一問題的 1.3 倍，而非 3 倍

• 一個 3.4K token 的狀態 — 在 4090 上為 102 ms，在 Thor 上為 220 ms，在 Orin Nano 上為 1,640 ms

• 密集吞吐量 — RTX 4090 上每秒 475 次決策，MI325X 上每秒 1,106 次

• 一張 384px 的圖片——在 4090 上耗時 17 毫秒，在 MI325X 上耗時 18 毫秒

那些數字僅描述 Liquid AI d1-3B。就 Liquid AI d1-omni-600M 而言，模型卡指出並未報告推論數據，因為該模型是仍在積極開發中的早期研究版本。這並不是說小型模型比較慢——幾乎可以肯定恰恰相反，因為在相同精度下，參數只有五分之一並不會變慢——而是根本沒有這樣的數字存在，而把 3B 的毫秒數拿來套用在 600M 上，會是一種看似合理的捏造。在不憑空杜撰任何東西的前提下，可以這麼說：在模型卡建議的 float16 精度下，587M 參數在尚未計入激活值（activations）之前，權重大約是 1.2 GB 等級；這是根據已公布的參數數量所做的算術，而非實測結果。

對大多數工作負載來說，串接才是真正的答案。

因為兩個檢查點是一起發布的，而且會傳回相同類型的物件——機率、帶有信賴度的標籤，或排序分數——所以它們的組合方式，是兩個任意模型所做不到的。600M 可以負責篩選，3B 可以負責裁決。用 Liquid AI d1-omni-600M 對進來的項目評分，並將它評在尺度中間附近的項目，升級給 Liquid AI d1-3B 做更精準的判斷。升級規則就是 600M 已經傳回的信賴度與分佈，因此路由邏輯不需要額外的模型。在絕大多數項目都很簡單的工作負載上，大多數流量永遠不會到達 3B，而大多數成本也永遠不會花費。

這種模式也正是這兩個模型值得放在路由器後方運行的原因。透過 OrcaRouter，兩者都會置於同一組 API 金鑰之下，並按各家供應商的定價原樣轉嫁、零加價計費，因此這種串接就只是一條路由規則，而不是另一套整合方案；此外，在供應商層級失敗的升級請求會改在備援上重試，而不會讓整個請求失敗。自動容錯在這裡比對一個成熟穩定的模型更為重要，因為這對組合中有一半是檢查點，而供應商自己也將其行為描述為仍在積極開發中。

這些都不是在聲稱可用性，而這個區別值得明確指出：開放的 d1 檢查點並不在我們的目錄中。廠商提供的途徑是下載權重並在本機執行——llama.cpp 支援在首日就涵蓋 Apple、AMD、Qualcomm 與 NVIDIA 硬體——或是透過廠商自家的 API 及第三方平台來取用它們。

一次完成選擇

如果你需要文字與圖像，而且答案必須正確無誤，就選 Liquid AI d1-3B。它具備基準測試、延遲表、更寬廣的上下文、更大的詞彙量與各種量化，而且是 Liquid 將其定位為同尺寸品質領先者的那對組合中的一員。

如果你需要在決策路徑中用到語音，就選 Liquid AI d1-omni-600M，因為在這一系列中，它是唯一一個接受音訊的開放權重選項；同時也要接受一個事實：你之所以採用它，靠的是直覺和一個 demo，直到有人發布音訊決策基準，或是那份被保留的視覺切分資料。

如果你還不知道上述哪一種情況描述的是你的工作負載，就先從 3B 開始，並量測它回傳的信心值。子分數就是關鍵線索：落在 Tools 或 Language 欄位的任務，交給 600M 會表現得很糟；而檢索形態的任務，則是小型檢查點比其總分所暗示的更接近的唯一情況。這個系列的存在，是為了讓你以準確度換取占用空間，而唯有你知道自己的任務落在哪個欄位，這樣的取捨才安全。

透過 OrcaRouter，兩個模型都位於同一組 API 金鑰之後，採用路由規則而非第二個整合；而升級若在供應商層失敗，會改由備援重試，而不是讓請求失敗。