Microsoft-Decision-1 對決 Laya：25 種語言藏在 API 背後，100+ 種藏在 322MB 下載背後

數一數語言數量，勝負似乎就已底定。 Microsoft-Decision-1自 2026 年 10 月 8 日起於 Microsoft Foundry 正式推出，列出 25 種支援語言，並明白表示涵蓋範圍、品質與校準「可能因語言而異」，並點名非英語、尤其是資源較少的語言為表現欠佳的領域。 Laya由 Convai Innovations 於 2026 年 9 月 18 日以 Apache 2.0 發布，自稱具備橫跨 100 多種語言的多語能力，並回報在 51 種受測語言中有 45 種在搭配路由時仍保持可用，相較之下，其僅支援英語的同系列模型則只有 51 種中的 23 種。一款是部署在 Azure 端點後方、具備 32,768 個詞元上下文的 9B 模型；另一款則是 4.21 億參數的分類器，在單張 Tesla T4 上每項決策只需 32.8 毫秒，而且免費。兩者都不產生任何詞元，且都會針對你定義的選項回傳機率。

但若完整讀完這兩份模型卡，語言數量就不再是有趣的數字。真正有意思的是它背後的校準故事，而這兩個專案以相反的方向講述了那個故事。

Laya 公布了那個讓自家行銷顯得尷尬的數字

Laya 模型卡在其自身的限制章節中指出，基礎檢查點在 typed-decisions 基準上的零樣本得分為 0.362——低於 0.461 的多數類別基線。這張卡等於在告訴你，它的模型在該測試上比猜「最常見答案」還差。它也指出，基礎檢查點在零樣本下接近隨機，備受矚目的 0.766 typed-decisions 數字需要在該基準自己的切分上微調，序數分數問題是最弱的基礎能力（SST-5 0.372），高基數選擇題之所以吃虧，是因為 77 個選項讓每個選項只剩大約三到四個 token，且 noul能遵循自己的標籤，且 action.act_probability欄位在 AUROC 0.30 下「尚未帶有任何可用訊號」。Convai 自己的總結句，才是任何評估都該帶著走的那句話：Laya 是可快速特化的基礎，不是零樣本決策引擎。

那份坦率比聽起來更有價值，因為它正好說明了 Laya 的用途。它是一個讓你用自己的標籤微調的編碼器——整個架構的設計，是為了讓新的結構描述無須重新訓練，但若要在某項任務上表現良好，則需要重新訓練。以這種方式使用時，公佈的數字很強勁：微調後，具型別決策為 0.766，對比 Jev 的 0.727；AG News 為 0.950，對比 0.910；DAIR Emotion 為 0.595，對比 0.480；ECE 為 0.081，對比 Jev 的 0.246——並誠實註明它發佈時過度自信，需要溫度重新擬合，這會使平均 ECE 從 0.466 變為 0.081。

Microsoft 公布方法論，但不公開結果。

Microsoft-Decision-1 的 Foundry 頁面則以相反方向進行同樣的練習。它詳細描述了評估——公開與社群決策基準，加上保留的內部資料集，指標包括準確度和校準誤差，選項順序變化，配對統計檢定，比較模型使用相同的測試框架——並報告該模型「與領先的決策模型表現相當，且領先於其他以相同方法評估的開放決策模型。」它列出了其強項（推理、規則應用、對提示格式的穩健性）和弱項（專業領域知識、非英語）。

接著它什麼都不會印出來。沒有準確率數字，沒有校準誤差，沒有逐項基準的分數。它自陳的限制是真實且有用的——分數會隨措辭與任務排序而變動、問得拙劣的問題照樣會回傳答案、校準在熟悉的任務類型上表現最強、不提供任何解釋——但一份限制清單並不等于一次量測。所以這筆取捨異常乾淨：Laya 給你的是你可以拿自己的資料試著推翻的數字，而 Microsoft 給你的則是一種合規姿態，以及一個能塞進長文件的 32K 上下文。

尺寸差異實際上換來什麼

Laya 的小巧在此並非妥協，而是設計。因為每個選項都會在它自己的 [MASK] token 上評分，並對該問題的選項做 softmax，答案空間是在請求時組裝，而非預先烘焙進詞彙頭中——這就是為什麼你今天下午才發明的結構描述不需要重新訓練，以及為什麼該模型能塞進 3.22 億到 4.21 億個參數。多語言檢查點比英語檢查點快約 2.2 倍，路由器在不到半毫秒內偵測書寫系統，而在單張 T4 上，批次吞吐量可達每秒 103 到 332 個問題。對於需要為每張工單、每份檢索到的文件或每個建議動作評分的工作負載而言，吞吐量才是關鍵，而非參數數量。

那個設計的代價同樣具體，也值得對照微軟的替代方案說清楚。英文檢查點採用 512 詞元的視窗；多語言檢查點則是 1,024，並可擴展至 8K。Microsoft-Decision-1 則採用 32,768。冗長的客服討論串、完整合約或好幾頁的政策文件，根本塞不進 Laya 的視窗，再快的速度也補償不了截斷。Laya 每次前向傳遞回答一組問題，每個選項都有文件明載的詞元預算；微軟文件記載的則是單次呼叫最多可達 32K 詞元，且沒有每題上限。另外，Laya 作為分類器時的競爭弱點也值得了解：它在 Banking77 上得分 0.425，而 Jev 為 0.870，這正是專門化處理最要緊的那種細粒度、高基數意圖問題。

不以 token 為單位的成本比較

Laya 在使用點是免費的——可自架、Apache 2.0，在自架成本清單上列為「$0」——而它真正的代價，是你在它能勝任你的任務之前所欠下的那一趟微調訓練。Microsoft-Decision-1 則是代管的 Foundry API，按 token 計費，費率並未印在模型頁面上，沒有權重可下載，沒有微調途徑，且批次推論已停用。一個是先期投入的資料標註專案，另一個是按量計費的呼叫。哪個比較便宜，完全取決於用量，而且交叉點很高：一個 421M 的編碼器在租來的 T4 上每秒可評分 300 個項目，一旦訓練完成，就每次決策而言極難被超越。

當流程是建立在這兩個模型任一個之上時，OrcaRouter 之所以能佔有一席之地，正是在這裡，而且僅限於生成端。我們既不代管 Microsoft-Decision-1，也不代管 Laya：兩者回傳的都是機率而非文字，兩者都不在我們的目錄中，而評分端點也不是 chat-completions 的目標。我們確實提供的是產出被評分內容的模型——也就是草擬回覆、提議的工具呼叫、候選答案，接著由 Laya 微調後的頭部進行評判。在單一 OpenAI 相容金鑰背後提供超過 200 個模型，以供應商定價原價轉嫁、0% 加價，並在某個服務路徑效能下降時自動容錯移轉。在一個會為自己生成的一切評分的迴圈中，生成呼叫正是可能失效的部分，而容錯移轉正是讓評分佇列持續有東西可處理的關鍵。

該選哪一個

採用 Laya，如果你的決策會以多種語言出現，如果你的量體大到每個 token 的計價很重要，如果你有標籤和一個星期的時間進行微調，或者如果你需要在自己邊界內的硬體上執行評分。接受 512 到 1,024 個 token 的視窗，以及基礎檢查點在你對它進行特化之前會接近隨機水準的事實，你就能得到一個對自己是起點這件事誠實的決策模型。

選擇Microsoft-Decision-1，如果你的輸入是長篇文件而非工單，如果你的部署關卡是 Azure 驗證、統一計費與一套負責任 AI 套件，而非一次下載，如果 25 種語言已足以涵蓋你的流量，或者你根本不想自己擁有這個模型。請接受你將得親自畫出它的第一條校準曲線，並為此在標註樣本上預留一個下午的時間——因為與 Laya 不同，這一個不會直接丟給你一個 ECE 數字讓你爭論。