MiniCPM-V 4.7 1B 與 MiniCPM-V 4.7：兩個檢查點、同一個名稱，以及截然不同的任務

並不存在名為 MiniCPM-V 4.7 的檢查點。OpenBMB 從未發布過這樣的東西，而理應存放它的模型網址回傳的是授權錯誤，而不是權重頁面。這個名字指的是整個系列。2026 年 10 月 12 日，該系列推出了兩樣東西，讀者用這個名稱來指涉其中任何一項都合情合理：MiniCPM-V 4.7 1B，一個稠密、擁有 15.5 億參數的模型，設計用來常駐於手機的工作記憶體中；以及那個 350 億參數的稀疏專家混合（mixture-of-experts）檢查點，它承載了發表會上所有重點宣傳的主張——裝置端展示、帕雷托前沿圖表，以及「首個能在裝置端順暢執行的開源 MoE」這句話。拿兩者相比並不是一場公平的較量，也從來無意如此。這是一個關於你願意花多少記憶體的問題，也是一個關於廠商自家數據是否強到足以證明這筆記憶體值得花的問題。

這個名稱是系列，不是型號。

有兩個儲存庫帶有 MiniCPM-V 4.7 這個名稱，而第三個則以加上後綴的形式沿用同一名稱。openbmb/MiniCPM-V-4.7-1B建立於 2026 年 10 月 6 日 17:40 UTC。openbmb/MiniCPM-V-4.7-35B-A3B接著於 10 月 7 日 07:07 UTC 推出。openbmb/MiniCPM-V-4.7-1B-DSpark——一個為小型模型而設、擁有 2.13 億參數的推測解碼草稿頭（speculative draft head）——於 10 月 8 日上線。三者皆為 Apache-2.0 授權。單純名為 openbmb/MiniCPM-V-4.7的儲存庫並不存在，而這件事值得明白說清楚，因為有不少報導寫得彷彿它存在，還把同一組數字冠在另一者的名稱之下。OpenBMB 的 README 把這次發布本身的日期訂為 10 月 12 日，若你需要一個日期，就該採用這個：儲存庫先上傳，四天後才對外公布，這是尋常的順序。

所以，對「1B vs 4.7」最誠實的界定，並不是在同名的小型模型與大型模型之間做比較。它是在該系列實際提供的兩個尺寸級別之間做比較，而其中一個恰好是單憑系列名稱就能找到的唯一一個。

1B 究竟是什麼

從 safetensors 中繼資料讀取，這個稠密檢查點在 BF16 下是 1,554,476,272 個參數——單一權重檔約 3.11 GB，這是任何考慮手機端部署的人最關注的數字。它的語言骨幹標記為 qwen3_6_text，共 24 層，隱藏大小為 1024，其注意力採用三線性對一全注意力的模式：24 層中有 18 層走線性路徑，六層執行傳統注意力。詞彙量為 248,094 個詞元。視覺塔是該系列自家的 minicpmv4_7_vision——27 層，隱藏大小 1152，patch 大小 14，影像大小 980，插入語言堆疊的第 6 層。有兩項設定對文件處理工作比其他設定更重要：downsample_mode 是 16x，而 mrope_mode 是 canvas，這是該系列用來在切片影像中維持空間結構完整的多模態旋轉嵌入方案。最大位置嵌入為 262,144，因此上下文視窗是貨真價實的 256K，而非名目上的。

在撰寫本文時，該儲存庫顯示有 14 次下載與 22 個讚。這個數字很小，而它忠實衡量了社群迄今為止對該模型的使用程度。

旗艦究竟是什麼

35B-A3B 檢查點在 BF16 下共有 35,212,875,824 個參數——分散於十六個 safetensors 分片、總計 70.4 GB，是稠密模型單次下載大小的 22 倍。在架構上，它是截然不同的物種：40 層、隱藏維度 2048，以及稀疏 MoE 前饋網路，內含 256 個專家，每個 token 啟動其中 8 個，並將 moe_intermediate_size 設為 512。詞彙量為 248,144，比 1B 略寬。其注意力模式是相同概念在更深層次上的體現——30 個線性層對上 10 個完整層。它是 MiniCPM-V 系列中的首個 MoE，也正是廠商效率敘事真正聚焦的檢查點：OpenBMB 宣稱在 iPhone 17 Pro Max 上使用約 3 GB 記憶體即可達到每秒 13 個以上的 token，並透過 Lookahead Expert Scheduling 跨層預取專家權重，使稀疏路由不會因記憶體頻寬而停滯，再加上配對的 MTP 頭以及混合 4x/16x 視覺 token 壓縮。那些是廠商數據，由廠商在其自家示範上測得。目前尚無其他人重現這些結果。該儲存庫顯示 166 次下載與 43 個讚——關注度比 1B 高出一個數量級。

這項比較，逐個維度來看

六個維度，雙方皆要，並註明每個數字各佔多少權重。

• 參數與架構 — MiniCPM-V 4.7 1B：1.55B 稠密，每個參數在每個 token 上都會啟用。MiniCPM-V 4.7 的旗艦版本：總計 35.2B，稀疏，每個 token 啟用 256 個專家中的 8 個。這兩個總數並非可互相比較的量；MoE 的啟用預算才是決定每個 token 運算量的因素，而 OpenBMB 並未公布該數據。請將「A3B」視為名稱的一部分，而非一項測量值。

• 權重佔用 — MiniCPM-V 4.7 1B：單一 BF16 檔案為 3.11 GB，而這正是它存在的唯一理由。MiniCPM-V 4.7 35B-A3B：BF16 格式下十六個分片共 70.4 GB。廠商所稱的 3 GB 裝置端數字，僅適用於較大模型在量化與專家串流之後，而非原始下載。

• 注意力與上下文——兩者皆是：256K 位置、3:1 的線性對完整注意力模式，以及相同的 canvas mRoPE 模式。MiniCPM-V 4.7 1B 以 24 層運行它；旗艦版則以 40 層運行。這是唯一一個兩款模型確實採用相同設計、僅規模不同的面向。

• 視覺路徑——兩者皆採用：該系列自家的 minicpmv4_7_vision 塔，具備 16 倍降採樣。差異在於壓縮步驟的另一端：旗艦款的圖表標榜 4x/16x 混合方案，而 1B 並未如此宣稱。

• 授權條款 — 兩者皆為：Apache-2.0，於儲存庫中宣告，並在專案 README 中明確載明。這一點很重要，因為這與同一系列一週前的情況正好相反；就這兩個檢查點而言，此處都沒有任何需要回報的模糊地帶。

• 品質證據 — MiniCPM-V 4.7 1B：僅有廠商圖表。MiniCPM-V 4.7 35B-A3B：廠商圖表、一段在 iPad M4 與 iPhone 上的廠商示範影片，以及一項已公布的裝置端每秒 token 數（tokens-per-second）宣稱。兩者皆無獨立評估，亦未經第三方以固定測試框架進行基準測試。

廠商自家圖表所聲稱的內容

OpenBMB 為兩個 checkpoint 都發布了基準測試圖表，而它們所能支援的差異頗具啟發性。1B 的圖表將該模型列在 MMBench 83.17、OCRBench 86.10 與 OmniDocBench v1.6 85.39，在同一張圖中與之並列的前一代 1.3B 級模型於這三項上均落後（分別為 81.89、83.80、82.52）。這些數字是廠商自行報告且未經重現的，而且圖表本身的欄位標示必須仔細閱讀，因為其中有一列印出的數值對於這個規模的模型而言並不可信。把絕對數字當作行銷宣傳，而與前一代相比的差值才是唯一具有內在邏輯的部分。

35B-A3B 圖表更容易判讀，因為比較的項目更密集。它列出 MMMU 80.22、MathVista 88.00、OCRBench 91.20、OCRBench_v2 68.47、OmniDocBench v1.6 94.24、CharXiv reasoning 75.60、TextVQA 84.99 與 CCOCR 81.14，對比一組包含兩個 35B-A3B 等級混合專家模型、一個 31B Gemma 和一個 27B Qwen3.8 的陣容。就廠商自家數據而言，MoE 在大多數列中些微勝出，並輸掉少數幾列——MMMU-Pro 和 MathVision 則相反。再次強調：由廠商自行回報、未經重現，唯一公允的解讀是「廠商相信它已達同等或更佳水準」，而非「它已達同等或更佳水準」。

有一個標籤問題值得指出，而非解決。這個儲存庫命名為1B。Hugging Face 側邊欄將該模型描述為 2B 參數。safetensors 中繼資料顯示 1,554,476,272——約 1.55B。供應商自家的圖表將該列標示為 1.3B。四個來源、四個數字，而其中最小的那個就在行銷所指向的圖表裡。這些都不會改變模型的功能，但如果你要依據規格表編列記憶體預算，請以 3.11 GB 的檔案為準，而不是任何標籤。

你真正想要哪一個？

如果限制條件是手機、筆電、單張小型 GPU，或任何有功耗預算的裝置，那這些選項中只有一個合乎條件。MiniCPM-V 4.7 1B 的存在，正是為了讓具備 256K 上下文的超大型多模態模型能塞進幾 GB 之內；它採用允許商業使用的授權條款發布，而且量化生態系早已就緒——GGUF、AWQ、GPTQ、int4 與 FP8 版本，加上 Rockchip、Houmo、Intel、AMD 和 Arm 硬體廠商與 OpenVINO 的首日支援。若要在 3 GB 佔用空間下進行裝置端 OCR、螢幕截圖理解與文件解析，它就是這個系列中能回答這個問題的版本。

MiniCPM-V 4.7 35B-A3B 回答的是另一個問題。它不是同一款產品的更大版本；它是試圖在每個 token 只付 8 個專家的成本下，維持 35B 等級模型的品質，而如果廠商的吞吐量宣稱站得住腳，它就是兩者中更有意思的工程成果。此外，它在 BF16 下為 70.4 GB，是伺服器或工作站的下載項目，而其裝置端故事是透過量化與專家串流來實現，而不是透過你從 Hub 取得的那個檔案。

路由器適用與不適用的時機

這兩個檢查點都沒有託管在 OrcaRouter 上。MiniCPM 完全沒有出現在我們的目錄中，而對於任何想執行其中任一個的人，正確的建議是下載權重並自行提供服務——llama.cpp、Ollama、vLLM 或 SGLang 都支援這個架構，而且上方的首日支援清單對這麼新的版本來說異常廣泛。路由問題只會出現在下一步：當小型本地模型不足以應付某個特定請求，而工作必須交給託管服務時，會發生什麼事。那次交接是路由決策，而不是第二份合約：OrcaRouter 將數百個託管模型置於單一金鑰之後，依各供應商的牌價計費，且不額外加價；當供應商服務降級時，還能進行容錯移轉。在該清單上的託管視覺模型中，有幾個與 1B 屬於同一量級—— qwen/qwen3-vl-8b-instruct 及其思考變體， qwen/qwen3-vl-235b-a22b-instruct 用於高負載端，以及 deepseek/deepseek-v4-flash-vision-exp 用於長上下文文件處理。那是這個家族之上的層級，而不是它的替代品，而且值得清楚說明每個模型落在這條線的哪一側。

看什麼

有兩件事能為這項比較定調，而兩者目前都還不存在。第一是獨立評估——在同一套硬體上，用同一套測試框架對兩個檢查點各跑一遍，而且不讓廠商挑選提示詞。在那樣的評估出現之前，本文中的每一個準確率數字都是廠商自家提供的，引用時都應附帶這一點。第二是 DSpark 草稿頭，它已針對 1B 發布，而且正是能讓小模型推論在手機上大幅加快的機制。如果推測解碼在這個規模下真如宣傳般可行，那麼稠密 1B 會成為遠比其規模所暗示的更好答案，而 35B-A3B 仍然是你只有在請求確實需要時才會動用的模型。

不需要等任何事情的是授權條款、架構、資源佔用和工具鏈。這些都在儲存庫裡，兩個檢查點都是 Apache-2.0，而且已足以讓你在今天就決定這兩者之中哪一個適合你的硬體。

那個模式的託管部分是一項路由決策，而不是第二份合約。各供應商的定價，我們不額外加價MiniCPM-V 4.7 的兩個檢查點都不是 OrcaRouter 上的託管模型——兩者都是你自己部署的權重。