Decision 3.0 vs Intern-Decision-4B：兩個團隊微調了同一個模型，卻在其他所有事情上意見分歧

把 d3-mini，也就是 Decision 3.0，放在 Intern-Decision-4B 旁邊，你首先注意到的並不是差異。兩者都是同一個基礎檢查點的微調版本，也就是 Qwen3.5-4B。兩者的參數量都列為 45.4 億。兩者都接收一個狀態、一組具名問題的結構描述與一組候選答案，並為每個候選答案回傳經過校準的機率，而不生成任何 token。兩者皆為 Apache-2.0。兩者都是在沒有公告的情況下發布——InternLM 在 2026 年 9 月 26 日於四十秒內上傳了三個檢查點，而 vLLM-SR 的 Decision 3.0 系列則在 2026 年 10 月 10 日登上 Hugging Face，相關消息僅由 vLLM 專案的 X 帳號披露。

在那之後的一切都是分歧。他們對於如何從模型中讀出機率、影片是否算作輸入、一個請求可以有多長，以及——最尖銳的是——團隊是否願意公布那個顯示自身信心值得信賴的數字，意見不一。本文談的是這四項分歧，以及每一項讓你付出什麼代價，而不是哪個模型「更好」，因為這兩者並非以同一把尺衡量，若不做兩家供應商都還沒做的工作，就無法彼此排名。

值得先理解的巧合

兩間實驗室在兩週內選用同一個 4B 主幹，其實並不完全令人意外——Qwen3.5-4B 對結構化輸出模型來說是個合理的基礎，而兩個團隊顯然都選擇了它，因為它小到足以低成本運行，又強到足以讀懂指令。真正令人意外的是，他們得出了相同到四位有效數字的參數量。這說明了微調保留了架構，而且雙方都沒有加入足以改變總量的獨立視覺塔。兩者都把多模態能力折疊進同一組權重裡。

有趣的部分在於讀出。兩個模型原則上以相同方式回答問題——對候選答案評分，而非生成答案——但在機制上完全不同：

• Intern-Decision-4 — 將每個選項映射到單一的 token 符號（A–Z，接著 a–z，然後 0–9），在提示中渲染出一個 JSON 骨架，每個欄位各有一個佔位符，並執行一次因果前向傳遞，讀取每個佔位符緊接其後位置的 logits。此機制在其模型卡上逐步記錄，包括 softmax 與溫度步驟。

• d-mini — 隨附一套自訂架構於 modeling_d.py，並在其專屬的 readout.safetensors 中配備獨立的 readout 頭，一個 decision_config.json 宣告 noncausal_full_attention 與最後 token 池化，以及一個定義於設定中而非以文字描述的 token 對程式碼對應。

這兩種做法都沒有明顯較好。InternLM 這條路線的優點在於，它能在標準的 Hugging Face 模型類別上執行，並具有有文件記載的數值序列——你可以查核它的運算。vLLM-SR 這條路線的優點在於，其讀出結果是訓練出來的 head，而非既有 token 嵌入的投影，因此擬合更自由；代價是你必須 trust_remote_code=True，而且得執行他們的程式碼才能做任何事。

每一個所公布的限制

這正是真正的偏好開始形成的地方，因為其中一張卡對於它在哪裡停止運作，遠比另一張來得明確。

• 輸入上限 — Intern-Decision-4B：預設為 8,192 個 token，超過此上限的請求會直接遭到拒絕，絕不會被截斷，且上限由建構函式引數設定。d3-mini：max_length 是 null 在隨附設定中，且卡片上任何地方都沒有出現 token 預算。

• 每次請求的題目數 — Intern-Decision-4B：1 到 16，並載明任一題最多可有 62 個選項。d3-mini：未載明限制；卡片僅說明題目會一併回答，各自來自其本身的前向傳遞。

• 圖片 — Intern-Decision-4B：每次請求最多八張，依您提供的清單排序，並由檢查點處理器負責調整大小與權杖擴展。d3-mini：每次請求可提供多張，以路徑、PIL 圖片或 base64 資料 URL 的形式，每張以最高 160 萬像素讀取，每個問題都能看到每張圖片。

• 影片 — Intern-Decision-4B：無。d3-mini：多個影片，以每秒 2 個影格讀取，上限為整段影片中分散取樣的 32 個影格，每格 0.2 百萬像素。

對大多數人來說，輸入上限就是決定這件事的關鍵界線。在狀態、問題指令與候選描述之間共享的 8,192-token 預算，對這些模型所主打的文件評分與長上下文路由工作而言，是一項實實在在的限制；而 InternLM 值得讚許的是，它直言不諱，而不是留待他人自行發現。vLLM-SR 未說明此事則恰恰相反：那不是隱藏的限制，而是未知的限制，而且再怎麼翻閱其儲存庫也無法確定。

校準才是真正的分野

每個決策模型都做出同樣的承諾：它回傳的數字是一個機率，而依此設定的閾值是有意義的。幾乎沒有模型能證明這件事。這正是兩個版本差異最大的地方，而差異的方向，恰恰與你從發布日期會猜到的方向相反。

Intern-Decision-4B 在其自身的卡片上公布，於其七個基準的平均上，Brier 分數為 0.347，預期校準誤差為 0.065，並公布一個經 NLL 最小化擬合得出的溫度 1.99241824，該擬合是在 1,728 個指定校準案例與 1,693 個獨立驗證案例上進行；同時明確聲明測試套件標籤並未用於選擇該溫度；以及一份 96 案例的診斷，顯示其校準從溫度調整前的 0.628 Brier / 0.213 ECE 變為調整後的 0.550 / 0.089。它亦說明預設值，並表示校準是依檢查點而定的，因此將此模組與其他尺寸搭配使用時將不會相符。

Decision 3.0 公布了一項準確度指標與一項覆蓋率聲明——140,178 個公開請求全部獲得回覆，沒有任何一個未受支援——卻完全沒有任何校準數值。在六個檢查點中的任何一個上，都沒有 Brier 分數、沒有 ECE，也沒有說明溫度。 溫度在 d3 隨附的 decision_config.json 中是 1.0，也就是恆等值，可能也可能不是擬合值；檔案並未說明。

把兩則索引標題並排閱讀，不對稱就更明顯了。d3-mini 的卡片回報 Jev Decision Index 0.3 public-suite 分數為 54.90，說明是使用官方工具包在已發布的權重上測量所得，而同一看板上的比較列則被描述為即時看板資料。Intern-Decision-4B 回報在其自身的七項基準測試中平均為 90.02。這兩個數字不在同一尺度上，它們並未使用相同的任務，把它們放進同一句話裡當作比較會是不誠實的。可相比較的是揭露程度：一張卡片告訴你它的信心程度錯得有多離譜，另一張則不知道，或者不願說。

延遲，以及為什麼這兩組毫秒數也無法互相比較

兩張卡都公佈了每請求延遲，而把它們照表面解讀會是個錯誤，原因就和準確率數字無法互相比較一樣。

• Intern-Decision-4B — 平均 44.16 毫秒，中位數 44.03 毫秒，p95 44.60 毫秒，在單張 RTX 4090 上透過本機 Hugging Face 路徑測得，並註明會依工作負載與硬體而異。

• d3-mini— 文字的中位延遲為 17.5 毫秒，搭配圖片時為 96.2 毫秒，搭配十秒影片時為 371.5 毫秒，在單一 AMD Instinct MI325X 上，一次處理一個請求。

有兩件事讓這兩者無法相提並論。第一是硬體與軟體路徑：4090 對上 MI325X，標準的 Hugging Face 前向傳遞對上可透過 flash-linear-attention 取得遮罩層 kernel 的自訂注意力實作。第二是工作負載：InternLM 的數字被描述為在未說明的混合工作負載下、每查詢的端到端數據，而 vLLM-SR 的數字則依輸入模態細分，因此純文字比較是唯一同基準的比較項目，而且甚至連它都跨越了兩家 GPU 廠商。

要從兩張卡片取得的數字不是排名，而是形狀。決策模型會在單一工作流程內被反覆呼叫——一筆支援紀錄可能需要一個目的地、一項退款檢查、一個升級決策和一組優先順序分數，也就是四個問題，而一批 128 筆紀錄會讓這變成 512 次決策。在那樣的量體下，17 毫秒和 44 毫秒相較於下游生成式模型的成本，都會顯得微不足道。真正該留意的是取決於模態的數字，因為就 d3-mini 自身的數據而言，一筆圖片或影片請求的成本是文字請求的五到二十倍；而如果你的決策是根據螢幕截圖做出來的，那你已經引入了一種大多數決策模型部署所沒有的成本概況。

到底該選哪一個？

如果你需要做的決策取決於影片，那就無需比較、也無需分析：Decision 3.0 能讀取影片，而 Intern-Decision-4B 不能。對於任何涉及螢幕錄影、相機片段或影格序列的情況，這就是完整的答案；而這個能力差距本身就足以證明較新系列存在的正當性。

如果你的輸入是文字和偶爾出現的圖片，選擇就取決於兩件事，而這兩者都不是排行榜。

當你需要針對閾值進行推理時，請採用 Intern-Decision-4B。在兩者之中，它是唯一會告訴你 0.9 是否代表十次中有九次、會明確說出它的溫度、會指出該溫度是在哪些案例上擬合出來的，並且將其推論記錄成一段簡短的編號程序，讓你能對著現成的模型類別重新實作。對於坐鎮在自動化動作之前的評分器而言，這才是真正要緊的性質，而且它比準確率分數更為罕見。

當你需要涵蓋範圍或模態時，請採用 Decision 3.0。從 0.59B 到 26.09B 的六個檢查點意味著，相同的請求格式可以由 6.7 毫秒的邊緣模型和 27B 的模型來服務，而且這個系列共用同一個介面，因此在層級之間移動只是設定變更，而不是重寫。問題在於，你信任的是一個未明示的輸入預算，以及一項未經稽核的校準宣稱，而這個系列中最大的模型，正是其索引編號由供應商在自己的測試框架上測得的那一個。

如今，兩者都不是安全的預設選擇。d3 下載次數最多的 checkpoint 在 Hugging Face 上架大約一天；Intern-Decision-4B 已上架兩週，累積約 3,200 次下載和 83 個讚，這代表有受到關注，但還不是正式生產環境的流量。兩者都便宜到足以測試，且背後都沒有第三方評估。如果你要把評分器放在會花錢的環節前面，正確做法是在你自己標註的案例上跑這兩者，並比較校準曲線，而不是比較排行榜上的列。

路由器適合放在哪裡，老實說

OrcaRouter 並未提供這兩個模型中的任何一個。Decision 3.0 的檢查點是 Hugging Face 儲存庫中的本機 Python 推論路徑，並未發布任何 HTTP 端點；而 Intern-Decision-4B 則是以一個 DecisionEngine 類別的形式發布，需由你自行具現化。兩者都不是我們目前能夠路由的對象，本文任何部分都不應被解讀為可用性聲明。

我們確實提供的是同一家族中的託管版本。typesafe/jev-1.13已在我們的目錄中，透過POST /v1/systemone提供服務——與上述兩個開放模型所實作的相同狀態與具名問題合約——每百萬輸入 token 收費 $0.042，且不收取完成費用，因為它從不產生任何完成內容。它與其他 200 多個模型並列，而這正是任何比較這兩者的人的實際重點：評分器是迴圈中便宜的部分，而依據決策採取行動的模型才是昂貴的部分。將兩者透過同一把金鑰進行路由，並在供應商不穩時自動容錯移轉，且供應商定價以 0% 加價原樣傳遞，這表示評估一個決策模型不需要簽署第二份合約，也不必在切換後端時改寫呼叫端。如果你正處於評估階段——這兩個模型今天都處於此階段——那就是在你決定採用任一個之前值得先架設好的部分。

未解決的問題

這兩張卡在「模型作者對讀者負有什麼責任」上意見相左，而這個分歧比模型本身更有趣。InternLM 公布了溫度值以及它擬合所用的案例，接著公布了顯示校準改善了多少的診斷資訊。vLLM-SR 公布了檔案雜湊值、固定的基礎修訂版、明示的硬體目標、覆蓋範圍的宣稱——貨真價實的溯源工作——卻完全沒有校準數字。

哪個版本會成熟，考驗不在於它是否在排行榜上勝出，而在於下一次的 Decision checkpoint 發布時是否附有 Brier 分數，以及 InternLM 的下一次上傳是否觸及影片。這兩者都能從外部看見，檢查起來也都很便宜，而且都還沒發生。