MiniCPM-V 4.7's "3B Active Parameters" Is Not in the Model Card — I Measured It From the Weights

The most repeated number about MiniCPM-V 4.7 35B-A3B is not printed anywhere in its own documentation. The claim — "only 3B active parameters (!) — it runs even on an iPhone" — comes from a third-party post on 13 October 2026, and the vendor's model card, repository README and launch notes never state an active-parameter figure at all. That is not a criticism of the claim so much as a gap worth closing: the checkpoint encodes its own answer. So, before anything else here, I pulled the safetensors index and every shard header for openbmb/MiniCPM-V-4.7-35B-A3B and counted. For comparison, the other model in the same post — Qwen3.8-27B, released 13 August 2026 — is a dense 27B and has no such ambiguity to resolve: every parameter is active on every token. The interesting question is whether "3B active" survives contact with the weights, and the answer is: it survives, but only if you define the word "active" the vendor's way, and the honest number is closer to 4B once you count the parts you cannot avoid running.

The ledger, read from the checkpoint itself

The index file lists 40 language layers plus a vision tower and a projector, 35,212,875,824 parameters in total in BF16 — 70.43 GB of weights to download. That matches the "35B" in the name. The MoE question is what fraction of that is touched per token:

• Total stored — 35.21B parameters, 70.43 GB at BF16. Every expert is on disk whether or not it is used.

• Router budget — 8 experts selected per token, out of 256, per MoE layer. Configured in config.json as num_experts_per_tok: 8. Each expert is small: 3.15M parameters.

• MoE path per layer — 8 experts (25.17M) + a shared expert (3.15M) + the router gate (0.52M) ≈ 28.83M.

• Attention path per layer — the architecture is hybrid: 30 of the 40 layers use linear attention (33.72M each), 10 use full attention (27.26M each). Total ≈ 2.44B across all 40 layers for attention plus MoE arithmetic, repeated per token.

• Plus what you cannot skip — token embeddings 508.2M, LM head 508.2M, vision tower 522.3M, projector 30.7M.

• The two defensible answers — ~2.44B active on the attention-and-MoE path alone; ~4.01B if you count embeddings, output head, vision tower and projector, which a vision request does exercise.

So "3B active" is not wrong. It is a rounding of 2.44B upward, and it lands in the gap between the two numbers above. It just isn't a figure OpenBMB published, and it is not the same thing as the "A3B" suffix — that suffix is part of the model's name, and the vendor's own materials never turn it into a measurement.

Why the suffix and the number are not the same thing

Naming conventions across the open-weights ecosystem imply an active-parameter count: a model called 30B-A3B, or 235B-A22B, is telling you it activates roughly that many parameters per token. The implication is usually reliable — but it is a convention, not a contract, and MiniCPM-V 4.7 is a case where nothing in the card, the README or the launch post converts the "A3B" into a number you can plan memory around. Until someone counts, the suffix is a label.

The count above is arithmetic, not inference from that label. It is also the reason the ~2.44B and ~4.01B figures differ: whether you count the embedding table and the output head is a real decision, not pedantry. On a dense model, embeddings are a small slice of a 27B budget. On a sparse model where the per-token compute path is only a few billion parameters, a 508M embedding table and a 508M LM head are no longer noise — together they are about a fifth of the active path, and they are stored at full width while the experts are quantised.

One consequence worth stating plainly: the ratio of stored to active parameters here is about 8.8 to 1 on the narrow reading. That is the whole reason a 35B model can be pitched as a phone model, and it is also the reason it is not one in the way a 3B dense model is. Storage does not shrink when the router ignores an expert.

The iPhone claim is a separate claim with a separate evidence base

Everything concrete about on-device performance in this release is vendor-reported and unreproduced. The specific figure is 13+ tokens per second at about 3 GB of memory on an iPhone 17 Pro Max, with the same checkpoint demonstrated on an iPad M4. OpenBMB attributes it to three techniques working together — Lookahead Expert Scheduling, which predicts cross-layer routing and prefetches experts, fine-grained layer-wise quantisation, and DSpark speculative sampling — and describes the result as the first open-source MoE model to run smoothly on-device without losing capability. There is no independent measurement of that throughput in the public record, no third-party reproduction, and no published breakdown of which quantisation the 3 GB figure assumes.

This matters for a specific reason: 3 GB is the number that determines whether the claim is interesting to you, and it is the number we know least about. A 35B MoE whose expert weights mostly sit on flash storage is not a 3 GB model, it is a model whose resident working set happens to fit in 3 GB once routing predictions, prefetch, and a quantised expert cache are all doing their job. Those are exactly the conditions under which benchmark throughput and real-world throughput diverge — the first prompt warms the cache, and the behaviour that gets you 13 tokens per second on a demo is a schedule, not a property of the weights.

Treat the 13 tokens per second as a claim about a technique, not about the checkpoint. The checkpoint is what you can verify today: 35.21B stored, 8 of 256 experts routed per token, ~2.44B to ~4.01B active depending on what you count, Apache-2.0, day-0 quantisations in GGUF, AWQ, GPTQ, int4 and FP8, and a vendor list of supported chips that includes Rockchip, Houmo, Intel, AMD and Arm.

What the active count does and does not decide

An active-parameter count is a compute proxy. It tells you how much matrix multiplication happens per token, which maps to how fast a GPU-bound decode runs. It does not tell you how much memory you need to hold the model, which is governed by the total — 70.43 GB of BF16 weights, or roughly a quarter of that at 4-bit, before you account for a KV cache. On a 256K-context model, that cache is not a rounding error either.

• Decode speed — governed by active parameters (~2.44B–4.01B here). This is what the 13 tokens/s claim is about.

• Resident memory — governed by total parameters (35.21B stored), then cut by quantisation and by whatever expert set stays resident.

• Storage and load — governed by the full 70.43 GB at BF16. Sparse routing does not reduce the download.

• Bandwidth, not flops — on a phone the binding constraint is getting experts through a memory bus, which is why the scheduling technique exists and why an active count alone predicts nothing about mobile latency.

The practical upshot: if you have a GPU with enough memory to hold the quantised weights, the active count is what determines your throughput and "3B active" is a good thing. If you are the reason the phrase "runs on an iPhone" appears in a post, the total count is the number that decides feasibility, and the vendor's scheduling work is the part that makes the total count livable. Both readings of the same headline are correct and they are not the same reading.

The comparison in that post needs two labels, not one

The framing that made this go around was local versus expensive hardware: MiniCPM-V 4.7 35B-A3B as the model that gets you the same capability without the rig, against Qwen3.8-27B as the model that was smarter but needed the rig. The capability half of that comes from Q​wen's own model card, and it is vendor-reported like everything else on this page. Q​wen's published numbers for Qwen3.8-27B include 90.3 on LiveCodeBench v6, 89.2 on GPQA Diamond, 84.3 on OSWorld-Verified and 79.0 on QwenSWEBench, and our own catalogue entry for it notes those as unusually strong agentic and coding results for a 27B dense model. Whether it was "smarter than Opus 4.6" is a claim from the social post, and I have no independent evaluation in front of me that settles it — so I am not going to restate it as fact.

The structural difference is the one that is actually checkable: Qwen3.8-27B is dense, so its 27B parameters are all active and its memory footprint and its compute bill are the same number. MiniCPM-V 4.7 35B-A3B splits those two numbers apart by roughly a factor of nine. That is the whole architectural argument, and it is real. It is just not the same as a benchmark comparison, and the post that made it famous blended the two.

Where a router changes the decision, and where it does not

Two things are true here and worth separating, because they point in opposite directions.

The first is that we do not serve MiniCPM-V 4.7. It is not in our catalogue. If you want it, the path is your own hardware — which is exactly what the release is designed for, with weights, quantisations and on-device deployment guides published alongside it. Nothing about a hosted API helps you run a model on a phone, and it would be misleading to suggest otherwise.

The second is that the model this one is being measured against is not in that position. Qwen3.8-27B is available through our API, self-hosted on our own infrastructure, at $0.33 per million input tokens and $2.40 per million output tokens. If the question you are actually asking is "do I replace my hosted Qwen3.8-27B calls with a locally deployed MiniCPM-V 4.7," the honest version of the answer is that you should run the experiment before you commit: the on-device throughput figure is unreproduced, and the capability comparison is the other party's own card. That is the situation failover exists for — route a fraction of traffic at a new path, keep the proven one behind it, and let a bad week cost you a fraction of a workload rather than the workload. A 0% markup model also keeps the arithmetic honest: when a vendor changes a price, the number you pay moves the same day, because there is no margin layer between their list price and your invoice.

What a router cannot do is make the local-versus-hosted question disappear. That one is decided by your hardware, your privacy constraints and whether a 70 GB download is acceptable — and the active-parameter count, however you round it, does not change any of the three.

What would settle it

Three things, in descending order of usefulness. An active-parameter figure published by OpenBMB, so that the number everyone repeats stops being a third party's arithmetic — mine included, and mine is reproducible from the shard headers if you disagree with it. An independent measurement of the 13 tokens per second on a phone, with the quantisation settings stated, because a schedule-dependent figure without its settings is not a specification. And a real evaluation comparing MiniCPM-V 4.7 35B-A3B against Qwen3.8-27B on the same tasks, since the comparison that made this model notable is currently one vendor's chart against another vendor's card.

Until then, the safe summary is narrower than the post: the weights are real, the sparsity is real, the download is 70.43 GB, and per token the model does somewhere between 2.4 and 4 billion parameters worth of work depending on how you count the parts you cannot route around. That is a genuine engineering result. It is not yet a measured phone benchmark, and it is not a benchmark win over a dense 27B.

Sourcing: parameters, expert counts, layer types, context length and download size were read directly from config.json and the safetensors shard headers of openbmb/MiniCPM-V-4.7-35B-A3B on 13 October 2026. On-device speed, memory figure, benchmark results and the Qwen3.8-27B evaluation numbers are vendor-reported and unreproduced. The "3B active parameters" and "smarter than Opus 4.6" claims originate with a third-party social post, not with either vendor.

None of that is hypothetical: the documented AI failures and agent incidents that a number like this one gets cited in are collected in the OrcaRouter AI Incident Archive , where each entry carries its own sources, severity, confidence grade and disputed flag.