# OpenBMB releases MiniCPM-V 4.7, its first mixture-of-experts vision model, with a 3 GB iPhone claim

URL: https://onticpost.com/minicpm-v-4-7-moe-vision-model/
Published: 2026-10-16
Updated: 2026-10-15
By: Hill, Onticpost

> OpenBMB's MiniCPM-V 4.7 has a 35B-A3B mixture of experts in 70.43 GB of files and a 1B model. Its 3 GB iPhone figure has no published run table.

OpenBMB released MiniCPM-V 4.7 on October 12, 2026, according to the news list in its MiniCPM-V code repository, in two sizes: a 35B-A3B model that the company calls the first mixture-of-experts model in the MiniCPM-V series, and a 1B model. Hugging Face counts 35,212,875,824 parameters in the larger model, stored as 70.43 GB of weight files, and 1,554,476,272 in the smaller one. OpenBMB’s headline claim is that the 35B-A3B model decodes at more than 13 tokens a second “with just 3 GB of memory” on an iPhone 17 Pro Max. Both models are open weights under the Apache 2.0 licence. We have not run either model.

**Takeaway points**

- OpenBMB released MiniCPM-V 4.7 on October 12, 2026, with a 35B-A3B mixture-of-experts model of 35,212,875,824 parameters and a 1B model of 1,554,476,272 parameters, both under Apache 2.0.
- The 3 GB iPhone figure depends on keeping most expert weights in storage and loading them as needed, while the full 35B-A3B weights are 70.43 GB of files and the smallest official GGUF build is 15.50 GB.
- OpenBMB publishes a measured speed table only for an iPad Pro with 16 GB, not for the iPhone claim, and we have not run either model.

## What is MiniCPM-V 4.7 and what did OpenBMB release?

MiniCPM-V 4.7 is a family of two vision language models that read images, several images at once, documents and video, and answer in text. The repository README says the family is “available in 35B-A3B and 1B variants” and that “The 35B-A3B variant is the series’ first MoE model.” MoE stands for mixture of experts, a design in which each token passes through a few small sub-networks chosen by a router instead of through the whole network.

The two main repositories on Hugging Face are openbmb/MiniCPM-V-4.7-35B-A3B and openbmb/MiniCPM-V-4.7-1B. Neither is gated. Hugging Face records the 1B repository as created on October 6 and the 35B-A3B repository on October 7, a few days before the release date in the GitHub news list. Both were last modified on October 14.

| Repository | Parameters (Hugging Face count) | Weight files | Created on Hugging Face |
| --- | --- | --- | --- |
| MiniCPM-V-4.7-35B-A3B | 35,212,875,824 in BF16 | 70.43 GB in 16 files | October 7, 2026 |
| MiniCPM-V-4.7-1B | 1,554,476,272 in BF16 | 3.11 GB in 1 file | October 6, 2026 |

The name of the smaller model undersells its size. The Hugging Face count for the 1B repository is 1.55 billion parameters, which includes the vision encoder as well as the language model. OpenBMB’s documents do not give a separate figure for the language part.

The model cards credit two outside projects for the parts. The acknowledgements thank Qwen3.5 and Qwen3.6 “for providing the language backbone” and SigLIP2 “for providing the vision understanding module”. The config files agree: the 35B-A3B text model is typed qwen3_5_moe_text and the 1B text model qwen3_5_text.

On October 15 the GitHub news list added DSpark speculative decoding heads, small draft models that propose tokens for the main model to check, in BF16 and GGUF form for both sizes.

## How does the MiniCPM-V 4.7 35B-A3B mixture of experts work?

The 35B-A3B model’s config describes 40 layers, 256 experts in each, and 8 experts chosen for every token, plus one shared expert. OpenBMB’s documents do not state the active parameter count as a number. The model’s name carries the suffix A3B.

The same config shows a mixed attention design. Its list of layer types repeats three linear attention layers followed by one full attention layer, ten times over, and it sets the maximum position count at 262,144. The vision encoder has 27 layers, a patch size of 14 and an image size of 980.

| Config field | 35B-A3B | 1B |
| --- | --- | --- |
| Text model type | qwen3_5_moe_text | qwen3_5_text |
| Layers | 40 | 24 |
| Experts per layer | 256, with 8 per token | none (dense) |
| Hidden size | 2,048 | 1,024 |
| Maximum positions | 262,144 | 262,144 |
| Vision encoder layers | 27 | 27 |

OpenBMB says the vision side compresses image tokens early, inside the vision encoder, using a technique from a project called LLaVA-UHD v4. The card says developers can choose between 4x and 16x compression of visual tokens, trading detail against cost. The usage table in the card sets 16x as the default.

## Can MiniCPM-V 4.7 run on an iPhone in 3 GB of memory?

OpenBMB says it can, but only by keeping most of the model out of memory and fetching experts from storage as they are needed. The card is plain about the problem: a mixture-of-experts model’s “on-device storage requirements are not limited to those active parameters”, because different tokens pick different experts at different layers.

OpenBMB’s answer is a scheduler it calls Lookahead Expert Scheduling, or LES, published in a separate repository named llama.cpp-omni. The LES document says it predicts which experts the next layer will need and loads them early, while computing the experts already loaded. The company says computation “still follows the model’s original token-level routing”, and that experts missed by the prediction are loaded as usual. The card adds layer-wise quantization of expert weights and the DSpark draft model as the other two parts.

The iPhone figure itself, “13+ tokens/s with just 3 GB of memory on iPhone 17 Pro Max”, appears in the model card and the repository README as a claim. Neither gives a table of runs behind it. The card points instead to what it calls unedited screen recordings captured directly on the devices.

The measured numbers that OpenBMB does publish come from a different device. The LES document reports results on an iPad Pro 11-inch with an M4 chip and 16 GB of memory, with each optimization added in turn.

| Stage, as named in the LES document | Decode speed | Against the baseline |
| --- | --- | --- |
| Expert weights loaded from SSD, no optimizations | 2.97 tokens a second | 1.00x |
| LES scheduling and load optimization | 9.81 tokens a second | 3.30x |
| LES plus layer-wise mixed-precision quantization | 14.92 tokens a second | 5.02x |
| Full LES plus DSpark speculative sampling | 17.39 tokens a second | 5.86x |

The document says decode speed is generated tokens divided by total decode time, and that its test data covered benchmarks including MMMU, MathVista, OCRBench, HumanEval and AIME2025, plus an internal dialogue set. It does not give a memory figure for the iPad runs.

## Do OpenBMB’s own documents agree on MiniCPM-V 4.7?

Mostly, with three gaps worth stating. The first is the speed-up. The repository README says LES delivers a five times speed-up on real devices “without sacrificing model capability”. The LES table shows 5.02x for LES with quantization and 5.86x once DSpark is added, so the README’s round figure matches the stage without speculative decoding.

The second is the device. The iPhone 17 Pro Max claim of more than 13 tokens a second in 3 GB has no table of its own, and the only table, from the iPad Pro, gives 17.39 tokens a second with no memory figure. The two numbers come from two devices and cannot be compared directly.

The third is how the release is described on each model card. The 35B-A3B card says MiniCPM-V 4.7 is “available in a 35B-A3B variant”, and the 1B card says it is “available in a 1B variant”. Only the GitHub README and its model guide name both sizes together.

On quality, OpenBMB claims that in instruct mode the 35B-A3B model “achieves a higher overall score in less inference time than Qwen3.6 35B-A3B”, and that the 1B model “substantially outperforms Qwen3.5 0.8B in both overall score and inference efficiency”. The benchmark scores behind these claims are published only as chart images in the card and the repository, not as a table of numbers. We have not reproduced any of them.

## Will MiniCPM-V 4.7 35B-A3B fit a 48 GB Mac?

Not at full precision. The 35B-A3B weight files come to 70.43 GB, which is 22.43 GB more than the 48 GB of memory on our test machine, an Apple M4 Pro. The quantized builds that OpenBMB publishes in its own account are smaller.

| Official build | Files | Size |
| --- | --- | --- |
| 35B-A3B, BF16 safetensors | 16 | 70.43 GB |
| 35B-A3B, GGUF F16 | 1 | 69.38 GB |
| 35B-A3B, FP8 safetensors | 2 | 38.01 GB |
| 35B-A3B, GGUF Q8_0 | 1 | 36.90 GB |
| 35B-A3B, int4 safetensors | 2 | 22.62 GB |
| 35B-A3B, GGUF Q4_K_M | 1 | 21.17 GB |
| 35B-A3B, GGUF mix_q3gud_im | 1 | 15.50 GB |
| 1B, GGUF Q4_K_M | 1 | 0.67 GB |

On file size alone, the 4-bit and 8-bit GGUF builds of the 35B-A3B model are smaller than 48 GB, and the vision projector file adds 1.12 GB in F16. File size is not the memory a running model needs, which also has to hold the context cache. Our reading is that the iPhone figure rests on streaming experts from storage, not on the model being small. The steps in [how to import a local GGUF file into Ollama with a Modelfile](https://onticpost.com/import-gguf-ollama-modelfile-gemma-4/) cover loading a GGUF file, though that guide was written for Gemma 4 31B and not for this model.

The card lists SGLang, vLLM, llama.cpp and Ollama as supported inference frameworks, and says the model is also available on Ollama. It does not say whether the LES scheduler is part of mainline llama.cpp or only of OpenBMB’s llama.cpp-omni repository. For another mixture-of-experts release we compared against the same 48 GB, see [Aleph Alpha Kolibri, a 78.84 GB open-weight model](https://onticpost.com/aleph-alpha-kolibri-open-weights/).

## What has OpenBMB not published about MiniCPM-V 4.7, and have we tested it?

OpenBMB has not published a run log for the iPhone 17 Pro Max claim, a memory figure for its iPad Pro table, an active parameter count in numbers, or its benchmark scores in a form other than images. It also has not said how much of the 70.43 GB of weights its quantized on-device build keeps, or how much storage that build needs on a phone.

We have not run MiniCPM-V 4.7. We read the two model cards, the repository README and model guide, the LES document and the Hugging Face data for six official repositories, saved on October 15, and we compared file sizes with the 48 GB of memory on our test machine. We took no speed, memory or quality measurement. Any speed figure we publish for a build that fits would be measured as described in [how to measure tokens per second in LM Studio without the cache fooling you](https://onticpost.com/measure-tokens-per-second-lm-studio/).

## Sources

- [OpenBMB model card, MiniCPM-V 4.7 35B-A3B](https://huggingface.co/openbmb/MiniCPM-V-4.7-35B-A3B)
- [OpenBMB MiniCPM-V repository and release notes](https://github.com/OpenBMB/MiniCPM-V)