Liquid AI d1 對比 Liquid AI d1-3B：Ollama 函式庫稱之為一個模型，而廠商卻稱之為兩個模型

同一組權重有兩種命名方式，而 Liquid AI d1 與 Liquid AI d1-3B 比任何參數比較都更能說明其差異。從第二個名稱去掉一個連字號與一個大小後綴，就會得到第一個，因此很容易把較短的字串視為暱稱。真正列出這些模型的兩份目錄並不認同這種解讀。Liquid AI 自家的文件索引將 d1 保留在獨立的一列，並在下載連結的位置標示「API」，同時將 d1-3B 與 d1-omni-600M 放在另一組兩列中，附有可用的 Hugging Face 與 GGUF 連結，且在可訓練欄位標示「No」。Ollama 的函式庫條目正是這個組合值得書寫的原因；它把所有內容收攏到一個名為 d1 的頁面，用一行文字描述為「一個來自 Liquid AI、建構於 LFM2.5-VL-3B 的 3B 決策模型」，並在下方恰好提供三個標籤。比較 Liquid AI d1 與 Liquid AI d1-3B 因此並不是在比較託管端點與開放檢查點，也不是在比較兩個檢查點。它比較的是一個託管端點，以及當你不加限定地說出這個詞時，本地執行環境生態系已認定為 d1 的那個開放檢查點。後續大部分內容，是在談你的部署實際上依賴的是上述哪一種解讀。

關於下列數據的來源說明：坦誠比呈現格式更重要。這裡所有數值都出自 Liquid AI 自家的報告，見於模型卡或 10 月 7 日的發布文章。Decision Index 的各列是由廠商以官方評分工具評分，而非提交公開排名；而且就我們所能找到的資料，沒有任何第三方獨立重現過任何 d1 結果。若某個數字是對已公布數值進行運算而得，而非實測結果，文中會加以註明。

這兩個名字從何而來

較短的名稱較早出現。Liquid AI 在 10 月 5 日的貼文中，以 Liquid AI d1 推出該模型——「我們的第一個決策模型」，在該版本中為多模態，能在單次前向傳遞中，針對由文字、圖像或兩者構成的狀態回答輸入的提問，且輸出 token 為零。該貼文列出託管價格為每百萬輸入 token 0.04 美元，僅就輸入 token 計費，並指出圖像與文字同樣計費，每 32×32 區塊以 1.5 個 token 計算，因此一張 1024×1024 的圖像需花費 1,536 個 token。文中也給出文字決策延遲為 200–300 毫秒。那些都是託管服務的數字，而貼文明確表示，其背後的執行環境是供應商自家的決策端點 api.liquid.ai/decisions/v1/systemone。

較長的名稱出現在 10 月 7 日的貼文和 Hugging Face 上，而它正是帶有可重現細節的那個名稱：3.12B 參數、32,768 個 token 的上下文、128,000 個 token 的詞彙表、十六種有文件記載的語言、一個 SigLIP2 NaFlex 形狀最佳化的 400M 視覺編碼器，以及基礎鏈 LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B。那張卡片也明白指出，該模型不是聊天模型，也不會撰寫文字。這正是整個本機生態系所建構其上的檢查點：GGUF 儲存庫收錄了 1.67 GB 的 Q4_K_M、2.87 GB 的 Q8_0，以及各為 5.4 GB 的 F16 與 BF16。

沒有哪份廠商文件會明說的是，Liquid AI d1 與 Liquid AI d1-3B 是同一組權重。文件索引把它們分配成不同的列。發布文章稱 d1 是一個系列，而非單一檢查點。第三方報導已注意到這個落差，並指出廠商尚未確認這項等同關係。所以誠實的說法很短：這兩個名稱所公布的數字，在我們能找到的任何地方都不衝突；系列發布與實際提供服務的端點相隔兩天宣布，且描述相容；而廠商並沒有說它們是同一個模型。把這種等同性當作合理的工作假設，而不是廠商已經具名背書的事實。

本機組建實際上會變更什麼

Ollama 的條目並非重新發布，也不是新的檢查點。這是一項封裝決策，而這種封裝帶來三項限制，廠商自家文件卻完全沒有提及。第一項是標籤清單：d1:latest、d1:3b 和 d1:3b-q8_0，三個標籤指向同一個量化版本。Liquid 所發布的 GGUF 儲存庫包含四種精度，而 1.67 GB 的 Q4_K_M——多數人在筆電上會選用的那個——並不在 Ollama 的標籤之中。你能拉取的是 2.87 GB 的 Q8_0，以及它在本機儲存中解壓後所佔的空間；模型庫頁面回報的下載大小為 3.7 GB。

第二個是請求契約。Ollama 在 /v1/systemone 上回應這些模型，接收一個 state 加上一個 questions 物件，並傳回帶有 output_tokens: 0 的具型別回答。這與廠商託管端點使用的結構相同，也正是這件事讓本地與託管之間的切換成為一項設定變更，而不是一次重寫。第三項限制位於 Ollama 的端點文件，而非模型頁面上，而且它比生成式模型的限制更嚴格：請求在沒有圖片時必須在 64 KiB 以內，有圖片時則必須在 32 MiB 以內；不支援串流；雲端託管的模型會被拒絕；而圖片必須是放在請求主體中的 base64 PNG、JPEG 或 WebP——遠端 URL 一律不受理。同一個請求中的每個問題會共用這些圖片，所以你只想讓某一個答案參考的圖片，就必須單獨發一次呼叫。輸入永遠不會被截斷，這意味著過大的 state 會傳回錯誤，而不是被悄悄裁掉。那是比較好的失敗模式，但它仍然是你的客戶端必須處理的一種失敗模式。

有兩個文件細節仍未解決，而且在提交錯誤報告前值得先知道。Ollama 的端點參考文件將選擇題類型描述為接受 2 到 255 個選項鍵，但其決策模型功能頁面卻說 2 到 26；兩者其中一個已經過時。而且該功能頁面將其支援的模型列為 Nimble、Tev1、Clef 和 Clef Flash，完全沒提到 d1——即使 d1 套件自己的 README 記錄了對 /v1/systemone 和 --ask 的支援，而且該套件要求 Ollama 0.40.4，而端點自身文件記載的最低版本卻是 0.35.0。請看套件上的版本需求，而不是指南裡的那個。

這些數字，以及它們是以哪個名稱發表的

這是配對中最容易出錯的部分，因為這兩個名稱都公布了績效數據，而這些數據的整理方式並非如你所預期。

• 決策指數 0.2.1 — 48.57，發佈於Liquid AI d1-3B。Liquid 將其描述為參數低於 10B 的決策模型中的最佳分數，並稱其領先於得分 47.11 的 35B-A3B 模型。• 文字決策延遲 — 200–300 毫秒，發佈於Liquid AI d1的託管 API 文章中。開放權重檢查點本身的名稱並未附有對應的數據。• 本地硬體上的單題延遲 — 在 RTX 4090 上為 8 毫秒，在 Jetson AGX Thor 上為 16 毫秒，在 Jetson AGX Orin 64 GB 上為 26 毫秒，在 Orin Nano 上為 50 毫秒，在 Apple M5 Pro 上為 30 毫秒。發佈於Liquid AI d1-3B。• 吞吐量 — 將問題打包成批次後，在 RTX 4090 上每秒可處理 475 次決策，在 AMD MI325X 上每秒可處理 1,106 次。發佈於Liquid AI d1-3B。• 視覺 — 在十一項公開圖像基準測試中平均為 74.1，而其所建構基礎 LFM2.5-VL-3B 則為 73.9。發佈於Liquid AI d1-3B。• 圖像消融 — 移除圖像後以同一組問題作答得分為 45.1，這是廠商自身對視覺路徑貢獻程度的衡量。發佈於Liquid AI d1-3B。

那份清單衍生出兩個問題，而兩者都不致命，這正是它們被忽略的原因。託管端的數字和本地端的數字相差 25 到 37 倍——200–300 毫秒對上 8 毫秒——而且它們是在供應商未以可比較方式描述的項目上測得的。把這個差距解讀為「本地更快」並不成立，因為託管端數字是透過 API 的端到端結果，而 8 毫秒是在某款具名 GPU 上的前向傳遞。它們不是同一種測量，而供應商也從未主張它們是。

第二個問題是視覺那一列。在十一項圖像基準測試中，相較於基礎模型提升 0.2 點，仍落在大多數基準測試報告的雜訊範圍內，所以無論決策頭帶來什麼，都不是實質上更好的圖像編碼器。消融那一列反方向的表現看起來亮眼得多——加入圖像後出現約 29 點的差距——但它比較的是兩組不同的問題集，而不是同一個問題集的兩個版本，Liquid 在文章中也這麼說明了。這兩列都有用。但兩者都不足以支持關於視覺決策品質的強烈主張，而且也沒有任何第三方跑過其中任何一項。

這兩個名稱在實務上分歧之處

對買家而言，這個區別歸結為四個問題，而答案未必都指向同一個方向。

• 成本結構 — Liquid AI d1按輸入 token 計費，採廠商公布的費率，且完全沒有輸出 token 的費用。Liquid AI d1-3B在 Ollama 的封裝中是 2.87 GB 的下載檔，或從廠商的 GGUF 儲存庫取得時為 1.67 GB，完全沒有按次呼叫的計量。• 延遲，可量測 —— 託管路線標示每次文字判斷為 200–300 毫秒。本地路線公布的 8 毫秒，是在模型已預熱的 RTX 4090 上進行一次前向傳遞，這是真實數字，而非一次請求往返。• 資料路徑 —— 託管路線會把狀態送到廠商那裡。本地路線則將它留在機器上，而對於客服工單、醫療紀錄或一張照片而言，這通常是終結爭論的決定性論點。• 版本鎖定 —— Liquid AI d1放在端點之後，就是廠商今天正在提供的版本。Liquid AI d1-3B在 Ollama 中則是你所掌控的固定套件，而交換條件是升級得由你自己負責。

這四點背後那個令人尷尬的現實是：開放權重檢查點是託管模型的兄弟，而非它的替代品，而廠商也未曾表示不然。開放檢查點的模型卡建議將它用於路由與分流、內容審核、意圖分類、擷取檢查、重排序、LLM 擔任評審，以及護欄，並描述它是在 LFM2.5-VL-3B 上後訓練而成，用於單次通過的校準決策。託管版本的發布文以不同措辭描述了同一組任務，並引用了託管價格。若兩者是同一個模型，那麼本地版本就是託管產品的免費副本，而實驗室若真如此出貨卻不說明，將是極不尋常的事。若兩者是同一個基礎模型的兩個微調版本，那麼已公布的數據就不應被假定能往任一方向移轉。第二種解釋對廠商的要求較低，也更符合我們手邊的證據。

在不運行兩套堆疊的情況下，同時執行決策的兩個部分

不論你最後選定哪個名稱，圍繞它的流程通常看起來都一樣。支援佇列會收到一個關於目的地團隊的選擇題、一個關於是否要求退款的 noul 問題，以及一個關於急迫性的分數題——一個狀態、三個答案、一次通過。這兩個名稱真正分歧的地方，在於決策把關著對一個你租用而非自建的生成式模型發出呼叫的那一刻。那個呼叫是另一個問題，有著不同的失效樣態，而它正是流程中 d1 正確與否最不重要的部分：一個機率 0.98 的路由答案，接著是你所路由到的模型回傳 502，無論如何都是一次失敗的請求。

我們不代管任何 Liquid AI 模型——寫這篇之前我們查過自家目錄——所以這裡沒有任何一句話是在說可以透過我們呼叫這些權重。我們做的，是決策另一側的那一層：一把與 OpenAI 相容的密鑰，對應分流後的請求會擴散到的各家模型，依各供應商的原價轉手、0% 加價，因此供應商降價當天就會反映到你身上，而不是等到合約續約，並具備跨供應商的自動容錯移轉，讓分流後的請求即使被路由到的模型掛掉也還撐得住。如果你是第一次把決策模型接進管線，這正是值得把它弄得無聊的那一半。

依情況使用哪個名稱

如果你想在本週試用這個模型，又沒有值得維護的 Python 環境，請使用本機執行環境所採用的名稱。請把Liquid AI d1從函式庫拉取，接受 Q8_0 和 3.7 GB，並把 64 KiB 的請求上限與禁止串流規則當成設計限制，而不是麻煩。你在第一天就能得到真正的端點、真正具型別的答案，而且沒有每次呼叫的計量。

如果你需要比 Q8_0 更小的佔用空間，要使用的名稱是Liquid AI d1-3B，因為 1.67 GB 的 Q4_K_M 版本存在於供應商的 GGUF 儲存庫中，而不在函式庫条目裡。這個單一事實是現今這兩個名稱之間最實際的差異，也是最容易被那些讀了函式庫頁面就停下來的人所忽略的一點。

如果你要把這東西推到付費用戶面前，而且需要先有準確度證據，那這兩個名稱目前都幫不了你。我們找不到任何對 d1 模型的獨立評估，Decision Index 的各列是自行評分的，而且供應商根本沒有發布任何音訊決策基準。你可以做的是，對模型已經回傳的信心值進行量測——0 到 1，反映的是機率有多強烈地偏向某一個答案，而不是那個答案有多可能是正確的——並在你自己的流量上找出這東西在哪些地方不確定。這項量測比上面任何投影片都更有價值，而且只需要一天。

決策模型是整條流程中便宜的那一半。它負責路由到的生成模型，才是需要合約的那一半——一把相容 OpenAI 的金鑰承載經分流後的請求所分派到的各個模型，每個都按供應商定價原樣轉嫁，0% 加價。

將蒸餾檢查點對照其自身的完整發行版來縮減規模，也是檢視紀錄的好時機：與小型 Liquid 模型相關、有文獻記載的 AI 事件與代理失敗，都收集在OrcaRouter AI Incident Archive，其中每筆條目都附有各自的來源、嚴重性、可信度等級與爭議標記。