Microsoft-Decision-1 vs Liquid AI d1-3B：同樣的 32K 視窗，兩種不同的意義

難得有一次規格對得上。 Microsoft-Decision-1自 2026 年 10 月 8 日起在 Microsoft Foundry 正式推出，可容納 32,768 個詞元的上下文脈絡。Liquid AI d1-3B也是如此，它於 2026 年 10 月 5 日上傳至 Hugging Face，並由 Liquid AI 在兩天後發布。兩者都接受一個狀態，外加一組帶型別的問題——是／否、從具名選項中擇一、在有序尺度上的位置——而且兩者都在單次前向傳遞中以機率分布作答，而非生成文字；Laya、Intern-Decision-4B、Kev 以及這個小眾領域的其他成員，在上下文長度上彼此看法不一，所以這是唯一一組該維度會消失、比較必須另尋依據的配對。

事實證明，那個額外的東西就是輸入管道。微軟的模型明確僅支援文字：它「不接受也不產生圖像、音訊或視訊內容」。Liquid AI 的模型則在 26 億參數的語言主幹上搭載 4 億參數的 SigLIP2 NaFlex 視覺編碼器，總參數達 31.2 億，而且它正是為了微軟排除的那件事而打造——拿螢幕截圖、掃描表單或相機畫面，對照固定問題進行評分。那項差異，再加上一個與能力無關的授權差異，就是整場對決的全部。

在兩者一致的地方，這比你想像的還要多。

• 上下文視窗 — Microsoft-Decision-1 為 32,768 個 token，Liquid AI d1-3B 亦為 32,768 個 token。

• 輸出型態 — 對所提供選項給出的校準機率；兩者皆不會生成文字，而 Liquid AI 的用量計數器會將此事實回報為 output_tokens: 0。

• 問題類型——兩者皆支援選項選擇、有序評分與二元是／否，且兩者都讓你能依每次請求自行定義選項集合，而不必重新訓練詞彙頭。

• 棄權 — Microsoft 文件說明了明確的棄權選項，例如「無法判斷」；Liquid AI 的 Decision Index 結構描述透過其選項集支援同樣的做法。

• 單次推論——雙方每次決策只需一次呼叫，這正是讓兩者在管線規模下皆可行的原因。

兩個模型能在這個細分領域中最難的兩項限制條件上達成一致，這件事值得停下來深思。32K 視窗能讓決策評分器用在完整合約、多頁政策文件或冗長的支援討論串上；512 token 的英文 Laya 檢查點，以及 Intern-Decision-4B 的每次呼叫問題數限制，則做不到這點。如果你的輸入很短，這個領域裡大多數選項都可互換，決策重點在於代管方式。如果你的輸入很長，選擇範圍就縮小到這兩者。

那種只有其中一個擁有的感覺

Liquid AI d1-3B 是多模態的，而模型樹讓其譜系一目了然：先是 LFM2.5-2.6B-Base，接著是 LFM2.5-VL-3B，然後是為單次通過的校準決策而後訓練的 d1-3B。影像經由 SigLIP2 NaFlex 編碼器進入，而模型卡報告在十一項公開影像基準測試上平均值為 74.1，相較於基礎視覺模型的 73.9——因此決策微調並未犧牲其視覺品質。它還報告了反向實驗：把影像拿掉後，同樣的問題掉到 45.1，這是你能得到最乾淨的證據，證明感知通道是關鍵支撐，而非裝飾性的。

Microsoft-Decision-1 沒有對應項目，而這項遺漏是刻意為之，而非尚未完成。Microsoft 的說明卡將超出範圍的用途列為文字生成、開放式問答、對話、翻譯與摘要，並另行表明該模型僅支援文字。對於需要依評分標準為表單截圖評分，或判斷相機畫面是否包含安全事件的流程而言，這就是一道無法跨越的硬性關卡——再怎麼設計提示詞，也無法挽回模型從未被賦予的模態。

語言數量的趨勢正好相反，而這是第二個真正的分歧。Microsoft-Decision-1 列出了 25 種支援的語言，而該公司坦承涵蓋範圍、品質和校準「可能因語言而異」，並指出非英語、尤其是低資源語言是表現不佳的領域。Liquid AI d1-3B 則表示支援 16 種語言。就廣度而言，Microsoft 在紙面上領先；而在對於廣度意味著什麼的誠實態度上，兩家供應商的說法類似，且雙方都未公布各語言的校準。

又是基準測試分頁

Microsoft-Decision-1 的 Foundry 頁面有一個 Benchmarks 分頁，內含方法論區段，但沒有圖表：公開與社群決策基準，加上保留的內部資料集；指標涵蓋準確度與校準誤差；選項順序經過變動；配對統計檢定；以及一項宣稱，該模型「表現與領先的決策模型相當，並優於以相同方法論評估的其他開放決策模型。」沒有可查核的內容，也沒有可重現的內容。

Liquid AI d1-3B 在 Decision Index 0.2.1 上公布 48.57 —— 而這個限定條件比數字本身更重要，因為 Decision Index 是 Liquid AI 自家的指數，d1-3B 也是 Liquid AI 自家的模型。這是供應商在自己撰寫的基準上、由自己評分所得的結果，並由該公司定位為 10B 以下決策模型中的最佳者，且在同一尺度上領先一個 35B 模型。請把 48.57 視為方向性的宣稱，而非經過審計的數字。與此同時，模型卡列出內部決策格式評估平均為 77.1、SQuAD 2.0 為 85.3、PAWS-X 為 76.9，以及 DecisionBench 71.8 —— 全部都是自我報告，而「10B 以下」這個框架是貨真價實的限定條件，不是迴避，因為該模型是 3.12B。

所以，校準問題的解決方式與整個領域如出一轍：Liquid AI 提供一個以其自身尺度產生的數字，Microsoft 提供一套方法論但沒有數字，而兩者都無法提供獨立的第三方測量。唯一會對你的部署重要的校準數字，是你根據自己的標註資料計算出來的那個。

服務、授權，以及你實際上買到的究竟是什麼

d1-3B 的延遲已公布，而這正是該模型存在的理由。在 RTX 4090 上每次決策八毫秒，在 AMD MI325X 上為九毫秒；在 64 個狀態下，封裝吞吐量分別為每秒 475 與 1,106。在邊緣硬體上：Apple M5 Pro 為 30 毫秒，Jetson AGX Thor 為 16 毫秒，Jetson AGX Orin 64 GB 為 26 毫秒，Orin Nano 為 50 毫秒。Microsoft-Decision-1 完全未公布任何延遲數字，而其內建設定的選項——以隨用隨付或預留佈建輸送量提供的託管 Foundry API，且已停用批次推論——意味著你得透過自己的部署來測量它。對於一個全部目的就是要在每份檢索到的文件或每個提議的動作上被呼叫一次的模型而言，這不是一個小差距。

授權條款正是兩者出現令人意外分歧的地方。Liquid AI d1-3B 標示的是lfm1.0，而非 Apache 2.0——這與 Liquid 的 LFM 系列其餘模型採用同一套家族授權，其中帶有寬鬆授權所沒有的使用條件。如果你的法務審查認為這是「與 OpenAI 相容、毫無附帶條件」，事實並非如此，而這點值得在模型正式上線之前、而非之後詳加細讀。Microsoft-Decision-1 則完全沒有權重：它是 Direct from Azure 產品組合下的一個託管端點，具備 Azure 驗證、統一帳務計費、無需下載，授權問題則由服務協議取而代之。這兩款模型都無法透過供應商文件所述的途徑進行微調，而這對決策模型而言是最嚴苛的限制——一個你無法用自己的標籤加以調校的評分器，其錯誤模式你無法修正，只能繞道而行。

繞過它們來進行路由，正是 OrcaRouter 在這個模式中所屬的位置，而且僅限於這個位置。我們既不託管 Microsoft-Dec-1，也不託管 Liquid AI d1-3B：兩者都不會回傳結果，都不在我們的目錄中，而機率評分端點並不是聊天補全的目標。我們所承載的是這個迴圈的生成端——那個負責草擬你的評分器將評分的答案、擷取你的評分器將評判的欄位，或提出你的評分器將核准的動作的模型。那是在同一把 OpenAI 相容金鑰背後超過 200 個模型，以供應商定價原價轉嫁、0% 加價，因此供應商一旦調價，我們這邊當天就會生效，而自動容錯移轉會涵蓋這個迴圈中的生成呼叫，這個迴圈沒有多餘的延遲可以重試一次。

兩個穩妥的選擇，還有一個毫無懸念

請選用Liquid AI d1-3B，只要你的流程中有任何環節是圖片。螢幕截圖分流、表單擷取、視覺 QA 路由、由審核員為攝影機畫面評分——Microsoft-Decision-1 根本無法勝任這些工作，而 d1-3B 正是為此而生，並已發表視覺基準測試來佐證這項說法。如果你需要在 Jetson 或筆電上進行以數十毫秒計的邊緣推論、想在自己的硬體上運行模型，或是一份你的法務讀得懂的授權條款就已足夠，那也該選它。

選擇 Microsoft-Decision-1若你的輸入是文字、你的文件很長、你的關卡是採購——Azure 驗證、統一帳單、負責任 AI 評估、有可上報的供應商——或者你的流量涵蓋超過 d1-3B 所列的 16 種語言。要接受它缺少延遲數據和缺少基準測試表，意味著你使用它的前兩週是測量，而不是整合。

唯一沒有懸念的是多模態工作：在那裡，當微軟把「text-only」寫進 model card 時，選擇就已經做出了。