OpenBMB releases MiniCPM-V 4.7, a 35B multimodal MoE built to run on phones

What did OpenBMB release?

OpenBMB, the open-source effort behind the MiniCPM family of small models, pushed MiniCPM-V 4.7 to its GitHub repository on 12 October 2026 and listed it in the project’s news as “MiniCPM-V 4.7 released”. The weights had been uploaded to Hugging Face over the previous week; the release notes and documentation went up on Monday.

There are two models. The headline one, MiniCPM-V 4.7 35B-A3B, is the first mixture-of-experts model in the MiniCPM-V line: about 35.2 billion parameters in total, of which roughly 3 billion are active for any given token. The second, MiniCPM-V 4.7 1B, is a compact model of about 1.55 billion parameters that OpenBMB’s own table labels 1.3B. Both read single images, several images and video, and answer in text.

The model card credits Qwen3.6 as the language backbone and Google’s SigLIP2 as the vision encoder, so this is a vision-language model built on open components rather than trained from scratch. Both models and the repository are released under the Apache License 2.0, which allows commercial use. If the mixture-of-experts idea is new to you, our explainer on mixture of experts covers the basics.

How does a 35B model run on a phone?

A mixture-of-experts model only computes with a few experts per token, but a phone still has to reach all of them. Different tokens pick different experts at each layer, and a 35-billion-parameter model does not fit in a phone’s memory. The usual fix is to keep the expert weights in flash storage and load them when they are needed, which works but stalls generation every time the model waits for a load.

Another shortcut is to lock the model to a fixed subset of experts for a whole prompt. OpenBMB argues that this trades away capability, because the router can no longer pick the experts it would normally choose. Its stated goal is “smooth inference without compromising performance”: the model’s own token-level routing stays intact.

The answer is Lookahead Expert Scheduling, or LES. It predicts, one layer ahead, which experts are likely to be needed and starts loading them early. When the real router makes its choice, experts that are already in memory are computed first while any that the prediction missed are loaded in parallel. OpenBMB stresses that the prediction only drives prefetching and scheduling, never the computation itself, and that no extra training is required.

Two more pieces sit on top. Layer-wise mixed-precision quantization shrinks the expert weights, and they are repacked into contiguous blocks so flash storage can read them sequentially instead of in scattered chunks. Finally, a small DSpark draft model, released alongside each size, adds speculative sampling to speed up decoding further.

OpenBMB’s write-up gives the numbers for each stage on an iPad Pro 11-inch M4 with 16 GB of memory. Loading experts from storage with no optimizations gave 2.97 tokens per second. Scheduling and load optimizations raised that to 9.81, quantization to 14.92, and speculative sampling to 17.39, which it calls a 5.86-fold gain with no loss of quality. On an iPhone 17 Pro Max the headline figure is more than 13 tokens per second using about 3 GB of memory.

How does MiniCPM-V 4.7 score?

OpenBMB compares the 35B-A3B model with Qwen3.6 35B-A3B, Qwen3.6 27B, Qwen3.8 27B and Google’s Gemma-4 31B, all in instruct mode. Its claim is a better trade-off rather than outright leadership: on its chart of average score against inference time, the new model reaches about 77 points in roughly a third of the time that similarly scoring models need.

The table shows where the gains are. With four-times visual-token compression, MiniCPM-V 4.7 scores 91.72 on MMBench, 80.22 on MMMU, 88.00 on MathVista and 91.20 on OCRBench, ahead of Qwen3.6 35B-A3B on each. The largest gap is document parsing: 94.24 on OmniDocBench v1.6 against 80.17, and 75.60 against 67.50 on CharXiv chart reasoning.

It does not win everywhere. Qwen3.6 35B-A3B is ahead on ScreenSpot, a test of finding interface elements on screen, with 92.94 against 86.99, which matters for the computer-use agents many teams are building. It is also slightly ahead on MMMU-Pro and SimpleVQA, and Qwen3.8 27B leads on MathVision and CCOCR.

The 1B model is pitched against much smaller rivals. OpenBMB’s table has it at 83.17 on MMBench and 86.10 on OCRBench, ahead of MiniCPM-V 4.6, Qwen3.5 0.8B and LiquidAI’s LFM2.5-VL 1.6B on most rows, while Gemma-4 E2B, which is several times larger, leads on MMMU and MathVision. OpenBMB says the results combine public reports with its own runs of official checkpoints.

How can developers run MiniCPM-V 4.7?

Both sizes are on Hugging Face and ModelScope, with quantized builds in GGUF, AWQ, GPTQ, FP8 and int4. OpenBMB lists support in Transformers 5.18 and later, SGLang, vLLM, llama.cpp and Ollama, where the 1B model is listed at about 1.8 GB with a 256K-token context. Fine-tuning recipes cover SWIFT and LLaMA-Factory.

For phones, OpenBMB maintains an apps repository with iOS, Android and HarmonyOS builds, and claims day-zero support on chips from Intel, AMD, Arm, Rockchip and Houmo. Intel’s OpenVINO toolkit is listed as supporting the model on Intel CPUs, GPUs and NPUs. Teams already experimenting with local GPU engines such as Google’s ML Drift now have another open multimodal model to test.

Developers get two quality-versus-cost dials. The vision encoder compresses image tokens early, and a downsample_mode setting switches between four-times compression for detail and sixteen-times compression for speed; the table shows the 16x mode giving up about one to six points depending on the test. OpenBMB is also releasing Self-Replay Fine-Tuning, a method it says adds new skills while reducing forgetting of old ones.

Why does on-device MoE matter?

Most on-device models are small dense models, because every parameter has to fit in memory. Mixture-of-experts models are bigger and stronger for the same compute per token, but their total size has kept them in data centers. MiniCPM-V 4.7 is an attempt to move that trade-off: use flash storage as overflow memory and hide the loading time behind computation.

If the approach holds up, it widens what can run offline on a phone, from receipts, screenshots and documents to video, without sending images to a cloud service. That matters for privacy and for latency, and it matches a wider move toward open-weight models that people run themselves, as with the heavily quantized Saluki 27B build for local GPUs.

The technique is also not tied to MiniCPM. LES lives in a llama.cpp fork and is described as needing no retraining, so other MoE models could in principle use the same scheduling if the work reaches mainstream runtimes.

What are the limits and open questions?

Every number here is OpenBMB’s. The speed results come from its own devices and test set, the benchmark table mixes published scores with its own runs, and we have not tested the models. Decode speed also says nothing about prefill time, which is how long the phone takes to read a large image or video before it starts answering.

Sustained use is another question. Streaming expert weights from flash for every token could affect battery life and heat on a phone over long sessions, and OpenBMB has not published power measurements. The 13+ tokens per second figure is for an iPhone 17 Pro Max; older or cheaper phones with slower storage may see less.

The LES code sits in a fork rather than upstream llama.cpp, and OpenVINO’s example notebook is still marked to be announced. A practical rule: try the 1B model where you need a small offline vision model today, and test the 35B-A3B model on your own phones and documents before relying on OpenBMB’s speed claims.