MiniCPM-V 4.7 將 35B 視覺模型塞進 3 GB：釐清 100 tok/s 的說法

一個 350 億參數的模型不可能塞進 3 GB 裡。MiniCPM-V 4.7 35B-A3B 卻仍能在大約 3 GB 的空間中運行，而這兩種說法都成立——這正是關鍵所在，也是為什麼這次發布周遭流傳的數字值得我們停下來細看。這個模型是 OpenBMB 在 MiniCPM-V 系列中首個稀疏混合專家（MoE）作品：儲存 352 億參數，每個 token 約有 30 億活躍參數，Apache-2.0 授權，權重放在 Hugging Face。它能讀取影像、多影像集合與影片，並以文字回答。自 10 月 10 日起，它也能在上游 llama.cpp 中運行，多數人正是從那裡認識它。接下來要拆解大家一再重複的三個數字——3 GB、35B 與 100 tok/s——並說明其中哪些是 OpenBMB 實際公布的。 200 多個託管模型，一組金鑰，供應商定價以 0% 加價原樣傳遞。 看看 OrcaRouter 如何路由 開放權重的檢查點留在你的硬體上；託管的應急出口則是一個端點。 像這次發布背後那些有記錄的 AI 失敗與代理事件，都收集在 OrcaRouter AI Incident Archive 中，每一條目都附有自己的來源、嚴重程度、信心評級與爭議標記。

三十億位元組、三百五十億個參數，卻毫無矛盾

只有當你假設「在記憶體中」是指「全部都在」時，這筆算術才會顯得不可能。MiniCPM-V 4.7 35B-A3B 讓約 30 億個參數常駐，其餘專家則在路由器要求時才串流載入——模型卡本身的說法是 Lookahead Expert Scheduling，這是一種跨層路由預測器，會預先擷取下一層可能需要的專家，並讓該載入與已在進行中的運算重疊。模型卡特別說明，預測僅用於驅動預先擷取與排程；權杖仍遵循模型的實際路由，而預測器漏掉的專家也會像其他專家一樣被載入並評估。

這種區別會帶來可量化的後果。GGUF 儲存庫會以每種常見量化格式發布整個模型，而這些檔案沒有任何一個是 3 GB：

• Q4_K_M — 磁碟上 21.2 GB。

• Q8_0 — 36.9 GB。

• F16 — 69.4 GB。

• 視覺投影器 — 4 倍壓縮下為 0.9 GB，f16 下為 1.1 GB。

所以「3 GB」是在手機上以專家串流運行時的常駐記憶體數字，既不是下載大小，也不是桌機的 VRAM 需求。如果你正在規劃部署，決定磁碟用量與首次載入的數字是 Q4_K_M 下的 21.2 GB，而決定你在手機上穩態佔用量的數字則是廠商所稱的約 3 GB。兩者都在發行資訊裡。它們回答的是不同問題，而大多數報導卻把它們混為一談。

100 tok/s 從何而來，以及何處並非如此

以下是值得直說的部分。OpenBMB 並未公布 MiniCPM-V 4.7 達到 100 tok/s 的數據。模型卡上的數字是 13+ tokens/s，測試裝置為 iPhone 17 Pro Max，記憶體約 3 GB。這是該次發布唯一提出的裝置端吞吐量說法，而且是由廠商在實驗室外部無人重現過的硬體上測得。

更高的數字確實存在，但它們來自另一份不同的產物。OpenBMB 的 llama.cpp-omni 分支——也就是承載裝置端最佳化的那個儲存庫——針對 35B-A3B 目標發布了自家的表格，並依開啟了哪些最佳化項目分層列出：

• iPhone 18 Pro Max，12 GB — 基準 3.38 tok/s，使用 Lookahead Expert Scheduling 後為 11.34，再加上混合精度後為 17.16，再加入 DSpark 草稿頭後為 20.51。

• iPad Pro 11 吋 M4，16 GB — 基準 2.97 tok/s，搭配 LES 為 9.81，混合精度為 14.92，搭配 DSpark 為 17.39。

這些是該模型已公布的最高裝置端數據，而最高階的數據是 20.51 tok/s——只有 100 的五分之一。這個差距很重要，因為它改變了模型的用途。在 13 tok/s 時，手機應用程式能在幾秒內回答關於照片的問題。在 100 tok/s 時，你會開始考慮把它當作影片的串流初讀器。前者是真正出貨的產品。後者並非實際出貨的內容，任何依據那則推文數字做規劃的人，都會因五倍差距而失望。

對 100 tok/s 這項宣稱最誠實的解讀是：它把三個各自獨立的事實——3 GB、可在本機執行、比上一代快上許多——壓縮成一個所有來源都沒有包含的數字。跨代改進是真實且巨大的：在同等級裝置上，從 3.38 到 20.51 tok/s 是 6 倍的躍進，而這是靠疊加三項技術達成，而非靠更大的晶片。

這次發佈並非只有一天，而日期很重要

MiniCPM-V 4.7 的問世方式，和現在許多開放權重模型的發布一樣：先有檔案，之後才有說明，而框架支援則介於兩者之間。

• 10 月 6 日 17:40 UTC——1B 模型及其 AWQ、GPTQ 與 int4 變體在 Hugging Face 上現身，另於 18:05 推出 GGUF 版本。

• 10月7日 07:07 UTC — 35B-A3B 儲存庫上線。仍然沒有模型卡。

• 10 月 8 日 — 兩種尺寸的 DSpark 推測解碼頭，以及 35B 的 FP8 版本。

• 10月10日 18:42 UTC — llama.cpp 合併模型支援。

• 10 月 12 日 — OpenBMB 提交模型卡、宣告採用 Apache-2.0，並宣布此次發布為一項有文件記載的產品。

• 10 月 15 日 — DSpark 的各個頭部已從主卡片建立連結，並附有兩個目標的 GGUF 草稿。

那個次序說明了二手報導中許多令人困惑之處。有人在十月第二週透過 llama.cpp 接觸到這個模型，當時跑的是一個官方尚未存在的版本，既沒有授權標籤，也沒有基準測試圖表；他們的吞吐量數字反映的是該框架自身的量化選擇，而非 OpenBMB 做過基準測試的任何結果。

llama.cpp 支援：已合併，但尚未完全完成

新增 MiniCPM-V 4.7 的上游 PR 對於變更內容異常清楚易讀，而答案是：架構上幾乎沒有任何改變。這個模型與 MiniCPM-V 4.6 幾乎完全相同；差異在於 3D RoPE，每個 token 的位置是三個值——時間、列、欄——而非多數視覺語言模型使用的單一純量。支援方式是擴展現有的 4.6 路徑，以承載這個額外維度。該 PR 在 9 月 25 日建立時，也把這個模型標註為「即將推出」，這相當程度暗示了權重當時流通得有多早。

在建構以它為基礎的 grounding 功能前，值得先了解這個殘留問題。自那次合併以來，上游 llama.cpp 在 MiniCPM-V 4.7 的提示中，會把圖像標記 token 指派到錯誤的位置：圖像 token 本身的位置正確，但 <slice>、</slice> 與列尾標記卻被當成純文字編號，而不是像參考實作 get_rope_index 那樣，賦予它們圖磚角落座標。可見的症狀是：當你詢問圖片中某個東西在哪裡時，回傳的座標會系統性偏低。帶有單元測試的修正已以開啟中的 pull request 形式存在，日期為 10 月 14 日，截至 10 月 20 日仍未合併。如果你的工作負載是「描述這個」，你不會注意到。如果是「給我邊界框」，你就會注意到，而你應該 Either 等待合併，或使用帶有修正後路徑的 fork。

還有一件事在來回轉換後依然成立：對 1B 模型而言，視覺投影器是較大的下載項目。Q4_K_M 權重為 672 MB；f16 投影器為 1.11 GB。因此，最小的實用 1B 部署大約是 1.8 GB 的檔案，其中大部分是「眼睛」而非語言——這個細節正是任何「1B 就等於 1 GB」的預期會弄錯的地方。

要執行什麼，以及在什麼上執行

如果目標是在本週試用，阻力最低的做法是透過 llama.cpp 或 Ollama 對接 GGUF 儲存庫，並將多模態用戶端指向相符的 mmproj 檔案。在 24 GB GPU 上，Q4_K_M 的 21.2 GB 幾乎沒有留下脈絡空間的餘裕——8K token 視窗加上影像圖塊會無法舒適地容納，因此若你也想要長提示，請規劃改用 Q4_K_S 或更小的量化。在 32 GB 或以上的 Mac 上，Q8_0 可行，而且是最接近參考行為的選擇。在手機上，只有廠商自家應用程式和 llama.cpp-omni 分支具備專家排程功能；原生 llama.cpp 只能確保正確性，無法達到 20 tok/s。

路由層在此真正發揮價值之處，在於本地呼叫的另一端。手機上一個 3B 活躍參數模型，在處理例行畫面上表現出色——讀一下這張收據、這個貨架看起來有沒有貨、這個招牌寫什麼——但它偶爾會遇到無法完成的頁面。OrcaRouter 將 200 多個託管模型置於單一金鑰之後，以 0% 加成轉傳各家供應商的定價，因此供應商調價當天即生效，並在上游服務劣化時自動容錯切換。行得通的做法是本地優先、搭配託管服務作為備援出口，而非純本地。開放權重檢查點仍由你自行託管；手機交辦出去的一切，全由路由器處理。

MiniCPM-V 4.7 並非由 OrcaRouter 提供服務，我們也不會暗示情況並非如此。它是一個由你自己執行的檢查點。

什麼能敲定這三個數字？

在具名手機上對 35B 模型進行獨立量測，並註明所用應用程式與量化方式，才能釐清吞吐量問題——包括 20.51 tok/s 能否經得起別人拿碼錶實測。若公布 3 GB 這個數字的定義——是常駐集、峰值配置，還是其他東西——就能釐清記憶體問題。而提供一張列出真實分數的逐項基準測試表，而非目前卡片隨附的五張連結圖表，才能對照 OpenBMB 所選的加權方式，檢驗「比 Qwen3.6 35B-A3B 更好且耗時更少」這項說法。這些目前都還不存在。在它們出現之前，準確的說法是那句無聊的話：一個 35B 稀疏模型能在手機上運行，據報以約 3 GB 達到每秒 13 個以上 token，下載大小為 21 GB，且合併後的框架路徑仍有一個未解決的座標錯誤。