OpenBMB Releases MiniCPM-V 4.7, Its First MoE Multimodal Model

OpenBMB released MiniCPM-V 4.7 on October 12, 2026 — the latest entry in its MiniCPM-V vision-language series and the first in that line to use a mixture-of-experts (MoE) architecture. The release ships two open-weight models under Apache 2.0: MiniCPM-V 4.7 35B-A3B and MiniCPM-V 4.7 1B. The headline claim is an efficiency one. OpenBMB describes the 35B-A3B variant as “the first open-source MoE model to run smoothly on-device without compromising performance,” quoting a decoding speed of 13+ tokens per second in roughly 3 GB of memory on an iPhone 17 Pro Max.

Advanced

Two Variants, Two Architectures

Although they share a name, the two models are very different underneath. Hugging Face safetensors metadata lists the 35B-A3B variant at 35,212,875,824 parameters in bfloat16, sharded across 16 files and about 70.6 GB of storage. The smaller “1B” variant’s safetensors metadata lists 1,554,476,272 parameters.

The published config.json for the 35B-A3B model describes a sparse MoE text stack: 40 layers, hidden size 2,048, 16 attention heads against 2 key/value heads, 256 experts with 8 active per token, a maximum position of 262,144 tokens, and a vocabulary of 248,144. The layer list alternates in a 3:1 pattern — three linear-attention layers for every full-attention layer. The vision tower is separate: 27 layers, hidden size 1,152, patch size 14, and a 980-pixel input size. The same file lists the text backbone’s model type as qwen3_5_moe_text, and sets visual token downsampling to 16x.

Fitting a 35B MoE on a Phone

Running an MoE model locally is not just a question of active parameters. Different tokens route to different experts, and a phone cannot hold every expert weight in memory, so weights must stream from storage — and repeated loading stalls can make decoding too slow for interactive use. OpenBMB’s answer is Lookahead Expert Scheduling (LES), which uses cross-layer routing prediction to preload experts the next layer is likely to need. The project’s technical note stresses that the prediction only drives prefetching and scheduling: computation still follows the model’s original token-level routing, and any required expert the prediction misses is loaded and evaluated as usual.

LES is combined with fine-grained layer-wise quantization and DSpark speculative sampling. The repository reports a 5× speedup on real devices from the optimization work without sacrificing capability, and publishes a separate DSpark draft model for speculative decoding. Beyond the 35B-A3B weights themselves, OpenBMB ships FP8, int4, AWQ, GPTQ and GGUF quantized variants, and lists support for SGLang, vLLM, llama.cpp and Ollama for inference, with SWIFT and LLaMA-Factory for fine-tuning. Deployment targets iOS, Android and HarmonyOS, with day-0 chip support from Rockchip, Houmo, Intel, AMD and Arm.

Benchmarks and the Efficiency Claim

OpenBMB positions both variants on a performance-versus-inference-time “Pareto frontier.” In its own comparison table for the 35B-A3B model in Instruct mode and 4x visual-token compression, the model scores 91.72 on MMBench, 80.22 on MMMU, 88.00 on MathVista, 91.20 on OCRBench and 94.24 on OmniDocBench_v1.6, against Qwen3.6 35B-A3B, Qwen3.6 27B, Qwen3.8 27B and Gemma-4 31B. The team states that 35B-A3B “achieves a higher overall score in less inference time than Qwen3.6 35B-A3B.”

For the smaller model, OpenBMB reports 83.17 on MMBench, 56.89 on MMMU and 86.10 on OCRBench at 4x compression, and says it “substantially outperforms Qwen3.5 0.8B in both overall score and inference efficiency,” while improving on the predecessor MiniCPM-V 4.6. Both variants use an intra-ViT early-compression technique borrowed from LLaVA-UHD v4, which trims visual tokens inside the vision encoder and supports mixed 4x/16x compression. OpenBMB also open-sourced a fine-tuning method, Self-Replay Fine-Tuning (SRFT), aimed at extending capabilities while reducing forgetting.

What This Means

The interesting part of this release is not a single benchmark number but the packaging: a 35B-class MoE, quantized and scheduled to stream from storage, in a form that phones can run interactively. That is a different engineering problem from shrinking a dense model, and LES — which preloads likely experts rather than permanently restricting the expert pool — is a plausible answer to it. Two caveats are worth keeping in view. The benchmark comparisons are OpenBMB’s own evaluations against official checkpoints, and the repository’s paper list still cites the MiniCPM-V 4.5 and MiniCPM-o 4.5 technical reports rather than a dedicated 4.7 report, so peer-reviewed or third-party verification of the 4.7 numbers is not yet available. Note too that the naming is loose: the variant called “1B” carries roughly 1.55B parameters by safetensors metadata, and OpenBMB’s own 1B comparison table labels the size as 1.3B.

Related Coverage

• MiniCPM-V 4.6: A 1.3B Multimodal Model Built for Phones — the predecessor small model that MiniCPM-V 4.7 1B builds on
• OpenBMB Releases MiniCPM5-2B, Topping Open Models Under 4B — the same lab’s separate small dense language-model line
• GLM-5.3-Flash: 320B Multimodal MoE, Weights on Day One — a much larger open multimodal MoE release for comparison

This post was drafted with AI assistance and reviewed by RITS staff.

Sources

• MiniCPM-V 4.7 35B-A3B model card (Hugging Face, OpenBMB)
• MiniCPM-V 4.7 1B model card (Hugging Face, OpenBMB)
• OpenBMB MiniCPM-V repository README and release history
• MiniCPM-V 4.7 model guide (OpenBMB, GitHub)
• MiniCPM-V 4.7 35B-A3B config.json (OpenBMB)
• Lookahead Expert Scheduling technical note
• Self-Replay Fine-Tuning (OpenBMB blog)
• OpenBMB open-sources MiniCPM-V 4.7 (AICoder)