Liquid AI d1-3B 與 LFM2.5-2.6B-Base：決策模型與它自己的祖先

這不是兩個對手之間的較量。Liquid AI d1-3B 是 Liquid AI 於 2026 年 10 月 7 日發布的開放權重決策模型，其基礎是由廠商將 LFM2.5-2.6B 的權重與 LFM2.5-VL-3B 的文字主幹取平均所建構而成。LFM2.5-2.6B-Base 就是那個第一親代——Liquid 於 2026 年 8 月 1 日上傳的原始預訓練檢查點，2.69B 參數、34 兆訓練 token、131,072 token 上下文，未經指令微調，也沒有聊天範本。所以，這場比較誠實的說法是後代對上祖先：一個已被後訓練成專司某項特定工作的模型，站在它被塑造出來之前那塊未成形的基底旁邊。其中一個今晚就能回答問題。另一個則是當你需要回答的問題還沒有人問過時，你會從那裡起步的地方。

每一個實際上是什麼

這兩份模型卡讀起來像是來自生產線不同階段的文件，而這些差異並非風格問題。

Liquid AI d1-3B擁有 31.2 億個參數、一個 400M 的 SigLIP2 NaFlex 視覺編碼器、32,768 個 token 的上下文視窗、128,000 個 token 的詞彙表，以及十六種有文件記載的語言。它是一個決策模型：你給它一個狀態與具名問題，它便會回傳是／否機率、附帶信賴度的選定標籤與完整選項分布，或是一個有序分數——全都在單次前向傳遞中完成，且不生成任何輸出 token。它提供一個 system_one 呼叫，用於一個狀態搭配數個問題；一個批次變體，可將許多請求打包而無需填充；以及一個原始 probabilities 存取器，用來取得底層分布。它不是聊天模型，也不會撰寫文字，而模型卡正是這樣寫的。

LFM2.5-2.6B-Base在 30 層中擁有 2.69B 個參數——22 個雙閘控短卷積區塊與 8 個分組查詢注意力區塊——以 34 兆個 token 訓練，並在中期訓練期間擴展至 131,072 個 token 的上下文，使用相同的 128,000 個 token 詞彙表與相同的十六種語言。它是僅含文字的預訓練檢查點，未經指令微調，其模型卡上沒有任何基準測試結果，而一項建議讀起來像是警告：僅將其用於需要大量微調的任務。它會完成文字。它不會遵循指令。

兩者都是 Liquid 自有開放授權下的無限制下載。兩者皆以文字為主。兩者都不在我們的目錄中，且此處沒有任何內容是對任一者的供應聲明。

譜系才是有趣的部分

Liquid 並沒有為了推出 d1 版本而微調一個全新的模型。它平均了兩個檢查點——LFM2.5-2.6B 和 LFM2.5-VL-3B 的文字塔——以獲得更好的起點，然後用不同的隨機種子和資料混合物進行了數次微調訓練，再將它們合併回去。該廠商對於是什麼改進了結果的說明，明顯沒有任何奇特的技術：對長輸入進行訓練、打亂答案選項出現的順序，以及從訓練資料中移除捷徑，比他們嘗試過的任何先進方法都更有效。

這個「移除捷徑」的細節值得停下來細想，因為它點出了這個類別之所以存在，正是為了避免的失敗。一個被訓練來回答選擇題的模型，會很樂意學到選項 B 通常是對的，或最長的選項會勝出。在訓練期間打亂選項順序，正是阻止這件事的關鍵。一個學到的是位置先驗、而不是去讀取狀態的決策模型，比無用還糟——它會在大規模下自信地犯錯——而這正是把真正的決策模型與帶有提示詞的分類器區隔開來的那個關鍵。

還有一個值得直說（因為廠商不會說）的退步：基礎檢查點有 131,072 個詞元的上下文視窗，而 Liquid AI d1-3B 只有 32,768。把模型後訓練成決策模型，代價是失去了四分之三的可用上下文。如果你以為後代在每個軸度上都嚴格支配其祖先，事實並非如此，而長文件決策正是較舊檢查點擁有更多空間的那個軸度——原則上是這樣，儘管它並沒有決策頭可以使用。

計分板，附有不對稱性

在基準測試上比較這兩者是一種範疇錯誤，但這是一種帶有資訊性輪廓的範疇錯誤，所以在此呈現，並附上這些但書。每個 d1-3B 的數字都是 Liquid 自家的，由廠商以官方評分器打分，而非提交至公開排行榜，且未經任何第三方重現。每個 LFM2.5-2.6B-Base 的數字都從缺，因為基礎模型沒有東西可測。

• Decision Index 0.2.1 — Liquid AI d1-3B 48.57，在廠商表格中所有低於 10B 的項目裡排名第一，並領先一個規模為其十二倍的決策模型。LFM2.5-2.6B-Base — 未評分，且在沒有決策頭的情況下無法評分。

• 文字基準測試 — Liquid AI d1-3B 在涵蓋理解、毒性、意圖、醫學問答與跨語言理解的七項公開基準測試中平均為 82.9。LFM2.5-2.6B-Base 則完全未公布任何基準測試表。

• 視覺 — Liquid AI d1-3B 在十一項以決策形式判讀的影像基準測試上平均得分 74.1；移除影像後，同樣的題目得分降至 45.1。LFM2.5-2.6B-Base 僅支援文字，沒有視覺塔。

• 參數 — 3.12B 對上 2.69B。決策模型是兩者中較大的那個，這與通常的後訓練情況相反。

• 上下文 —— 32,768 個 token 對比 131,072 個。祖先在這一列勝出，而這是它唯一勝出的一列。

• 延遲 — Liquid AI d1-3B 在 RTX 4090 上以 8 毫秒回答單一問題，在 Jetson Orin Nano 上則為 50 毫秒，並在 4090 上以每秒 475 個的速度執行 64 個 packed states。LFM2.5-2.6B-Base 沒有可引用的延遲數字，除非你將它微調成能回答問題的模型；到了那時，這個數字就是你微調版本的數字。

實際上，你是在哪些選項之間做選擇

這裡的決策規則異常明確，因為這兩個檢查點並不會爭奪同一筆預算項目。

選擇 Liquid AI d1-3B當問題已然存在，且屬於決策模型能處理的三種形態之一：是或否、從一組具名選項中挑選，或在有序尺度上評分。目前已發表的應用全都是辨識得出來的真實生產苦差事——分流與路由、內容審核、意圖與主題分類、擷取檢查、重新排序、代理護欄，以及視覺檢查。廠商在 10 月 5 日跑的示範數據，讓 d1 在六項這類任務上與 GPT-6.1 Sol 和 Claude Opus 5.5 對比，並宣稱它在其中四項上追平或超越 GPT-6.1 Sol，而成本只要 19 分之一到 200 分之一；方法論頁面明白指出，每個應用在每個模型上各跑一次，所以要把這項宣稱的樣態當成發現，而不是那些小數位。真正引人注目的是那項檢查示範：在四條生產線上做良品與不良品的分類，準確率達 85% 到 97%，而這是模型從未受訓過的任務，僅憑一段簡短描述就理解。

LFM2.5-2.6B-Base，當問題尚未存在時就選它。對於你打算自己擁有的微調而言，它是更便宜的起點——一個領域決策頭、一個客製分類器、一項沒有人有檢查點的任務。你繼承了架構、分詞器與長上下文，並以運算、資料和評估作為代價。供應商圍繞 d1 打造的四個應用中，有兩個是從開源專案而非從零開始，這公允地描繪了基礎檢查點加上紀律實際上能產出什麼。

實際的陷阱在於把基礎檢查點當成可直接替代的成品。它不是助理，不會遵循提示，而若以聊天模型來評估，它的得分近乎零——但這並非關於其品質的事實，而是關於「基礎」一詞代表什麼的事實。

自行架設其中任一個，以及上一層

兩者都以權重形式釋出，而廠商已為 d1 這一側完成部署工作：首日即支援 llama.cpp、涵蓋從 DGX 到 Jetson 的完整 NVIDIA 堆疊、NVFP4 量化、8 位元權重與活化值變體，以及在 Hugging Face 上的 GGUF 轉換。基礎檢查點本身也透過更廣泛的 LFM2.5 家族提供 GGUF、ONNX 與 MLX 變體。如果你不想自行託管任何東西，Liquid 會從自家 API 提供託管版d1，僅依輸入 token 計價，圖片則以每 32×32 像素區塊 1.5 個 token 計費；純文字存取也可透過第三方平台取得。

兩條路徑都改變不了的，是堆疊的其餘部分。你自行託管的模型，就是個你必須維持運作、管理版本並容錯移轉的模型——而它所餵養的決策，仍然會與你並未託管的生成式呼叫並肩落在同一處。這樣的混合，正是路由器所收攏的那一層：一個端點橫跨 200 多個模型，供應商定價以 0% 加成原樣傳遞，因此供應商一調價，當天就在你這邊生效，而且自動容錯移轉，讓某個上游的一個糟糕午後不會變成你的服務中斷。在旁邊自行託管一個 3B 決策模型，會讓路由問題變得更尖銳而非更緩和，因為現在這條流程有一半歸你所有，另一半則是租來的。

哪一個，給誰？

如果你這週需要回答的問題，正好是決策模型所採取的三種形態之一，而且這個問題已經有別人設想過了，那麼其衍生的成果已經完成、免費，還能在沒有 GPU 的裝置上以 50 毫秒執行——直接用 Liquid AI d1-3B，別再多想了。

如果你正在打造那個能回答還沒有人問過的問題的東西，而且你擁有資料和算力去掌握那件事，那麼 LFM2.5-2.6B-Base 就是誠實的起點，而且值得知道的是，本文中的後繼模型正是沿著你即將踏上的同一條路徑，從它衍生而來。

而如果你不確定自己處於這兩種情況中的哪一種，答案幾乎總是第一種。後訓練成一個決策頭是昂貴的做法；跑別人的則免費。