In mid-October 2026, ModelBest and OpenBMB released MiniCPM-V 4.7, the first 35B-parameter MoE multimodal model that runs on a phone — the official docs state 13+ tokens/s decoding with roughly 3 GB of memory on an iPhone 17 Pro Max. Model, docs, and weights live in the OpenBMB/MiniCPM-V repository (github.com/OpenBMB/MiniCPM-V; 26,753 stars per the GitHub API snapshot of 2026-10-15). But three realities get in the way: the phone-build download is about 16.6 GB; desktop LES acceleration means compiling an engine called llama.cpp-omni yourself; and the Ollama official library, the easiest path of all, still has no MiniCPM-V 4.7 as of October 15, 2026 — for one-click convenience it only carries the previous generation, 4.6. This SOP covers the three paths: direct phone install, desktop self-build, and the Ollama shortcut, with steps, tests, and pitfalls for each. A scope note: this pairs with our same-batch feature on the model's capability and ecosystem; here we only cover deployment. Unlike our earlier piece on running a 27B text model in 4 GB of VRAM (the airllm relocation route) and our general deployment tool comparison, this is the native on-device route for a multimodal MoE model. All figures reflect official documentation as of 2026-10-15.
Two Official Numbers to Understand First
The first number is 3 GB. The official documentation states that 35B-A3B decodes at 13+ tokens/s on an iPhone 17 Pro Max "with just 3 GB of memory." That 3 GB is the model's runtime footprint, not the minimum free RAM your phone needs. Expert weights stay on flash and stream into memory on demand — that MoE-SSD mechanism is what lets a phone hold 35 billion parameters at all. The official app hardware table recommends at least 12 GB of device RAM for 35B-A3B, validated on a 12 GB iPhone 17 Pro Max; lower-RAM devices fall back to a smaller expert cache and run considerably slower (official statement; not measured here).
The second number rests on three stacked techniques: Lookahead Expert Scheduling (LES) predicts which experts the next layer needs and prefetches them, overlapping loading with computation; fine-grained layer-wise quantization cuts expert-weight storage and bandwidth cost; DSpark speculative sampling lifts decode speed further. The official repo claims a roughly 5x real-device speedup without sacrificing capability. A different iPad Pro M4 figure has circulated; per our rule on conflicting numbers, this article uses only the official figure above.
With those numbers in hand the choice is simple: on the go with a recent flagship, take Route 1; full control on your own machine, Route 2; multimodal Q&A in five minutes, Route 3.
<table> <tr> <th>Variant and form</th><th>Quantization</th><th>Download size</th><th>Recommended device memory</th><th>Source</th> </tr> <tr> <td>4.7 35B-A3B, phone build (-les split)</td><td>q3gud-im (Q3_K experts)</td><td>~16.6 GB (main file + 40 expert shards + vision module)</td><td>RAM 12 GB or more</td><td>Official app hardware table; validated on 12 GB iPhone 17 Pro Max</td> </tr> <tr> <td>4.7 1B, phone build</td><td>Q4_K_M</td><td>~1.8 GB (incl. vision module)</td><td>RAM 4 GB or more</td><td>Official app hardware table</td> </tr> <tr> <td>4.7 35B-A3B, desktop GGUF</td><td>Q4_K_M</td><td>~22 GB</td><td>Not stated officially; not tested by this site</td><td>Ollama publisher page tag sizes</td> </tr> <tr> <td>4.7 1B, desktop GGUF</td><td>Q4_K_M</td><td>~1.8 GB</td><td>Not stated officially; not tested by this site</td><td>Ollama publisher page tag sizes</td> </tr> <tr> <td>4.6, reference (Ollama library)</td><td>Listed as 1b, vision</td><td>Shown per tag on pull</td><td>Not listed on the library entry</td><td>Ollama official library, snapshot 2026-10-15</td> </tr> </table>Route 1: Direct Install on Phone or Tablet
Who it suits: anyone with a 12 GB-RAM-class flagship who wants the full 35B-A3B experience, or anyone with 4 GB or more of RAM trying the 1B variant. This is the only fully offline route.
Prerequisites: an iOS, Android, or HarmonyOS device; about 17 GB of free storage for 35B-A3B or 2 GB for 1B; no developer tools for the app itself. The official app and source live in the OpenBMB/MiniCPM-V-Apps repository (github.com/OpenBMB/MiniCPM-V-Apps), covering iOS, Android, and HarmonyOS NEXT.
Steps: the easiest entry is the official prebuilt packages — iOS via a public TestFlight link (repo README), Android and HarmonyOS as APK/HAP packages on the GitHub Releases page, details in DOWNLOAD.md. Once installed, open Model Management in Settings, download the model, activate it, and send an image in the chat to start asking. Source builds are documented too: iOS needs Xcode and CMake 3.28 or newer, then the bundled ./scripts/build_xcframework.sh, your own signing team, and Developer Mode; Android needs Android Studio with NDK 27 and an arm64-v8a device (./gradlew assembleDebug, models sideloadable via adb push); HarmonyOS needs DevEco Studio 5.0 or newer with automatic signing (a Huawei developer account is required).
Acceptance test: ask "what is in this picture" about any local image and get an answer grounded in the image content. The 1B variant should also pass on a 4 GB-RAM device, just more slowly.
Common pitfalls: flash speed matters — 35B-A3B streams expert weights from storage, so confirm about 17 GB free on fast internal storage. Devices under 12 GB use a smaller expert cache and run noticeably slower — official statement, gap not measured by this site. Shard integrity: the main file and its experts/ directory (40 shards plus a manifest) must stay together; mismatched files fail a consistency check, so in-app downloads are safest since they verify shards. Keep NPU expectations in check: the app runs llama.cpp's generic inference path on CPU/GPU compute, and the official Day-0 support for Rockchip, Houmo, Intel, AMD, and Arm chips is a separate chip-vendor track — your phone's NPU sits idle for now.
Route 2: Desktop Self-Build with llama.cpp-omni
Who it suits: developers who want 4.7 on their own machine, need API integration or a local service, and care enough about LES acceleration to compile it. Highest friction, full-control payoff.
Prerequisites: a Windows, Linux, or macOS machine; git and CMake; disk space for your quantization tier (Q4_K_M starts around 22 GB); a C/C++ toolchain for the first build.
Steps: first, pull the code and weights. The engine has two repositories: the LES link in the official model documentation points to OpenBMB/llama.cpp-omni (github.com/OpenBMB/llama.cpp-omni, pushed October 14, 2026), while the original community repository tc-mb/llama.cpp-omni (github.com/tc-mb/llama.cpp-omni) has more stars and fuller documentation; the two share one code lineage as independent repositories. For weights, take the official standard quants — openbmb/MiniCPM-V-4.7-35B-A3B-gguf and openbmb/MiniCPM-V-4.7-1B-gguf on Hugging Face or ModelScope, from F16 down to Q4_K_M — which the official weights table describes as intended for lower-memory CPU inference. Second, build, using the commands from the official README:
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --target llama-omni-server --target llama-omni-cli -jCMake auto-detects acceleration: Metal on macOS, CUDA on Linux with an NVIDIA GPU. If you would rather not compile, the Releases page carries prebuilt installers for Windows and macOS. Third, run — the README's basic usage is ./build/bin/llama-omni-cli -m /path/to/model.gguf, with flags including -c (context size, default 4096), -ngl (GPU layers, default 99), and --no-tts (text-only output).
One honest caveat: as of our sourcing date the README's quick-start examples are written around MiniCPM-o 4.5's full-duplex voice pipeline. For 4.7 specifics, defer to the official repository README and the LES document (under docs/les/ in the tc-mb repository); we have not tested the exact 4.7 GGUF load commands on this engine and will not invent them. Build with the verified commands above, then follow the official README and the GGUF guide in the OpenSQZ/MiniCPM-V-CookBook repository. The official 4.7 documentation also lists SGLang, vLLM, and stock llama.cpp as supported frameworks; with ample VRAM, the Transformers route with FP8 or int4 weights is documented in minicpm_v4dot7_en.md.
Acceptance test: ask a question about a local image and get an answer grounded in its content; a chat API call via llama-omni-server returning text also counts.
Common pitfalls: do not reuse the phone build's -les split on the desktop — the official standard GGUF repositories carry no -les variant; that split is an artifact made for the phone app, and desktops should use standard whole-model quants. The official docs publish no VRAM floor for 4.7, and the 35B-A3B Q4_K_M file alone is about 22 GB — validate your workflow on the 1B model first if memory is tight. Watch which repository you clone; the phone demo's submodule uses the engine's ios-omni branch. Warnings like "ignoring duplicate libraries" during the build are documented as harmless.
Route 3: The Ollama Shortcut — the Library Only Has 4.6
Who it suits: anyone who wants results in five minutes without compiling, and existing Ollama users. The defining reality here is the hook of this article: MiniCPM-V 4.7 is not in the Ollama official model library.
Status check (2026-10-15): the Ollama library at ollama.com/library lists three MiniCPM entries: minicpm-v (5.5M pulls), minicpm-v4.5 (54.6K pulls), and minicpm-v4.6 (69.5K pulls, tagged 1b and vision). minicpm-v4.6 joined the library on June 25, 2026 (official repository changelog) and remains the newest generation there.
Steps: with Ollama installed, one command:
ollama run minicpm-v4.64.6 also handles image understanding — reference a local image in the session and try multimodal Q&A right away.
A half-step worth knowing: the official 4.7 documentation links to an Ollama publisher page at ollama.com/openbmb/minicpm-v4.7 — an upload by the official OpenBMB account outside the curated library. Its live tags include 1b (Q4_K_M, ~1.8 GB) and 35b-a3b (Q4_K_M, ~22 GB, also the default latest tag), plus q8_0 and fp16 tiers, with a 256K context window. So ollama run openbmb/minicpm-v4.7 works today — just without official-library status, and with no promotion timeline. Watch ollama.com/library if you prefer to wait.
Acceptance test: after the pull finishes, reference an image in the session and get a relevant answer.
Common pitfalls: the latest tag points at the 22 GB 35b-a3b quantization by default — on a small machine, always specify :1b explicitly or you will pull a model you cannot load. The publisher page and the official library have different update rhythms; when something misbehaves, check the publisher page's tag timestamps first. This route runs whole-model quants with no expert-streaming mechanism, so the 22 GB file genuinely occupies 22 GB-class memory — the "3 GB runs 35B" claim does not apply here.
Related reading
- Mellum2.1 Deploy SOP: Run a 12B Coding Agent on 24GB
- 80GB GPU or bust: local Ming-Image deploy plus layer SOP
- Half the VRAM, Nothing Runs: Five Ways Out
FAQ
Q1: About that 3 GB of memory — what phones can actually run this? A1: Per the official documentation, 35B-A3B runs at about 3 GB of memory with 13+ tokens/s on an iPhone 17 Pro Max — the 3 GB is the model's runtime footprint, not the phone's total RAM. The official app hardware table recommends 12 GB or more of device RAM for 35B-A3B (validated on the 12 GB iPhone 17 Pro Max); lower-RAM devices fall back to a smaller expert cache and run noticeably slower. The 1B variant recommends 4 GB or more. Bottom line: a 12 GB flagship for 35B-A3B, or the 1B build on 4 GB-class phones.
Q2: When will the Ollama official library get 4.7?
A2: No official timeline as of 2026-10-15. The library's newest entry is still minicpm-v4.6, added June 25, 2026. OpenBMB does run a publisher page at openbmb/minicpm-v4.7 where ollama run openbmb/minicpm-v4.7 already works (1b ~1.8 GB, 35b-a3b ~22 GB) — just outside the curated library. Watch ollama.com/library for promotion.
Q3: What is the relationship between llama.cpp-omni and stock llama.cpp? A3: The official README positions it as a high-performance omni multimodal inference engine built on llama.cpp, compatible with its interfaces and ecosystem, with GGUF support across Windows, Linux, and macOS. They coexist rather than compete: the 4.7 documentation links LES acceleration to OpenBMB/llama.cpp-omni while also listing stock llama.cpp among 4.7's supported frameworks, and the official phone demo's submodule uses the engine's ios-omni branch. Two same-named repositories — OpenBMB's and tc-mb's — currently share this code lineage.
Q4: Do I need a GPU to run MiniCPM-V 4.7? A4: Depends on the route. Route 1 needs none — the phone's general-purpose compute suffices. On Route 2 there is no official VRAM floor for 4.7 (untested by this site), but macOS uses Metal, CPU inference is a baseline llama.cpp capability, and the official GGUF targets lower-memory CPU inference; an NVIDIA GPU gets automatic CUDA acceleration. On Route 3 it depends on the tag: 1b runs on an ordinary machine, while the 22 GB 35b-a3b quantization demands serious memory or VRAM.
Q5: Can the weights be used commercially? What is the license? A5: Quoting the Model License section of the official project documentation (project_en.md): the MiniCPM-o/V model weights and code are open-sourced under the Apache-2.0 license. An optional registration questionnaire and a disclaiming usage statement add no licensing restriction. Apache-2.0 is a standard license; commercial rights and obligations follow its text, matching the repository's LICENSE file.
The One-Line Summary
For offline phone use, take Route 1 and mind two gates: 12 GB of RAM and 17 GB of storage. For desktop control and LES acceleration, take Route 2 and follow the official README and official GGUF repositories. For the fastest start, take Route 3 with the library's 4.6 — or pull openbmb/minicpm-v4.7 from the publisher page while waiting for the official listing. All three end the same way: hand the model an image — if it can tell you what is in it, you are running a multimodal model locally.