Liquid AI d1 與 Liquid AI d1-omni-600M：能聽見你的開源決策模型

搜尋 Liquid AI d1 這個名稱，你會找到一個能讀取文字與圖像的三十億參數模型。同一系列中的另一個開放檢查點大小只有它的五分之一，可處理長達三十秒的語音，而且是兩者之中唯一能對語音做出任何判斷的模型。它叫做 Liquid AI d1-omni-600M，而如果你是透過本機執行階段函式庫，而不是透過供應商自家文件找到這個系列，那你很有可能從未見過它的名字。這個比較正是為了修正這種情況而存在，因為這兩個模型並不是同一個問題的競爭答案。它們是兩個不同問題的答案，而其中只有一個涉及聆聽。

以下每一個數字都來自 Liquid AI 自家的資料：LiquidAI/d1-omni-600M 模型卡、搭配的 d1-omni-600M-GGUF 儲存庫，以及 10 月 7 日同時宣布這兩個開放檢查點的發布文章。效能列是由廠商在其自行維護的指數上評分，而非提交供公開排名；該文章也直言，專用的音訊決策基準仍然是一個未解的問題。這裡沒有任何內容曾被實驗室以外的人重現。

5.87 億個參數是由什麼組成的

頭條數字背後，藏著一種不尋常的拆分方式。總參數量為 587M，而且它們並非單一堆疊：一個 381M 的共享主幹、上頭掛著決策頭，一個 94M 的視覺編碼器，還有一個 112M 的音訊編碼器。每一種模態都跑在同一組主幹權重上，而這正是讓整體維持輕巧的設計決策——這個模型並不是三個模型披著一件風衣，而是一個負責決策的主幹，搭配兩種餵資料給它的方式。

這些元件來自 Liquid 產品目錄中的不同位置。主幹源自 LFM2.5-Encoder-350M，這是一個雙向編碼器，而非來自較大兄弟模型所屬的僅解碼器系列。視覺塔是取自 LFM2.5-VL-450M 的 SigLIP2，並對主幹套用了轉接器與 LoRA 更新。音訊路徑是 17 層的 FastConformer 編碼器，帶有自己的轉接器，並以凍結的文字主幹進行微調。模型卡指出，文字、圖像與音訊位置共同共享 16,384 個符元的上下文，當有圖像時文字會縮減至 896 個符元，且詞彙量為 65,536 個符元——是其較大兄弟模型 128,000 的一半。如果你使用的語言是這個系列僅部分涵蓋的語言，最後那個數字值得留意。

雙向與僅解碼器（decoder-only）之別，正是任何兩者都用過的人會覺得這兩個模型感受不同的原因。編碼器形的主幹會在產出任何東西之前，一次讀取整個狀態，而且是雙向進行。解碼器形的那個則像語言模型那樣向前讀取。兩者都被訓練成以零輸出詞元、從某個分布中報出答案，因此兩者都不會寫出文字——但底層的機制屬於不同類別的模型，而底下討論的準確率差距，就是這個較小的編碼器形設計所付出的可見代價。

三十秒的演說，卻沒有東西可以為它評分。

音訊正是這個檢查點存在的原因。它接受一段最長 30 秒、16 kHz 單聲道的片段，並在產生答案的同一次前向傳遞中完成，而且它是該系列中唯一能做到這點的開放權重成員。對裝置端工作而言，這並非邊緣功能。一台在產線上標記缺陷的相機會是較大兄弟模型已能處理的視覺問題；而一台能路由語音請求、分類話語，或判斷來電者是否要求退款的裝置，則是只有這個模型能被指派處理的問題。

有兩項限制疊加在那項能力之上，而兩者都有文件記載，這表示在正式環境中誤踩這些限制沒有任何藉口。首先，單一請求會攜帶圖像或音訊，絕不會同時攜帶兩者——同時傳入會引發 ValueError，而不是默默丟棄其中一項，因此失敗會很明顯，且在測試中很容易發現。其次，音訊路徑是以英語使用者與助理之間的交流訓練而成，音訊片段裁切為 30 秒。那是一種說話者幾何、一種對話輪次結構，以及一種口音分布。把它用在客服中心錄音或現場音訊上，等於要求模型卡未宣稱的行為，而這正是如果有基準存在的話，基準會揭露的那種落差。

目前並不存在。發布貼文稱專門的音訊決策基準「目前仍是個未解的問題」，並邀請社群打造一個，這對一間實驗室而言是相當坦率的說法，對任何評估該模型的人來說也是一項實際的限制。Liquid AI d1-omni-600M必須以一種目前無人能衡量的能力來證明自身價值。該廠商也完全未公布推論數據，聲稱理由是該模型屬於仍在積極開發中的早期研究版本。因此，600M 完全沒有延遲數據——文字沒有、視覺沒有，而身為整體重點的音訊路徑也沒有。

能說而不憑空發明的，只有對已公布參數數量所做的算術：在模型卡建議 GPU 採用的 float16 精度下，587M 參數在計入活化值之前，權重大約是 1.2 GB；相較之下，同精度的 3.12B 同系列模型約為 6.2 GB。模型卡也附有一項容易一眼掠過、卻不該忽略的精度警告：模型是以 float32 訓練，GPU 上建議使用 float16，而在測試期間，bfloat16 改變了某些資料列的最高排名答案。如果你的 serving stack 預設為 bfloat16，那麼對這個模型而言，那項預設並不安全。

為什麼家中較小的一半容易被忽略

讀者之所以會走到 3B 就停下來，是結構使然，而非偶然。Liquid AI 的文件索引在決策模型項下列出三列，而它們讀起來並不一樣：d1-3B 與 d1-omni-600M帶有 Hugging Face 與 GGUF 連結，且在可訓練欄位標著「否」，而 d1則自成一列，在其他每個模型原本該放的下載連結位置上，只寫著光禿禿的「API」兩個字母。發布文章稱 d1為一個系列名稱，卻從未區分所服務的端點與開放權重檢查點。於是本地執行環境函式庫便採用了 3B，因為它的規模與模態數量正好符合它們想發布的條目，而 600M 根本不出現在同一份清單裡。

結果是一個家族，其對外公布的取用說明若快速掃過，看起來就像是單一模型加上單一 API 資料列。實際上提供的，是兩個開放檢查點，各有不同的骨幹、不同的模態，而且在廠商自家指數上的分數差距達 32 分，另外還有一個代管端點，而廠商從未確認它與這兩個檢查點之間究竟是什麼關係。600M 並沒有被藏在任何東西後面。d1它只是沒有能讓搜尋找到它的名字，而它是兩者之中唯一聽得見的那一個。

現有的分數，以及唯一值得閱讀的專欄

在 Decision Index 0.2.1 上，供應商回報 Liquid AI d1-omni-600M為 15.95，而其較大型的同系列產品則為 48.57——差距之大，使總分幾乎無法作為選擇依據。各項子分數比總和更具參考價值，其中一項更是著實令人意外。

• 知識 — 8.3 對比 23.8

• 語言 — 12.9 對比 56.4

• 檢索 — 35.0 對比 52.8

• 工具 — 15.1 74.5

• 藝術 — 6.8 對比 36.3

檢索是小型模型仍能站穩腳步的地方：相較於大型模型的分數，它在這裡只落後不到三分之一；而在其他四個欄位，它則落後 60% 到 80%。這個模式正好符合一個訓練有素的編碼器應該擅長的事：將狀態與內容進行比對，幾乎就是主幹當初被打造來做的事，而且它對解碼器形態的兄弟模型從多得多的預訓練中繼承而來的分層語言能力，依賴程度低得多。Tools 欄位則是相反的故事；如果你的工作負載是要將請求路由到正確的函式，那麼那裡 59 分的差距就是你該緊盯的數字。

在七項公開文本基準測試上，情況就緩和了些。供應商回報 600M 的平均分為 78.4，3B 則為 82.9，其中小型模型在 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 以四分之一的參數量，擊敗了一個 2B 決策模型的 77.1 平均分。兩套基準測試套件給出兩種不同的表面結論，且都是自我回報的；而誠實的解讀是，兩者都無法對音訊路徑下定論，因為音訊路徑並不在任何一套之中。

兩者真正交會之處

儘管有種種差異，程式設計模型完全相同，而這正是讓它們在某種特定意義上可以互換的原因。兩者都能針對某個狀態回答 noul、選擇題與評分題，兩者都會回傳所選答案，附帶機率分布圖以及介於 0 與 1 之間的信心值，且兩者都會回報 output_tokens: 0。confidence 欄位正是人們常誤讀的那個：它衡量的是機率有多強烈偏向某個答案，而不是該答案正確的機率。在一個問得很糟的問題上得到 0.96，就是一個很有信心的錯誤答案，而這個欄位不會警告你。

在實務上，它們交會之處形成一種串接式流程。用Liquid AI d1-omni-600M 來篩選——成本低、可在地端執行，而且涵蓋純文字評分器無法觸及的音訊案例——接著把被它評定在尺度中段附近的項目，升級到較大的檢查點，以做出更精準的判斷。升級規則採用的是 600M 已經回傳的信心值與分布，因此路由邏輯不需要額外模型；而在簡單項目占絕大多數的工作負載中，大部分流量永遠不會到達第二階段。這種組合之所以可行，是因為兩個模型回傳的是同一種物件。任意兩個模型則不然。

如果那個串聯最終是要用來觸發對一個你租用、而非自行運行的生成式模型的呼叫，那麼底下那一層就是管線變得有趣的地方，也是我們登場的地方。把一項決策導引通過一連串模型，正是路由規則存在的意義：OrcaRouter 將多個模型組合在單一與 OpenAI 相容的端點之後，每一個都以其供應商的標價原價轉出，零加成，並具備跨供應商的自動容錯移轉，因此當某個升級流程在供應商層失敗時，會改在備援上重試，而不是讓請求失敗。我們並未代管任何 Liquid AI 模型——這點我們在撰寫本文前查證過——所以上述內容都不是關於透過我們呼叫這些權重的說法。重點在於：決策模型是整條管線中便宜的那一部分，而另一側那個借來的模型才是會掛掉的那一部分。

檔案來自哪裡，如果你想今天執行的話

用於本地部署時，廠商自家針對 600M 的 GGUF 儲存庫提供 407 MB 的 Q8_0，以及各為 764 MB 的 F16 和 BF16，並未列出任何 4 位元版本——因此最小的官方下載檔比更大模型的對應版本大約小七倍，大小約等於一張中解析度照片。這張卡本身的範例會以 4096 的批次旗標啟動 llama.cpp 伺服器，並建議在狀態較長時將它們提高到 16384，然後查詢與較大兄弟型號相同的 /v1/systemone 端點。

本地路線唯一沒給你的，是音訊路徑的數字，因為那些數字根本不存在。如果你打算在真實使用者面前用這個來處理語音，評估就得由你自己建立：一組有標註的片段、同樣的三種問題類型，以及每個類別測量出的回答率。這並不是在否定這個模型——一個 587M 的檢查點能在單次處理中對一段語音片段做出判斷，和一個綁在轉錄步驟上的文字分類器是真正不同的工具，它值得一場真正的測試，而不是憑感覺的測試。

如果那個級聯流程把關的是對你租用而非自行運行的生成式模型所發出的呼叫，OrcaRouter 會在單一 OpenAI 相容端點後方整合多個模型，每個模型都以供應商的定價原樣提供，0% 加價。

選擇 omni 檢查點而非純文字檢查點，也是檢視這一類模型已經出過哪些問題的好時機：涉及小型多模態模型的已記錄 AI 事件與代理失效案例，都收錄於 OrcaRouter AI Incident Archive，其中每筆條目都帶有自己的來源、嚴重程度、信心等級與爭議標記。