ZoomGain-4B 對上 MiniCPM5 2B：可攜性才是無人公開發表的基準

兩張模型卡都少了一個數字，而這個數字決定了大多數部署。MiniCPM5-2B 提供 GGUF、MLX、GPTQ 與 LiteRT 版本，具備用於推測解碼的 DSpark 草稿模型，而且——最能說明問題的細節——帶有 FlagOS 版本，支援九種不同的加速器系列，包括 Ascend、Hygon、Kunlunxin 與 Metax。ZoomGain-4B 以三種精度提供 GGUF，並且用模型卡自己的話說，需要「具備 Qwen3.5 多模態支援的 llama.cpp 版本」。其中一個模型幾乎能在任何地方執行。另一個則只能在你能建置特定執行環境的地方執行。兩張模型卡都沒有把這稱為基準測試，而對任何必須實際營運模型、而非只是引用它的人來說，這一列比兩個模型的準確率欄位都更重要。

那種說法並不是在迴避準確度比較——比較會在後面出現，而且事實證明，準確度比較並沒有看起來那麼具決定性，因為這兩個模型不是在同一條軸線上衡量，也不可能如此。OpenBMB 的 MiniCPM5-2B 是文字模型：25.2 億參數，於 2026 年 9 月 6 日發布，針對代理、工具呼叫、程式碼與長上下文進行調校。inclusionAI 的 ZoomGain-4B 是視覺語言專門模型，於 2026 年 11 月 11 日發布，透過強化學習針對細微視覺細節問題進行訓練。接下來要談的是各自衡量什麼、各自建置起來要花多少成本，以及誠實的分界線落在哪裡。

缺少的那一列：執行每一項所需的條件

先從文物清單開始，因為這是兩家發行商中任何一家給過你最具體的東西。

• MiniCPM5-2B。一個建構於標準 LlamaForCausalLM 類別上的稠密因果 Transformer——42 層、GQA（16 個查詢頭與 2 個 KV 頭）、131,072 個 token 的上下文、總參數量 2,516,756,480，其中 1,981,982,720 為非嵌入參數。由於架構是標準的，它繼承了任何人已為 Llama 形狀模型撰寫的每一條服務路徑。該組織將 SFT、Midtrain 與 Base 變體發佈為獨立儲存庫，另加上 GGUF、MLX 與 GPTQ 量化版本，另加上用於推測性解碼的 DSpark 草稿模型，另加上用於裝置端 Android 的 LiteRT，另加上具有相同變體集的 1B 兄弟模型。

• ZoomGain-4B。以 BF16 計算共有 4,539,265,536 個參數，分佈於一個語言模型與一個獨立的視覺編碼器。三種 GGUF 精度——Q4_K_M 為 2.71 GB、Q8_0 為 4.48 GB、F16 為 8.42 GB——各自搭配一個 mmproj 投影器檔案，卡片上表示這是影像輸入的必備項目。沒有 MLX 版本、沒有 GPTQ、沒有 ONNX、也沒有草稿模型。唯一點名的執行環境是支援 Qwen3.5 多模態的 llama.cpp，而這項要求比聽起來更嚴格：你需要一個夠新的版本，才認得 qwen35 架構，而且卡片要你明確提供兩個檔案，而不是指向一個現成的路徑。

這種不對稱並不是在批評 inclusionAI。一個九天前才發布、從未正式宣布的視覺模型，本來就不該被期待具備 Android 執行環境。這只是目前的實際狀況，也意味著這兩個模型在成本這個面向上無法互換：MiniCPM5-2B 能在你既有的硬體上執行，包括手機；ZoomGain-4B 則只能在 GPU 上、在你可能得自行編譯的執行環境中執行，別無他處。

「小」的兩種不同定義

兩者都被稱為「小型模型」，但「small」這個詞在兩種情況下發揮的作用並不相同。

• 參數，如實計算。MiniCPM5-2B 在 2.52B 總參數中，有 1.98B 非嵌入參數——這個數字決定每個 token 的運算量。ZoomGain-4B 總計 4.54B，其中約五億是視覺編碼器與投影器。移除視覺堆疊後，兩個語言主幹的規模相同，差距僅在捨入誤差之內。行為上的差異來自其上額外訓練的內容，而非規模。

• 這項訓練的目標是什麼。 MiniCPM5-2B 的說明卡將其最強項列為程式碼與數學推理、長上下文理解、工具使用與代理式任務，並將其目標定位為本地助理、編碼代理與裝置端部署。ZoomGain-4B 的說明卡則只談一件事：模型能否回答一個唯有放大圖像才看得見答案的問題。

• 各家發布者選擇交出了哪些內容。 OpenBMB 發布了 MiniCPM5 的完整變體階梯——base、midtrained、SFT、RL-plus-OPD 最終版，另加一個草稿模型與九個晶片系列的預先建置二進位檔。inclusionAI 發布了三個模型儲存庫、兩個資料集，以及一個包含資料建構管線與 GRPO 啟動器的程式碼儲存庫。一個是產品線；另一個是附有實驗室筆記的研究發布。

• 授權條款。MiniCPM5-2B 在其模型卡片上標示為 Apache 2.0，並同時套用於儲存庫與權重。ZoomGain 的程式碼為 Apache 2.0，而檢查點條款則延後至檢查點儲存庫處理；截至本週，該儲存庫的中繼資料中並未帶有授權標籤。出貨前請先詳閱該檔案。

基準欄位，以及它們為何不符合

這兩個模型之間沒有任何共用的基準測試。一個都沒有。ZoomGainBench 是一組關於照片的問題，而 MiniCPM5-2B 沒有影像編碼器；MiniCPM5 表格中的其他每個基準測試都是文字，而 ZoomGain-4B 從未在任何一個上執行過。因此，與其做直接對決，以下是各發布者實際測量的內容，特意分開呈現。

MiniCPM5-2B，廠商報告數據，在其測試套件中平均 53.9：

• 程式碼 — LiveCodeBench v6 69.1、OJBench 32.5、SWE-bench Verified 46.4。

• 數學 — AIME 2025 86.5、AIME 2026 86.5、MATH-500 94.6。

• 知識 — MMLU-Pro 70.8，GPQA-Diamond 70.2。

• 長上下文 — AA-LCR 59.0、NoLiMa 68.1、LongBench v2 43.7。

• 工具使用與代理 — τ²-Bench Telecom 97.1、BFCL v4 66.6、BrowseComp-ZH 43.5、GAIA Text-103 88.7。

ZoomGain-4B，廠商回報：

• 感知能力，保留集基準測試 — 在 ZoomGainBench 上得分 55.81，相較於其 Qwen3.5-4B 母模型的 30.03。

• 感知，留出集平均 — 在訓練從未見過的十項基準測試上為 60.96，相較之下父模型為 54.20。值得引用的就是這 6.76 分的增益。

• 個別留出變動 — Visual Probe 43.30 至 57.28，O3-Bench 54.20 至 63.19，HR-Bench 4K 81.25 至 87.25，MME-RealWorld-Lite 57.89 至 61.59。

並排閱讀這兩份清單，決策的輪廓就顯而易見。MiniCPM5-2B 已在開發者關心的十七個項目上接受測試，且幾乎在所有項目上都取得相當不錯的成績；τ²-Bench Telecom 的 97.1 與 GAIA Text-103 的 88.7 是當中的亮眼數字，也是其定位所倚仗的依據。ZoomGain-4B 僅在感知方面接受過測試，除此之外基本上別無其他，而它帶來的增益——在未見的基準上平均約七個百分點——雖然真實，卻相當狹窄。

如果你只需要一句話：MiniCPM5-2B 是一款通用型小型模型，其 benchmark 成績表異常深厚；而 ZoomGain-4B 則是專才型模型，它那七點的平均增幅在通用型排行榜上根本看不出來，因為通用型排行榜並不包含它擅長的那些題目。

兩者實際上會共存的地方

兩種都是正確答案的工作負載有個共同形態：文件、螢幕截圖、照片、表單。必須有東西查看影像並擷取值，也必須有東西處理後續一切——解析結構描述、呼叫正確工具、驗證、重試、轉交真人。

這次萃取呈現 ZoomGain 的形態：小字、緊密裁切、非對即錯的答案，以及一個經過明確訓練、能分辨在裁切圖中讀取標籤與在完整畫面中讀取同一標籤之差異的模型。ZoomGain-4B 在 HR-Bench 4K（訓練後從 81.25 到 87.25）與 MME-RealWorld-Lite 上的留出集數字，正好符合一個在密集細節上變得更強、卻沒有在其他方面變差的模型樣貌。

其餘部分則是 MiniCPM5 的形態，而在工具使用上，它以自身規模而言異常強大——τ²-Bench Telecom 的 97.1 是大多數大三倍的模型都達不到的數字，BFCL v4 的 66.6 則說明其函式呼叫可不是演示。

同時執行兩者意味著兩套執行環境、兩份授權，以及多一個可能出錯的地方。這也正是路由器能證明自己有其價值、而不只是口號的地方：影像呼叫會送往視覺端點，工具呼叫的那一輪則送往便宜的文字端點，而任一端點停滯時會自動切換到另一端，而不是在你的流程中以 504 的形式浮現。一組金鑰、一張帳單，容錯切換邏輯集中在一處，而不是在兩套 SDK 中重複實作。

值得把話說清楚：我們提供什麼、不提供什麼。MiniCPM5-2B 目前不在我們的目錄中。我們確實有託管 Qwen3.5 系列——35B-A3B 每百萬 token 輸入 $0.057、輸出 $0.459，27B 則為 $0.086 與 $0.688，兩者皆為多模態——而該系列正是 ZoomGain-4B 訓練所基於的基礎模型，因此如果你想在決定採用自架 4B 之前，先測試裁切後提問是否能提升準確率，它會是最接近的託管替代方案。至於工具呼叫這一部分，同一個目錄今天就能提供你可呼叫的模型。我們做不到的是託管 ZoomGain-4B，再多的路由也改變不了這點：它是可供下載的模型，不是 API。

誠實的裁決

選擇 MiniCPM5-2B，若你想要一個能在本週部署到你已擁有的硬體上、使用現有執行環境、採用 Apache 2.0 授權，而且有足夠全面的基準測試表可預測其行為表現的小模型。在兩者之中，它是完成度較高的成品。其 1.98B 非嵌入參數讓每 token 成本低廉，工具呼叫的數據是其所屬欄位中最出色的表現，而晶片廠商提供的版本則意味著它不只是資料中心專屬的方案。

若符合以下條件，就選 ZoomGain-4B：你要消除的特定錯誤是視覺性且細粒度的，而且你願意用 GPU 執行冷門的 llama.cpp 建置來修正它。它的立論建立在一個可信的數字上——在 9,000 個訓練樣本下，於十項留出的感知基準測試中平均提升 6.76 點——也建立在基準測試、資料與測試框架上，讓你能自行核查這項說法，而不必直接相信它。

兩者都別選，如果你還沒量測出你的流程哪裡出錯。MiniCPM5-2B 已公布的最弱成績落在搜尋代理與長文件推理（BrowseComp-ZH 43.5、LongBench v2 43.7），而 ZoomGain-4B 從來沒被問過任何與圖片無關的問題。為了處理一個你還沒摸清的問題而買下其中任何一個，就是三十億參數模型最後進了生產環境卻什麼也做不了的原因。

不怎麼光鮮的結論：這兩個模型不是競爭對手，而是同一項工作的兩個相鄰階段；而這個比較之所以不斷被框成競賽，是因為發表基準測試比可移植性容易。MiniCPM5-2B 贏的是會被發表的那一欄。ZoomGain-4B 贏的是一個尚不存在的欄位，在單一任務上大約領先七個百分點，而且附帶一項會讓大多數團隊在門口就打退堂鼓的執行期需求。