Liquid AI d1-3B 登陸 Ollama：為決策模型而生的靜謐本地端點

Ollama 的模型庫中出現了一個新的 d1，而且它不是聊天模型。條目用一句話描述它——「來自 Liquid AI 的 3B 決策模型，建構於 LFM2.5-VL-3B 之上」——而這一句話就包含了最重要的兩個事實。Liquid AI d1-3B，這個由 Liquid AI 建構於 Liquid AI LFM2.5-VL-3B 之上的小型模型，於 2026 年 10 月 5 日以開放權重釋出，如今已打包完成，只要執行一次 pull 就能把它放到你自己的機器上；而且它仍然會針對有型別的提問回傳經過校準的機率，而非生成文字，與底層檢查點的行為完全一致。如果你的流程中有分流、路由、審核或閘控步驟，這是這個特定模型家族第一次只需一個指令就能執行，不需要 API 金鑰、沒有每次呼叫的費用，也不會有任何狀態文字離開你的硬體。

不過，「安靜」這個詞在這裡確實發揮了實際作用，而值得精確說明的是：這個故事哪一半有紀錄、哪一半沒有。Liquid AI 自己的部落格從未提及 Ollama：該實驗室最近一篇發文是在 2026 年 10 月 13 日，介紹的是 LFM2.5 系列中的另一款模型；而它的兩篇 d1 貼文——10 月 5 日的視覺公告，以及 10 月 7 日的「Open d1」發布——描述的是權重、一個 API 和一項基準測試分數，而不是本機執行環境。Ollama 的 d1 模型庫頁面同樣沒有任何公告，廠商的說明文件索引也沒有；該索引將 GGUF 標記為可用於 Liquid AI d1-3B 及其具音訊能力的同系列模型 Liquid AI d1-omni-600M，卻只把 llama.cpp、Ollama 和 MLX 列為一般部署選項。實際存在的是：一個已發布的套件、一筆附有可驗證摘要的登錄項目、一份可用的 readme，以及一個下載計數器；在 2026 年 10 月 15 日本文撰寫時，該計數器顯示 10.4K。不存在的是廠商的一句聲明：「我們做了這件事。」

該清單實際包含的內容

頁面上列出了三個標籤——d1:latest、d1:3b 和 d1:3b-q8_0——而這三者都解析到相同的 manifest 摘要：8c2d9ddae441。這是理解這個頁面的第一件事：函式庫的「3 個模型」計數器計算的是標籤數量，而不是檢查點。一個產物、三個名稱、3.7 GB、32K 上下文視窗，以及文字與圖像輸入。如果你原本期望能挑選大小或量化版本，目前還沒有任何可挑選的項目。

頁面背後的登錄庫比頁面本身更有資訊量。該套件的設定 blob 回報模型系列為 lfm2、模型類型為 2.7B、檔案類型為 Q8_0，以及最低執行環境為 Ollama 0.40.4。它以兩層權重形式提供：一個 2.87 GB 的生成式模型，以及一個獨立的 856 MB 投影器。第二層是視覺編碼器，它的存在告訴你，這個本地建置保留了多模態路徑，而不是把 d1 精簡成純文字——模型仍然可以同時讀取一張照片和一張支援工單，並回答關於兩者的問題。這個頁面上兩個看似不一致的數字——說明中的「3B」和登錄庫中的「2.7B」——最好解讀為主幹與整體：Liquid AI 的模型卡將該檢查點列為 3.12B 參數，其中包含一個 400M 參數的視覺編碼器，而語言主幹則是較小的數字。這項推算是我們自己的，不是供應商的，而且它是作為解釋而非規格提出。

圖書館頁面上任何地方都沒有日曆日期。它顯示的是相對時間標記——在擷取當下顯示「2 小時前更新」——以及一個下載次數計數器，這表示這個列表首次出現的日子無法從列表本身得知。可標定日期的錨點全都在 Hugging Face 與廠商端：Liquid AI d1-3B 的權重儲存庫建立於 2026 年 10 月 5 日，配套的 GGUF 儲存庫建立於 10 月 6 日，而 Liquid AI 則於 10 月 7 日刊出發布貼文。如果你需要為「這何時開始能在本機執行」標上日期，今天誠實的答案是：這個套件已經存在，而且現在正被拉取，而 Ollama 以外的任何人都無法說出它是在哪個早晨上架的。

為什麼包裝活動是一場真實的活動

Ollama 在 2026 年 9 月 29 日開闢了決策模型這個類別，當天它推出了 /v1/systemone 端點，以及 --ask 這道 CLI 旗標，供能在單次前向傳遞中回答具型別問題的模型使用。Nimble 與 Clef 是最早走過那道門的家族。新的 d1 套件所增添的，跟多一列基準測試成績是兩回事：它把一個直到現在不是活在內附模型類別的 Python 環境裡、就是躲在代管端點之後的模型，讓本機推論變成一行指令。

這份合約值得重新闡述，因為它並不是大多數讀者所說的「執行模型」。你把一個狀態——一個字串、一個 JSON 物件、一個陣列，或一個字串加上圖片——以及一組具名問題交給 d1，然後取回答案，完全沒有任何生成的 token。noul 是一個是非題，以 0 到 1 之間的單一機率來回答。choice 會傳回所選標籤、信心度，以及你所有選項的完整機率對應表。score 會把該狀態放到一個包含二到十個等級的有序評分規準上，並傳回機率加權後的等級，以及各等級的機率。一個狀態、最多 64 個問題、對輸入進行一次掃描。Ollama 本身針對支援工單的範例回應會傳回 usage.output_tokens: 0，這是對這項設計最簡潔的表達。

對於任何已經透過 HTTP 呼叫決策模型的管線來說，改用本機途徑會同時改變三件事：延遲，因為請求不再離開這台機器；成本，因為沒有按次計費的計量器；以及資料處理方式，因為你正在分類的工單文字與照片永遠不會跨越網路。如果你的狀態是客戶的訊息或內部文件，最後這一點通常就是唯一需要提出的理由。

執行它，以及文件對它設下的限制

有三種支援的接入方式，全都記載在函式庫頁面上。CLI 途徑是 ollama run d1 --ask "Is a refund being requested?"，狀態會從檔案以管線輸入，另外兩種問題類型則使用 --choice 和 --level 旗標。HTTP 途徑是對 http://localhost:11434/v1/systemone 發出 POST，附帶 model、state、選用的 images 陣列，以及 questions 物件。SDK 途徑會將 TypeSafe 的 Python 用戶端指向 localhost；在該處 API 金鑰會被忽略，任何 placeholder 值都能運作。

這些限制來自 Ollama 的端點文件，而不是 Liquid AI，而且比生成式模型的限制更嚴格：沒有影像時，請求必須在 64 KiB 以內；有影像時，則必須在 32 MiB 以內；不支援串流；雲端託管的模型會直接遭到拒絕；影像必須是在請求主體中以 base64 傳送的 PNG、JPEG 或 WebP——遠端 URL 會遭到拒絕。同一個請求中的每個問題都會共用影像，因此如果你只希望第一個答案考量某張圖片，就必須將該圖片作為獨立呼叫傳送。輸入永遠不會被截斷，這表示過大的狀態會是錯誤，而不是被默默裁切的提示。

有兩個文件細節值得標示為尚未解決。Ollama 的端點參考文件將 choice 類型描述為可接受 2 到 255 個選項鍵，而決策模型的能力頁面則說是 2 到 26——兩者之一已經過時，而且不明顯是哪一個。此外，能力頁面將其支援的模型列為 Nimble、Tev1、Clef 和 Clef Flash，完全沒提到 d1，儘管 d1 套件自己的 readme 指出它可以透過 /v1/systemone 和 --ask 運作。該套件需要 Ollama 0.40.4；端點本身記載的最低版本是 0.35.0。這些都不是會阻止你拉取模型的矛盾，但請閱讀套件上的版本需求，而不是能力指南中的那個。

這些數字，以及每一個數字分別是由誰產出的

現在輪到最值得謹慎看待的部分。這個模型附帶的每一項效能數據都來自 Liquid AI，而就我們所能找到的，並不存在針對 Liquid AI d1-3B 的獨立評估。廠商回報的結果，在 Ollama 頁面和模型卡上重複出現的，是這些：

• Decision Index 0.2.1 — d1-3B 為 48.57，相較於 Decider 35B-A3B 的 47.11，Liquid 稱其為參數低於 10B 的決策模型中最佳分數。 • 視覺 — 在十一項公開影像基準測試中平均為 74.1，相較於其建構基礎 LFM2.5-VL-3B 的 73.9。 • 延遲 — 在 RTX 4090 上每次決策為 8 毫秒，在 AMD MI325X 上為 9 毫秒，在 Apple M5 Pro 上為 30 毫秒。 • 吞吐量 — 當問題打包成批次時，在 4090 上每秒可處理 475 次決策，在 MI325X 上則為 1,106 次。 • 消融 — 同一組問題在沒有影像的情況下回答得分為 45.1，這是 Liquid 自身衡量視覺路徑貢獻程度的指標。

視覺列才是應該用來壓低期望的一列。在一組影像基準測試上比基礎模型提升 0.2 點，這落在大多數基準測試報告的雜訊範圍內；無論決策頭帶來什麼，它都不是實質上更好的影像編碼器。消融列從另一個方向看更有意思——加入圖像時約有 29 點的變動——但它比較的是兩組不同的問題集，而不是同一個問題集的兩個版本。而 Decision Index 是一項第三方工具，Liquid 是在其上為自己的參賽項目自行評分，而不是把它們提交出去接受公開排名，所以請把 48.57 當成廠商借用別人的尺規所做的宣稱。速度數字同樣未經稽核：在 4090 上達到 8 ms，對一個做單次前向傳遞的 3B 模型來說是合理的數字，而且情況依舊是：沒有人發表過不是自己跑出來的執行結果。

OrcaRouter 適合的地方，以及不適合的地方

OrcaRouter 不提供 Liquid AI d1-3B。我們在撰寫本文前查過自家目錄——207 個模型，其中沒有任何一個是 Liquid AI，也沒有任何一個是決策模型——所以如果你想透過 API 而非從自己的硬體呼叫 d1，目前代管途徑就是供應商自家的決策端點 api.liquid.ai/decisions/v1/systemone；在那裡，付費的 d1 層級可處理圖像，免費的 d1:free 層級則僅限文字，此外還有任何第三方平台採用它的情況。本文任何內容都不應被解讀為我們代管它的宣稱。

我們所做的，與這個模型所解決的問題相鄰。決策模型之所以存在，是因為管線需要一種便宜、確定性的方式在多個選項之間做選擇，而 d1 自己文件記載的範例，是一張被路由到目的團隊的工單——那是比我們低一層的路由問題。當那項決策決定是否要呼叫一個你租用而非自行運行的生成式模型時，OrcaRouter 就是一把相容於 OpenAI 的金鑰，可存取 200 多個託管模型，價格為供應商的定價，並以 0% 加價原樣傳遞，因此供應商降價在生效當天就會反映到你身上，而不是等到下一次合約續約。而且，由於這條管線的本地那一半是你擁有的那一半，風險就落在託管的那一半：跨供應商的自動容錯移轉會在你路由過去的模型掛掉時，讓一個已分類分流的請求繼續存活。這兩者都不是使用 3B 決策模型的理由。它們是決策另一端的那個東西不應該成為單點故障的理由。

什麼能讓這從一則包裝說明變成一個故事

五件事，任何一件都會改變這個判讀。Liquid AI 承認這個移植，或其文件索引把 Ollama 加入目前填著 llama.cpp 與 MLX 的部署列。第二種量化：Liquid 自家的 GGUF 儲存庫除了 Q8_0 之外還一併提供 Q4_K_M、F16 與 BF16，所以較小的本機建置在技術上是可取得的，只是不是透過這個套件。以及為 Liquid AI d1-omni-600M 提供本機路徑，這是擁有 587M 參數的兄弟模型，可讀取長達三十秒的音訊，且供應商將其標示為早期研究版本——對裝置端工作而言，那個模型會比 3B 更重要，而且目前在任何函式庫中都還看不到它的蹤影。一個獨立的 Decision Index 列，或一個公開排行榜條目，這是整個模型家族唯一缺少的一塊。以及 Ollama 把 d1 加入其決策能力頁面，這是一行就能完成的變更，會告訴你這個移植是獲得正式認可的，而非偶然為之。

在那之前，這個決定還算簡單，可以按你自己的方式來做。如果你已經在跑近期版本的 Ollama，pull 只要一行指令，下載量是 3.7 GB，而它所取代的，要不就是你不想拿客戶文字去發的託管呼叫，要不就是一個維護起來比模型本身價值還費工的 Python 環境。如果你需要在它擺到真實使用者面前之前，先取得準確度的獨立證據，那麼目前任何 d1 模型都還沒有這種證據，而再多的本地封裝也變不出來。

在自己的硬體上執行決策步驟時，也是檢視這類系統已出過哪些問題的好時機：涉及決策模型的已記錄 AI 事件與代理程式失效案例，都收錄在OrcaRouter AI Incident Archive，其中每個條目都附有自己的來源、嚴重程度、信心等級與爭議旗標。