MiniCPM-V 4.7 有了模型卡：OpenBMB 公布了基準測試、授權條款與裝置端宣稱

在它問世的前六天裡，MiniCPM-V 4.7 只是一個 70 GB 的 bfloat16 張量資料夾，沒有 README——沒有模型卡、沒有授權標籤、沒有基準測試表，什麼都沒告訴你它是做什麼用的。這一切在 2026 年 10 月 12 日改變了，OpenBMB 將一份完整的模型卡提交至 openbmb/MiniCPM-V-4.7-35B-A3B，宣告採用 Apache-2.0 授權，改寫了 MiniCPM-o 儲存庫的 README，讓新系列打頭陣，並宣布這是一款鎖定 iOS、Android 與 HarmonyOS 裝置的開源 MLLM 發布。同一輪文件更新也涵蓋了 1B 的兄弟型號，它現在掛著完全相同的模型卡結構。本文要談的是差異——模型卡實際上宣稱了什麼、哪些宣稱你可以自行查核，以及哪些宣稱目前只存在於供應商提供的 PNG 像素之中。

10月12日有什麼到來，而什麼是原本就已經在那裡的？

權重沒有變動。openbmb/MiniCPM-V-4.7-1B 建立於 2026 年 10 月 6 日 17:40 UTC，而 openbmb/MiniCPM-V-4.7-35B-A3B 建立於 10 月 7 日 07:07 UTC；兩者回報的最後修改時間戳仍是 10 月 12 日，因為最後一天花在文字說明上，而不是參數。35B 儲存庫在 10 月 12 日的提交紀錄是一場文件衝刺：新增模型卡 於 16:08、更新模型卡 於 16:15、將 35BA3B 重新命名 於 16:23、新增中繼資料 於 16:26、絕對資源 URL 於 16:50，四個 新增快速入門 提交直到 17:07，以及 連結 LES 文件 於 17:09。歷史中那條線以下的一切都是 init。該儲存庫在大約一小時內，從十八個檔案且沒有模型卡，變成一個附有圖片、評估圖表、部署指示與授權條款的已記錄版本。

這對你如何解讀這則公告很重要，因為一篇發布貼文和一次發布並不是同一回事。10 月 12 日，檢查點本身沒有任何改變。改變的是，MiniCPM-V 4.7 不再是一個未經說明的上傳項目，而變成一個你能在紙上評估的產品。

這兩種變體，以及為何它們不是同一個發行版

公告描述了兩個模型，而它們在視覺塔之下的架構並不相關——一個是稀疏的混合專家模型，另一個是小型稠密模型。

• MiniCPM-V 4.7 35B-A3B — 稀疏 MoE 架構，總參數量 352 億，256 個專家、每個 token 啟用 8 個，40 個文字層，隱藏層大小 2,048，16 個查詢頭對上 2 個鍵/值頭，最大位置 262,144 個 token，詞彙量 248,144。

• MiniCPM-V 4.7 1B — 一個稠密的 qwen3_5_text主幹，24 層、隱藏大小 1,024，8 個查詢頭對上 2 個鍵/值頭，相同的 262,144 詞元上下文，詞彙量 248,094，單一 3.1 GB safetensors 檔案。

• 共享視覺塔 — minicpmv4_7_vision，27 層、隱藏大小 1,152，patch 大小 14，影像大小 980，插入於文字堆疊的第 6 層。

• 壓縮 — 混合 4x 與 16x 視覺 token 降採樣，並採用 OpenBMB 歸功於 LLaVA-UHD v4 的 ViT 內部早期壓縮技術；預設為 16x，4x 則為更精細的細節設定。

• 注意力結構 — 兩種變體中皆為三比一的重複模式：三個 linear_attention 層，其後接一個 full_attention 層，在 35B 模型的 40 個文字層中重複十次。

• 授權 — 兩者皆採用 Apache-2.0，並於卡片的前置資料中載明，這是這兩個儲存庫首度明確載明條款。

35B-A3B 是這則公告打頭陣介紹的模型，也是背後有著有趣工程故事的模型：整體賣點在於，一個儲存 350 億個參數的稀疏 MoE 竟能在手機上順暢運行。

裝置端的宣稱才是真正的新穎之處，而這是個排程問題。

任何嘗試在手機上執行 MoE 的人都知道這種失效模式。總參數量存放在儲存空間中，每個 token 只會啟用少數參數，而在沒有足夠記憶體或頻寬容納所有專家的裝置上，權重會被分頁載入與移出。結果就是解碼速度慢到根本無法進行對話。顯而易見的變通做法——將路由器在整個 prompt 期間鎖定到固定的專家子集——雖然能讓它變快，卻也悄悄剝奪了能力，因為 token 再也無法觸及模型原本會選擇的專家。

OpenBMB 的答案是由三項技術堆疊而成，而這張卡片異常具體地說明了每一項技術的作用：

• Lookahead Expert Scheduling (LES) —— 一個跨層路由預測器會預先載入下一層可能需要的專家，在真實路由器實際選中的專家之間排定優先順序，並讓它们的運算與其他仍待處理的負載相互重疊。這份說明卡特別謹慎地指出，預測僅用於驅動預取與排程；運算仍依循模型本身的 token 層級路由，而預測漏掉的專家也會照常載入與評估。

• 細粒度逐層量化 — 縮減專家權重的記憶體佔用與資料搬移量，讓載入模式能契合裝置端記憶體與頻寬的限制。

• DSpark 推測性取樣——將草稿模型路徑整合至裝置推論迴圈中，與排程和量化並列。

頭條數字是 35B-A3B 在 iPhone 17 Pro Max 上達到每秒 13+ 個 token。那是供應商的實測數據，用的是我們沒見過的裝置、我們沒跑過的應用程式，而它是本次發布中最值得先持保留態度的一個數字，直到實驗室以外有人重現它為止。它也是整個「首個能在裝置端順暢運行、且不犧牲效能的開源 MoE」框架所依賴的主張——這種主張就定義而言很難被否證，因為「不犧牲效能」是相對於供應商自行選擇的基準來衡量的。

卡片中真正屬於新資訊的部分：生態系統清單

在10月12日之前，完全沒有公開的服務配方。這張卡現在列出了該模型預期可搭配使用的框架，而這份清單涵蓋範圍夠廣，無論基準測試結果如何都很有用：

• 推論 — SGLang、vLLM、llama.cpp 和 Ollama，並透過 transformers serve 路徑提供 OpenAI 相容的本機端點，以及供 Intel CPU、GPU 與 NPU 使用的 OpenVINO 路徑。

• 微調 — SWIFT 與 LLaMA-Factory，外加一套 OpenBMB 稱作 Self-Replay Fine-Tuning 的訓練配方，其定位為一種低成本的方式，可在擴展能力的同時限制遺忘。

• 量化 — GGUF、BNB、AWQ、GPTQ 與 FP8，並為 35B 模型的 AWQ、GPTQ、int4、FP8 與 GGUF 變體發布了各自的儲存庫。

• 硬體 — 聲稱首日即支援 Rockchip、Houmo、Intel、AMD 與 Arm 晶片平台，同時可部署於 iOS、Android 及 HarmonyOS。

• 工具——一本包含單圖對話、多圖對話、影片、OCR、PDF 解析與視覺定位任務指南的食譜，以及一個存放手機應用程式的邊緣部署儲存庫。

• 推測解碼 — 為 35B 與 1B 目標分別提供獨立的 DSpark 草稿檢查點。

實際效果是，MiniCPM-V 4.7 從「你必須自己寫載入器」進展到「至少四個服務堆疊中都有文件記載的路徑」。如果你原本在等這張卡才要花時間做本地試用，那等待已經結束；如果你是在等獨立證據證明裝置端數據是真的，那還沒結束。

基準測試確立了什麼，以及沒有確立什麼

這張卡片的評估區段對其本質很誠實：由供應商回報，而非經獨立重現。文中明確提出兩項比較性宣稱，且兩者都是以比較形式陳述，而非絕對分數。在 Instruct 模式下，35B-A3B 被宣稱能比 Qwen3.6 35B-A3B 在更少推論時間內達到更高的整體分數——這是效能與延遲的宣稱，而非原始品質的宣稱。1B 變體被宣稱在 MiniCPM-V 4.6 的核心能力上有所提升，並在整體分數與推論效率兩方面都大幅超越 Qwen3.5 0.8B。

以下是值得特別指出的部分。實際數字並沒有寫在內文裡。評估部分由五張連結圖片組成——35B 模型視覺語言任務的整體效能圖表、一張語言圖表、1B 圖表、效能效率前沿圖，以及裝置端速度比較 GIF——而圍繞這些圖片的文字承載的是敘事，而非數據。README 中沒有逐項基準測試表，因此沒有可引用的機器可讀分數，也因此本文沒有可作為數字引用的內容。「整體分數高於 Qwen3.6 35B-A3B」就是目前公開紀錄所能達到的精確程度。

隨之而來有兩個後果。第一，MiniCPM-V 4.7 在我們通常會尋求經審核比較的中立第三方排行榜上沒有登錄項目——沒有推理指數、沒有代理式指數，也沒有獨立評分的多模態分數。第二，OpenBMB 所繪製的匯總結果，是該供應商自行在其選定的基準群組上做出的複合分數，這意味著「整體分數更高」這項說法有多大意義，取決於其背後的加權方式，而該加權方式同樣未公開。這一切都不代表那些數字有錯。這只代表它們未經審核，而那是另一回事；這個區別在數字最漂亮的地方，偏偏最為重要。

你今天就能自行驗證的事

剝除行銷包裝後，有一個紮實、可查核的核心，全部都能直接從儲存庫讀取，無須信任任何人：

• 權重位元組——35B 模型上有十六個 safetensors 分片，總計 70,425,903,448 位元組，與 BF16 35.2B 檢查點相符；1B 模型則是單一 3.1 GB 檔案。

• 架構——上方的每一項結構數字都位於config.json 中，公開發布，並與卡片上的文字敘述相符。

• 授權條款—— Apache-2.0，已在卡片的前置資料中聲明，現在已明確無疑。就商業用途而言，這是本次發布中最重要的一行，而且是新增的。

• 量化變體 — AWQ、GPTQ、int4、FP8 與 GGUF 儲存庫皆已存在且可供下載，因此在權重層面上，部署並非空談。

• 採用訊號——截至 10 月 13 日，這個 35B 儲存庫約有 166 次下載與 38 個讚，相較於它還是個來歷不明的上傳檔案時近乎掛零的數字已有所成長，但對於一個宣稱達到帕雷托前沿的發布而言，仍只是個小數目。

你無法驗證的，是支撐這次發布的那項主張：這是第一個能在手機上運行、且不必犧牲任何東西的開源 MoE，速度達每秒 13 個以上 token。這還有待第三方拿著 iPhone 和碼錶來驗證。

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

MiniCPM-V 4.7 並非由 OrcaRouter 提供服務。它是一個開放權重的檢查點，這代表模型本身得由你自己託管——無論是在工作站上、GPU 主機上，還是這張卡所瞄準的手機上。而路由層真正發揮價值的地方，就在這套架構的另一端：當自我託管的視覺模型判斷自己力有未逮，並把棘手的畫面交給更強大的模型處理的那一刻。OrcaRouter 用單一金鑰串接 200 多個託管模型，以 0% 加成原樣傳遞各家供應商的定價，因此供應商一調價，當天就即時生效，並在供應商服務品質下降時自動容錯切換——這正是混合式架構所需要的形式：由便宜的本地模型處理例行工作，託管模型則承接它無法負荷的情況。

接下來要看什麼

有三件事能讓這次發布從一項有文件佐證的主張，變成確立不移的事實。對 35B 模型進行獨立的裝置端測量——由擁有 iPhone 17 Pro Max、使用已發布的應用程式，並自行計時的人來執行——就能確立整套宣傳所憑藉的那個數字。一份逐項列出實際分數的基準測試表，而非圖表，才能讓 Pareto 主張對照它所指名的基線受到檢驗。而在中立排行榜上的一次執行，則會把 MiniCPM-V 4.7 放到並非由它自己選擇的條件下受評估的模型旁邊。在那之前，誠實的總結是：OpenBMB 發布了一個真實、採 Apache-2.0、文件完善的模型，帶著一個可信卻未經證實的效率故事；而這兩者之間的差異，正是規格卡與基準測試之間的差異。