Decision 3.0 對比 Microsoft-Decision-1：一個是下載，另一個是 SKU

9B 層級的 Decision 3.0與Microsoft-Decision-1在紙面上是同一款產品。兩者都將 Qwen3.5-9B 後訓練成一個評分器，能針對一組固定的候選答案，為每個答案給出經過校準的機率，且完全不生成任何詞元。兩者都鎖定相同的工作——將請求路由、依據評分規準為輸出評分、管制代理動作、分流佇列。兩者在一週內相繼推出：Microsoft-Decision-1 於 2026 年 10 月 8 日在 Microsoft Foundry 正式推出，並於隔天宣布，而 d3-flash 於 2026 年 10 月 10 日 17:23 UTC 被推送到 Hugging Face。

差別不在於模型本身，而在於你能拿它做什麼。d3-flash 是一個 83.9 億參數的 Apache-2.0 檢查點，讓你下載並自行執行，在一個從 0.59B 起跳、最高到 26.09B 的家族中位居第三。Microsoft-Decision-1 則是 Foundry 上的託管端點，權重完全不對外發布，微軟表示這條產品線日後將改以自家的 MAI 模型為基礎重建。這兩者一個是產物，另一個是服務。關於這對組合的幾乎每個實際問題，都源自這個單一事實，包括那些看起來像是在談基準測試的問題。

關於決策模型用途的兩項決定

Microsoft 的公告明確界定範疇，而模型卡鮮少如此。支援的問題形式包括是非、選擇、評等、分類，以及以評分規準為基礎的評分。排除項目也同樣清楚地列出：並非設計用於文字生成、開放式問答、對話、翻譯或摘要，也不適用於需要輸入內容所無之知識的任務。它會對最多 32,768 個 token 進行一次處理，並產生零個輸出 token，因為其中沒有解碼迴圈。Microsoft 也支援棄權選項，例如在提供的證據不足時可選「無法判斷」；正是這個細節，才讓對輸出設定閾值真正具有意義。

d3-flash 位於同一個概念框架內——Choice、Noul（是／否）與 Score 問題，每個問題一次前向傳遞，每個選項一個機率，不進行生成——然後擴展了輸入端。Microsoft-Decision-1 在設計上僅限文字，而 d3-flash 則接受文字或 JSON，每次請求可包含多張圖片，每張最高達 160 萬像素，還可包含多段影片，以每秒 2 幀讀取。請求中的每個問題都會看到附加於該請求的每一張圖片與每一段影片。它是個較小的模型，卻能對提供給它的輸入發揮更大效用。

那是第一個真正的分界，而這無關品味。如果你需要做的決定是關於螢幕截圖、收據、圖表或相機拍下的片段，Microsoft-Decision-1 無法做出那個決定。那是能力邊界，不是品質落差，再多的準確度調校也無法弭平。

每一個發布什麼，以及如何發布

這裡的兩個發行版確實在做截然不同類型的證明，值得將它們分開來看，而不是把數字並列比較。

Microsoft 進行了一項涵蓋近 150,000 個問題的 36 項基準測試比較，這些問題在訓練時皆保持盲測，涵蓋路由、排序、長上下文、多語言與分布外任務、推理及安全，並表示其模型在這些測試集中表現最佳。它將延遲以比率而非數字回報——p50 比 GPT-6 Sol 快約 35 倍，並比 H2O-Lightning-4B v1.1 快 2.5 倍，後者被其列為第二名。它將穩健性記錄為一套程序：同一個請求以八種方式擾動，平均決策翻轉率為 1.3%，而當選項描述被改寫，或選項被反轉或隨機排列時，翻轉次數為零。它在 11 項涵蓋有害內容、越獄與提示注入的基準測試中，以 5,250 個請求測試安全性。它陳述了其自我要求的校準標準——在具代表性的案例中，90% 的預測應該大約每十次中對九次。

vLLM-SR 發布了一份指數。Jev Decision Index 0.3.1 將 d3 列於 64.7，而 d3-flash 在公開套件上為 57.79，相較於 Decision 2.0 的 9B 模型（46.76），聲稱有 11.0 的增益。它同時聲稱 140,178 筆公開請求全數獲得回應，且沒有任何一筆缺乏依據——這是一項涵蓋範圍的陳述，而非準確度的陳述。模型卡揭露，d3 自身的那一列屬於內部評估，而與之並列比較的各列——Perplexity Decider v1.1、Fastino GLiDE、Jev、Torchcast Decision 27B——則是即時排行榜資料。而在多模態方面，d3 系列模型回報了全部 19,140 道驗證題的 Perception Test 分數，其中 d3-flash 為 73.3，對照三選項的隨機基準 33.3。

所以：微軟發表了一項廣度主張，附有具文件記載的方法與一項穩健性數值，卻沒有各檢查點的校準數值。vLLM-SR 發表了一個排行榜名次，並明示其自身那一列與其他列之間存在來源落差，外加一項影片結果，同樣沒有校準數值。這兩張卡都沒有針對其所描述的模型提供 Brier 分數或期望校準誤差數值。對於兩個產品而言，其整體價值主張就是回傳的數字具有意義，而這正是它們共同的缺口，也是任一供應商接下來所能推出的最有用的一件事。

通路比規格表更能決定一切。

這裡就是比較不再關乎模型的地方。

有了 d3-flash，你會獲得權重、一個decision_config.json，用來鎖定基礎修訂版本、每檔案 SHA-256 清單、自訂建模程式碼、讀出頭，以及一份有文件記錄的相依套件集，其中包含transformers==5.17.0，以及一個供線性注意力層使用的選用 CUDA 核心套件。你可以在自己的硬體上執行、微調、量化、氣隙隔離。你也同時承接了維運工作：Python 類別不是端點，而且模型卡沒有說明狀態加上問題加上候選描述所需的 token 預算——max_length 是 null 在隨附的設定中，因此那個上限得由你自己去發現。

使用 Microsoft-Decision-1你能在既有的雲端帳戶內取得端點，並享有隨之而來的身分驗證、區域可用性與佈建控制，而且完全不必做維運工作。但你也完全沒有控制權。沒有可下載的儲存庫、沒有微調途徑，也沒有自架選項；模型的生命週期由 Microsoft 掌握，而非由你決定，而淘汰通知或改以不同骨幹為基礎，都是你只能被動承受的變更，而不是你能事先安排的變更。Microsoft 表示將會轉移到自家 MAI 模型，對於一個重點就在於快速單次評分的模型來說，這是合理的發展藍圖，同時也意味著你當初做基準測試的特定檢查點，未必是你一年後會呼叫的那一個。

延遲這件事也需要仔細解讀。微軟的標題數字是相對於一個大得多的通用模型的比例，這對其論點而言是正確的比較——決策模型的職責，就是用便宜的評分呼叫取代昂貴的生成式呼叫，而相對於 GPT-6 Sol 在 p50 的 35 倍，就是這個論點成立時的樣子。vLLM-SR 的數字是絕對值、單次請求與單一 GPU，而且清楚顯示模態稅：在一張 AMD Instinct MI325X 上，對 d3-flash 發出的文字請求中位數需時 19.1 毫秒，同一請求加上圖像需時 149.4 毫秒，加上十秒影片則需 407.6 毫秒。這兩組數據都是廠商自行報告的，且是在不同硬體上得出，兩者都尚未在產生數據的實驗室外被重現。

如何選擇

決策規則很短，這是個好跡象，代表這兩項產品其實並沒有在爭奪同一個位置。

選擇 Microsoft-Decision-1，前提是這項決策僅涉及文字、你已經在 Foundry 上運行，而且重點在於它是一次呼叫而非一項部署——不必購買 GPU、不必操作容器、不必擁有模型生命週期。對平台團隊而言，微軟的佐證資料也是兩者中較實用的：擾動測試、安全測試次數，以及明確聲明支援棄權選項，這些正是你撰寫閾值政策時所需要的，而 32,768 個 token 的上限也有明確載明，而非留空。

採用 Decision 3.0——實際上就是 d3-flash 或 d3-mini——如果這項決定的任何部分取決於圖像或影片片段、如果你需要在託管 API 無法觸及的地方執行它，或者你想用自己的標註案例微調評分器。Apache-2.0 授權與檔案層級雜湊清單讓這成為真正可行的選項，而非理論上的可能性。你換來的是未明示的輸入預算、沒有公開的校準，以及這個系列才推出幾天、背後幾乎沒有外部使用案例支撐的事實。

如果你兩者都需要——例行文字路徑用託管評分器，多模態或氣隙環境用自架評分器，並透過同一個介面呼叫——那麼誠實的立場是：目前沒有廠商能提供這樣的方案，而這兩種請求格式雖然接近到足以統一，卻並非完全相同。

OrcaRouter 位於何處，以及不位於何處

typesafe/jev-1.13是我們型錄中的決策模型，透過POST /v1/systemone提供上方兩個模型皆實作的相同狀態與具名問題契約：輸入文字，輸出結構化 JSON，最多約 64K 輸入 token，非串流，每百萬輸入 token 收費 $0.042，且不收完成費用，因為它從不產生完成內容。值得注意的是，上方兩張卡片都未完整回答的 Android 風格 token 預算問題，在此獲得解答。

本次比較中的這兩款模型，我們都沒有提供。Decision 3.0 的檢查點是以 Hugging Face 儲存庫中的本機推論路徑形式發布，而非可路由的端點；Microsoft-Decision-1 則是透過 Microsoft 自家平台及數個第三方平台散布，並非透過我們。這裡的任何內容都不應被解讀為對任一模型可用性的聲明。

在這個決策中，路由層真正值錢的地方在於迴圈的另一半。評分器在結構上本來就便宜；但依據它的輸出採取行動的模型並不便宜，而把決策模型與生成式模型配在一起，通常意味著兩套整合、兩段帳務關係，以及兩種故障模式。用一組金鑰就能跨 200 多個模型同時呼叫兩者——當供應商不穩時自動容錯移轉，並以 0% 加成直接轉嫁供應商的定價，讓廠商價格一有變動當天就生效——這意味著你可以汰換評分器，而不必更動呼叫端。這一點在這裡格外重要，因為這兩個模型都還處於早期階段，你這週做出的決定，應該要是下個月就能推翻的決定。

六個月後將決定此事的問題

兩個團隊在同一週把同一個基礎檢查點後訓練成相同形態的產品，卻對它該如何觸達客戶得出相反的結論。這與其說是時機上的巧合，不如說是這個類別銷售方式的分岔：以權重或是以服務，以一種你擁有的東西或是一種你呼叫的東西。

觀察三個訊號。微軟將基礎轉移到 MAI 或自家模型，是否會改變它目前主打的準確度與延遲表現——以及客戶能提前多久獲得通知。vLLM-SR 是否會為 Decision 3.0 公布輸入預算與校準數值，縮小那個讓其指數無法實際採用的落差。以及是否有任何不屬於這兩間實驗室的人，在已釋出的 d3 權重上執行公開測試套件，因為目前唯一能平息這項比較的數字，是兩家廠商都尚未產出的那個數字。