d1-2B：Liquid AI 推出 1.9B 決策模型，卻未發文宣布

Hugging Face 上LiquidAI/d1-2B 的儲存庫建立於 2026 年 10 月 24 日 19:30 UTC。它的兄弟模型 d1-Omni-2B 在二十四秒後出現。到那天傍晚結束時，兩個儲存庫都已完整——3.84GB 的 BF16 safetensors、四十多個自訂 Transformers 程式碼檔案、一張校準表、一個型別化問題 API——而 Liquid AI 發布的任何內容都沒有說這兩個模型存在。第一句提到d1-2B 的廠商文句直到 10 月 27 日才出現，位於 LFM3 家族發布內容中——同一篇文章刊載於 liquid.ai 與 Hugging Face 自家部落格——而且是關於兩個決策模型的段落裡的一個子句。此後就沒有專文。所以這不是一則發布故事；若把它當成發布故事，就會憑空捏造一個從未發生過的行銷時刻。這是一則關於一個完整模型產物卻只有不完整公告的故事，也是關於讀者仍能對它做的兩件事：閱讀該儲存庫，以及對廠商提供的數字保持審慎距離，直到實驗室外有人實際跑過它們。

在權重與句子之間的那五天

d1 系列已經發布過兩次，而這兩次發布都不像這一次。10 月 7 日，Liquid AI 發布了〈Open d1：文字、視覺與音訊的邊緣決策模型〉，介紹了擁有 3.12B 參數的 d1-3B，以及擁有 587M 參數的 d1-omni-600M，並提出一項重點宣稱、附上一張基準測試表、延遲數據，以及一篇至今仍在線上的部落格文章。那篇文章中並沒有 2B 模型。

2B 產品線依不同時程推進。基礎檢查點 LFM3-Omni-2B 於 10 月 21 日出現。10 月 24 日 19:30 與 19:30:24 UTC，Liquid AI 建立了 d1-2B 與 d1-Omni-2B 儲存庫。接著在 10 月 27 日，LFM3 發布文章將這對模型稱為「由視覺與 omni 模型特化而成的決策模型」——這是描述，不是公告。同日，d1-2B 的四個衍生儲存庫上線：fp16、8 位元與 4 位元的 MLX 版本，外加一個 ONNX 匯出。也沒有人為這些寫過貼文。

這在實務上有其重要性。公告是廠商表明定位的地方：模型用途為何、費用多少、目標執行環境是什麼、以及它不做什麼。這張卡片完成了其中部分工作，而且做得格外好。但缺少那篇貼文所留下的缺口真實而具體，這些缺口列在本文末尾，而非被掩蓋過去。

儲存庫實際上會告訴你什麼

撇開包裝說法，這個 checkpoint 就是一個小型、規格密集的多模態分類器，拒絕生成文字。每次呼叫都會回傳附帶機率的具型別答案，以及 output_tokens: 0。說明卡直言：d1-2B「不是聊天模型」。

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

• 基礎版 — LFM3-VL-2B，基於 LFM3 主幹：24 層，其中 13 層為閘控短卷積、5 層為滑動視窗注意力、6 層為全域注意力。

• 上下文 — 128K 個 token 與 128,000 個 token 的詞彙量，是 d1-3B 的 32,768 視窗的四倍。

• 輸入 — 一種狀態，可以是文字或任何 JSON 值、圖片 或影片，以及任意數量的具名問題，全部放在同一個 媒體清單中。影片是 d1-3B 未列出的能力。

• 輸出 — 是/否、從具名選項中擇一、有序分數、從文件中讀取的值或日期及其範圍、帶有 p10–p90 區間的數字、邊界框，或每個物件執行個體及其計數。每項都帶有機率。

• 語言——十六種：英文、阿拉伯文、中文、法文、德文、義大利文、日文、韓文、葡萄牙文、西班牙文、越南文、泰文、印尼文、印地文、俄文、波蘭文。

• 授權 — LFM Open License v1.0。年營收低於 10,000,000 美元者授予商業使用；授權文本將該數字定義為門檻，而超過該門檻的商業使用權利，則以不超過該門檻為條件。

• 速度 — 在 H100 PCIe 上，單次決策耗時 5.7 毫秒；在 AMD MI325X 上則為 3.8 毫秒；當 64 個狀態批次合併為一次呼叫時，每秒分別可完成 1,132 與 1,699 次決策。在 Apple M5 Pro 上，單一問題的耗時為 18.6 毫秒。

值得爭論的主張：它勝過它所取代的模型

Liquid AI 的模型卡提出了一項毫不含糊的比較性主張：d1-2B「在平均表現上，以及在我們由超過一百項決策基準組成的評測板上，領先各開放 d1 模型；其規模不到 d1-3B 的三分之二，卻領先 d1-3B。」這是一個 1.92B 模型針對 3.12B 模型所作的強烈陳述，而且可以查核，因為模型卡把全部四款開放 d1 模型列在同一張表中，並以相同的評分器對相同項目評分。

頭條數字是 Decision Index 公開測試集 0.3 版上的 51.1 對 49.0——領先 2.1 分。在任何人把這解讀為一場乾淨勝利之前，有兩點但書應與之並列。第一，d1-3B 自己的模型卡在 Decision Index 0.2.1 上回報 48.57，而 48.57 與 49.0 的差異是索引版本，不是模型有所改進；d1-2B 的卡片指出，四個模型都已在相同項目上重新評分，因此 d1-3B 的少數數字與其自身卡片不同。第二，公開套件只是決定公開排行榜的一小部分：重建該套件的獨立評估者描述，37 項公開基準在分數中佔 20% 權重，其餘則來自僅由維護者執行的私有測試。

49.0 之所以作為一個數字具有可信度——即使 d1-2B 本身沒有外部驗證——是因為已經有人在这个確切版本上複現了 3B。Efraín Garay 在十月中旬對 Decision Index 0.3 的 6,000 筆請求分層樣本跑了 d1-3B，得到 49.11，而 Liquid 自己在相同資料列上得到 49.04，在完整測試組上得到 48.99。這是在零點一個百分點以內的複現。它並未驗證 d1-2B 的 51.1——沒有任何第三方跑過——但它確實驗證了 51.1 所在那張表背後的評分方法。

較小模型未領先之處

「在大多數單項基準測試中領先」這句話在這句裡正默默發揮作用。在同一輪執行的表格中，d1-3B 仍贏得對部署決策有影響的二十幾行裡的三行：

• Fast Decisions — 3B 為 59.3，對上 58.8；這是唯一一項以速度為導向的決策基準，較大型模型在此略占上風。

• 具型別決策 — 65.0 對 61.3，差距 3.7 分，也是當輸出必須是具型別的值而非標籤時，支持較舊模型最明確的單一論據。

• AI2D — 79.9 對 76.7，這是圖表閱讀基準測試，在此更大的視覺塔仍能換取準確度。

在其他各項上，排序都會翻轉，有時甚至大幅反轉。VisualWebBench 上 d1-2B 為 96.2，而 d1-3B 為 71.4。ImajevBench v2.0-lite 為 75.5，對比 64.0。MMMU-Pro 則是 26.4 對 18.5——兩者都低到不該讓任一模型負責困難的多模態推理，這點值得直說，而不是把 7.9 分的差距包裝成一場勝利。視覺平均分別為 70.2 與 65.4。

這張卡片無法填補的三個空缺

缺失的公告會以缺失的產物形式顯現。這些都不是模型的缺陷；每一項都是模型如今比其基準線所示更難被採用的原因。

• 沒有 GGUF。d1-3B 和 d1-omni-600M 都在 10 月 6 日有了 GGUF 儲存庫，就在其權重上線後一天；d1-3B 隨後還推出了 8 位元權重－啟用版本和四個 MLX 變體。截至 10 月 27 日，d1-2B 已有 MLX 和 ONNX 版本，但沒有 GGUF——因此，儘管基礎模型 LFM3-VL-2B 已於 10 月 19 日有了自己的 GGUF，決策頭仍沒有發布 llama.cpp 路徑。如果你的邊緣端技術堆疊是 llama.cpp，這就是全部情況。

• 沒有價格，也沒有端點。 這張卡片未列出託管 API、沒有按 token 計價，也沒有推論供應商。對開放權重發布而言這並不罕見，但這意味著使用 d1-2B 的唯一方式就是自行執行，而卡片的部署章節止於一個 Transformers 程式碼片段。

• 無獨立基準測試。截至 10 月 28 日，該儲存庫顯示 44 次下載與 13 個讚。現有的獨立決策模型評估涵蓋 d1-3B 與 d1-omni-600M，並不包括此模型。上述每一項效能數據皆為 Liquid AI 自家提供。

模型卡本身也說明了限制：答案「在狀態超過約 64K 個 token 後會變得較不可靠」，這只有宣傳所稱 128K 視窗的一半；而且估計值在計數和分數上可靠，在自由數量上則較不可靠。一張會告訴你它在哪裡退化的模型卡，比不說的更有用，但 128K 這個標題數字應被解讀為容量數字，而不是工作範圍。

首次部署實際上長什麼樣子

實用做法是使用 Transformers 5.19 或更新版本，並搭配 trust_remote_code=True、GPU 上的 bf16，以及 system_one 或 system_one_batch 呼叫。沒有取樣參數，因為沒有取樣。唯一重要的調校旋鈕是 set_size，其預設值為訓練大小 16；提高它可換取速度，但會犧牲文字準確度。

卡片本身的建議，是多數團隊會跳過的那一步：用你自己使用情境的資料來校準決策閾值。單看 0.62 的機率沒有意義。如果你是在分流客服工單或標記文件，區分「升級處理」與「自動處理」的閾值，必須用你自己標註的樣本進行擬合，因為廠商的校準是用他們的樣本擬合出來的。

這適合的形態是管線中的一個步驟，而不是助理：分流、審核、意圖分類、表單擷取、重排序、視覺檢查。這些正是管線已經會呼叫多個模型的地方，也是決策周邊的生成步驟通常來自託管 API 的地方。OrcaRouter 目前不提供任何 Liquid AI 模型——包括這個在內——所以執行 d1-2B 意味著你得自己執行。路由器有用之處在於鏈路的其餘部分：一把相容於 OpenAI 的金鑰，適用於 200 多個託管模型，一套路由 DSL，可將各步驟組合成單一呼叫，並在供應商中斷時自動容錯轉移，讓你在 GPU 上的決策節點不會被旁邊的生成節點挾持。

什麼會改變這個故事

四件事，依影響程度由高到低排列。一份 GGUF 會讓 d1-2B 與其同系列模型處於相同的執行環境基礎，並讓邊緣運算的訴求成真。一篇專門的貼文能告訴買家，除了模型卡上列出的流程步驟之外，Liquid AI 認為這個模型是要用來做什麼。一次獨立執行——理想上是重現 d1-3B 的同一份 6,000 列樣本——能把 51.1 從廠商說法變成實測數據。而託管價格將讓自建與購買的問題至少能夠被回答。

在那之前，誠實的摘要範圍有限卻實用：一個 1.92B 的決策模型確實存在，其儲存庫完整到足以評估，它在廠商自家同一次執行的表格上對 3B 的基準測試領先是真實的，但在其他任何地方都未經證實；而缺少的公告讓它沒有配套——執行環境、端點、價格——而多數團隊在把模型放進管線之前都需要這些。如果你已經在用 Transformers，而且想要一個具備影片輸入的 128K 視窗分類器，它值得花一個下午。如果你需要 llama.cpp 或託管端點，那就再等等。