MiniCPM-V 4.7 1B 在一般 iPhone 上：所謂「超越 Pro Max」到底是什麼意思

MiniCPM-V 4.7 1B 是一個 15.5 億參數的視覺語言模型，OpenBMB 於 2026 年 10 月 6 日將它上傳到 Hugging Face，並在其自家發布說明中標註為 10 月 12 日。它有模型卡、十一個量化同系列模型、一個 Ollama 標籤，以及一個裝置端示範應用程式。它沒有的，是一個在把硬體成本算進去之後依然站得住腳的說法版本。開發者圈流傳的說法是：該模型現在能在一般 iPhone 的 OnDeviceLLM 應用程式中運行，而不只是在 12GB 的 Pro Max 上；這正是值得仔細檢視的部分，因為「跑在手機上」和「跑在 你的手機上」之間，隔著約 3 GB 的記憶體餘裕，而大多數 iPhone 並沒有這樣的餘裕。像這類發布背後的已記錄 AI 失誤與代理事件，都彙集在 OrcaRouter AI Incident Archive，其中每個條目都附有各自的來源、嚴重程度、信心等級與爭議標記。

以下是目前的情況，而且連接縫都看得見。以下所有內容，不是直接讀自權重檔案、OpenBMB 自家文件，就是讀自 Apple 公布的規格。若某個數字來自開發者的貼文，而非可重現的產物，本文會如實說明。

哪些是真正已知的，哪些只是宣稱

這個模型是真實存在且可下載的。BF16 檢查點有 1,554,476,272 個參數，換算下來約 3.1 GB 的磁碟空間。該儲存庫附有完整的模型卡——在這一家族近期的歷史中實屬罕見——標明採用 Qwen3.5 文字主幹、具備 27 層、隱藏維度 1152 的 SigLIP2 視覺塔、980 像素的輸入圖磚、262,144 詞元的上下文視窗，以及 Apache 2.0 授權。OpenBMB 自家的 README 條目將發布日期定為 2026-10-12；而 Hugging Face 儲存庫則建立於 2026-10-06。這六天的落差，正是這一家族向來為人所知的上傳與公告時間差，也正是為什麼一篇十月的文章，仍能把一個已存在六天的儲存庫稱為一次悄然發布。

任何產物都未確立的是這項具體主張：1B 能在「12GB Pro Max 以外的日常 iPhone」上於 OnDeviceLLM 中運行。這種說法源自一篇開發者貼文。OnDeviceLLM 專案的公開儲存庫——它是離線聊天與翻譯應用程式的入門套件，並非已正式上架的 App Store 產品——星數為零，且最後推送時間為 2026 年 7 月 27 日。它比 MiniCPM-V 4.7 的權重早十週問世，因此其中對這個模型的任何支援都是近期新增且未有文件記載的。請將「已在 OnDeviceLLM 中運行」視為做過此事者的回報，而非廠商支援的部署途徑。

這個區別很重要，因為廠商自家提供的裝置端數據根本不是針對 1B。

3 GB 這個數字屬於 35B，而不是 1B。

OpenBMB 的頭條宣稱——「在 iPhone 17 Pro Max 上僅用 3 GB 記憶體就能達到每秒 13+ 個 token」——是針對35B-A3B 混合專家變體所提出，該變體運行於 Apple 所販售的最大尺寸 iPhone 上。其背後的技術 Lookahead Expert Scheduling 會將大多數專家權重保留在 SSD 上，並預取下一層可能需要的權重。這是一項令人印象深刻的系統工程成果，也是 35B 這個名稱不斷出現在手機相關報導中的原因。

1B 不需要上述任何東西。它是一個稠密模型，能直接完整放進記憶體。理論上，這讓它在兩者之中顯得更親民，也正是「日常 iPhone」這個說法站得住腳的原因。但實際的算術並不像這套說法所暗示的那麼友善：

• BF16 權重 — 磁碟上為 3.1 GB，載入後常駐記憶體大致相同，且這還不包括任何 KV 快取或視覺激活 • Q8_0 GGUF — 1.08 GB 的權重，外加在 4× 壓縮設定下為 0.90 GB 的視覺投影器，或在 16× 下為 1.11 GB • Q4_K_M GGUF — 0.67 GB 的權重，並有相同的投影器額外開銷 • 視覺投影器 — 這是人們會忘記的部分；它不會隨著語言模型量化而縮小，而且每個已載入模型只計一次 • 上下文 — 帳面上最多 262,144 個 token；KV 快取中的每個 token 都是模型卡未編列預算的額外記憶體

採用 16× projector 的 Q4 版本，權重約落在 1.8 GB。若再為數千個 token 的對話與圖像佔位符加上可用的 KV 快取，就等於要求應用程式占用約 2.2–2.8 GB 的空間。在 12GB 的 Pro Max 上，這還算寬裕。但在 8GB 的 iPhone 上，作業系統和其他所有常駐應用程式早已在競爭同一塊記憶體池，此時一個要求 2.5 GB 的應用程式，等於要吃掉剩下可用記憶體的一大部分。iOS 可能會批准，也可能會在記憶體壓力下讓應用程式被 jetsam 終止。

為什麼 iPhone 規格表上的 RAM 那一行才是真正的規格

蘋果不在行銷規格中公布 iPhone 的 RAM，也從未鼓勵開發者把這款手機當成可定址記憶體的電腦來看待。這正是「超越 12GB Pro Max」這項說法所碰到的限制。Pro Max 等級已連續好幾代配備比標準機型更多的記憶體，而「評測影片裡的手機」與「讀者口袋裡的手機」之間的落差，正是這款機型的裝置端論述所依賴的落差。

把這個說法誠實地講，範圍會更窄，但仍然有趣：一個過去需要筆記型電腦或旗艦手機的 1B 視覺模型，現在能塞進中階手機的記憶體預算內，如果你使用 4 位元量化並接受較短的上下文。這確實是硬體等級的真正下放。這不等同於「能在每一款 iPhone 上執行」，而這個差別值得明白說出來，因為它決定讀者能否真的把這個東西出貨。

模型卡無法據此定論。它記錄了對 iOS、Android 與 HarmonyOS 的支援、來自 Rockchip、Houmo、Intel、AMD 與 Arm 的首日晶片支援，並連結到一個包含應用程式與原始碼的邊緣部署儲存庫。但它完全沒有列出最低裝置記憶體、經測試的裝置矩陣，或 1B 在各裝置上的 token 速率。1B 自己的示範素材中唯一具名的裝置是 iPhone 17 Pro Max——與 35B 頭條所指的裝置相同。

這個模型在 1B 規模下真正擅長的是什麼

值得做這番記憶體算計的原因在於：一個能在手機上進行文件與螢幕理解的 10 億參數模型，與聊天機器人屬於不同的產品類別。這意味著收據、表單、菜單、標籤或螢幕截圖都能在不經過網路往返的情況下轉成結構化文字——無需上傳、沒有每張影像的成本，也沒有由基地台決定的延遲下限。

OpenBMB 公布的 1B 數據全為廠商自行報告，截至本文撰寫時尚無任何獨立重現結果；其 OCRBench 為 86.1、MathVista 為 74.3、CharXiv Reasoning 為 48.8、LongVideoBench 為 53.4、MotionBench 為 54.55。廠商的重點比較對象是 Qwen3.5 0.8B，並稱其在總體分數與推論效率上均勝過對方；另一比較對象是 MiniCPM-V 4.6，並稱其在各項核心能力上均有提升。這些都是廠商自家的基準測試，由廠商自行執行，而模型卡以圖表而非附有測試框架細節的表格呈現這些結果。

對於任何實際部署此系統的人來說，有兩個架構細節比分數更重要：

• 混合 4×/16× 視覺 token 壓縮 — 呼叫端可依每次請求選擇要讓影像變成詳細的 token 序列，還是低成本的序列，因此收據掃描與縮圖可共用同一份部署 • ViT 內部早期壓縮，借鏡 LLaVA-UHD v4 — 視覺 token 是在視覺編碼器內部被裁減，而不是在編碼器之後才裁減，這正是讓 4× 路徑得以具成本效益的關鍵 • 切片 — 高解析度影像會分割成 448×448 圖磚，外加一張低解析度總覽，切片數量為執行期參數（卡片建議影像用 36、視訊用 1） • 視訊取樣 — max_num_frames 預設為 128，且 stack_frames 會將子影格合成為網格，這讓手機能在不把每個影格都保留在記憶體中的情況下處理完螢幕錄影

針對提示詞提到的收據使用情境，流程是：拍攝、將長邊縮小到接近 980 像素、以 4× 搭配高切片數執行，並要求結構化輸出。36 個切片的 4× 路徑是成本較高的設定；16× 路徑的 token 數大約只有四分之一，也是手機能保持流暢的地方。16× 是否足以讀取熱感應收據，只有你自己的影像能回答，而且卡片中沒有已發表的基準測試會依降採樣模式報告 OCR 準確率。

「demo」與「app」之間的落差

從一個能跑通的示範，到一款真正能上架的 iOS app，中間還卡著三件事，而這三件事都不是模型的權重。

首先是封裝問題。該模型以 Transformers、GGUF、AWQ、GPTQ 與 int4 格式發佈。只有 GGUF 在 iOS 上有成熟的裝置端執行器——llama.cpp 及其相關專案——而且只有 GGUF 儲存庫附帶多模態路徑所需的獨立視覺投影器（mmproj）檔案。如果你從 BF16 檢查點開始，期望能單檔直接替換使用，你會發現投影器是另一個獨立產物，有其自身的大小。

第二個是散熱預算。1B 模型產生幾百個 token 屬於突發性工作負載；1B 模型對一張 36 切片的頁面進行 OCR 則屬於持續性工作負載。廠商的示範 GIF 是螢幕錄影，不是溫度軌跡。規格卡上沒有任何已公佈的數據提供在任何手機上的持續每秒 token 數，而這正是決定掃描 App 在第三份或第三十份文件上是否仍感覺即時的關鍵數字。

第三項是你堆疊的其餘部分。裝置端推論負責影像。它不負責將擷取到的收據與總帳核對、把模稜兩可的項目升級給更大的模型，或在手機太舊以致應用程式拒絕載入權重時進行備援。這正是路由器能佔有一席之地、而非取代任何東西的界線：OrcaRouter 將200 多個託管模型 置於一個相容 OpenAI 的端點之後，且加成 0%，直接傳遞各供應商的標價，並提供自動容錯移轉，以及用於主要與備援設定的路由 DSL。手機端擷取器可將其不確定的案例交給託管視覺模型，而同一把金鑰可承載這兩條路徑。MiniCPM-V 4.7 1B 本身不在該目錄中——它是你自己執行的檢查點——因此路由器是升級路徑，而不是呼叫此模型的方式。

靜默發布模式，以及它為何持續造成這種混淆

MiniCPM-V 4.7 在沒有發表活動的情況下登場。35B-A3B 儲存庫於 2026 年 10 月 6 日出現，當時完全沒有模型卡——模型卡在六天後才與標註日期的發布說明一同上線。1B 也遵循相同模式：先有儲存庫，後有文件，期間由社群持續發掘。在這段空窗期，報導只能根據現有產物補齊內容，這也是為何早期文章描述的是 35B MoE 模型，之後卻必須在 1B 及其模型卡出現時修訂。

這並不是在批評 OpenBMB 的工程實力，而是在描述關於這個模型的資訊如何傳播；這也是為什麼「能在日常 iPhone 上執行」這類說法，會比對其構成限定的記憶體數據傳播得更快。儲存庫是主要來源。模型卡是主要來源。開發者手機上應用程式運作中的截圖只是一個資料點，不是規格。

具體來說，這該怎麼處理？

如果你有 Pro Max 或 iPad。下載 Q8_0 GGUF 與 16× projector，透過 llama.cpp 或 Ollama 執行，並在兩種降採樣設定下測試你自己的文件。你將能在一個下午內得到可用的本地 OCR 與影像問答流程，而且 1B 模型夠小，可以讓它常駐並與其他應用程式同時運行。

如果你用的是標準 iPhone。先從 Q4_K_M 和 16× 投影器開始，把 slice 數量上限設在適度的值，然後實測。記憶體計算顯示它應該放得下；持續使用下的散熱與 jetsam 行為，才是沒有人發表過的部分。請在你打算支援的最舊裝置上測試，而不是最新的裝置。

如果你正在打造一款產品。請把裝置端模型視為快速路徑，把託管模型視為正確性路徑。這種升級是一種路由決策，而從第一天就把它建進去，會比在第一張「手機誤讀收據」的客服單之後才補建更便宜。

啟動這篇文章的那項主張——{{1}}1B 多模態模型如今能在 Pro Max 層級以下的手機上運行{{/1}}——從記憶體計算來看合理，但在已公開的紀錄中尚未獲得證實。對如此年輕的模型而言，這是正常狀態，也是應該實測而非等待的理由。權重採用 Apache 2.0，量化版本也已存在，而你與答案之間唯一的阻礙，就是花一個下午用自己的硬體實測。

重點：MiniCPM-V 4.7 1B 是一個真實存在、有文件記載、採用 Apache-2.0 授權的視覺模型，在 Q4 量化下連同視覺投影器約佔 1.8 GB——小到讓中階手機成為可信的目標，而不只是 12GB 的 Pro Max。廠商尚未公布裝置相容清單或最低記憶體數據，而「日常 iPhone」的說法源自開發者報告，並非模型卡。在依此規劃之前，請先在自己的裝置上測試。