OpenBMB releases MiniCPM-V 4.7 with 35B-A3B and 1B models

• Two open multimodal models shipped: OpenBMB's launch introduces MiniCPM-V 4.7 in 35B-A3B MoE and 1B dense sizes.
• Mobile decoding gets roughly a fivefold speedup: OpenBMB reports 17+ tokens/s on a 16GB iPad Pro M4 and 13+ tokens/s on an iPhone 17 Pro Max.
• Expert prefetching preserves the original router: OpenBMB's LES description says predictions control loading and scheduling, while actual token-level routing still determines computation.
• Customization uses ordinary SFT: OpenBMB's deployment post introduces Self-Replay Fine-Tuning, whose published recipe mixes filtered, self-generated responses into task data.

The LES ablation is the engineering highlight, with separate timings for scheduling, quantization, and speculative sampling. The mobile app README contains a deployment gotcha: the phone demo cannot load the standard 35B GGUF. The fine-tuning experiments test the new recipe on earlier checkpoints, including MiniCPM-V 4.5.

OpenBMB released the family on October 12, with code and model weights under Apache-2.0, according to its release README.

• 35B-A3B: 35 billion total parameters and 3 billion active per token. The model card identifies it as the MiniCPM-V series' first MoE.
• 1B: a dense model small enough to keep resident in memory. Its model card covers single-image, multi-image, and video inputs.

A phone can store MoE expert weights on flash without holding them all in RAM. Loading each expert only when the router requests it introduces repeated generation stalls.

LES overlaps that I/O with computation:

1. Predict: cross-layer routing prediction estimates which experts the next layer will need.
2. Prefetch: likely expert weights load ahead of demand.
3. Schedule: among experts selected by the actual router, already-loaded experts compute first while the remaining required weights load in parallel.
4. Recover misses: experts missed by the prediction still load and execute normally.

OpenBMB also repacks weights into contiguous layouts to reduce scattered reads. LES requires no additional training; the launch claims byte-for-byte identical outputs from its accelerated inference.

The LES documentation measures successive optimizations on an 11-inch iPad Pro M4 with 16GB RAM:

| Configuration | Decode speed | Gain over baseline |
| --- | ---: | ---: |
| SSD expert loading, no listed optimizations | 2.97 tokens/s | 1.00× |
| Scheduling and loading optimizations | 9.81 tokens/s | 3.30× |
| Plus layer-wise mixed-precision quantization | 14.92 tokens/s | 5.02× |
| Plus DSpark speculative sampling | 17.39 tokens/s | 5.86× |

The fivefold figure includes quantization. Scheduling and loading changes alone deliver 3.30×; speculative sampling adds another 17% over the quantized configuration.

Speed is generated tokens divided by total decode time. The test set spans visual reasoning, OCR, coding, mathematics, and an internal dialogue evaluation; the model card also lists a separately trained DSpark draft checkpoint.

Both models compress tokens early inside the vision encoder, reducing work in subsequent encoder layers. The Transformers interface exposes the trade-off directly:

• downsample_mode="16x": the default, with fewer visual tokens.
• downsample_mode="4x": retains four times as many tokens for finer detail.
• Processor and generation: both receive downsample_mode, controlling placeholder counts and vision-encoder processing respectively.
• Image slicing: max_slice_nums defaults to 9; the image example uses 36 and the video example uses 1.
• Video sampling: max_num_frames defaults to 128. Higher stack_frames values add grid-composited subframes between main frames.

OpenBMB combines public reports with its own evaluations of official checkpoints, using Instruct mode, in its benchmark tables.

The launch post claims a 5.2-point OCRBench lead over Qwen3.6 35B-A3B at 16× compression. The table gives Qwen 86.0, MiniCPM 91.2 at 4×, and MiniCPM 90.4 at 16×: the corresponding leads are 5.2 points at 4× and 4.4 points at 16×.

Other comparisons against Qwen3.6 35B-A3B, with both models at 4× compression:

• OmniDocBench v1.6: 80.17 → 94.24, +14.07 points.
• LongVideoBench: 63.10 → 68.90, +5.80 points.
• ScreenSpot: 92.94 → 86.99, −5.95 points.

Compression also changes accuracy unevenly within MiniCPM: switching from 4× to 16× costs 0.8 points on OCRBench but 6.4 points on CharXiv reasoning.

OpenBMB evaluated text tasks alongside vision in its language benchmark table. The tool-use results split across two evaluations:

• τ²-Bench: Qwen3.6 35B-A3B's 79.65 → MiniCPM's 84.65, +5.00 points.
• BFCL-V4: Qwen3.6 35B-A3B's 60.20 → MiniCPM's 60.06, −0.14 points.
• LiveCodeBench v6: MiniCPM scores 56.57, versus Gemma-4 31B's 71.24, a 14.67-point gap.

OpenBMB welcomed early agent-workflow tests, naming tool use, long-context handling, and agent loops as areas where efficient models need to prove themselves.

Self-Replay Fine-Tuning constructs a fixed replay dataset from the checkpoint being customized. OpenBMB's SRFT write-up describes five stages:

1. Seed prompts: cover existing capabilities, including general instructions, business queries, OCR, and visual question answering.
2. Candidate sampling: generate multiple responses per prompt with the pre-fine-tuning model.
3. Filtering: score factual correctness, format, length, safety, and reasoning quality; retain the best passing candidate.
4. Curation: deduplicate, fill metadata, and balance capability buckets.
5. Mixed training: combine replay examples with unchanged task inputs and labels, then run ordinary SFT.

The architecture, loss, and training loop stay unchanged. Replay responses are generated offline and remain fixed during training.

On MiniCPM-o 4.5's Counting task, a 4:1 task-to-replay ratio reduced general-capability drop from 7.92 to 1.59 points. Task gain changed from 29.66 to 28.90 points, a 0.76-point cost for substantially better retention.

OpenBMB lists the following launch support:

• Inference: SGLang, vLLM, llama.cpp, mlx-vlm, and Ollama.
• Fine-tuning: SWIFT and LLaMA-Factory.
• Quantization: GGUF, BNB, AWQ, GPTQ, and FP8.
• Day-zero hardware: Apple, Intel, AMD, Arm, and Rockchip.
• Additional FlagOS platforms: Huawei, Hygon, Moore Threads, and Kunlunxin.

The model card also documents Transformers 5.18.0 or newer and an OpenAI-compatible transformers serve endpoint, including a function-calling request example.

OpenBMB advertises 3GB memory use, while its app README recommends at least 12GB of device RAM for the 35B demo and fast internal storage.

• 35B-A3B download: approximately 16.6GB, including the main file, vision weights, and 40 expert shards.
• 1B download: approximately 1.8GB, with at least 4GB device RAM recommended.
• App context: 4K tokens by default; KV-cache memory grows roughly linearly with context length.
• Platforms: fully offline iOS, Android, and HarmonyOS NEXT demos share the llama.cpp-omni submodule's ios-omni branch.

The phone build loads an app-specific -les.gguf plus an experts/ directory from the split-weight repository. Standard 35B GGUF files keep routed experts inline; the README says loading the roughly 15.5GB file as a single Metal buffer or resident allocation gets the app killed by the OS.

The split bundle includes a manifest. A mismatched main file and expert shards fail the on-disk consistency check, and the model refuses to load.