Liquid AI d1-ultra vs Liquid AI d1-3B：每百萬 $0.042 的租用端點，還是你擁有的 2.87 GB 檢查點

Liquid AI d1-ultra的計價是每百萬個輸入 token 收費 0.042 美元，而且是在別人的資料中心、別人的加速器上運行。Liquid AI d1-3B每次呼叫的收費是零，而且是在桌上的一台 Jetson Orin Nano 上運行。這兩句話描述的是 Liquid AI 相隔八天推出的兩款模型——d1-3B 是 2026 年 10 月 7 日發表的開放權重檢查點，d1-ultra 則是 10 月 15 日推出的純 API 模型——而它們描述的是完全相同的工作：把一組由文字、圖像或兩者構成的狀態交給模型，再交給它一組具型別的提問，然後在單次前向傳遞中取回經過校準的答案，完全不生成任何輸出 token。兩者都不寫散文。兩者都不串流。它們之間的差異並不是抽象意義上的「哪一個比較聰明」，因為誠實的答案完全取決於你一天要問多少次。對於一款失效模式仍未有任何文獻記載的模型來說，真正有用的對照資料，是其他地方已經出過什麼錯的紀錄：這一類模型的已記載 AI 事故與代理失效案例，都蒐集在the OrcaRouter AI Incident Archive之中，其中每一筆紀錄都附有自己的來源、嚴重程度、可信度等級與爭議標記。

這套切入角度，正是這項比較比規格表更有價值的原因。d1-3B 與 d1-ultra 位於 Liquid AI 如今已在自家文件中明確表態的決策光譜兩端：你可以按 token 租用該系列中能力最強的模型，也可以擁有一個 312 億參數的模型，改以晶片、電力與工程時數支付成本。兩者都是現行產品。d1-ultra 是該公司最新推出的產品，而 d1-3B 大概是大多數讀者應該先從它開始的選擇。對特定管線而言，哪一個才合適，是一個帶有真正交叉點的算術問題，而且能用已公布的數字回答——接下來正是如此。

在進入數字之前，先做一則取材說明，因為這件事比數字的呈現方式更重要。以下幾乎所有內容都出自 Liquid AI 自家的說法：模型卡、10 月 7 日的開放權重文章，以及 10 月 15 日的 d1-ultra 文章。我們並未為本文獨立重現任何決策模型基準測試，而就我們所能判斷，也沒有其他人做過。若某項數字是我們根據已公布數值所做的計算，而非任何人的測量結果，該數字所在的句子會明確說明。

截至 2026 年 10 月中旬，每個模型實際上究竟是什麼

Liquid AI d1-3B 是一個開放權重、擁有 31.2 億參數的決策模型，以 LFM2.5-VL-3B 訓練而成，而後者是一個僅含解碼器的視覺語言模型。它搭載 SigLIP2 NaFlex 400M 視覺編碼器、32,768 個詞元的上下文視窗，以及 128,000 個詞元的詞彙表，可接受文字、JSON、圖像或其混合內容作為狀態，並在一次前向傳遞中回答一個或多個問題——Choice、Score，或 noul，也就是回傳 0 到 1 之間機率的是／否基本原語。權重以 LFM 開放授權條款發布於 Hugging Face，供應商稱其可免費使用，包括年營收低於 1,000 萬美元的商業用途。官方表示首日即支援 llama.cpp，並在 Apple、AMD、Qualcomm 與 NVIDIA 上提供 NVFP4 版本。

Liquid AI d1-ultra is the same shape of product pointed at a harder problem. It is API-only — there are no weights, no GGUF, no MLX or ONNX export, and the vendor's documentation index lists it in a row whose only downloadable artifact is the word "API". It was built, per the announcement, on "a larger open-weight model with a series of Liquid-specific heavy customizations," which is the entire architectural disclosure: no parameter count, no context window and no latency figure appear on the vendor's pages. Third-party gateway listings put the context window at 32,768 tokens and one listing has described it as roughly 8.3B total parameters with about 1.5B active per token, but those are catalogue entries, not vendor statements, and we treat them as unconfirmed. The model string is d1-ultra, on the same endpoint as d1: https://api.liquid.ai/decisions/v1/systemone.

那些段落之所以如此失衡，並非出於編輯偏頗，而是整個比較本身使然。d1-3B 的文件記錄詳盡到讓你在下載任何東西之前，就能估算硬體需求。d1-ultra 的文件記錄詳盡到只夠你呼叫它，除此之外別無其他。

這兩個指數數字並不在同一把尺上

每一篇關於這組數字的二手報導，都會把 65 和 48.57 並列，讓你得出那個顯而易見的結論。先讀標籤，因為這兩個數字是在不同的工具下發布的。

• 在 10 月 7 日的發布貼文中，d1-3B 於 Decision Index v0.2.1 公開分割上的成績為 48.57。廠商另外表示，該模型領先所有 10B 以下的模型，並與規模為其十二倍的 Decider 35B-A3B 持平。

• d1-ultra 的分數——65，在 10 月 15 日的貼文中被描述為領先 Artificial Analysis Decision Index 至少八分，並宣稱 d1-ultra 在所有任務上都勝過 Jev 1.14。針對該公告的媒體報導指出 Jev 1.14 為 57，這與領先八分相符。

有兩件事確實成立，值得直說。第一，d1-ultra 那個 65 背後的指數是第三方的，但這個數字是透過 Liquid AI 自家的公告、以及媒體對該公告的報導才傳到我們這裡的——我們自己無法載入任何顯示 65 的公開表格——所以在本文中，它屬於廠商自行回報的數據。第二，0.2.1 版的公開切分分數與未標示版本的指數分數，不保證落在同一個尺度上，而且 v0.3 指數有一個未公開的視覺切分，開源釋出版本明確並未針對它回報結果。請把這個落差當成方向性的指標——付費模型確實明顯更好——而不是 16.4 點的測量值。沒有人，包括我們在內，曾把這兩個模型放進同一套測試框架中跑過。

延遲：其中一個數字已公布，另一個則未公布。

開源模型的速度有異常詳盡的記錄，這使得付費模型上的遺漏更加顯眼。d1-3B 的模型卡指出，單一問題在 RTX 4090 上耗時 8 毫秒，在 AMD MI325X 上耗時 9 毫秒，在 Jetson AGX Thor 上耗時 16 毫秒，在 Jetson AGX Orin 64 GB 上耗時 26 毫秒，在 Apple M5 Pro 上耗時 30 毫秒，在 Jetson Orin Nano 上耗時 50 毫秒，而在 MI325X 上，批次吞吐量達到每秒 1,106 次決策。

那些是在具名硬體上的前向傳遞計時，而非端到端請求計時，而這個區別並非吹毛求疵。Liquid AI 上次公布決策模型的代管延遲——10 月 5 日介紹 d1 的文章——是文字決策 200 到 300 毫秒，那是包含排隊與網路的 API 往返時間，無法與本機顯示卡上 8 毫秒的一次傳遞相比。至於 d1-ultra，廠商完全沒有公布任何延遲數字，兩種形式都沒有。如果你的管線受延遲限制而非受準確度限制，那麼這個空缺就是本頁最重要的一件事：你目前無法得知那個昂貴的模型是否夠快，而唯一能查明的方法就是自己測量。

行銷頁面沒有做的那道算術

這裡正是兩個產品真正分道揚鑣的地方，而這是一個你可以用一張餐巾紙算出來的計算。以一個支援分流關卡為例：它每張工單會問一個 noul 問題，每月 200,000 張工單，每個問題約有 1,200 個輸入 token，其中包含一張小截圖。那相當於每月 2.4 億個輸入 token，而正是這個數量，讓每百萬 token 的費率變得一目了然。

• 在 d1-ultra 上，每百萬個輸入 token 為 $0.042，換算下來每月約 $10.08。在 d1-3B 上，每次呼叫為零，因此每月 $0.00，再加上硬體成本的任何費用。

• 一個 2.87 GB 的 Q8_0 建置版本能輕鬆裝進 Jetson Orin Nano。如果你買那台機器就是專門為了這個工作負載，那麼相對於代管端點的回本時間是以年為單位，而不是以週為單位——這是誠實的結論，也不是硬體廠商會印出來的那種說法。

• 把規模翻過來看。每月兩億個問題——兩千四百億個輸入 token——d1-ultra 的帳單大約是每月 $10,080，而本地自建版本照樣在吃同樣的電。這正是「自己持有 checkpoint」不再只是哲學偏好，而是變成帳上一筆實質開銷的地方。

三個但書，而它們全都指向同一個方向。上面每一個 token 數量都是我們選定的；你的狀態長度和圖片數量會不一樣，而圖片是以文字計費，每 32×32 像素區塊收 1.5 個 token，所以單一張 1024×1024 的圖片就是 1,536 個輸入 token。每個問題都各自算一則提示來計費，包含它的文字和所有圖片，所以對同一張截圖問三個問題，就得為那張截圖付三次錢。而這些全都沒把工程成本算進去：走本地路線換來的是得做量化選擇、得維持執行環境更新，還有一個在 3.12B 權重之前就先吃掉記憶體的視覺編碼器。如果你一個月呼叫模型幾千次，用代管端點還比開一場決定要不要自架的會議便宜。

每一個分別在什麼情況下不再是正確答案

Liquid AI d1-3B在下列任一條件成為關鍵限制時，就是正確的預設選擇：資料不能離開本地環境或裝置；網路往返延遲無法接受；使用量高到每次呼叫的計價成為主要成本；或者狀態是即時攝影機畫面或螢幕截圖，而你不願意將其傳送給第三方。供應商自己的說法也支持第一點——這次的開放釋出明確鎖定邊緣與裝置端部署，涵蓋 NVIDIA DGX、RTX 與 Jetson 硬體——而該檢查點在第一個月錄得的 17,820 次下載，顯示許多人很快就得出相同結論。

Liquid AI d1-ultra是正確答案，當決策本身才是難題時。知識密集的問題、需要對照真實世界脈絡的視覺主張——廠商自己舉的例子是電路板瑕疵，以及將損壞理賠與客戶照片進行比對——還有長尾案例，在這些案例中，3B 模型的信心根本不值得信賴。Liquid AI 對它提出的具體主張不只是準確度，還有校準：文章論稱，多數決策模型都過度自信，而 d1-ultra 經過訓練，使其機率值具有意義。如果你是以機率設閾值，而不是取 argmax——把高於 0.8 的任何項目路由到自動解決，其餘一切交給真人——校準就是整場勝負的關鍵，而這也是本次發布中最難讓外部人士查核的一項主張。

兩者皆不適用的情況也值得點名。如果你的答案是自由形式文字、多步驟追蹤紀錄或摘要，那麼決策模型就是錯誤的工具，而且供應商在自己的文件中也這麼說。如果你需要在狀態中加入音訊，而不只是文字和影像，家族中的第三位成員 d1-omni-600M 才是能勝任的那個——用 d1-ultra 來做那件事並不是升級，而是範疇錯誤。

將此融入你已在運行的技術堆疊中

決策模型幾乎從來不是整條流程的全部。它是那道閘門：決定一張工單是否緊急、一張照片是否為瑕疵、一次工具呼叫是否該放行的關鍵。但還是得有人把回覆寫出來，而在本地路線上，那個「有人」是你現在必須自行託管的第二個模型——這才是走向自架託管的真正成本，也是那項永遠不會出現在每 token 比較裡的成本。在中小量級下真正行得通的模式，是用法地端的 d1-3B 處理高頻率的閘門判斷，用租來的端點處理罕見的棘手案例，再搭配一把 OrcaRouter 金鑰來承接這些決策所分流到的生成式模型：單一 API 串接 200+ 個模型，以 0% 加價原價轉嫁供應商定價，以及跨供應商自動容錯移轉，因此單一上游的一個糟糕下午，不會把你的分流佇列變成堆積如山的待辦。值得把話講精確：這涵蓋了什麼、沒涵蓋什麼——我們不託管任何 Liquid AI 模型，所以決策呼叫本身會送到 Liquid AI 的 API 或本地檢查點，而 OrcaRouter 就是位於其後的東西。

一旦你不再把決策模型視為固定不變，這種比較就不再是二元的。路由 DSL 讓你能把便宜的閘門與昂貴的寫入器組合成單一呼叫，而 fusion 讓一組模型共同回答，當單一模型不夠可信時。這兩者都不是選擇 d1-ultra 而非 d1-3B 的理由。兩者都是這個選擇值得在實際運算量足以產生變化的規模下重新檢視的理由。

什麼會改變這個答案

三件事，依可能性排序。一份獨立基準測試，讓 d1-3B 和 d1-ultra 在相同任務上跑同一套測試框架——到那時候，48.57 與 65 的差距就會變成實測數據，而非方向性的猜測。d1-ultra 公布延遲數據，少了這個，任何對延遲敏感的流程都該把這個託管模型當成未知數，先在金絲雀路徑中測量它。以及最終以較大主幹為基礎推出的開放權重版本——從這個系列家族的歷史來看，這聽起來沒那麼牽強：其他每個一開始採託管形式的 d1 模型，最後都在兩天內變成可下載。

在那之前，這個經驗法則依然適用。先從 d1-3B 開始，因為它可以免費試用、在你可能已經擁有的硬體上速度很快，而且文件記錄得夠完善，讓你在正式投入前能妥善評估規模。把那些回過頭來看仍不具說服力的具體決策，移到 d1-ultra。兩者之間的差距確實存在；只是它比價格差異所暗示的還要小，而且遠比那些指標數字在沒有版本標籤並列印出時所暗示的差距小得多。