Microsoft-Decision-1 對 Kev：購買分數，還是擁有產出分數的配方

Jared Palmer 在他的模型旁邊放了一份收據。Kev 家族——Kev-0.8B、Kev-4B 與 Kev-9B，建構於凍結的開放權重基礎檢查點之上，搭配一個秩為 16 的 LoRA 適配器與一個小型指標頭——於 2026 年 9 月 24 日發布，其訓練配方、各階段的資料筆數以及評估數字全部公開；而對任何拿它與 Microsoft-Decision-1 相比的人來說，最誠實的標題是：Kev 告訴你的關於如何複製它自身的資訊要多得多。微軟的評分器於 2026 年 10 月 8 日在 Microsoft Foundry 正式推出：一個由微軟後訓練的 Qwen3.5-9B 基礎模型，32,768 詞元的上下文，僅支援文字，權重不釋出，公開了評估方法論，但未公開任何結果。兩者都接收一個狀態與一組帶型別的問題，並回傳校準過的機率分布，而非生成的文字。一個是服務，另一個是你今晚就能在 notebook 裡執行的方法。

決定這場對決的是這項區別，而不是能力：Kev-4B 在其域外鎖定測試上報告 ECE 0.017，而 Microsoft-Decision-1 則未報告任何數據，因此，通常能裁決評分器對評分器比較的校準論據，只有一方陳述了其立場。

Kev 實際上發佈的內容

Kev-4B 的卡片異常具體，而這份具體性正是重點。其主幹是 Qwen3.5-4B-Base，凍結於一個具名修訂版本，具有 24 層 Gated DeltaNet 線性注意力層，以及 8 層隱藏大小為 2,560 的完整注意力層。在其之上是一個秩為 16 的 LoRA 適配器——3380 萬個可訓練參數，套用於注意力、MLP 與 DeltaNet 投影——以及一個指標頭，會將每個選項的結尾詞元與問題的最終詞元進行評分並做 softmax。有一個溫度值 T = 2.41 儲存於頭部檔案中，並在載入時套用，而卡片給出了擬合值與檔案雜湊。訓練分階段進行，並公布了記錄數量：基礎配方為 12,576 筆記錄，1,425 筆用於日期與缺失證據，5,219 筆真實 CFPB 投訴敘述，6,000 筆技能記錄與 5,320 筆開發者工具記錄，後續階段則重播較早的階段。卡片也說明了未使用的部分：「未使用任何 Jev（TypeSafe 的託管決策模型）的輸出。」

基準表在同一頁上陳述，並且附帶了失敗案例，這比成功案例更為罕見。Transfer-v4 鎖定的域外測試：準確率 0.838，Brier 0.224，ECE 0.017。Breadth-v1 在 14 個保留資料集和 3,089 個問題上：準確率 0.690，ECE 0.029。Hard-v1 測試：0.803。Documents-v1 測試：0.903。MMLU-Pro 有十個選項：0.565。日期運算：0.65，被作者稱為最弱的部分，並提供了一個預處理器旗標作為部分修復，且明確註明它未重新測量。限制章節補充說，校準是單一的分布內溫度，因此覆蓋率在域外會下降，選項順序可能翻轉答案，而且超過 8,192 個 token 的長度會被提供但未經驗證。服務數據也已發布：在 H100 上，六個問題在短狀態下的時間為 18.1 毫秒，快取時為 12.9 毫秒，14.3 GB 的常駐 GPU 記憶體。

微軟反而發佈的內容

Microsoft-Decision-1 涵蓋大部分相同範圍，但採不同取向。它會對是/否、多選、評等、分類與評分規準題進行評分，支援「無法判斷」等明確棄答選項，傳回 JSON 機率，並可在單次呼叫中執行、處理最多 32K 個權杖——是 Kev 所驗證上下文長度的四倍。它以託管 API 形式在 Microsoft Foundry 的 Direct from Azure 產品組合下提供，具備無伺服器與統一端點部署、標準 SKU、Azure 驗證及統一計費路徑。批次推論已停用，且不提供權重下載與微調途徑。

評估部分描述了公開與社群決策基準，以及保留的內部資料集、包含準確度與校準誤差的指標、選項順序變化、成對統計檢定，並聲稱該模型「表現與領先的決策模型相當，且領先於其他以相同方法評估的開放決策模型」。文中沒有表格。模型卡誠實地列出自身限制——分數會隨措辭與選項排序而變動、校準在熟悉的任務類型上最強、不產生解釋，且非英語覆蓋率最弱——但限制清單不等於校準量測。任何人在 Microsoft-Decision-1 上設定 0.9 自動接受閾值，都是憑信心設定，並在生產環境中調整。

比較中需要付費的部分

Kev 的經濟效益是這場對決真正接近的原因。這個做法是凍結的基礎模型加上一個 33.8M 的適配器，這意味著你訓練的邊際模型所耗費的算力是適配器規模，而非基礎模型規模。你可以將基礎模型一次保留在記憶體中，並載入多個適配器——每個決策領域一個——這是 Microsoft 的代管 API 完全無法表達的部署形態。如果你的路由規則與通用評判器的不同，Kev 讓你訓練出差異；Microsoft-Decision-1 則讓你寫出更好的提示詞，然後祈禱。

相對地，託管 API 不帶任何維運面。沒有需要追蹤的 adapter，沒有需要保持暖機的服務堆疊，沒有驗證情境與實際服務情境之間的落差需要推敲，也沒有風險是：在某個資料集上擬合出的 temperature，到了你的資料集上卻有不同表現。對決策量不大的團隊來說，即使 token 要花錢，以工程時數計，這項服務仍是較便宜的產物；對每天要為數百萬個項目評分的團隊來說，一旦 GPU 成本付清，自架 adapter 就會在單位成本上勝出。

還有第三條路徑，它在模型最弱的那個環節上兩者都不用，而這正是 OrcaRouter 所在的位置。我們不自行託管 Microsoft-Decision-1 或 Kev——一個會回傳機率的評分器並不是 chat-completions 的目標端點，而這兩個模型也都不在我們的目錄中。決策流程中生成的那一半，才是我們所提供的：負責草擬候選答案、撰寫評分準則，或發出待評分之工具呼叫的模型。這些全都透過一把與 OpenAI 相容的金鑰提供，其上掛載超過 200 個模型，以供應商定價原價轉嫁、零加成，因此供應商一調價，我們這邊當天就同步生效。如果你正在打造評分或分流迴圈，撰寫的那個呼叫是可路由的，評分的那個呼叫則不是，而把這條界線劃分清楚，正是防止評分流程悄悄變成聊天流程的關鍵。

如何決定

選擇 Kev，當你需要在上線前先取得數字、當你想用自己的決策標籤進行微調、當你想在自己的邊界內以零邊際成本執行評分，或當你想讓多個決策領域共用同一個常駐基礎模型時。它公布的 ECE 數字仍是作者以自家測試框架所做的自行測量——請把它們視為可信的自我評估，而非經稽核的第三方結果——但至少它們是一個已明確陳述的尺度，讓你可以嘗試重現，而且重現它們的做法就擺在眼前。

當決策的把關條件在於採購流程或上下文長度時，請選擇Microsoft-Decision-1：一個受管理的 Azure 端點，具備統一帳單與負責任 AI 套件、支援長文件的 32K 輸入，以及有供應商可以讓你向上呈報求助。它缺少基準測試比較表並不是什麼醜聞——許多託管模型推出時也都沒有這類表格——但這確實意味著這個模型的第一條校準曲線將由它的使用者來描繪，而你應該規劃自己成為其中之一，在你自己的標註資料上先行驗證，之後才把正式環境的門檻指向它。