d1-omni 對上 Liquid AI D1 Ultra：一個 850MB 檔案對上 0.042 美元的計價單位，而這筆算術並非如你所料

當你把d1-omni放到Liquid AI D1 Ultra旁邊時，直覺會認為它們佔據同一光譜的兩端，而這個選擇關乎野心。一個是 587M 參數的開放權重模型——本週出現在 Ollama 模型庫中的標籤在磁碟上為 850MB，這個檢查點自 2026 年 10 月 5 日起已從 Hugging Face 被下載約 13,900 次。另一個是 Liquid AI 的旗艦決策模型，於 2026 年 10 月 15 日發布，未披露參數數量、未公布權重，而唯一公布、且比任何基準測試都更重要的數字是：每百萬輸入 token 0.042 美元。租用前沿決策模型，對比擁有一個小型模型，聽起來像是預算問題。但拿真實工作負載來跑計費表，這多半就不再是預算問題了——小型模型的優勢不在於它便宜，而在於它是屬於你的。

這個區別值得精確釐清，因為被比較的兩者並不是同一個貨架上的兩個模型。Liquid AI D1 Ultra 是你呼叫的端點。d1-omni 是你執行的檔案。兩者都回答相同的三種問題形式——帶機率的是/否、每個標籤各帶機率的標籤，或量表上的位置——而且兩者都在單次前向傳遞中回傳這些答案，生成零個輸出 token。此後的一切，包括這些答案的成本，以及當它們漂移時由誰負責，都取決於你選了這兩者中的哪一個。

租賃面，按 Liquid AI 實際計費的方式定價

Liquid AI D1 Ultra 僅對輸入收費，每百萬個輸入 token 收費 0.042 美元，且不收取補全費用，因為它沒有補全。這就是完整的價目表，而有趣的部分是其下的圖片規則。圖片按文字費率以圖塊為單位計費：每個 32×32 像素圖塊 1.5 個 token，因此一張 1024×1024 圖片為 1,536 個 token。而且每個問題都作為各自的提示詞計費，各自攜帶一份狀態副本和所有附加圖片。對同一張照片問四個問題，你就要為那張照片付四次費用。

為一個最適合用視覺判斷來處理的工作負載估算一下數字。假設每晚要批次處理 25,000 筆商品刊登，每筆都有一張 1024×1024 的照片，以及約 200 個 token 的刊登文字，並提出兩個指定類型的問題——一個是/否問題，詢問圖片是否符合分類；一個評分問題，評估圖片品質。每個提示包含 1,536 個圖片 token 加上 200 個文字 token，共 1,736 個 token；由於有兩個問題，因此每筆商品刊登為 3,472 個 token。這趟批次處理的輸入 token 為 8,680 萬個，約 3.65 美元。若每晚執行、整月下來，費用會落在數百美元的低檔。

對任何假設前沿選項就是昂貴選項的人來說，這著實是個令人不安的結果。原因就在定價模型：決策模型從不輸出 token，因此成本曲線沒有會暴增的輸出項，而每題重新計費是可預先規劃的固定乘數，而不是等到帳單才發現的變數。

己方，以及其成本究竟藏在何處

d1-omni 完全沒有按次計價。它是一個 587M 參數的模型——381M 的共享主幹與決策頭、一個沿用自 Liquid AI LFM2.5-VL-450M 的 94M SigLIP2 視覺編碼器，以及一個 112M 音訊編碼器——依 Liquid 的 LFM 1.0 條款發布，GGUF 版本隨後於 10 月 6 日推出，MLX 版本於 10 月 12 日推出。它的成本就是你已經擁有的硬體，再加上比較表裡沒人會列出的那一部分：讓它繼續維持運作的工夫。

就決定部署的各個面向而言，這兩個選項有哪些共同點、哪些不同點：

• 權重 — d1-omni 已依 LFM 1.0 發布；Liquid AI D1 Ultra 則未發布。 Liquid 僅將其旗艦模型描述為「基於一個更大的開放權重模型，並經過一系列 Liquid 專屬的深度自訂」。基礎模型是開放的；你所呼叫的模型則不是。

• 參數量 — d1-omni 為 587M，且已完整逐項列出；d1-ultra 則未公開。 你無法為旗艦型號規劃硬體規模，因為 Liquid 尚未公布規模。你可以精確地為 600M 規劃硬體規模：Ollama 的混合 Q8_0 標籤為 850MB，BF16 標籤為 1.2GB。

• 價格 — d1-omni 沒有按次計費；d1-ultra 每百萬輸入 token 為 $0.042，圖片以每 32×32 區塊 1.5 個 token 計算，且每次提問都會以完整狀態重新計費。

• 模態 — d1-omni 接受文字加圖片，或文字加上最多 30 秒的音訊，但同一個請求中絕不會兩者並用。 d1-ultra 被描述為多模態，但未公布模態細分；Liquid 文件所說明的是問題類型與圖片 token 規則。

• 上下文 — d1-omni 在文字、圖像與音訊位置上合計為 16,384 個 token，每當附上圖像時，「依訓練設定」會縮減為 896 個 token 的狀態與問題文字。d1-ultra 尚未公布任何上下文數字。

• 延遲 — d1-omni 沒有已公布的推論數據，因為 Liquid 表示，對於其稱為仍在積極開發中的早期研究版本的檢查點，不會公布這些數據；d1-ultra 是以端到端方式提供服務，也未另行公布延遲數字。

• 校準——旗艦模型是明確為此接受訓練的。Liquid 提出的理由是，大多數決策模型都過度自信，因此 d1-ultra 經過調校，以產生更可靠的機率。d1-omni 自身帶有 校準標籤，但 600M 是實驗性檢查點，且尚無第三方測量過這兩個模型的校準。

這兩個分數不是同一把尺

把 15.95 寫在旗艦模型旁邊然後相減，這很誘人。不要這麼做。d1-omni 的 15.95 來自 Decision Index v0.2.1 的公開分割，那是 Liquid AI 用官方評分器為自家項目打分、而非提交參賽的榜單——子分數為 Knowledge 8.3、Language 12.9、Retrieval 35.0、Tools 15.1、Arts 6.8，相較於同家族中 d1-3B 的 48.57。Liquid 對 d1-ultra 的主張是：在 Artificial Analysis Decision Index 上以至少八分的優勢拿下第一名，但那是另一個榜單、另一個版本，且是在該旗艦模型問世之前發布的。這兩個數字是用不同的尺衡量不同的東西；誠實解讀這對數字，只能說差距很大——不能說差距是四十幾分。

經得起比較的數字，正是沒有人公布的那個：600M 完全沒有推論數據，所以若不親自實測，你就無法說明它在你自己硬體上每次決策的成本。做出自建或租用抉擇的依據，是那項實測，而不是排行榜。

三種工作負載，三種不同答案

• 每晚一批 25,000 次影像檢查 — 在 Liquid AI D1 Ultra 上每次執行約 $3.65，而在 d1-omni 上則是 1.2GB 的下載，加上你自己指定的任何 GPU。在這個用量規模下，計費錶不是決定性因素；決定性因素是你是否想要旗艦機型所宣稱的準確度，以及每晚三美元是否比維護一台模型伺服器更值得。

• 一道硬性關卡，其中機率就是決策——核准、審核裁決、在門檻觸發的交易。在這裡，校準就是產品本身，而 d1-ultra 是兩者中唯一一個 Liquid 表示專門為此訓練的模型。一個自信但錯誤的 0.6 機率，比完全沒有機率更糟，而且目前還沒有第三方針對這點檢查過這兩個模型中的任何一個。如果門檻事關重大，你會希望在邊界上信任它之前，先重現廠商的校準主張。

• 裝置端的高吞吐、低風險分類器——將語音指令路由、分流收件匣、標記刊登項目以供人工審查。這樣的工作負載完全不需要託管式前沿模型。600M 能在 850MB 中透過單次前向傳遞回傳具型別的答案，這正是它存在的全部理由；而 896 個 token 的圖像預算，對於一句狀態描述和一張照片來說已經足夠。

路由邊界實際上位於何處

這兩款模型都不在我們的目錄中，而且值得直言不諱，而不是暗示相反：每一次 Liquid AI d1-omni-600M 呼叫和每一次 Liquid AI d1-ultra 呼叫，都是前往你自己的硬體，或供應商自家的 API 與第三方平台，而不是經過我們。OrcaRouter 涵蓋的是流程中決策模型無法自行完成的那一半。一個 587M 的決策模型會回傳標籤或機率然後就停止；仍然需要有一個環節來撰寫回覆、摘要案例，或依據分數採取行動。一套 API 支援 200+ 款模型，並將各供應商的定價原樣傳遞，且在經分流的請求需要分送到多個模型時可使用路由 DSL，這種說法比「我們託管決策模型」更為低調，但它是真實的。

什麼會改變答案？

目前這項比較取決於兩項資訊缺口。Liquid AI D1 Ultra 沒有公布參數量，因此無法相對於它正在執行的工作規模來推斷其每 token 成本；它也沒有延遲數據，因此若不實測，就無法圍繞它設計互動式路徑。而 d1-omni 則是廠商自行選擇不公布推論數據，因此在自建與租用的計算中，有一邊只能靠你自己硬體的基準測試來補足。

只要這兩者中任一項成交，決策的形狀就會改變。d1-ultra 的獨立校準結果將能底定閘門工作負載，而它的價格早已比多數人猜的還便宜一個數量級。若能取得 Liquid 公布 600M 的延遲數字，使用者就能有信心地把它放進互動式路徑，而不必先測試。在那之前，安全的判讀既狹窄又不起眼：旗艦款的定價已接近免費，單靠預算不會促使你自行執行任何東西；而 600M 的真正優勢在於，一旦你拿到檔案，就沒有人能從你腳下改變數字、條款或端點。

像這次發布背後有紀錄的 AI 失敗與代理事件，都收錄於 OrcaRouter AI Incident Archive，其中每一筆條目都附有各自的來源、嚴重程度、信心評級與爭議標記。