d1-2B 對上 Liquid AI d1-3B：較小的模型贏了排行榜，卻輸了部署

四個問題決定這場對決，而其中沒有一個是「哪個模型更好」。狀態是否包含影片？它是否超過 32K tokens？你是否需要在 llama.cpp 下執行它？你承擔得起成為第一個測試它的人嗎？d1-2B是 Liquid AI 的 1.92B 決策模型，建構於 LFM3-VL-2B 之上，並在廠商的 Decision Index 表中獲得 51.1 分。Liquid AI d1-3B是於 10 月 7 日發布的 3.12B 模型，建構於 LFM2.5-VL-3B 之上，並在同一張表中獲得 49.0 分。較新、較小的模型平均領先。但它在部署真正取決於的三列上仍然落敗，而且它是兩者之中沒有 llama.cpp 路徑、也沒有獨立測試結果的那一個。本頁是圍繞那四個問題來組織，而不是圍繞排行榜，因為排行榜對這些問題一個都回答不了。

簡答：依工作負載而定

• 大量純文字分流—— d1-2B，憑藉每秒可為 64 個批次狀態處理 1,132 次決策，以及 3.84GB 的權重。當輸出只是一個標籤時，3B 在 Typed Decisions 上的優勢便無關緊要。

• 圖表與圖形閱讀 — Liquid AI d1-3B。它在 AI2D 以 79.9 對 76.7 勝出，而且是背後有獨立執行結果支持的模型。

• 長文件、長表單、長通話逐字稿 — d1-2B。其視窗為 128K tokens，相較於 32,768，而說明卡也坦承可靠度在超過約 64K 後會下降，但這仍留有 3B 總容量的兩倍。

• 執行 llama.cpp 的邊緣裝置——Liquid AI d1-3B，是預設而非憑實力。它有 GGUF 儲存庫和量化權重-激活版本；d1-2B 兩者皆無。

• 任何錯誤判斷代價高昂且未經測試的情況——在你用自己的資料把兩者都跑過之前，兩者皆非。其中甚至只有一個曾被第三方運行過。

同一家族，相隔一代

這兩個模型並非名稱所暗示的那種同輩關係。Liquid AI d1-3B 源自 LFM2.5-VL-3B，而後者衍生自 LFM2.5-2.6B-Base，並搭載 400M SigLIP2 NaFlex 視覺編碼器。d1-2B 則源自下一個系列 LFM3-VL-2B，其主幹共 24 層，劃分為 13 層閘控短卷積、5 層滑動視窗注意力與 6 層全域注意力。基準測試結果之所以反轉，正是來自這個世代差距：較新的架構在每個參數上能發揮更多效用，因此較小的檢查點在多數列上都能勝過較大的檢查點。

• 參數量 — d1-2B 為 1.92B，Liquid AI d1-3B 則為 3.12B。

• 下載 — 3.84GB 對比 6.25GB 的 BF16 safetensors，兩者皆為單一檔案。

• 上下文 — 128K tokens 對比 32,768。

• 詞彙 — 128,000 個 token，相較於 LFM2.5 的詞彙。

• 輸入 — 文字或 JSON、圖片 或影片，再加上具名問題，適用於 d1-2B；3B 則為文字或 JSON 加上圖片。影片是兩者之間最明顯的能力差異。

• 語言 — 各十六種，同一套。

• 授權 — 兩者皆採用 LFM Open License v1.0，商業使用以年營收低於 10,000,000 美元為條件。沒有授權方面的理由偏好任何一方。

• 發布 — d1-3B 的權重於 10 月 5 日上線，並於 10 月 7 日公布。d1-2B 的儲存庫於 10 月 24 日建立，且從未有過專屬貼文；唯一提及它的廠商語句出現在 10 月 27 日的 LFM3 發布中。

有一個文件細節值得當作訊號而非事實來解讀：Liquid AI 的決策模型文件頁面現在列出 d1-2B、d1-omni-2B、d1-omni-600M、d1.1 和 d1-ultra。它不再列出 d1-3B。3B 並未退役——其 repo、GGUF 和 MLX 版本都仍上線——但廠商自家的索引已把開放權重的位置移到 2B。

計分板，逐行讀取

以下所有數字都來自 d1-2B 模型卡上的基準測試表；該表以同一個評分器，對四個開放 d1 模型在相同項目上進行評分。這一點很重要，因為 Liquid AI d1-3B 自己的模型卡在 Decision Index 0.2.1 上標示 48.57，而本表在 0.3 版上標示 49.0；差距來自指數版本，而非模型變更，模型卡也在註記中說明了這一點。直接比較兩張模型卡——48.57 對 51.1——會是在兩個不同測試之間相減。在本表內部進行比較是合理的，而本節其餘部分也正是這麼做。

• 決策指數公開套件 v0.3— 51.1 對 49.0。

• DecisionBench（Hanno Labs）v1 — 77.1 對 73.1。

• Decision Bench（decisionbench.ai）v4 — 85.2 對 83.6。

• JevBench v1.4.1 — 77.9 對 76.2。

• ImajevBench v2.0-lite — 75.5 對 64.0，決策端最大的差距。

• WorkflowEvals — 81.6 對 74.4。

• Liquid AI 的內部排行榜 — 63.2 對 58.8。

• 視覺平均 — 在十八項基準測試中，70.2 對 65.4。

該表中每一個具名決策套件都由 2B 勝出，這正是 LFM3 發布貼文所表達的意思：它稱 d1-2B 是 d1-3B 的替代品，「參數少了三分之一」，且「在全部四個決策套件上」分數更高。這項說法照字面來看是準確的——而且比「勝過 3B」更狹窄，這就是為什麼會有下一段。接著是方向相反的那三列。Fast Decisions 上，d1-2B 是 58.8，3B 是 59.3。Typed Decisions 則是 61.3 對 65.0。AI2D 是 76.7 對 79.9。這些差距都不大，而且三者中有兩個在一個百分點以內，但這些正是多出的 1.2B 參數仍能換來可測量效益的資料列：偏向速度的決策、型別化擷取，以及圖表閱讀。如果你的管線工作是從表單進行型別化擷取，那麼 3B 並不是文件頁面所暗示的過時選項。

延遲：這兩個主要數字並不可比

Liquid AI 報出 d1-2B 每次決策為 5.7 毫秒、Liquid AI d1-3B 為 8 毫秒，但這兩者並非同一種測量。2B 的數字是在 H100 PCIe 上測得；3B 的數字則是在 RTX 4090 上測得。兩張不同 GPU 之間的 2.3 毫秒差距，完全無法說明哪個模型在你的硬體上更快；若把它當成比較來重複引用，正是這個部落格存在的目的所要避免的那種數字洗白。

兩張卡都列出同一台機器。在 Apple M5 Pro 上，d1-2B 每個問題耗時 18.6 毫秒，3B 則耗時 30 毫秒——在相同晶片上減少 38%。這是如實的速度比較，而其結果與尺寸差異所暗示的方向一致。在批次處理方面，d1-2B 在 H100 PCIe 上每秒處理 1,132 個決策，在 MI325X 上以單次呼叫處理 64 個狀態時每秒處理 1,699 個；3B 的卡則報告在 RTX 4090 上每秒 475 個、在 MI325X 上每秒 1,106 個。MI325X 那一列是兩張卡共有的項目，而在那裡 2B 領先約 54%。

現存唯一的獨立測試跑的是 3B

十月中旬，Efraín Garay 以 Decision Index 0.3 和三項真實資料任務測試了八個決策模型，並連同程式碼公布了結果。有兩項發現與這項比較相關。

第一點對記分板來說令人安心。他從其套件重建了公開測試套件，檢查下載的檔案是否與官方檔案相符，抽樣了 6,000 筆請求，並將 Liquid AI d1-3B 評為 49.11——相較於 Liquid 自己在相同資料列上的 49.04，以及完整套件上的 48.99。這是目前可得最強力的證據，證明上表中的 v0.3 數字計算正確。這是關於 3B 的證據，而非關於 d1-2B；他並未測試後者。

第二點是關於指數衡量了什麼的警告。在一個由 10,000 筆付款組成的合成信用卡詐欺資料庫上，Liquid AI d1-3B 的 AUC 得分為 0.314——低於隨機水準，將異常交易排名為比正常付款更不可疑，因為連續付款的爆發落在中位機率 0.41，而正常付款為 0.56。該模型在公開指數上排名第二，在該任務上則墊底。這個教訓可直接套用：d1-2B 的 51.1 是通用決策套件上的分數，而沒有人證明它能預測你在特定決策上的表現。供應商在其自己的說明卡中也這麼說，並指示要根據你自己的資料校準閾值。

你今天實際能運行什麼

這就是雙方差距不再接近的地方。Liquid AI d1-3B 自 10 月 6 日起就有 GGUF 儲存庫，自 10 月 7 日起有 8 位元權重激活版本，自 10 月 12 日起有四種 MLX 變體。d1-2B 在 10 月 27 日取得了三個 MLX 組建與一份 ONNX 匯出，除此之外別無其他。沒有 d1-2B 的 GGUF，也沒有 MLX 的 4 位元與 8 位元之外的量化，因此決策頭沒有已發布的 llama.cpp 路徑——儘管基礎模型 LFM3-VL-2B 自 10 月 19 日起就有自己的 GGUF。

對 Transformers 部署而言，這個差異就消失了：兩者都會以 trust_remote_code=True 載入，並提供相同的 system_one 與 system_one_batch 呼叫。但對邊緣部署而言並非如此。如果你的技術堆疊是在 Jetson 或手機上執行 llama.cpp，那麼在這兩者之中，3B 是唯一不需要撰寫執行階段整合就能執行的模型，而其公布的邊緣數據——Jetson AGX Thor 上 16 ms、AGX Orin 64GB 上 26 ms、Orin Nano 上 50 ms——正是你可以據以規劃的數據。

這兩個模型都不是由 OrcaRouter 提供服務，因此無論如何，在它們之間做選擇都是自架（self-hosting）的決定。路由器的價值所在，是在往外一層：決策模型很少單獨運作，而依據路由標籤採取行動的生成步驟，通常來自託管模型。一把相容於 OpenAI 的金鑰，即可存取 200 多個模型、一套路由 DSL 讓你能把這些步驟組合成單一次呼叫，再加上自動容錯移轉，使管線的這一半不會變成另一個整合專案，同時決策節點仍留在你自己的硬體上。

如果您正在移轉，有三件事會改變

API 介面已足夠接近，讓移植看似微不足道，實則不然。首先，輸入契約：d1-3B 接受影像；d1-2B 接受一個 媒體清單，該清單可包含影片，而其卡片說明媒體會在單次呼叫中對所有問題僅編碼一次。傳入單一影像的程式碼會執行，但不會用上模型原本所設計的用途。

其次，閾值。兩個模型都會回傳機率，且兩者都需要一個在你的資料上擬合出的決策閾值。在 d1-3B 校準上調校出的閾值無法直接沿用——校準表隨各個 repo 分別附帶、各自擬合——因此，若遷移時保留舊的截止值，將會產生不同的操作點，而在內容審核或詐騙偵測流程中，也會產生不同的錯誤輪廓。

第三，可靠性斷崖。128K 視窗是主要賣點；規格卡指出，當狀態超過約 64K 個 token 後，答案的可靠性就會下降。在 3B 上，上限是 32,768，因此遷移到 d1-2B 通常會是直接的容量提升——但如果某條管線因為現在做得到，就開始餵入 100K token 的狀態，那是在測試供應商已標示為較弱的那段範圍。

這個結論比計分板呈現的更不對稱。若是在 Transformers 上進行全新專案，無論處理文字、圖像或影片，且狀態可能持續很長，d1-2B 是更適合的預設選擇，執行成本也更低。若是部署在 llama.cpp 下的邊緣裝置、進行型別化擷取，或以圖表為主的視覺任務，Liquid AI d1-3B 仍是首選模型——而且它是兩者中唯一有外部證據支持的。唯一不該做的事，就是只憑 51.1 對 49.0 這條分數線來選擇。廠商指數上的兩分差距，落在兩個沒人在你的任務上跑過的模型之間，這不是決策；只是打破平手。