d1-Omni-2B：Liquid AI 最低調的 2B 決策模型隨附了什麼——以及它略過了什麼

的 Hugging Face 儲存庫LiquidAI/d1-Omni-2B於 2026 年 10 月 24 日 19:30 UTC 建立。第一篇提到此模型名稱的 Liquid AI 部落格文章於 10 月 27 日上線。在那三天裡，該儲存庫是公開且完整的——完整的規格表、4.33GB 的 BF16 safetensors、可運作的 Transformers 程式碼——而供應商發布的任何內容都未表明它存在。當提及終於出現時，它只是某個六模型家族發布中的兩段文字和一張四行表格，並非獨立的發布。這就是本次發布的樣貌，也是以下所有內容的誠實框架：權重可供檢查，各項宣稱出自供應商，而買家通常會從公告中取得的資訊——價格、託管端點、獨立基準測試——目前仍不存在。

權重與文字之間的五天差距

Liquid AI 的決策模型故事已被講述過兩次，而 d1-Omni-2B 在兩次敘述中都未出現。10 月 7 日，該公司發表了《Open d1：文字、視覺與音訊的邊緣決策模型》，其中正好推出兩個開放檢查點：d1-3B，一個 3.12B 的視覺與文字模型；以及 d1-omni-600M，一個 587M 模型，可接收文字搭配圖像，或文字搭配最長 30 秒的音訊。那篇文章仍可閱覽，而且其中仍然沒有 2B 模型。

2B 系列以不同的時程登場。10 月 21 日，基礎檢查點 LFM3-Omni-2B 出現在 Hugging Face 上。10 月 24 日，Liquid AI 相隔二十四秒先後建立了 d1-2B 與 d1-Omni-2B 的儲存庫。接著，10 月 27 日的 LFM3 發布文章為這個系列命名：六個約 2B 參數的模型，其中四個涵蓋文字、視覺、音訊與 omni，而且用該文章自己的話來說，「最後兩個是從視覺與 omni 模型特化而成的決策模型。」那句話就是發布公告。沒有獨立的 d1-Omni-2B 文章、沒有定價頁面、沒有發布合作夥伴引述，也沒有更新 10 月 7 日的文章。

所以這個模型並非沒有文件紀錄——該儲存庫是 Liquid AI 所發布、文件較完善的小型檢查點之一，而廠商針對決策模型的文件頁面也把它與 d1-2B 和 d1-omni-600M 並列。它只是發布宣傳不足。這個區別很重要，因為它能告訴你哪些說法已經過發布審查，哪些則否。

將這張卡當作規格表來解讀

撇開包裝不談，這個檢查點很直截了當。d1-Omni-2B 是以 LFM3-Omni-2B 為基礎後訓練而成的決策模型，而且它不是聊天模型：它不會寫出文字，也不會產生語音，每次呼叫都回傳 output_tokens: 0。

• 參數量 — 2.17B，以單一 4.33GB BF16 safetensors 檔案形式提供。

• 架構 — LFM3 主幹：24 層，其中 13 層是閘控短卷積，5 層是視窗大小為 256 個 token 的滑動視窗注意力，6 層是全域注意力。家族文章將這種三混合組合描述為在 14 種裝置與後端組合上執行硬體在環架構搜尋所得的結果。

• 上下文與詞彙 — 128K 個 token，以及與 LFM3 其餘部分共用的 128,000 個 token 詞彙表。

• 輸入 — 一種可為文字或任何 JSON 值的狀態，另加圖片、視訊影格與音訊片段，以及任意數量的具名問題（可為書面或口語）。此卡片的 API 會將所有這些內容收進單一 媒體清單中，這與 587M 檢查點有顯著差異：d1-omni-600M 的文件記載為文字搭配圖片或文字搭配音訊，而非同時兼具兩者。

• 輸出 — 具型別且附帶機率的答案。是/否、從具名選項中挑選、排序分數、從文件中讀取的值及其範圍、附有 p10–p90 區間的數字、邊界框，或每個物件實例及其計數。

• 語言——十六種。語音涵蓋的語言相同，但不含印地語、泰語、越南語與印尼語；這點值得特別指出，因為文字部分有列出這些語言。

• 授權 — LFM Open License v1.0。年營收低於 10,000,000 美元時授予商業使用；超過該門檻時，授權條款文字指出商業使用「不依本協議授權」。

音訊是值得檢驗的主張。

選擇這個檢查點而非 d1-2B 的原因是音訊。Liquid AI 將其定位於「通話與語音訊息路由以及聲音事件」，而模型卡帶有發布文章通常會率先展示的那項證據：針對相同項目所做的口說與書面比較。

• 業務路由與分流（DecisionBench，Hanno Labs v1） — 83.4 書面，78.2 口語。

• 客服案件（輸入型決策） — 50.5 書面，48.0 口語。

• JevBench v1.4.1，語音可朗讀的那些列——書面為 87.6、口語為 89.0，意即口語測試的得分略高，但這屬於雜訊，並非增益。

• 聲音事件 (ESC-50) — 84.5，沒有對應的文字表達。

• 口語語言辨識（FLEURS，43 種語言） — 92.5。

那些數字支撐了這套推銷說法。音訊章節其餘部分則告訴你不該在哪裡建置，而且對廠商規格卡來說異常坦率。短口語陳述的表現從書面輸入的 42.0 降至聽覺輸入的 22.8。八種語言的 Belebele 段落從 83.6 降至 41.8。規格卡明白指出，長篇口語段落會喪失大部分準確度，「尤其是在拉丁字母語言以外」，並指引沒有音訊輸入的人改用 d1-2B；卡上稱 d1-2B 在文字與單一框方面更強、更常回報缺失值，且校準更好。

把這些橫列合起來看，描述的是一個模型：它擅長處理主要語言中簡短、可路由的話語，但在任何需要維持長時間口語狀態的任務上就弱得多。客服中心的分流作業很適合，四十分鐘的會議錄音則不然。

計分板是廠商的，而索引已變更版本。

這款模型上的每一項效能數字都是 Liquid AI 自己的。模型卡對方法說得很明確：四個 d1 模型都在相同項目上以相同評分方式評分，因此有些數字與它們各自來源的個別模型卡略有不同。它並未說明有任何第三方重現了其中任何結果，而且截至撰寫時，d1-Omni-2B 尚無獨立評估。

• Decision Index 公開測試套件，v0.3 — d1-Omni-2B 為 49.0，相較於 d1-2B 的 51.1、d1-3B 的 49.0，以及 d1-omni-600M 的 18.3。

• DecisionBench (Hanno Labs) v1 — 76.4，對比於分別為 77.1、73.1 與 58.7。

• decisionbench.ai v4 — 84.7，相較於 85.2、83.6 與 57.9。

• ImajevBench v2.0-lite — 72.3，相較於 75.5、64.0 與 21.7。

• 廠商自家涵蓋一百多項基準測試的排行榜——61.8，相較於 63.2、58.8，而 600M 則無分數。

• 18 項圖像基準測試的視覺平均分 — 67.7，相較於 70.2、65.4 和 42.8。

這裡中間有一個陷阱。10 月 7 日的貼文報導 d1-omni-600M 在 Decision Index v0.2.1 上為 15.95。新卡片則報導它在 v0.3 上為 18.3。這些是不同的評測套件，差異並非能力提升；不要把兩者相減。唯一公平的比較是卡片實際所做的比較，也就是讓全部四個模型在同一批項目上重新評分。

在重新評分後仍成立的情況是：d1-Omni-2B 在幾乎所有項目上都略低於 d1-2B，卻大幅高於上一代。Liquid AI 將其描述為以 70% 的參數量，在自家決策看板上以及 18 項影像基準中的 16 項上勝過 d1-3B；就表上所列而言這是真的，但同時也是與該系列如今已被取代的模型作比較。

儲存庫沒有回答的是什麼

還有五個問題尚未解決，而這些問題沒有一個能靠閱讀權重來解答。

• 託管存取與價格。 LFM3 貼文表示，基礎模型與後訓練模型可在 Hugging Face、Playground 與 Liquid AI API 上取得。然而，decision-models 文件表格將 d1-Omni-2B 列為開放權重，並將其僅限託管的列保留給 d1.1 與 d1-ultra；Hugging Face 模型頁面則指出「此模型未由任何 Inference Provider 部署」。本文能找到的任何地方都沒有公布此檢查點的每次呼叫價格，因此請將託管存取視為看似合理但未經證實。

• 訓練資料。這張模型卡沒有提供語料庫、沒有組成說明，也沒有資料集描述。它提到要在「沒有任何訓練資料列包含的」音訊片段與聲音上進行測試，這暗示存在一個訓練集，卻完全沒說明裡面有什麼。

• 量化。 主儲存庫提供 BF16，而 Liquid AI 發布了三個同系列建置版本：MLX fp16、MLX 8 位元，以及 ONNX 匯出。雖然沒有廠商提供的 GGUF，但 Ollama 的 d1-omni 函式庫帶有 2b 標籤，大小為 4.4GB、上下文為 125K，而且其大小與 BF16 檢查點足夠接近，看起來不像激進量化。

• 獨立評測。無。上方每個數字皆由廠商自行執行，使用廠商自家的評分器，在廠商自家的測試平台上跑出。

• 是否會取代 d1-omni-600M。 在沒有音訊時，模型卡建議使用 d1-2B 而非此模型；在有音訊時，則建議使用此模型而非 d1-2B。模型卡未提及 587M 檢查點的未來，且 Liquid AI 尚未將其棄用。

執行它，以及它在硬體上的成本

推論路徑為 Transformers 5.19 或更新版本，並搭配 trust_remote_code，呼叫方式為 model.system_one(state, questions, media)。無需設定取樣參數，因為不會進行任何取樣。首次呼叫時編譯約需一分鐘；之後該卡回報，在 H100 PCIe 上單一問題為 5.8 毫秒、三個問題為 7.7 毫秒，在 AMD MI325X 上為 3.7 毫秒與 5.6 毫秒，在 Apple M5 Pro 上為 21.1 毫秒與 28.9 毫秒。5K token 的狀態在 H100 上耗時 52 毫秒。批次處理正是吞吐量所在：在單次呼叫中處理 64 個狀態時，H100 每秒可處理 1,154 個狀態，MI325X 則為每秒 1,697 個。

對這類模型而言，那些數字就是論據。它不是在品質上跟聊天模型競爭，而是在跟「究竟要不要跑聊天模型」這件事競爭。一次耗時 5.8 ms、會回傳校準後機率的前向傳遞，跟一次會回傳一段還得由你解析的生成式呼叫，是完全不同的預算項目。

決策終結之處，就是流程其餘部分的起點

這樣的模型只負責一跳。它會把工單、通話錄音或攝影機影格轉成標籤與信心分數，接著必須有某個環節根據該標籤採取行動——起草回覆、升級案件、呼叫 API。OrcaRouter 的型錄中沒有 Liquid AI 模型，因此第二跳正是我們產品實際所在之處：取用該決策的生成式模型會透過一組 OpenAI 相容金鑰涵蓋 200 多個模型，依各供應商牌價原價轉供、0% 加成，並在請求落到暫時出狀況的供應商時自動容錯移轉。決策模型是便宜、快速、具確定性的那一部分。值得把昂貴、非確定性的那一部分，接上能夠重試的機制。

什麼能讓它塵埃落定

有三件事能讓 d1-Omni-2B 從「有潛力」變成「值得推薦」，而且這三件事都不需要再寫一篇部落格文章。第一件事，是在廠商無法掌控的硬體上獨立跑一次音訊套件——在口說短狀態上，22.8 對 42.0 的差距，是最有可能在別人的麥克風下出現變動的數字。第二件事，是公布託管存取（hosted access）的價格；沒有這個價格，自建與購買的計算就無法完成。第三件事，是在同一批含音訊任務上，與 d1-2B 做直接比較，因為這張卡本身最有用的那句話——只有在輸入包含音訊時才使用 2B omni——也正是從來沒有人曾在 Liquid AI 之外測試過的那句話。