NVIDIA Nemotron Labs Dory 1.0 4B 對上 MiniCPM5 2B：自訂執行環境對決純粹的 LlamaForCausalLM

關於 NVIDIA Nemotron Labs Dory 1.0 4B 與 MiniCPM5-2B，最值得注意的不是任何一個模型的基準測試表，而是 MiniCPM5-2B 架構章節第一行所出現的內容。它的模型卡直截了當地說，其架構是標準的 LlamaForCausalLM：42 層、分組查詢注意力，具有 16 個查詢頭與 2 個 KV 頭，沒有自訂核心，也不需要分支模型程式碼。Dory 的模型卡在每個實際層面上都說了相反的事。它的架構是迴圈式潛在遞迴網路，其層區塊會以可變次數套用；而今天若要部署它，你得從一個公開的 pull request 安裝 vLLM，或從某個固定提交建置 llama.cpp。這些模型其中一個可以直接放入你現有的技術堆疊。另一個則要求你先改變堆疊。這個差異將決定的部署數量，會比任一家廠商公布的任何分數都更多。

兩個小型模型，兩個截然不同的押注

NVIDIA Nemotron Labs Dory 1.0 4B是 NVIDIA 的 4B 稠密迴圈模型，以 BF16、MXFP8、NVFP4 與 Q5_K_M GGUF 格式在 Hugging Face 上發布，採用 OpenMDW 1.1 授權，其模型卡標註為「GA (10/16/2026)」。它僅支援文字且僅支援英文，可處理最多 256K 個 token，並將約 6 兆個預訓練 token 投入一套原生以 NVFP4 訓練的技術堆疊，前約 4.5T 個 token 採用此方式，之後切換至 BF16，接著再以 300B 個 token 擴展至長上下文，最後以 SFT 加上多環境 GRPO 強化學習收尾。它的發布沒有伴隨任何形式的公告。

MiniCPM5-2B 是 OpenBMB 的 2.5B 稠密模型——總參數為 2,516,756,480 個，其中非嵌入參數有 1,981,982,720 個——採用 Apache 2.0 授權，具備 131,072 個詞元的上下文視窗，並支援英文與中文雙語。它是 MiniCPM5 系列繼 1B 之後的第二款作品，旨在將模型卡所稱的同一套訓練配方規模化，並且明確鎖定裝置端、本機與資源受限的部署情境。後訓練階段進行了監督式微調、強化學習與同策略蒸餾。模型卡宣稱其在基準測試集上以 53.9 的平均分達到 2B 級開源技術水準。

兩者都小到可以在單一加速器上運行。兩者現在都可下載。之後的一切就分道揚鑣了。

對比，逐個維度來看

• 架構 — Dory 1.0 4B 是迴圈式潛在遞迴的正規化 GPT，交錯使用滑動視窗與完整注意力，內含 8 層輸入區塊、20 層遞迴區塊與 8 層輸出區塊。MiniCPM5-2B 則是傳統的稠密因果 Transformer，42 層，GQA 為 16 個查詢頭對 2 個 KV 頭，標準的 LlamaForCausalLM.

• 入門的服務成本 — 這是重點。MiniCPM5-2B 不需要自訂核心，也不需要分支引擎；如果你的堆疊能運行 Llama 形狀的模型，就能運行這個。Dory 需要從未合併的 pull request 建置 vLLM，或從固定的 commit 建置 llama.cpp，並在執行時覆寫迴圈數和 KV-cache 模式。

• 參數 — 4B 稠密，對比總計 2.516B（1.98B 非嵌入）。Dory 大約大了 60%，而且其循環區塊會反覆套用，因此在四次迴圈下，每個 token 的有效運算量超出參數數量所暗示的程度。

• 背景 — Dory 在 vLLM 中達到 256K tokens，並驗證了 262,144 個位置。MiniCPM5-2B 支援 131,072。Dory 的視窗是兩倍；你是否想為此付出代價，就是下方會說明的 KV-cache 問題。

• 語言 — Dory 僅支援英文，其預訓練混合資料中包含 43 種程式語言。MiniCPM5-2B 則支援英文與中文雙語。對於中文工作負載而言，這個面向即可決定比較結果，無須參考其他任何一列。

• 授權 — Dory 採用 OpenMDW 1.1，MiniCPM5-2B 採用 Apache 2.0。兩者皆允許商業使用；Apache 2.0 是大多數法律審查已核准的授權條款。

• 運算彈性 — Dory 的深度是執行階段參數：一次迴圈換取低延遲，兩次是建議的預設值，四次則適用於代理任務準確度更重要的情況，全都來自單一檢查點。MiniCPM5-2B 的深度固定，其效能槓桿是量化——該系列提供 GGUF、MLX、GPTQ 與 LiteRT 版本，以及用於推測解碼的 DSpark 草稿模型。

• 生態系 — MiniCPM5-2B 自 2026 年 9 月初起已公開，下載次數超過一百萬，並有各式各樣的量化與衍生版本。Dory 的四個儲存庫在一夜之間被填入內容，而在撰寫本文時，其下載計數器均為零。

這些數字，以及為什麼你不應該將它們相減

兩張卡都公布了基準測試表，而這些表在夠多任務上有所重疊，因此可以進行並排比較。這件事值得仔細去做，因為天真的相減會以一種明確且可預期的方式造成誤導。

讀取 Dory 在其三種迴圈設定下的數值，並與 MiniCPM5-2B 的單一報告數據對照：

• SciCode — 27.3 / 34.94 / 35.11，對比 26.3。在兩次迴圈及以上時，Dory 領先。

• SWE-bench Verified — 50.3 / 59.5 / 61.8 相較於 46.4。

• Terminal-Bench 2.1 — 12.5 / 18.1 / 22.2，相較於 8.6。

• GPQA Diamond — 69.19 / 72.41 / 72.16 對上 70.2。即使只跑一輪，Dory 名義上也落後；跑到三輪以上時，它就略占上風。

• HLE，純文字 — 8.25 / 10.89 / 10.43 對比 8.9。

• IFBench — 74.29 / 77.94 / 79，相較於 66.3。

• AA-LCR — 63 / 71 / 73，相較於 59.0。

Dory 在這些項目中的大多數看起來都更強，有時還強上不少。不過，現在說說為什麼不該相信這套算術：這是兩套不同的測試框架，量測的是兩組不同的提示集，而且兩家廠商都沒有跑過對方的模型。 N​VIDIA 在 NeMo Gym 與 Nemo Evaluator SDK 上量測 Dory，其模型卡也揭露了各項基準的重複次數——SciCode 八次、AA-LCR 十六次，還有幾項基準就只跑那麼一次。OpenBMB 則是在自家環境中量測 MiniCPM5-2B，並在其整套測試上回報了單一平均值 53.9。這兩套設定之間兩、三分的差距不過是雜訊，不是定論。兩份模型卡裡都沒有任何獨立複現，也沒有第三方發表過這兩個模型的正面對決。

有一個結構性理由讓人預期，Dory 的表面優勢在代理型任務上確實存在，並在其他地方消散。其模型卡顯示，迴圈在 SWE-bench 與 Terminal-Bench 上帶來的增益最大，在知識回憶上最小——AA-Omniscience 幾乎不隨迴圈次數變動。MiniCPM5-2B 自身的優勢分布則不同：它回報 τ²-Bench Telecom 97.1、GAIA Text-103 88.7，這些代理型結果是 NVIDIA 的模型卡未以可比較形式衡量的。如果你的任務是狹窄領域中的工具使用，MiniCPM 模型卡的數字才是該優先測試的，而它們沒有一個出現在 Dory 的表格上。

也要注意這兩張模型卡不願比較什麼。MiniCPM5-2B 在其自身平均分上，以 51.1 對比 Qwen3.5-4B、42.7 對比 granite-4.2-3B，以及 33.2 對比 LFM2.5-2.6B。Dory 則以 Qwen3.5-4B、Qwen3.5-9B、Gemma 4 26B A4B 和 Qwen3.6-35B-A3B 作為自己的比較對象。兩張模型卡唯一都給出數字的模型是 Qwen3.5-4B，而它們對它的評分不同——這更能說明測試框架的差異，而非 Qwen 本身。

每一個運作起來要花你多少成本

MiniCPM5-2B 的運作故事很無聊，而在這裡，無聊是種讚美。標準架構、沒有自訂核心、各式現成的量化版本，而且這個家族已經包含針對 Apple Silicon 的 MLX 版本、用於 GPU 推論的 GPTQ、面向行動裝置的 LiteRT，以及用於推測解碼的草稿模型。一個 128K 上下文、2.5B 的 LLaMA 架構模型，能塞進不大的記憶體，並在你已經運行的引擎上提供服務。OpenBMB 將整個系列定位為設計上就是裝置端、資源受限，而模型卡裡沒有任何內容要求你採用新東西。

Dory 的運作故事才是有趣的那個，而且還沒完結。vLLM 支援正在 pull request 60149 中接受審查；在它合併之前，卡片會要你從該分支安裝 vLLM，並設定 precompiled-kernel 旗標，然後以覆寫設定啟動，設定 recurrent 迴圈次數與 KV-cache 模式。llama.cpp 支援在 pull request 30306 中，採用固定修訂版本而非持續變動的 head，並提供針對 Apple Silicon 上原生 ARM64 macOS 的建置指示。N​VIDIA 唯一公布的 Dory 速度數據，是 DGX Spark 上的量化加速——視輸入／輸出組合而定，MXFP8 相較於 BF16 為 1.69× 與 1.84×，NVFP4 則為 2.17× 與 2.44×——不是吞吐量數字。在我們能查證的任何地方，都沒有 Dory 的託管端點。

Dory 這邊唯一真正新穎的工程部分是記憶體設計，而這正是你在投入之前最值得測試的主張。標準的循環迴路會為每個迴圈保留獨立的 KV 快取，因此每增加一次傳遞，記憶體用量就跟著攀升。Dory 支援一種「最後迴圈」KV 快取模式，在每個遞迴注意力層只保留單一快取，並在每次傳遞時覆寫它，無論你跑多少個迴圈，記憶體占用都大致維持在單一迴圈的大小。NVIDIA 表示，準確度仍接近逐迴圈模式，且輸出長度幾乎不變。若此言屬實，彈性深度就是一項實質能力；若準確度有所偏移，這項功能的代價就超出這張卡所暗示的範圍。NVIDIA 以外還沒有人驗證過。

路由器在哪裡能發揮價值——以及在哪裡不能

MiniCPM5-2B 不在 OrcaRouter 的目錄中，N​VIDIA N​emotron Labs Dory 1.0 4B 也不在。Dory 在我們能確認的任何地方都沒有託管端點；MiniCPM5-2B 是裝置端模型，其模型卡是為本機部署而撰寫，而非為推論平台。直白地說出這點，比找一個切入角度更重要，因為實際影響是：這項比較的兩邊，都在你擁有的硬體上執行。

這時，託管的基準模型就成了實驗中令人尷尬的那一部分。大多數評估 2B 或 4B 模型的團隊，並不是在真空中進行評估——他們想問的是，它能否以一小部分的成本、一小部分的能力取代託管呼叫，而要回答這個問題，就得讓託管模型跑同一組任務。一組 OrcaRouter 金鑰就能以供應商定價、0% 加成觸及那些託管模型，不必簽第二份合約，也不必接第二個 SDK，因此這項比較無須自行走一套採購流程。自動容錯移轉在這裡之所以重要，原因不同：在單一 GPU 上進行的長時間本地評估一定會被打斷，而把備援路徑事先接在同一端點之後，就能讓整輪執行持續下去。路由 DSL 讓本地端點與託管端點共用同一個呼叫點，因此混合部署的兩半不會分岔成兩套程式碼庫。這一切都沒有在 Dory 與 MiniCPM5-2B 之間選出贏家。它只是讓淘汰輸家變得便宜。

裁決結果

如果部署摩擦比峰值代理分數更重要，就選 MiniCPM5-2B。它是 Apache 2.0、體積只有一半、雙語、標準架構，而且周邊有各種量化版本，包括行動執行環境。如果你的團隊必須在這個月出貨，而替代方案是要與核心建置搏鬥，那麼 2.5B 光在後勤安排上就勝出——而且它回報的 τ²-Bench 與 GAIA 結果顯示，對於小型模型實際部署所處理的工具使用任務，它並沒有放棄太多。

如果你想要的不是一個模型，而是一場實驗，就選擇 NVIDIA Nemotron Labs Dory 1.0 4B：單一檢查點能隨推論運算量擴展自身的準確率，一個 256K 視窗搭配旨在讓其變得可負擔的快取設計，以及允許商業部署的授權條款。投入前請明白，你將從某個分支自行建置你的服務引擎，每一項公布的數字都是廠商在自家測試框架上取得，重複次數則揭露於註腳，而且下載計數器仍然是零。好處是，你會成為 NVIDIA 之外首批測試以真正不同方式將運算資源花在小模型上的人之一。代價是，你會替 NVIDIA 做它的驗證工作。

最快改變這項比較的，不是某個基準測試。而是 {{1}}vLLM{{/1}} 與 {{2}}llama.cpp{{/2}} 合併它們的 Dory 拉取請求。一旦 Dory 能從已發佈的二進位檔載入，目前有利於 {{3}}MiniCPM5-2B{{/3}} 的阻力論點大多就會消失，而這兩個模型終於能依照基準測試表格所暗示的條件競爭，而不是依照你的建置系統所強加的條件競爭。

這些都不是假設：像這次發布這類版本背後那些有紀錄的 AI 失效與代理事件，全都收錄在OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。