MiniCPM-V 4.7 1B vs MiniCPM-V 4.7: Two Checkpoints, One Name, and a Very Different Job

There is no checkpoint called MiniCPM-V 4.7. OpenBMB has never published one, and the model URL that would hold it returns an authorisation error rather than a weights page. The name is the series. On 12 October 2026 that series shipped two things that a reader could reasonably mean by it: MiniCPM-V 4.7 1B, a dense 1.55-billion-parameter model built to sit in a phone's working memory, and the 35-billion-parameter sparse mixture-of-experts checkpoint that carries every headline claim in the launch — the on-device demo, the Pareto-frontier chart, the phrase "first open-source MoE to run smoothly on-device." Comparing them is not a fair fight and was never meant to be one. It is a question about how much memory you are willing to spend, and about whether the vendor's own numbers are strong enough to justify spending it.

The name is a series, not a model

Two repositories carry the MiniCPM-V 4.7 name, and a third carries it with a suffix. openbmb/MiniCPM-V-4.7-1B was created on 6 October 2026 at 17:40 UTC. openbmb/MiniCPM-V-4.7-35B-A3B followed on 7 October at 07:07 UTC. openbmb/MiniCPM-V-4.7-1B-DSpark — a 213-million-parameter speculative draft head for the small model — landed on 8 October. All three are Apache-2.0. The bare openbmb/MiniCPM-V-4.7 repository does not exist, and it is worth saying that plainly because a fair amount of coverage writes as though it did and quotes one set of numbers under the other's name. The OpenBMB README dates the release itself to 12 October, which is the date to use if you need one: the repositories were uploaded first and announced four days later, in the ordinary order.

So the honest framing of "1B vs 4.7" is not a comparison between a small model and a large one with the same name. It is a comparison between the two size classes the series actually offers, where one of them happens to be the only one the series name alone will find.

What the 1B actually is

Read from the safetensors metadata, the dense checkpoint is 1,554,476,272 parameters in BF16 — about 3.11 GB in a single weights file, which is the headline number for anyone thinking about a handset. Its language backbone is tagged qwen3_6_text, 24 layers deep with a hidden size of 1024, and its attention runs a three-linear-to-one-full pattern: 18 of the 24 layers take a linear path and six run conventional attention. Vocabulary is 248,094 tokens. The vision tower is the lineage's own minicpmv4_7_vision — 27 layers, hidden size 1152, patch size 14, image size 980, inserted into the language stack at layer 6. Two settings matter more than the rest for document work: downsample_mode is 16x, and mrope_mode is canvas, which is the multimodal rotary embedding scheme the family uses to keep spatial structure intact across a sliced image. Maximum position embeddings are 262,144, so the context window is a genuine 256K rather than a nominal one.

At the time of writing the repository shows 14 downloads and 22 likes. That is small, and it is the honest measure of how much the community has exercised the model so far.

What the flagship actually is

The 35B-A3B checkpoint is 35,212,875,824 parameters in BF16 — 70.4 GB spread across sixteen safetensors shards, which is 22 times the size of the dense model in a single download. Architecturally it is a different animal: 40 layers, hidden size 2048, and a sparse MoE feed-forward with 256 experts of which 8 are active per token, with moe_intermediate_size set to 512. Vocabulary is 248,144, slightly wider than the 1B's. The attention pattern is the same idea at greater depth — 30 linear layers to 10 full ones. It is the first MoE in the MiniCPM-V line, and it is the checkpoint the vendor's efficiency story is actually about: OpenBMB's claim is 13-plus tokens per second using roughly 3 GB of memory on an iPhone 17 Pro Max, with Lookahead Expert Scheduling prefetching expert weights across layers so that sparse routing does not stall on memory bandwidth, plus a paired MTP head and mixed 4x/16x visual token compression. Those are vendor figures, measured by the vendor, on the vendor's demo. Nobody else has reproduced them yet. The repository shows 166 downloads and 43 likes — an order of magnitude more attention than the 1B has drawn.

The comparison, dimension by dimension

Six dimensions, both sides, with a note on how much weight each number carries.

• Parameters and shape — MiniCPM-V 4.7 1B: 1.55B dense, every parameter active on every token. MiniCPM-V 4.7's flagship: 35.2B total, sparse, 8 of 256 experts per token. The two totals are not comparable quantities; the active budget of the MoE is what determines per-token compute, and OpenBMB does not publish it. Read "A3B" as part of the name, not as a measurement.

• Weight footprint — MiniCPM-V 4.7 1B: 3.11 GB in one BF16 file, which is the whole reason it exists. MiniCPM-V 4.7 35B-A3B: 70.4 GB across sixteen shards in BF16. The vendor's 3 GB on-device figure applies to the larger model only after quantisation and expert streaming, not to the raw download.

• Attention and context — both: 256K positions, a 3:1 linear-to-full attention pattern, and the same canvas mRoPE mode. MiniCPM-V 4.7 1B runs it over 24 layers; the flagship over 40. This is the one dimension where the two models are genuinely the same design, scaled.

• Vision path — both: the family's own minicpmv4_7_vision tower with 16x downsampling. The difference is on the other side of the compression step: the flagship's charts advertise a 4x/16x mixed scheme that the 1B does not claim.

• Licence — both: Apache-2.0, declared in the repository and asserted in the project README. This matters because it is the opposite of what the same series looked like a week earlier; there is no ambiguity to report here for either checkpoint.

• Evidence of quality — MiniCPM-V 4.7 1B: vendor charts only. MiniCPM-V 4.7 35B-A3B: vendor charts, a vendor demo video on an iPad M4 and an iPhone, and a published on-device tokens-per-second claim. Neither has an independent evaluation, and neither has been benchmarked by a third party against a fixed harness.

What the vendor's own charts claim

OpenBMB published benchmark charts for both checkpoints, and the difference in what they can support is instructive. The 1B chart places the model at MMBench 83.17, OCRBench 86.10 and OmniDocBench v1.6 85.39, ahead of the previous-generation 1.3B-class model it sits next to in the same figure on all three (81.89, 83.80, 82.52 respectively). Those are vendor-reported and unreproduced, and the chart's own column labelling has to be read carefully, because one row in it prints a value that is not credible for a model of this size. Treat the absolute numbers as marketing and the deltas against the previous generation as the only part with an internal logic.

The 35B-A3B chart is more legible because the comparison is more crowded. It reports MMMU 80.22, MathVista 88.00, OCRBench 91.20, OCRBench_v2 68.47, OmniDocBench v1.6 94.24, CharXiv reasoning 75.60, TextVQA 84.99 and CCOCR 81.14, against a field that includes two 35B-A3B-class mixture-of-experts models, a 31B Gemma and a 27B Qwen3.8. On the vendor's own numbers the MoE wins most rows narrowly and loses a couple — MMMU-Pro and MathVision go the other way. Again: vendor-reported, unreproduced, and the only fair reading is "the vendor believes it is at parity or better," not "it is at parity or better."

There is a labelling problem worth flagging rather than resolving. The repository is named 1B. The Hugging Face sidebar describes the model as 2B parameters. The safetensors metadata says 1,554,476,272 — about 1.55B. The vendor's own chart labels the row 1.3B. Four sources, four numbers, and the smallest of them is in the chart the marketing points at. None of this changes what the model does, but if you are budgeting memory against a spec sheet, budget against the 3.11 GB file rather than any of the labels.

Which one you actually want

If the constraint is a phone, a laptop, a single small GPU, or anything with a power budget, only one of these is a candidate. MiniCPM-V 4.7 1B exists precisely so that a 256K-context multimodal model fits in a few gigabytes, it ships under a licence that permits commercial use, and the quantisation ecosystem is already there — GGUF, AWQ, GPTQ, int4 and FP8 builds, plus first-day support from Rockchip, Houmo, Intel, AMD and Arm hardware vendors and OpenVINO. For on-device OCR, screenshot understanding and document parsing at a 3 GB footprint, it is the version of this series that answers the question.

MiniCPM-V 4.7 35B-A3B answers a different one. It is not a larger version of the same product; it is the attempt to keep the quality of a 35B-class model while only paying for 8 experts per token, and if the vendor's throughput claim holds up it is the more interesting engineering result of the two. It is also, at 70.4 GB in BF16, a server or workstation download, and its on-device story runs through quantisation and expert streaming rather than through the file you get from the Hub.

Where a router fits, and where it does not

Neither checkpoint is hosted on OrcaRouter. MiniCPM does not appear in our catalogue at all, and the correct advice for anyone who wants to run either of these is to download the weights and serve them yourself — llama.cpp, Ollama, vLLM or SGLang all support the architecture, and the day-one support list above is unusually broad for a release this young. The routing question only arrives at the next step, which is what happens when a small local model is not enough for a particular request and the work has to go to something hosted. That handoff is a routing decision rather than a second contract: OrcaRouter puts a couple of hundred hosted models behind one key at each provider's list price with nothing added on top, with failover when a provider degrades. Among the hosted vision models on that list are several in the same weight class as the 1B — qwen/qwen3-vl-8b-instruct and its thinking variant, qwen/qwen3-vl-235b-a22b-instruct for the heavy end, and deepseek/deepseek-v4-flash-vision-exp for long-context document work. That is the tier above this family, not a replacement for it, and it is worth being clear which side of the line each model sits on.

What to watch

Two things will settle this comparison and neither exists yet. The first is an independent evaluation — the same harness run against both checkpoints, on the same hardware, without the vendor choosing the prompts. Until that appears, every accuracy number in this article is the vendor's own and should be quoted with that attached. The second is the DSpark draft head, which is already published for the 1B and is the mechanism that would make small-model inference meaningfully faster on a phone. If speculative decoding works as advertised at this scale, the dense 1B becomes a considerably better answer than its size suggests, and the 35B-A3B remains the model you reach for only when the request genuinely needs it.

What does not need to wait on anything is the licence, the architecture, the footprint and the tooling. Those are in the repositories, they are Apache-2.0 for both checkpoints, and they are enough to decide today which of the two belongs on your hardware.

The hosted half of that pattern is a routing decision rather than a second contract. each provider's list price with no markup added by us Neither MiniCPM-V 4.7 checkpoint is a hosted model on OrcaRouter - both are weights you serve yourself.