Decision 3.0 已在 Hugging Face 上推出：六個開放多模態決策模型，僅在 X 上公布

Decision 3.0 已以一種你現在就能下載的形式存在，而且幾乎沒有人把它記錄下來。六個檢查點—— d3、d3-flash、d3-mini、d3-nano、d3-lite 與 d3-edge——已進駐 vllm-sr 組織（位於 Hugging Face），於 2026 年 10 月 10 日，由最新到最舊，從 09:38 UTC 開始，並以 d3-edge 在 23:49 UTC 作結。它們採用 Apache-2.0，建構於 Qwen3.5 與 Qwen3.8 主幹之上，能以每個選項一個機率來回答選擇題、是/否題與評分題，而不是生成詞元；六個之中已有五個現在能讀取影像與影片。每張模型卡都自述為「Decision 3.0 的 27B 多模態基礎決策模型，vLLM Semantic Router 的決策模型」，也就是 vLLM 專案的開放決策層。

缺少的是公告。vLLM 專案的 X 帳號祝賀 vLLM-SR 團隊在10月11日發布，並引用了維護者自己的介紹討論串——這就是全部的公開紀錄。該專案的部落格索引仍停在10月10日，最後一篇文章是關於路由決策模型，而不是關於這些模型。其 GitHub 發佈頁面（針對 vllm-project/semantic-router）仍最高只到9月27日的 v0.4.0。模型權重已發布；發布公告則尚未。

這個區別會影響你如何解讀底下所有內容。本文中的每一項效能數據都來自 vLLM-SR 自家的模型卡，是在他們自己的硬體上、以他們自己的測試工具測得。這裡沒有任何內容經過外部第三方重現，而他們發表結果所用的排行榜也是由他們自己維護。這是一份對某個真實存在的產物、以及一項尚未經過稽核的主張所做的早期且誠實的解讀。

Hugging Face 上到底有什麼？

這六個儲存庫簡單、完整，且彼此一致。每個都帶有 safetensors 權重、聊天範本，以及一個 decision_config.json，用於固定基礎模型修訂版本；自訂建模程式碼（modeling_d3.py、d3_engine.py、d3_server.py）、一個獨立的讀出頭 readout.safetensors，以及一個 MODEL_MANIFEST.json，其中每個檔案都有 SHA-256。第七個儲存庫，即集合頁面，列出了全部六個。

這個家族，依尺寸大小排序：

• d3 — 26.09B 個參數，包含一個 0.46B 視覺編碼器，建構於 Qwen/Qwen3.8-27B。上傳於 10 月 10 日 09:38 UTC。

• d3-flash — 8.39B，內含 0.46B 視覺編碼器，建構於 Qwen/Qwen3.5-9B。

• d3-mini — 4.54B，包含 0.33B 視覺編碼器，建構於 Qwen/Qwen3.5-4B。

• d3-nano——總計 2.21B，包含一個 0.33B 的視覺編碼器，建構於 Qwen/Qwen3.5-2B。

• d3-lite — 共 0.85B，包含 0.10B 視覺編碼器，建構於 Qwen/Qwen3.5-0.8B。

• d3-edge — 0.59B，包含 0.10B 的視覺編碼器，同樣建構於 Qwen/Qwen3.5-0.8B。最後上傳，UTC 23:49。

這六者都帶有相同的請求契約：一個狀態（文字或 JSON，可選附帶圖片與影片）加上一組具名問題的字典，以及一組具型別的機率分佈作為回應。問題有三種類型——Choice、Noul（是/否）、Score——而模型會在一次呼叫中回答所有問題，方式是對相同的輸入為每個問題各執行一次前向傳遞，且任何地方都沒有解碼迴圈。

這些數字，以及它們屬於誰

vLLM-SR 發布了一個它稱為 Jev Decision Index 0.3.1 的排行榜，並把 d3 放在榜首。頭條列，全數由廠商回報：

• d3 — 指數 64.7，公開測試套件 65.5，同技能測試 62.8，新領域任務 56.6。

• Perplexity Decider v1.1 (27B) — 62.8, 62.3, 61.1, 55.6.

• Fastino GLiDE 無思考模式（28B）——60.2、59.1、59.5、52.9。

• Jev — 60.1, 58.0, 58.0, 55.0.

• Torchcast Decision 27B — 59.9、65.1、58.1、50.8。

• Decision 2.0 (27B)，上一世代 — 55.9、57.0、55.7、47.9。

d3 卡片上的一則註腳明白指出，d3 自己那一列是內部評估，而比較列則是 10 月 10 日讀取的即時看板資料。這是該做的正確揭露，而且值得讀兩次：競爭對手的數字是從看板抓下來的，而受測對象的數字則是由打造該模型的團隊產生的。卡片還聲稱，所有 140,178 筆公開請求都得到了回應，沒有任何一筆未獲支援——這是覆蓋率主張，而非準確度主張，而且是一項不尋常會公開的主張。

較小的檢查點都宣稱自己步伐一致地前進。每張卡都給出公開測試套件的成績，以及相對於 Decision 2.0 中同等規模的變化量：d3-flash 57.79，比先前的 9B 高出 11.0；d3-mini 54.90，高出 10.7；d3-nano 42.22，高出 12.2；d3-lite 36.93，高出 16.4；d3-edge 28.82，高出 12.1。相對增幅在該範圍的最低端最大——如果多模態預訓練配方對小模型的助益大於大模型，這正是你會預期的結果；而如果你把小模型調得最用力，也會得到同樣的結果。從外部無從分辨究竟是哪一種。

多模態的部分才是真正的變革

Decision 2.0 的模型讀取文字。Decision 3.0 的模型則讀取文字、圖像與影片，而這正是兩代之間的實質差異——並非索引的變動。每張卡片都將圖像輸入列為 PNG、JPEG 或 WebP，並以路徑、URL、PIL 圖像或 base64 資料 URL 的形式提供，每次請求可附上數張，每張最高 1.6 百萬像素；影片則為 MP4、WebM、MOV 或 MKV，或以幀陣列的形式提供，以每秒 2 幀讀取，整段影片最多 32 幀，每幀最高 0.2 百萬像素。請求中的每個問題都能看到附加於該請求的每張圖像與每段影片。

影片的佐證是涵蓋全部 19,140 道驗證題的 Perception Test 結果：d3 為 77.4，d3-flash 73.3，d3-mini 70.3，d3-nano 63.5，d3-lite 59.3，d3-edge 46.6，對照三選項題中已有文獻記載的隨機基準 33.3。vLLM-SR 將此標示為內部評估。d3 也有一份視覺排行榜，將其整體列於 71.6，領先 Perplexity Decider v1.1 的 70.6 與 JEV-27B-VL 的 69.6，而比較列同樣取自排行榜資料，而非由作者實際執行。

吞吐量數字是單一請求、單一 GPU 的數據，且已如此註明：d3 在單一 AMD Instinct MI325X 上，回覆文字請求的中位數為 55 毫秒，攜帶影像的請求為 273 毫秒，攜帶十秒影片的請求為 553 毫秒。d3-edge 則分別以 6.7 毫秒、41.9 毫秒和 308.3 毫秒完成相同工作。那些是每個問題的中位數，而該模型是設計來在單一工作流程中被呼叫許多次的，這才是這些模型所針對的架構真正重要的數字——二十個連續決策每個多花 100 毫秒，就會多出兩秒；Microsoft 本月針對自家的決策模型也提出了相同論點。

這些儲存庫沒有說的事

在任何人據此規劃之前，有三個缺口值得先指出。

首先是輸入預算。decision_config.json針對最大的模型集max_length設為 null，而且沒有任何卡片針對狀態、問題加上選項說明訂出 token 上限。Decision 1.0 的卡片公布了明確的預算——編碼器分支為 1,024 個 token，解碼器分支為 16,384 個——這些數字是實實在在的規劃限制。它們在此處付之闕如格外顯眼，而這是後續提交最值得補上的一項。

第二點是校準。決策模型最重要的數字不是準確率，而是回傳的 0.9 是否代表十次中有九次。視覺與文字指標對此隻字未提。六張卡片中，沒有 Brier 分數，沒有期望校準誤差數字，也沒有溫度。InternLM 在九月就自家決策模型公布了這兩項；vLLM-SR 則尚未，對這個家族的任何成員皆然。

第三個是獨立性。Decision 2.0 的模型已經有兩週的外部使用；Decision 3.0 的模型則只有幾個小時。10 月 11 日的下載次數——d3 是 130、d3-lite 是 83、d3-nano 是 82——是一次上傳留下的足跡，而不是被採用的證明。請把上述每一項指數數字都當成一個附有儲存庫的假設。

這在你今天就能用得上的堆疊中處於什麼位置

關於決策模型，實務上的問題在於它是否能直接放入既有的流程，而在這裡，生態系走得比模型本身更前面。這些模型使用的 System One 請求格式並非 vLLM-SR 專有：它與呼叫託管 Jev 模型時所用的狀態與具名問題契約相同，這正是為何「Jev」既以指標名稱出現在 d3 的模型卡中，也以排行榜上的一列出現。

OrcaRouter 負責這個家族的那一邊。typesafe/jev-1.13已收錄在我們的型錄中，並透過POST /v1/systemone 提供服務——相同的合約內容，價格為每百萬輸入 token 0.042 美元，且不收完成費用，因為根本沒有完成輸出，輸入上限約 64K token，文字進、結構化 JSON 出，不支援串流。這正是決策層今天就能呼叫的那種模型。有兩件事我們不做任何宣稱：d3 以及 Decision 3.0 的其餘部分並不在我們的型錄中，而 Decision 3.0 的本機推論路徑是 Hugging Face 儲存庫裡的一個 Python 類別，並不是我們就算想路由也無從路由的端點。路由器在這裡真正能為你帶來的價值，在於迴圈的另一端——也就是對決策採取行動的生成式模型，透過單一金鑰在 200 多個模型之間路由，並在供應商出狀況時自動容錯移轉，因此在工作流程前面多加一道評分步驟，並不代表還得多添一段供應商關係。

什麼會改變這幅景象？

四件事，大致按照它們能告訴你多少資訊的順序排列。一篇來自該專案的部落格文章，說明輸入預算與預期的部署形態，這將確認這是一次發布，而不是一次推送。任何一個檢查點上的 Brier 分數或 ECE 數字。第三方在已發布的權重上執行公開測試套件，而不是閱讀索引。還有一個執行環境——semantic-router 儲存庫在 10 月 11 日提交了兩筆提交，將 d3 和 d3-edge 接入其模型執行環境，包括影片輸入，這表明服務方案正在建構中，並且將成為讓這些模型可以低成本試用的關鍵。

至少在那些東西有第一項問世之前，老實的總結是這樣：Hugging Face 上確實坐著一個完整、採 Apache-2.0 授權、名副其實的多模態決策模型家族，規模從 0.6B 到 27B，發表時附帶異常完善的來源追溯——檔案雜湊、鎖定的基礎修訂版本、明確標示的硬體目標——但周邊文件卻異常稀少，讓你無從判斷是否該採用它。下載它不花你一毛錢。要相信那個指數，則還得再等等。