MiniCPM-V 4.7 Got a Model Card: OpenBMB Published the Benchmarks, the Licence and the On-Device Claim

For the first six days of its life, MiniCPM-V 4.7 was a 70 GB folder of bfloat16 tensors with no README — no model card, no licence tag, no benchmark table, nothing that told you what it was for. That changed on October 12, 2026, when OpenBMB committed a full model card to openbmb/MiniCPM-V-4.7-35B-A3B, declared an Apache-2.0 licence, rewrote the README of the MiniCPM-o repository to lead with the new series, and announced it as an open-source MLLM release aimed at iOS, Android and HarmonyOS devices. The same documentation pass touched the 1B sibling, which now carries the identical card structure. This piece is about the delta — what the card actually claims, which of those claims you can check yourself, and which of them exist today only as pixels in a vendor-supplied PNG.

What arrived on October 12, and what was already there

The weights did not move. openbmb/MiniCPM-V-4.7-1B was created on October 6, 2026 at 17:40 UTC and openbmb/MiniCPM-V-4.7-35B-A3B on October 7 at 07:07 UTC; both still report a last-modified timestamp of October 12 because that last day was spent on prose, not parameters. The commit log on the 35B repository for October 12 is a documentation sprint: add model card at 16:08, update model card at 16:15, rename 35BA3B at 16:23, add metadata at 16:26, absolute asset urls at 16:50, four add get started commits through 17:07, and link LES doc at 17:09. Everything below that line in the history is init. The repository went from eighteen files and no card to a documented release with images, evaluation charts, deployment instructions and a licence, in the space of about an hour.

That matters for how you read the announcement, because a launch post is not the same thing as a launch. Nothing about the checkpoint changed on October 12. What changed is that MiniCPM-V 4.7 stopped being an unexplained upload and became a product you can evaluate on paper.

The two variants, and why they are not the same release

The announcement describes two models, and they are architecturally unrelated below the vision tower — one is a sparse mixture-of-experts, the other a small dense model.

• MiniCPM-V 4.7 35B-A3B — 35.2 billion total parameters as a sparse MoE, 256 experts with 8 active per token, 40 text layers, hidden size 2,048, 16 query heads against 2 key/value heads, 262,144-token maximum position, vocabulary 248,144.

• MiniCPM-V 4.7 1B — a dense qwen3_5_text backbone, 24 layers at hidden size 1,024, 8 query heads against 2 key/value heads, the same 262,144-token context, vocabulary 248,094, single 3.1 GB safetensors file.

• Shared vision tower — minicpmv4_7_vision, 27 layers at hidden size 1,152, patch size 14, image size 980, inserted at layer 6 of the text stack.

• Compression — mixed 4x and 16x visual token downsampling, with the intra-ViT early-compression technique OpenBMB credits to LLaVA-UHD v4; the default is 16x, and 4x is the finer-detail setting.

• Attention shape — a three-to-one repeating pattern in both variants: three linear_attention layers followed by one full_attention layer, ten times over the 40 text layers of the 35B model.

• Licence — Apache-2.0 on both, declared in the card front matter, which is the first time either repository has stated terms at all.

The 35B-A3B is the one the announcement leads with, and it is the one with the interesting engineering story: the whole pitch is that a sparse MoE with 35 billion stored parameters can be made to run smoothly on a phone.

The on-device claim is the actual novelty, and it is a scheduling problem

Anyone who has tried to run a MoE on a handset knows the failure mode. Total parameters live in storage, only a handful activate per token, and on a device without the RAM or bandwidth to hold every expert, weights get paged in and out. The result decodes at a speed that makes conversation impossible. The obvious workaround — lock the router to a fixed expert subset for the whole prompt — makes it fast and quietly strips capability, because tokens can no longer reach experts the model would otherwise have chosen.

OpenBMB's answer is three techniques stacked together, and the card is unusually specific about what each one does:

• Lookahead Expert Scheduling (LES) — a cross-layer routing predictor preloads experts likely to be needed by the next layer, prioritising among the experts the real router actually selected and overlapping their computation with the load of whatever else is still required. The card is careful to say prediction only drives prefetch and scheduling; computation still follows the model's own token-level routing, and experts the prediction missed are loaded and evaluated as normal.

• Fine-grained layer-wise quantization — shrinks expert weight footprint and memory traffic so the load pattern fits on-device memory and bandwidth.

• DSpark speculative sampling — integrates the draft-model path into the device inference loop, alongside scheduling and quantization.

The headline number is 13+ tokens per second on an iPhone 17 Pro Max for the 35B-A3B. That is a vendor measurement, on a device we have not seen, using an app we have not run, and it is the single figure in this release most worth holding loosely until someone outside the lab reproduces it. It is also the claim the entire "first open-source MoE to run smoothly on-device without compromising performance" framing rests on — a claim that is definitionally hard to falsify, because "without compromising performance" is measured against a baseline the vendor chooses.

The part of the card that is genuinely new information: the ecosystem list

Before October 12 there was no published serving recipe at all. The card now names the frameworks the model is expected to work with, and the list is broad enough to be useful regardless of how the benchmarks land:

• Inference — SGLang, vLLM, llama.cpp and Ollama, with a transformers serve path for an OpenAI-compatible local endpoint and an OpenVINO path for Intel CPU, GPU and NPU.

• Fine-tuning — SWIFT and LLaMA-Factory, plus a training recipe OpenBMB calls Self-Replay Fine-Tuning, positioned as a low-cost way to extend capabilities while limiting forgetting.

• Quantization — GGUF, BNB, AWQ, GPTQ and FP8, with separate repositories published for AWQ, GPTQ, int4, FP8 and GGUF variants of the 35B model.

• Hardware — day-0 support claimed for Rockchip, Houmo, Intel, AMD and Arm chip platforms, alongside iOS, Android and HarmonyOS deployment.

• Tooling — a cookbook with task guides for single-image chat, multi-image chat, video, OCR, PDF parsing and visual grounding, plus an edge-deployment repository holding the phone apps.

• Speculative decoding — separate DSpark draft checkpoints for both the 35B and 1B targets.

The practical effect is that MiniCPM-V 4.7 moved from "you would have to write the loader yourself" to "there is a documented path in at least four serving stacks." If you were waiting on the card before spending time on a local trial, the waiting is over; if you were waiting on independent evidence that the on-device numbers are real, it is not.

What the benchmarks do and do not establish

The card's evaluation section is honest about what it is: vendor-reported, not independently reproduced. Two comparison claims are made explicitly, and both are stated as comparisons rather than absolute scores. In Instruct mode, 35B-A3B is claimed to reach a higher overall score in less inference time than Qwen3.6 35B-A3B — a performance-versus-latency claim, not a raw-quality claim. The 1B variant is claimed to improve on MiniCPM-V 4.6's core capabilities and substantially outperform Qwen3.5 0.8B on both overall score and inference efficiency.

Here is the part worth flagging. The actual numbers are not in the text. The evaluation section consists of five linked images — an overall performance chart for the 35B model's vision-language tasks, a language chart, the 1B chart, a performance-efficiency frontier plot, and an on-device speed comparison GIF — and the text around them carries the narrative, not the figures. There is no per-benchmark table in the README, so there is no machine-readable score to quote, and consequently nothing for this article to cite as a number. "Higher overall score than Qwen3.6 35B-A3B" is as precise as the public record currently gets.

Two consequences follow. First, MiniCPM-V 4.7 has no entry on the neutral third-party leaderboards we would normally go to for an audited comparison — no reasoning index, no agentic index, no independently graded multimodal score. Second, the aggregate OpenBMB is plotting is the vendor's own composite across benchmark groups it selected, which means the "higher overall score" claim is only as meaningful as the weighting behind it, and that weighting is not published either. None of this makes the numbers wrong. It makes them unaudited, which is a different thing, and the distinction matters most exactly where the numbers are strongest.

What you can verify yourself, today

Strip the marketing and there is a solid, checkable core, all of it readable from the repository without trusting anyone:

• Weight bytes — sixteen safetensors shards on the 35B model totalling 70,425,903,448 bytes, consistent with a BF16 35.2B checkpoint; the 1B model is a single 3.1 GB file.

• Architecture — every structural figure above is in config.json, published openly, and matches the card's prose.

• Licence — Apache-2.0, declared in the card front matter and now unambiguous. For commercial use, this is the single most important line in the release, and it is new.

• Quantized variants — AWQ, GPTQ, int4, FP8 and GGUF repositories exist and are downloadable, so the deployment story is not theoretical at the weight level.

• Adoption signals — the 35B repository is at roughly 166 downloads and 38 likes as of October 13, a step up from the near-zero figures it carried when it was an unexplained upload but still a small number for a claimed Pareto-frontier release.

What you cannot verify is the claim that carries the release: that this is the first open-source MoE that runs on a phone without giving anything up, at 13-plus tokens per second. That waits on a third party with an iPhone and a stopwatch.

Where a router fits, and where it does not

MiniCPM-V 4.7 is not served by OrcaRouter. It is an open-weights checkpoint, which means the model itself is something you host — on a workstation, on a GPU box, or on the phone the card is aimed at. The place a routing layer earns its keep is on the other side of that arrangement: the point where a self-hosted vision model decides it is out of its depth and hands the hard frame to something bigger. OrcaRouter puts 200-plus hosted models behind one key, passes each provider's list price through at 0% markup so a vendor price change is live the same day, and fails over automatically when a provider degrades — which is the shape a hybrid setup needs, with the cheap local model doing the routine work and a hosted model absorbing the cases it cannot carry.

What to watch next

Three things would turn this release from a documented claim into a settled fact. An independent on-device measurement of the 35B model — someone with an iPhone 17 Pro Max, the published app, and their own timing — would settle the number the whole pitch rests on. A per-benchmark table with actual scores, rather than charts, would let the Pareto claim be checked against the baseline it names. And a run on a neutral leaderboard would put MiniCPM-V 4.7 next to models evaluated under conditions it did not choose. Until then, the honest summary is that OpenBMB shipped a real, Apache-2.0, well-documented model with a credible and unproven efficiency story, and that the difference between those two things is exactly the difference between a card and a benchmark.