d1-2B 對比 Liquid AI d1-omni-600M：當決定性輸入是聲音時

把一則語音備註和一張拍下來的發票放到這兩個模型面前，只有其中一個能回答，而且不是分數較高的那一個。d1-2B可讀取文字、JSON、圖片和影片，完全無法接受音訊。Liquid AI d1-omni-600M可讀取文字搭配圖片，或文字搭配最長 30 秒的語音，但無法在同一個請求中同時接受音訊和圖片。光是這項不對稱，在多數實際部署中就已決定結果，甚至還不必參考任何基準測試。不過，以下仍是忠實版本的比較：587M 模型真正具競爭力之處、1.92B 模型還遠遠無法被取代之處，以及唯一一種同時使用兩者、卻不假裝它們是替代方案的管線模式。

這項決定屬於模式（modality）的問題，而非分數的問題。

決策模型接收一個狀態與一組具名問題，並回傳每個答案的機率，不會生成任何 token。狀態就是完整的輸入，而狀態的 type 是具約束力的限制條件。d1-2B 的卡片列出文字、JSON、圖片與影片。Liquid AI d1-omni-600M 的卡片列出文字搭配圖片，或文字搭配音訊——而程式碼會強制執行這項互斥規則：同時將圖片與音訊片段傳給 system_one 會引發 ValueError。

所以第一個問題不是哪個模型得分更高，而是你需要判斷的東西是以像素、文字，還是波形的形式出現。如果它以波形形式出現，那麼在這對模型中只有一個答案，而本頁其餘內容要談的是，為了得到它，你得犧牲多少準確度。

5.87 億實際上能買到什麼

600M 並不是 d1-2B 的小型版本。它是不同的建構方式，而這份預算值得逐項檢視，因為它說明了其優勢與上限。

• 參數 — 總計 587M：381M 的共享主幹與決策頭、94M 的視覺編碼器，以及 112M 的音訊編碼器。每種模態都透過相同的主幹權重運行。

• Base — LFM2.5-Encoder-350M，一個雙向編碼器，配備從 LFM2.5-VL-450M 借用的 SigLIP2 視覺塔，以及用於音訊的 17 層 FastConformer。

• 上下文 — 文字、圖像與音訊位置合計共 16,384 個 token，以及 65,536 個 token 的詞彙表。d1-2B 的視窗為 128K。

• 音訊 — 每個請求最多 30 秒的 16 kHz 單聲道語音。模型卡明確指出，音訊部分是針對英文使用者與助理之間的請求進行訓練，而對於一個人們會用來處理通話錄音的模型而言，這樣的分布範圍相當狹窄。

• 媒體規則 — 圖片或音訊，絕不可同時使用。此卡片記錄了 ValueError，而非讓你自行發現它。

• 授權— LFM Open License v1.0，與 d1-2B 相同的門檻結構：年營收低於 10,000,000 美元可商業使用。

• 速度 — 未公布。此模型卡未提供任何延遲數據，並稱該模型為仍在積極開發中的早期研究版本。d1-2B 公布在 H100 PCIe 上為 5.7 毫秒、在 MI325X 上為 3.8 毫秒，以及在 M5 Pro 上為 18.6 毫秒。

同一次執行產生的表格，以及差距很小的列

兩個模型都出現在 d1-2B 卡片上的基準測試表中，該表以相同的評分器，針對相同題目為四個開源 d1 模型評分。這讓此項比較比大多數跨卡片比較更為乾淨，但有一點需注意：d1-omni-600M 自己的卡片在 Decision Index 0.2.1 上回報 15.95，而此表則在 0.3 版上回報 18.3。差異在於指標版本，而兩個數字對各自的測試而言都是正確的。

• Decision Index 公開評測套件 v0.3 — d1-2B 為 51.1，Liquid AI d1-omni-600M 則為 18.3。

• DecisionBench (Hanno Labs) v1 — 77.1 對 58.7。

• Decision Bench (decisionbench.ai) v4 — 85.2 對 57.9。

• ImajevBench v2.0-lite— 75.5 對 21.7，是兩者在決策端最大的差距。

• WorkflowEvals — 81.6 對 48.8。

• Vision 平均，18 項基準測試 — 70.2 對 42.8。

• VisualWebBench — 96.2 對 14.9，這與其說是比較，不如說是在說明一個 94M 視覺編碼器能承載多少。

接著是主張克制的那些列。Typed Decisions 是 61.3 對 57.5——對一個參數量只有三分之一的模型來說，是 3.8 分的差距。POPE，這個物件幻覺基準，是 88.7 對 82.7。JevBench 是 77.9 對 58.0，差距很大，但 DecisionBench v4 是 85.2 對 57.9，而兩者合起來說明 600M 表現不均，而非全面偏弱。Liquid AI 自家的發布貼文把其七項基準的平均值列為 78.4，對 587M 來說算高；d1-2B 的模型卡沒有公布對應的平均值，因此這兩個數字不應並列比較。

唯一不偏袒任一模型的數字，是獨立得出的那個數字。Efraín Garay 在 Decision Index 0.3 的 6,000 筆請求樣本上跑了 Liquid AI d1-omni-600M，得到 14.0，而廠商自己在同一個樣本上的結果是 14.17——高度重現。他也發現有 1,758 筆請求超出模型的指令與選項預算而被拒絕，並被計為錯誤；這是在一個為更長狀態設計的套件上使用 16K 視窗的真實代價。

在 600M 是唯一選項的情況下

音訊路由正是這個模型當初所針對的情境，而卡片上的範例很具體：通話與語音訊息路由、聲音事件，以及在書面狀態之上給出的口語指示。d1-2B 完全無法以任何準確度提供上述任何一項，因為它沒有音訊編碼器，輸入結構中也沒有音訊位置。

兩個獨立的資料點應該讓這番推銷降降溫。第一個是上述評估：600M 在真實資料任務上的射擊偵測 AUC 為 0.580、降雨預報 AUC 為 0.593——僅略高於隨機猜測，且落後於所有受測的較大型模型。第二個是一篇實測評論，其測得使用中的 VRAM 低於 2GB，並發現該模型對音訊中的表達方式和語氣進行分類，遠比對語意內容可靠，而推論型問題的表現則接近擲硬幣。兩者都指向同一結論：這是一個篩選模型。它擅長回答「這是哪一類東西」，但不能取代能理解所說內容的模型。

這不是在批評 587M 的檢查點。這就是 587M 在其中有 381M 是共享主幹時所能換來的東西。使用它的理由是成本與佔用空間——低於 2GB 的 VRAM、自 10 月 6 日起提供的 GGUF 儲存庫、自 10 月 12 日起提供的 MLX 建置，以及一次前向傳遞就能做出決策——而不是保真度。

同時使用兩者的級聯

錯誤在於把這些當成競爭對手。它們是同一個篩選流程的兩個階段，而自然的流程會先執行成本較低的模型。

第一階段：Liquid AI d1-omni-600M 接收進來的項目——語音留言、客服來電、附有附件的書面投訴——並回答粗略的問題。這是帳務問題還是技術問題？來電者生氣了嗎？這則訊息到底有沒有包含請求？在低於 2GB 且只需一次處理的情況下，成本低到足以對每個項目執行。

第二階段：凡是 600M 在其尺度上判定接近中間地帶的內容，或任何附有需要判讀影像的內容，都會升級到 d1-2B。2B 具備 128K 視窗、影片輸入，以及大約三倍的視覺平均表現，而且它只會看到第一階段無法處理的那部分流量。

閾值才是重點。兩張卡片都會回傳機率，而且都告訴你要用自己的資料進行校準——d1-2B 的卡片正是這麼寫的。一條中間帶未經校準的級聯，要嘛會把所有東西都往上呈報，如此一來 600M 就只是裝飾；要嘛什麼都不往上呈報，如此一來 2B 永遠無法修正那個讀不懂的階段。

在大多數真實系統中還有第三個階段：負責撰寫回覆的模型。這正是託管 API 進場的地方，也是 OrcaRouter 發揮作用之處。兩個 Liquid AI 模型都不是由我們提供服務，因此決策節點仍留在你自己的 GPU 上；而消費其標籤的生成步驟，則可來自一把相容於 OpenAI、涵蓋 200 多款模型的金鑰，供應商定價零加成，且若供應商在流量進行中斷線，會自動容錯切換。路由 DSL 也是表達這套串接流程最誠實的方式——把兩個決策模型當作 GPU 端步驟、把回覆生成當作託管步驟，以組合方式串起來，而不是在應用程式碼裡硬黏在一起。

兩個模型都沒做的事，以及第三個選項

兩者都不會撰寫文字。兩者都會回傳具型別的答案與機率，輸出 token 為零；若下一步需要文字敘述，那就是另一個模型。兩者都無法處理帶有音訊的影片：d1-2B 接收視訊影格但不接收聲音，600M 接收聲音但不伴隨影像，而 30 秒的音訊上限是硬性限制，而非建議。

如果需求確實是「同一請求中包含音訊和影像」，那麼答案不是這兩者，而是 d1-Omni-2B：這是 Liquid AI 在 d1-2B 之後二十四秒所打造的 2.17B 同系列模型，可在單一媒體清單中接受文字、圖片、影片影格與音訊片段。它在同一張 v0.3 表上的 Decision Index 分數為 49.0，視覺平均為 67.7，且同樣缺乏獨立測試。它的參數量約為 600M 的四倍，這就是不在模態之間做選擇的代價。

所以規則很簡短。如果狀態包含語音，且沒有其他需要查看的內容，Liquid AI d1-omni-600M 就是這對組合中唯一能執行的成員，而且應將它視為螢幕。如果狀態是文字、圖像或影片，且答案必須經得起考驗，那麼 d1-2B 就是該模型——它也是擁有已公布延遲數據、128K 視窗，以及一項即使逐列細讀也依然成立的基準測試領先優勢的模型。如果狀態同時包含兩者，兩者都不是答案，而是 2.17B omni 模型。