MiniCPM-V 4.7 手機大模型：3 GB 記憶體，容量去了哪裡？（2026）

2026 年 10 月 12 日，OpenBMB 在 GitHub 的官方發布紀錄公開了 MiniCPM-V 4.7：一套理解圖片、影片與文件的多模態模型，包含 35B-A3B 與 1B 兩種版本。最吸引人的說法是，35B-A3B 在 iPhone 17 Pro Max 上，只用約 3 GB 推論記憶體便達到每秒超過 13 個 tokens。這個數字是團隊自報，值得追問的是：模型的容量究竟去了哪裡？

先看原文想解決的問題，再拆開記憶體、儲存與速度的測量口徑，最後判斷什麼證據足以支持採用。這次進展的重點，是讓大型模型的不同部分在對的時間抵達計算單元；你的手機仍要存下那些權重。

MiniCPM-V 4.7 的核心：專家不必同時坐在桌前

原文將 35B-A3B 定位為 MiniCPM-V 系列的首個 MoE（混合專家）模型。官方 App 文件把名稱解釋為約 350 億總參數、約 30 億活躍參數。你可以把它想成一間有很多專家的圖書館：每一步計算只叫其中一部分來工作，下一步可能又需要不同的人。活躍參數少，能降低每一步的工作量；其餘專家的資料仍需留在裝置上。

大型模型放在手機，難處因此有兩層：容量是否放得下，以及需要的權重能否及時讀進來。將專家權重留在內部儲存，確實能減少同時占用的 RAM；但每走一層都等讀檔，回答便可能斷斷續續。原文的 LES（Lookahead Expert Scheduling，前瞻專家排程），就是對準這段等待。

computation still follows the model’s original token-level routing

中文：計算仍然遵循模型原本逐 token 的路由。

OpenBMB，MiniCPM-V 4.7 模型卡節錄

模型卡說明：LES 先預測下一層可能需要哪些專家，提早讀取；真正的路由選出專家後，先算已到位的部分，同時載入其餘需要的權重。預測漏掉的專家仍會載入並參與計算。這個設計的價值，是改變等待與計算的安排，而非用預測取代模型原本的選擇。

MiniCPM-V 4.7 的 3 GB：先與 16.6 GB 放在同一張表

decoding speed of 13+ tokens/s with just 3 GB of memory on iPhone 17 Pro Max

中文：在 iPhone 17 Pro Max 上，以約 3 GB 記憶體達到每秒超過 13 個 tokens 的解碼速度。

OpenBMB，官方 README 節錄

單讀這句，容易把「執行時的記憶體占用」聽成「整套模型大小」。截至 2026 年 10 月 14 日，官方硬體需求表列出手機專用 35B-A3B 組合：主檔約 1.7 GB、視覺元件約 1.1 GB，加上拆出的專家權重，總下載約 16.6 GB。文件建議預留約 17 GB 儲存，裝置 RAM 至少 12 GB，並使用快速內部儲存。3 GB、16.6 GB、12 GB 回答的是三個不同問題。

數字	官方所指範圍	應如何判讀
約 3 GB	iPhone 測試宣稱的推論記憶體占用	不能當成模型總下載量或手機總 RAM 需求
約 16.6 GB	35B-A3B 手機分拆版的完整下載	包含主檔、40 份專家分片與視覺元件
至少 12 GB	官方建議的裝置 RAM	需留出系統、App 與推論工作空間
約 1.8 GB／至少 4 GB	1B 版下載／建議裝置 RAM	是另一個模型的部署條件，不能沿用 35B 的速度主張

App 文件另區分桌機的一般 GGUF 與手機專用的分拆版：後者把專家放在獨立的 experts/ 目錄，與主檔配對使用。嘗試手機 Demo 時，先沿其模型管理器下載完整組合，避免只拿一份桌機 GGUF 就期待得到相同結果。想先建立容量觀念，可接著讀 本機 LLM 記憶體規劃。

每秒 13 個 tokens，與整件工作完成得快，是兩張成績單

OpenBMB 的速度主張限定在 iPhone 17 Pro Max 的解碼階段。解碼是模型逐步生成文字；打開 App、載入模型、處理圖片或影片、讀提示，以及等待第一個字，還有各自的時間。Tokens 是模型的文字處理單位，也不能直接換成固定中文字數。要評估掃描文件是否方便，應量從交出圖片到得到合格答案的總等待。

團隊的LES 分階段測試提供了更具體的對照，但硬體是 11 吋 iPad Pro M4、16 GB RAM。其表格依序列出：未啟用所列優化的 SSD 專家載入基準為 2.97 token/s；加入前瞻排程與載入優化後為 9.81；再加逐層混合精度量化為 14.92；完整 LES 加 DSpark 推測取樣為 17.39。後兩階段相對基準分別約 5.02 倍、5.86 倍。

這些是團隊在列明資料集上的測量，解碼速度定義為生成 token 數除以總解碼時間。它讓原文的「約五倍」有了比較起點，也揭示加速是多種技術共同的結果。iPad 的分階段倍率不能直接套成 iPhone 的倍率；13+ 也不能當成每部 Android 手機的承諾。AlphaLab 本篇依公開文件分析，未執行手機重現；因此這些數字保留為 OpenBMB 的測試結果。

評測圖想說什麼？同時看能力與推論成本

原文的這張圖，把平均評測分數與推論時間放在一起；它想說的是，同一資源預算下，模型不只要答得好，還要較快交付。官方稱 35B-A3B 在 Instruct 模式下，比 Qwen3.6 35B-A3B 得到較高總分、使用較短推論時間；1B 則被用來展示小模型的能力密度。這是該評測配置下的比較主張，不能直接讀成所有任務都更好，也不能把圖中的推論時間當成你的手機速度。

視覺輸入另有一個成本旋鈕。模型指南列出 4×／16× 視覺 token 壓縮，並說明較細的 4× 模式保留更多細節。讀一張清楚的大字告示，與讀密集表格、小字帳單，對細節的要求不同。選模型時，把辨識錯誤也放進時間帳：少等幾秒、卻多改幾個金額，工作未必更早完成。

開放權重則讓這些選擇更容易被檢查。官方 README 與兩種模型的 Hugging Face 授權標記均列為 Apache-2.0；仍需依授權保留必要通知。團隊也提供 iOS、Android、HarmonyOS 部署入口與微調資源。原文提到的 SRFT旨在擴展新任務時減輕既有能力遺忘；它是另一條自訂模型路線，不能替這次手機速度測試背書。

AlphaLab 的判讀：容量限制被重新安排，代價仍要計算

我同意的，是這個排程問題有實際價值。模型需要某個專家時，若權重已在路上，就能減少空等。OpenBMB 把模型、排程與手機 App 的公開材料連在一起，讓「在手機上跑大模型」有更具體的檢查入口。這比單張速度海報更有用。

但這條思路有研究脈絡。Apple 的 LLM in a Flash也研究把超過 DRAM 容量的權重放在快閃儲存，降低搬運量並改善連續讀取。這份獨立研究支持「容量與讀取排程值得共同設計」的方向；其方法與實驗不同，並不獨立驗證 MiniCPM-V 4.7 的 13+ 或 3 GB。原文的「首個」與「無損」也應留在團隊自己的界定，不能替整個市場或所有量化版本蓋章。

我存疑的，是把解碼流暢外推成全面實用。LES 保留原路由的說明，能回答是否因預載預測而跳過需要的專家；量化後的任務品質、長時間溫度與耗電、不同儲存速度、長上下文與繁體中文 OCR，則應各有驗收。這些不是由一個 tokens/s 數字自然推得的結果。

離線推論提供另一個有吸引力的選项：已下載模型後，把圖片處理留在裝置上，降低任務對連線的依賴。若你在意資料流，還要核對 App 的下載、權限、紀錄、備份與分享行為；「模型本機執行」只回答計算位置。先從不含私人資料的樣本開始，能把辨識品質與資料處理分開觀察。

下一步：讓自己的文件決定要試 35B，還是 1B

先選十份你有權處理、答案可以核對的素材：清楚文字、密集表格、模糊照片、多頁文件與短影片都可各占一部分。寫下必須正確的欄位、可以接受的等待，以及答錯時該如何處理。已有合適硬體的人，再沿 官方 App 入口核對版本、檔案組合與空間；硬體尚未備妥的人，先整理素材和答案，不必為了一個宣傳數字換手機。

每次保存模型與量化版本、裝置、冷啟動時間、第一個字等待、總耗時、答案正確性，以及連續使用後的溫度與耗電觀察。先把 1B 當作可比較的輕量候選；35B 是否值得增加儲存與載入成本，讓它在同一批素材上證明。LLM 推論引擎入門能補上模型與 runtime 的分工；MoE 快取排查則提供相鄰的容量與等待觀念。