MiniCPM-V 4.7 35B-A3B vs MiniCPM-V 4.7: One of These Names Is Not a Model

Search for MiniCPM-V 4.7 and you will find a model card, a benchmark table, a phone demo and a download button. Search for MiniCPM-V 4.7 35B-A3B and you will find the same things, because they are the same release — and that is the entire difficulty of comparing them. OpenBMB's model card opens with the line that settles it: MiniCPM-V 4.7 is the latest model in the series, available in a 35B-A3B variant, and 35B-A3B is the first MoE in that series. The bare name is a banner. The suffixed name is a checkpoint. Put a 35-billion-parameter sparse mixture-of-experts on one side and a banner on the other and you do not have a comparison, you have a question about which artefact you meant to download. Answer that and the rest of this page is a spec sheet.

The names, resolved

Three things answer to "MiniCPM-V 4.7", and only two of them are downloadable.

• openbmb/MiniCPM-V-4.7 — does not exist. The URL returns an authorisation error, not a weights page. There has never been a bare checkpoint under this name, and coverage that quotes one set of figures under the other's label is quoting the 35B numbers under a name with no repository behind it.

• The series — a Hugging Face collection OpenBMB maintains, holding thirteen repositories under the 4.7 banner: the base 35B-A3B checkpoint, a GGUF build, FP8, AWQ, GPTQ and int4 quantisations of it, a paired DSpark speculative draft head, and the same six-way ladder again for the small model. That collection is what "MiniCPM-V 4.7" denotes when it is used as a product line.

• openbmb/MiniCPM-V-4.7-35B-A3B — the checkpoint the announcement is about, created on 7 October 2026 at 07:07 UTC, licensed Apache-2.0, with a full model card added on 12 October. This is the only thing in the family that currently carries vendor benchmark tables.

So the honest answer to "MiniCPM-V 4.7 vs MiniCPM-V 4.7 35B-A3B" is that the question resolves to a variant choice inside one series, and the series name alone will not get you a file. The one file it does get you is the 35B-A3B, which is why readers arrive thinking they are the same thing.

What the launch actually consists of

OpenBMB's own README describes two variants and one shared vision tower, and it dates the release to 12 October 2026 — five and six days after the weights were uploaded. That gap matters if you are citing a release date. The repositories were created on 6 and 7 October; the card, the licence tag, the charts and the announcement all landed on the 12th. The parameters did not move on the 12th. The documentation did.

What the documentation covers, for both variants:

• Two checkpoints — a 35B-A3B sparse MoE and a 1B dense model, sharing a lineage name and a vision tower, and nothing else below it.

• A shared visual path — the family's own minicpmv4_7_vision tower, 27 layers at hidden size 1,152, patch size 14, image size 980, spliced into the language stack at layer 6, with the intra-ViT early compression OpenBMB credits to LLaVA-UHD v4 ahead of it.

• Mixed 4x/16x visual token compression — selectable per request, 16x by default for throughput and 4x for detail. The card notes that no other model in its comparison table offers the choice, and that the setting has to be passed to both the chat template and the generate call or the placeholder count and the vision encoder disagree.

• A deployment story that stops being about weights — iOS, Android and HarmonyOS targets, day-0 chip support from Rockchip, Houmo, Intel, AMD and Arm, OpenVINO for Intel CPU/GPU/NPU, and framework support across SGLang, vLLM, llama.cpp and Ollama. The app and the quantised builds are the product here, not the BF16 download.

The two checkpoints, dimension by dimension

Six dimensions, both sides, with a note on what each number is actually worth.

• Parameters and shape — MiniCPM-V 4.7 35B-A3B: 35,212,875,824 stored parameters, sparse, 256 experts with 8 active per token at an expert intermediate size of 512 plus a shared expert of the same size. MiniCPM-V 4.7's 1B variant: 1,554,476,272 parameters, dense, every one of them active on every token. The two totals are not the same quantity, and the MoE's active-per-token budget is not published, so read the "A3B" as part of the name rather than as a measurement you can compare against the dense model.

• Download footprint — MiniCPM-V 4.7 35B-A3B: 70.4 GB spread over sixteen safetensors shards in BF16, before any KV cache. MiniCPM-V 4.7 1B: roughly 3.1 GB in a single weights file. Twenty-two times the download on one side, and the honest measure of which of these is a handset model out of the box — neither is, until you take a quantisation from the ladder.

• Text backbone and depth — MiniCPM-V 4.7 35B-A3B: a Qwen-family sparse MoE text stack, 40 layers at hidden size 2,048, sixteen query heads against two key/value heads, vocabulary 248,144. MiniCPM-V 4.7 1B: a dense Qwen-family text stack, 24 layers at hidden size 1,024, eight query heads against two key/value heads, vocabulary 248,094. The same design idea, one rung down.

• Attention — both: a fixed three-to-one repeat of linear attention to full attention. Thirty of the 35B's forty layers take the linear path against ten conventional; eighteen of the 1B's twenty-four against six. This is the dimension where the two models are genuinely the same architecture scaled, and it is the reason both carry a 256K context without the KV cache exploding.

• Context — both: 262,144 maximum positions, with the same canvas multimodal rotary embedding mode. No variant tax, no truncation on the small model.

• Licence — both: Apache-2.0, declared in the repository front matter and asserted in the README. Both also ship on Hugging Face and on ModelScope. There is no terms difference to weigh.

The benchmark table exists for one of them

Here is the asymmetry that actually shapes a decision. The 35B-A3B checkpoint carries OpenBMB's comparison tables — MMMU around 80.2, OCRBench around 91.2, OmniDocBench v1.6 in the high nineties, CharXiv reasoning in the mid-seventies, TextVQA in the mid-eighties — set against two 35B-A3B-class Qwen models, a 31B Gemma and two 27B Qwens, in Instruct mode. This article covered what those tables are worth when the release was documented; the short version is vendor-reported, vendor-harnessed, unreproduced, and drawn from PNG charts rather than a published score table.

The 1B has its own chart in the same document, and the comparison there is against a smaller field. If you are choosing between the two sizes, the useful thing the cards give you is not a score — it is that the larger checkpoint is the one the efficiency argument was written for. The on-device number that anchors the whole release, 13-plus tokens per second at roughly 3 GB of memory on an iPhone 17 Pro Max, is a 35B-A3B figure, produced with Lookahead Expert Scheduling prefetching experts across layers through quantised weights. The small dense model does not need that machinery, because 1.55 billion dense parameters fit in a phone's working memory without any of it.

That is the inversion worth sitting with: the small model is straightforward and undocumented in benchmark terms; the large model is heavily documented and hard to run. Neither position is obviously better.

Which one people actually download

The Hugging Face counters add a fact neither model card states, and it argues for the larger model. Read on 13 October 2026, the base openbmb/MiniCPM-V-4.7-35B-A3B repository shows 630 downloads; the -gguf build of the same checkpoint shows just over 10,000, roughly sixteen times the traffic. For the 1B, the base repository and its GGUF build sit at 263 and 2,064 respectively, a similar ratio at a much smaller absolute scale.

Two readings, both consistent with the data. Either people are pulling the quantised build first because that is what runs, or the BF16 numbers simply lag because the BF16 checkpoint is not what anyone deploys. Either way, the download counter is measuring which artefact matters — and it is not the one whose size is in the name. If you are sizing this decision, size it against the GGUF or the AWQ build, not against 70.4 GB.

There is one more listing detail that runs the other way. Both repositories carry the "On-Device Model" tag inherited from the rest of the MiniCPM-V family, which on a 70 GB BF16 MoE means what the tag means on the 1B's 3.1 GB file only after quantisation and expert streaming. Treat the tag as a family label, not a specification.

Where a hosted API changes the question

Neither checkpoint is hosted on OrcaRouter, and for this comparison that turns out to be the deciding structural fact. Both are open weights you serve yourself, which means the 35B-A3B requires hardware you probably do not have and the 1B requires hardware you definitely do — and the gap between "some GPU" and "a phone" is the real content of "35B-A3B vs 4.7".

The place a router earns its keep is the boundary. If you pick the 1B and it is not enough for a request, the work has to go somewhere, and the somewhere is usually a hosted model you would rather not manage provider by provider: OrcaRouter covers a couple of hundred hosted models behind one key at each provider's list price with nothing added on top, and fails over between providers when one degrades. One of those hosted ids, qwen/qwen3.6-35b-a3b, is the direct hosted counterpart to the checkpoint this article is about — the same 35B-A3B shape, accessible without owning the accelerator, which makes it the natural ceiling to test against before committing 70 GB of your own disk to the local version.

That is a routing decision, not a second integration, and it is the one part of this choice that costs nothing to reverse.

The pick

If the constraint is a phone, a laptop or a single small GPU, the 1B is the only candidate — 3.1 GB, a licence that permits commercial use, and a quantisation ladder that has been shipping since the first week. If the goal is the efficiency result OpenBMB is actually arguing about, you want the 35B-A3B, and you want it in a quantised build rather than the 70 GB original, because that is what every other downloader has taken and what the on-device claim was measured on.

What you should not do is treat the two names as interchangeable. One of them is a checkpoint you can run this afternoon. The other is a label that will keep returning the 35B-A3B's model card no matter which of the two you meant.