d1-Omni-2B 對比 MiniCPM5-2B：決策模型不是小型聊天模型

兩者都是開放權重，參數量都接近二十億，而且都鎖定放在桌上而非機櫃裡的硬體。相似之處僅止於此。d1-Omni-2B接收一個狀態——文字、JSON、影像、視訊影格、音訊——再加上一組具名問題，並在單次前向傳遞中回傳帶有校準機率的具型別答案。MiniCPM5-2B接收文字並寫出更多文字，一次一個 token 推理出答案。把其中一個換成另一個，既不是模型升級，也不是模型降級；而是改寫所有消費該回應的程式。因此，值得做的比較不是哪一個分數更高，而是你的管線實際能接受哪一種契約，以及為了履行它，各自在授權、延遲與部署工作上要讓你付出多少成本。

一次呼叫實際上會回傳什麼

d1 呼叫看起來像一份結構定義，而不是一段對話。你傳入 system_one 一個狀態和一個問題字典，每個問題都有一種型別——是/否、單選、多選、有序分數、文字範圍、數字、日期、一個或多個邊界框——然後你會取回每個問題的一個值，並附帶一個機率。模型卡自身的範例會將支援工單分流：退款旗標、依兩項指定準則做出的團隊指派，以及每一項的信心度。沒有長篇文字，沒有對話逐字稿，沒有輸出任何 token。卡片明白指出：它不是聊天模型。

那個設計就是整個產品。因為沒有解碼任何東西，所以沒有解析步驟、沒有 JSON 修復，也沒有針對把答案包在道歉裡的模型所設的重試迴圈。值會在你選定的閾值回傳，而當選項集中沒有任何適用項時，還有棄權路徑——Liquid 在該棄權測試上回報書面 78.5、口語 75.8。如果你的下游程式碼需要佇列指派和一個數字，這就是你要的形狀。

MiniCPM5-2B 呈現的則是相反的形態。它是一個標準的 Llama 架構解碼器，會先思考再回答，建構於一個 4,000 億 token 的深度思考 SFT 階段、領域 RL，以及一個同策略蒸餾步驟之上；該步驟將十六個專家教師整合進單一稠密檢查點。你絕對可以從它取得結構化輸出——它的函式呼叫分數相當不錯，而且 OpenBMB 為 vLLM 提供了工具解析器——但這是靠你在提示詞中提出要求，並信任解碼器會照做而得到的。推理本身就是這項特色。它也是你每次呼叫時所付費換取的東西。

不存在的正面交鋒

沒有任何一項基準測試同時跑過這兩個模型。這不是報告的缺口，而是上述分割所造成的結果。d1-Omni-2B 只出現在 Liquid 的決策套件中——DecisionBench v1 為 76.4、decisionbench.ai v4 為 84.7、Decision Index 公開套件 v0.3 為 49.0、ImajevBench v2.0-lite 為 72.3，以及在十八項基準測試上的未加權視覺平均 67.7。MiniCPM5-2B 只出現在 OpenBMB 的推理與代理套件中：34 項測試平均 53.9、LiveCodeBench v6 為 69.1、AIME 2025 為 86.5、SWE-bench Verified 為 46.4、BFCL v4 為 66.6，而在 Humanity's Last Exam 上僅有 8.9，顯得遜色許多。上述這些數字中，沒有任何一個與第一份清單中的任何數字，是在相同題目上、由相同評分者所測得。

任何人把這些分數並排列成兩欄表格，都是在拼湊；而這種拼湊比看起來更糟。d1-Omni-2B 的每一項數字都是廠商自行執行，且截至發表時，尚未經獨立重現。OpenBMB 的主打平均分也是廠商自行執行——該公司釋出了其訓練語料庫與 RL 框架，這比大多數實驗室做得更多，但那是方法的可重現性，不是分數的可重現性。

這些確實存在的獨立數字值得仔細閱讀，因為它們在不同索引版本之間彼此不一致。Artificial Analysis 在 9 月 7 日報導這次發布時，於其 v4.2 Intelligence Index 上給 MiniCPM5-2B 評了 15 分；目前即時頁面顯示的是 12 分；OpenBMB 自己宣稱的 23 分則是在 v4.1.1 上做出的。這三個數字既不代表退步，也不是爭議——是指標在它們底下改版了，而不同版本的分数不能相比。看趨勢方向，忽略具體數字。Artificial Analysis 完全沒有 d1-Omni-2B 或其同系列 d1-2B 的頁面，所以這個決策模型目前尚未有任何形式的獨立測量。

有一個看起來可轉移、其實不然的數字：Liquid 對其聊天模型 LFM3-1.7B 與 MiniCPM5-2B 進行了 27 項測試的比較，並以 23 比 4 勝出。該結果表示，Liquid 後訓練的解碼器在那些測試上勝過 OpenBMB 的。它完全沒有說明決策頭，後者從未出現在那次執行中，也不應被借用來裁定這個配對。

規格真正拉開差距的地方

• 輸出契約 — 具型別值搭配機率與零輸出權杖，對比帶有隱含推理軌跡的生成文字。這份清單上的其他一切都位於其下游。

• 大小 — 4.33GB 的 BF16 檢查點中有 2.17B 個參數，相較於總計 2.52B、非嵌入部分 1.98B，BF16 下約 5GB。差距夠小，單就佔用空間而言，兩者都無法勝出。

• 輸入 — 文字或 JSON 狀態、圖像、視訊幀與音訊，可在單一請求中混合使用，相較之下僅支援文字。MiniCPM5-2B 沒有視覺編碼器，也沒有音訊通路；若狀態中含有波形，此比較到此為止。若你想要 OpenBMB 的多模態系列，那是 MiniCPM-V 4.7，屬於不同家族，權衡取捨也不同。

• 上下文 — 128,000 個 token 對上 131,072 個。這是同一個數字以兩種方式表述，並不是選擇任一模型的理由。它唯一重要之處在於兩者都能容納長文件；d1-Omni-2B 的限制是，長篇口語段落會在視窗填滿前很久就降低其準確度，而規格卡也如此說明。

• 授權 — LFM Open License v1.0 設有 $10,000,000 的年營收門檻，相較之下，Apache-2.0 完全沒有任何條件。這是表格中最大的單一差異，而且與模型品質毫無關係。

• 執行階段 — 自訂建模程式碼依賴 trust_remote_code，需 Transformers 5.19 或更新版本，僅限 BF16，不提供廠商 GGUF，亦無文件記載的 vLLM 或 SGLang 途徑；對比未經修改的 Llama 工具鏈：vLLM、SGLang、llama.cpp、MLX、GPTQ、儲存庫中的官方 GGUF，以及已在流通的量化版本。

• 採用情況 — 該儲存庫於 10 月 24 日現身後四天內有 36 次下載與 10 個讚，相較之下，自 9 月 6 日以來則有 1,216,145 次下載與 1,823 個讚。附註：MiniCPM 的數字已有七週時間與一篇發布貼文，d1 的數字兩者皆無，因此應將其視為成熟度訊號，而非最終評斷。

五毫秒對上一個念頭

Liquid 公布 d1-Omni-2B 的暖呼叫延遲，測量方式為在 compile() 之後於 BF16 下進行，取二十次呼叫的中位數。在 H100 PCIe 上，單一問題耗時 5.8ms，三個問題 7.7ms，5,000 個 token 的狀態 52ms，384 像素影像 12.1ms，十秒音訊 12.4ms。每次呼叫以 64 個狀態批次處理時，每秒可執行 1,154 個狀態；而 MI325X 更快，為 3.7ms 與每秒 1,697 個狀態。M5 Pro 在單一問題上為 21.1ms，每秒 110 個狀態——與資料中心顯示卡相比算慢，但仍快到在桌面應用程式內感覺即時。

這不是一場公平的競賽，因為另一方不公布時間。從結構上能說的是，解碼器的延遲會隨著它思考多少而增加，而 MiniCPM5-2B 就是一個為思考而打造的模型。在路由或分診呼叫中——正確答案只是四個佇列名稱之一——你卻要為沒人要求的理由說明付費，而且還要按 token 為此付費。Artificial Analysis 為此給出了一個數字：在其 Intelligence Index 測試中，該模型輸出了 7400 萬個輸出 token，而可比模型的中位數為 6700 萬個，其摘要稱這「有些冗長」。這並不是反對該模型的理由；而是反對把它用在 d1-Omni-2B 所為之打造的角色上的理由。

對 d1 的數字要抱持一貫的審慎態度。這些是廠商測量值，是在特定硬體上並經過編譯步驟取得的，而獨立重跑幾乎肯定會落在不同的結果。真正經得起考驗的，是數量級——每次決策只需個位數毫秒。

凌駕於計分板之上的授權條款

MiniCPM5-2B 以 Apache-2.0 授權發布。您可以將其用於商業用途、建立分支、重新散布、嵌入產品，而且永遠不必為此諮詢律師。d1-Omni-2B 以 LFM Open License v1.0 授權發布，該授權僅在您的組織年營收低於 $10,000,000 時授予商業使用權。達到或超過該門檻時，授權條款載明商業使用「不依本協議授權」——意思是您需要與 Liquid AI 另行達成安排，否則就不得發布該模型。

兩者都允許再散布，但 LFM 這一側附有條件：將授權條款一併傳遞、標記修改過的檔案、保留相關聲明。沒有重新品牌化的要求。對研究團隊、原型專案，或一家明顯低於門檻的公司而言，那條款只是形式。對一家可能在模型有效生命週期內跨過門檻的公司的產品團隊而言，這會是第一個基準測試都還沒出爐就先報到的採購問題——而且這種事往往由法務在架構定案後才姍姍來遲地發現。

這種不對稱性足夠明顯，應該毫不含糊地指出：單就授權而言，MiniCPM5-2B 對任何商業部署都是較穩妥的選擇，而 d1-Omni-2B 的授權是選擇它的一項實際成本，並非附註。

你今天實際能跑哪一個？

MiniCPM5-2B 部署起來平淡無奇，而這是對這個尺寸的模型所能給予的最高讚美。它是標準解碼器，因此 vLLM 和 SGLang 無需修補即可支援，llama.cpp 和 LM Studio 可直接讀取 GGUF，MLX 涵蓋 Apple silicon，而 Q4_K_M 版本約為 1.45GB。唯一的陷阱是工具呼叫：模型會發出 XML 風格的呼叫，因此 vLLM 需要啟用minicpm5 工具呼叫解析器，否則你的函式呼叫會以一般文字形式送達。

d1-Omni-2B 還沒到乏味的地步。要載入它，得使用較新的 Transformers，並搭配 trust_remote_code=True，再加上 torch、torchvision 和 Pillow；該儲存庫只提供 BF16 safetensors，別無其他。它沒有廠商提供的 GGUF，模型卡裡也沒有合併好的 vLLM 配方，而且 Hugging Face 並未為它列出任何推論供應商——因此沒有可測試的託管端點，這也是為什麼沒有託管價格可報。多數人會採行的實務做法是使用 Ollama 標籤 d1-omni:2b，這是一個 4.4GB 的社群封裝，包裝了相同的權重。這行得通。這也是開發者能在一個下午內試用這個模型的唯一原因，而這是第三方的工作成果，不是 Liquid 的。

這兩個模型都沒有公布每個 token 的價格，因為兩者都不是按 token 販售。你找到的任何每百萬 token 數字，都是從 GPU 租賃成本推算而來，而不是供應商報價。如果你要比較成本，請以一次決策花費多少秒 GPU 時間來比較——並記住：決策模型在呼叫返回時答案就完成了，而聊天模型則要等到它停止思考才算完成。

同時使用兩者的模式

這項比較的誠實結論是：它們並不是競爭對手，而有用的架構也正是這樣看待它們。d1-Omni-2B 負責低成本、高吞吐量、對延遲敏感的判斷：哪個佇列、哪個團隊、這是不是同一張發票、有多緊急、這十二個箱子中該選哪一個。它在本機執行，回傳一個你可以設定閾值的數字，並且在不知道時選擇不表態。

MiniCPM5-2B 負責需要語言的部分：向客戶解釋決策、草擬回覆、撰寫修正內容、呼叫鏈結中的下一個工具。它在第一項工作上較差，在第二項工作上較好，而這樣分工的唯一成本，就是兩者之間的一次函式呼叫——這條路由只有在便宜模型的信心低於你的門檻時，才會升級到昂貴模型。這個升級層正是路由平台派得上用場的地方：一組 API 金鑰即可橫跨 200+ 個模型，對供應商列表價格零加成、供應商出狀況時自動容錯切換，還有路由 DSL 讓你能把多個模型組合在單次呼叫背後。d1-Omni-2B 和 MiniCPM5-2B 目前都不在 OrcaRouter 的目錄中，所以這個模式的決策那一半暫時仍得自行託管——但生成的那一半，也就是當更好的小型模型問世時你會想替換的那一半，正是值得交給路由、而非硬編碼的那一半。

誰應該選哪個？

當狀態包含音訊或視訊時、當你需要的是機率而非句子時、當答案必須是邊界框、文字片段，或帶有範圍的數字時，以及當呼叫身處迴圈中，而 6ms 和 78ms 代表不同產品時，就採用 d1-Omni-2B。採用時要明白授權門檻適用於你、部署屬於自訂程式碼的範疇，而且目前尚無獨立評測——Liquid 自家的模型卡把沒有音訊需求的人指向 d1-2B，這比多數廠商主動提供的指引更誠實。

當輸入是文字時、當輸出必須由人類閱讀，或要餵給需要自然語言敘述的工具時、當你需要跨長篇文件進行推理時，以及當 Apache-2.0 與標準 Llama 部署路徑能在你寫下任何一行程式碼之前排除兩類風險時，採用 MiniCPM5-2B。採用它時要明白：供應商所稱的 53.9 平均分尚未被重現；它在現行指數上的獨立分數是 12——遠高於同尺寸級別模型的中位數 5，且不能與早期版本記錄的 15 或 23 相比——而它最弱的已公布結果 Terminal-Bench 8.6 與 SWE-bench Pro 14.4，正是最接近代理式工作的項目，而那也是它行銷最力的領域。

而如果你真正想要的是一個能看的小型聊天模型，那這兩個都別選。MiniCPM5-2B 不能看，d1-Omni-2B 不會聊天，而人們把這兩個名字之一輸入搜尋框時通常指的那個模型，其實是同系列家族中的另一個。要留意的是 d1-Omni-2B 首個獨立音訊評測。它的口語語言結果——在 43 種語言上 FLEURS 得 92.5，但書面 42.0 在短狀態下轉為聽測時跌至 22.8，多語言段落則從 83.6 降至 41.8——描述的是一個擅長辨識語言、卻在理解朗讀段落上很脆弱的模型。直到 Liquid 之外的某個人測量出這個落差之前，語音輸入這個用例只是一個附帶數字的承諾，而不是結果。