Liquid AI d1-3B vs Granite 4.2 3B：兩個永遠不會執行相同任務的 3B 模型

把 Liquid AI d1-3B 和 Granite 4.2 3B 放上同一張 GPU，兩者都能輕鬆裝得下——一邊是 3.12B 參數，另一邊是 3B。它們的表現也會像是來自不同學科。Granite 4.2 3B（IBM 自家的模型卡標註日期為 2026 年 8 月 25 日）是一個推理模型：三種思考模式、一個 <think> 區塊，以及你所閱讀的答案。Liquid AI d1-3B 於 2026 年 10 月 5 日上傳到 Hugging Face，並由 Liquid 在兩天後發布，是一個決策模型：它接收一個狀態加上一組明確的具型別問題，並在一次前向傳遞中回傳一個機率、一個標籤或一個尺度上的位置，並回報 output_tokens: 0，因為它從不寫出任何內容。有用的問題不是哪一個比較好，而是你的哪些呼叫實際上是一項決策，因為這兩個 repo 是為那個分野的相反兩半而打造的。

每個儲存庫裡實際上有些什麼？

以下所有內容均來自這兩份模型卡與 Liquid 的公告文章。這裡沒有任何內容經過獨立重現，也沒有第三方在同一套評估框架上對任一模型進行評分，而模型卡中的數字是廠商自己的。

• 規模 — Liquid AI d1-3B 總計 3.12B，建構於 Liquid 的 LFM2.5-VL-3B；Granite 4.2 3B 是一個 3B 的僅解碼器稠密 Transformer，建構於 granite-4.1-3b-base

• 輸出 — d1-3 會回傳機率、標籤與信心值，且完全不輸出任何文字；Granite 4.2 3B 會產生 token，包括可選的思維鏈，內含於 <think> 標籤

• 上下文 — d1-3B 32,768 個 token；Granite 4.2 3B 原生支援 128K，並在模型卡上提供延伸至 512K 的長上下文擴充

• 輸入 — d1-3B 文字、JSON、圖像或混合內容，透過 SigLIP2 NaFlex 400M 視覺編碼器；Granite 4.2 3B 僅限文字

• 授權 — d1-3B 採用 Liquid 的 LFM Open License v1.0；Granite 4.2 3B 採用 Apache 2.0

• 語言 —— d1-3B 列出 16 種；Granite 4.2 3B 列出十二種已測試，卡片並註明其他尚未測試

• 服務 — d1-3B 隨附自訂程式碼（trust_remote_code=True，transformers>=5.14），同一系列中有 GGUF 與 w8a8 儲存庫，並為 llama.cpp、Ollama 和 vLLM 記錄了模型卡；Granite 4.2 3B 可在 vLLM 0.20+ 或 SGLang 0.5.18+ 下執行，並搭配自訂思考解析器

其中兩行比其他行承擔更多作用。輸出列就是這篇文章的整個論點，而授權列則是沒有人會放進比較表的那一列。

其中一個寫下思考鏈，另一個則拒絕書寫。

Granite 4.2 3B 靠著把思考過程說出來，證明自己值得採用。它的模型卡記載了三種模式：預設開啟思考、非思考，以及會保留推理軌跡但將其縮短的低投入模式。服務堆疊會把推理軌跡與最終答案分開，讓你的應用程式收到乾淨的內容，外加一個獨立的推理欄位。對於需要一步步推演的問題——數學題、邏輯分支、必須先寫出來才能評斷的程式碼——這種設計很合適。

d1-3B 沒有這種模式，而它的說明卡直言不諱地說：「它不是聊天模型，也不會撰寫文字。」一次呼叫會以類型宣告問題。noul 是一種是／否，回傳介於 0 與 1 之間的 P(yes)。choice 會從具名選項集中挑選一個標籤，並回傳該標籤、一個信心值，以及每個選項的機率。score 會將狀態置於一個有序的二到十量表上，並回傳預期等級及其分布與圖例。訊號是在一次傳遞中，從一個預留位置的 logits 讀取，而非逐詞元取樣，這就是為什麼使用量區塊可以回報零輸出詞元而不算說謊。

那個差異會先改變你的帳單，然後才可能改變你的準確度。一次會思考 400 個 token 的 Granite 分類呼叫，就是一次你得為 400 個輸出 token 付費的呼叫，而你想要的標籤就埋在文字裡，接著還得靠解析器把它找出來。d1-3B 呼叫只會對輸入計費。如果你大部分的流量都是附帶規則的標籤，那麼無論推理是否改變了標籤，你都一直在為推理付費。

在哪些情況下，Granite 4.2 3B 顯然是更好的選擇

若直接採信這些推理基準測試的結果——它們是 IBM 自家的，透過內部 NeMo Evaluator 流程執行，且尚無外部第三方重現過——那麼這個 3B 就其規模而言異常強大：AIME25 78.33、HMMT February 2025 66.67、GPQA 54.80、LiveCodeBench v6 69.71、MMLU-Pro 67.84、IFBench 74.33、BFCL v4 52.41、tau3-bench 45.78，以及 RULER 64K 67.52，到 128K 時降至 55.30。

從那份清單可得出四項工作，而 d1-3B 不在其中任何一項。

• 原生 128K 上下文，可擴展至 512K，對比 d1-3B 的 32,768 個 token——如果你的狀態是一份長文件，選擇已經替你做好了

• 具代理性的工具呼叫，具備已文件化的解析器，以及與 OpenCode、Pi 和 OpenHands 的框架整合，而決策模型並沒有與之對等的機制

• 任何答案為一段文字的任務：摘要、起草、擷取成自由形式結構、程式碼生成

• 無營收上限的微調與再散布，因為 Apache 2.0 沒有門檻條款

請注意不在Granite 模型卡上的項目：SWE-Bench 與 Terminal-Bench 資料列在 3B 上標示為 NA。IBM 的代理式強化學習階段僅套用於該系列的 8B 與 30B 成員，因此最小的模型並不具備其較大手足所具備的代理式分數。若團隊讀到「Granite 4.2」便假設 3B 會繼承該系列的代理式特性，將會感到意外。

d1-3B 在 Granite 完成思考前勝出之處

Liquid 自家的延遲表，是在暖機狀態下、一次只送一個請求所測得，是其論點最有力的部分：單一問題在 RTX 4090 上為 8 毫秒，在 AMD MI325X 上為 9 毫秒，在 Jetson AGX Thor 上為 16 毫秒，在 Jetson AGX Orin 64GB 上為 26 毫秒；而 64 個狀態打包進單次處理，在 4090 上達每秒 475 次，在 MI325X 上達每秒 1,106 次。作為規模參照，這大約是 Granite 4.2 3B 產生其推理軌跡中幾個 token 所需的時間。

在 4090 上，針對單一狀態執行三種問題類型只需花費 d1-3B 21 毫秒，而不是三次個別呼叫，因為該狀態及其影像只需讀取一次，就能供所有問題使用。在以往每條規則都會發出一次 HTTP 請求的審核或路由堆疊中，這就是一整排呼叫與僅一次呼叫之間的差別。

它也能看見。d1-3B 在十一項公開影像基準測試中平均得分 74.1，相較其基礎模型的 73.9；而模型卡指出，若移除影像，同樣問題的得分為 45.1——答案來自圖片，而非文字提示。個別項目則互有高低（CV-Bench 82.1 對上基礎模型的 87.6，POPE 88.5 對上 90.1），因此視覺能力的說法是「與基礎模型相當」，而非「優於基礎模型」。

誠實的制衡：d1-3B 在 Decision Index 0.2.1 上的 48.57，是由 Liquid 自行運行官方評分器所產生，而非來自排行榜提交；而與之競爭的資料列則來自公開排行榜。它在八項「以基準作為決策」任務上的 77.1 平均值，以及在 DecisionBench 上的 71.8，同樣都屬於第一方數據。這項比較中 d1 這一側的一切都未經驗證。

為什麼 3B 推理器不是 3B 決策模型

誘人的做法是把 Granite 4.2 3B 當作 d1-3B 的更便宜替代品，或反過來也一樣。兩者都行不通，而這種失敗並非品質問題。

要求 Granite 做決定，你得到的是一段必須剖析的生成內容、一筆會隨模型認為問題有多難而變動的帳單，以及一個取決於你所選思考模式的延遲。要求 d1-3B 進行推理，你卻什麼也得不到——它根本沒有可供推理的 token 串流。這兩個模型分別位於一條線的兩側，而大多數管線在每次請求中都會跨越這條線好幾次：有些東西必須做決定，有些東西必須開口。d1-3B 屬於前段，在那裡由分流規則挑選路徑並回傳校準過的信心分數。Granite 4.2 3B 則屬於它後面，位於需要寫出答案的那條分支上。

還有第二個更隱晦的陷阱。決策模型的價值在於校準——0.9 的信心值，代表十次裡有九次是對的。Granite 4.2 3B 的模型卡並未公布任何校準指標，也沒有公布機率；它公布的是準確度與推理分數。在基準測試排行榜上比較兩者，並無法告訴你該信任哪一個來設定閾值。

沒有人放進表格裡的那一行授權條款

Granite 4.2 3B 以 Apache 2.0 授權發布。d1-3B 則以 LFM Open License v1.0 發布，這份授權條款讀起來相當寬鬆，直到第 5 條：商業使用雖獲授予，但條件是你或你的法律實體必須低於同一文件所定義的門檻，即年營收一千萬美元以上；而任何超過該門檻的商業使用，則完全未獲授權。非營利組織與研究使用者則被排除在該限制之外。

對業餘愛好者或新創公司來說，這根本不是問題。但對一家在年中越過那條線的公司——或是可能被這類公司收購的公司——而言，無論兩者的參數量看起來多麼相近，這兩個儲存庫都不是等價的產物；而授權審查往往要等到有人早已把原型出貨之後才發生。這是本頁最值得及早檢查、成本也最低的一件事。

將這一對組合作為單一管線來執行

這兩款模型目前都不在我們的目錄中，所以這並非可用性聲明：兩者都是自架構件，尤其 Granite 4.2 3B 的卡片上完全沒有列出任何推論供應商。但團隊實際上最終採用的模式，是一個呼叫負責判斷、另一個呼叫負責發聲，而這種模式正是路由層得以發揮價值之處。OrcaRouter 把超過 200 款模型放在同一把 API 金鑰之後，並以 0% 加價轉嫁供應商定價，因此供應商降價當天就會反映到你的帳單，而不必等到下一次合約續約，而且跨供應商自動容錯移轉意味著管線中間的共用元件不會在你仍在評估它的時候變成單點故障。如果你想在投入自架部署之前，用自己的流量把 d1-3B 與託管的通用型模型做 A/B 測試，最接近 Granite 血統的路由鄰居是 Gemma 4 31B，每百萬輸入詞元 $0.13、每百萬輸出 $0.38——模型大得多，但在管線中扮演同樣的「負責寫作的通用型」角色。

裁決，以規則的形式表述

如果你需要的是判斷——是不是垃圾訊息、該進哪個佇列、有多緊急、這是否符合那段描述——d1-3B 是唯一能一次搞定的那個，而且它能在個位數毫秒內完成。如果你需要的是書面答案、讀完一份長文件、工具呼叫或一段程式碼，Granite 4.2 3B 才是真正具備 token 串流的那個，而這款 3B 的推論分數就其規模而言確實令人驚豔——在 IBM 自家的評估上，而且還沒有人查核過那些評估。

真正會改變局面的，不是新增一列基準測試成績。而是由第三方在同一套校準測試框架上為兩個模型評分，因為決定你能否對一個模型設下閾值的特性，正是現今兩份模型卡都無法讓你比較的那一項。