A Voxel Pagoda, 10% Fewer Tokens, and the One Sentence OpenBMB Actually Stands Behind

The most-quoted sentence about MiniCPM-V 4.7 35B-A3B this week is not in its model card. It is a tweet, posted on 13 October 2026, that reads: "MiniCPM-V 4.7 35B-A3B not only used fewer tokens, but also produced a better voxel pagoda than Qwen 3.6 35B-A3." The demonstration it points at is a video of two language models each writing the code for a 3D voxel Japanese pagoda, rendered side by side. It is a genuinely interesting artefact — it shows a vision-language model reproducing a built structure in three dimensions from an image prompt, which is a harder task than captioning one. But it is worth separating what that tweet is from what it is not, because three different claims have been fused into one line, and they have three different levels of backing. MiniCPM-V 4.7 35B-A3B is a real checkpoint from OpenBMB and it is roughly a week old; Qwen3.6-35B-A3B is a nine-month-old open-weights rival, also Apache-2.0, also a sparse mixture-of-experts at the same headline size. Everything below is about which of the efficiency claims around them is checkable, and which is a JPEG of a chart.

Three claims wearing one sentence

The tweet bundles three separable things, and they deserve separating because only one of them is documented.

• "Used fewer tokens" — this is a measurable statement about token consumption for one task. The figure circulating alongside the demo is 10% fewer tokens than Qwen3.6 35B-A3B. That number comes from the third-party creator who ran the comparison, not from OpenBMB's evaluation, and it is a single prompt pair, not a benchmark.

• "Produced a better voxel pagoda" — this is a judgement, made by looking at two rendered pagodas. There is no rubric, no scoring harness, and no independent party. It is the kind of claim a human makes in three seconds and a benchmark cannot make at all, because "better pagoda" has no ground truth.

• "Efficiency plus quality is the real battleground" — that part is a thesis, and it happens to be the one OpenBMB does argue in writing, with numbers attached, in the model card. It is just not the sentence that travelled.

This matters because the first two claims are the memorable ones and the third is the defensible one. If you are deciding whether to spend 70 GB of download on a checkpoint, you want the third.

What OpenBMB actually wrote, and when

The timeline first, because it has been compressed by retelling. The weights went up quietly: openbmb/MiniCPM-V-4.7-1Bwas created on 6 October 2026 at 17:40 UTC,openbmb/MiniCPM-V-4.7-35B-A3Bon 7 October at 07:07 UTC. Neither carried a model card, a licence tag or a benchmark at that point — this was covered here at the time, and it was an odd state of affairs for a 35-billion-parameter upload. Six days later, on 12 October 2026, OpenBMB committed the documentation in one sitting: model card, Apache-2.0 licence, evaluation charts, a rewritten repository README leading with the new series, and an announcement. The parameters did not change that day. The explanation did.

So the honest framing is not "MiniCPM-V 4.7 35B-A3B launched this week." It is "MiniCPM-V 4.7 35B-A3B became legible this week." Everything about it that is now citable was either uploaded on the 6th and 7th but undocumented, or written on the 12th and is a vendor claim.

The claim the model card does make

Here is the sentence, verbatim from the card, and it is narrower than the tweet: in Instruct mode, the 35B-A3B variant "achieves a higher overall score in less inference time than Qwen3.6 35B-A3B." That is it. No token count, no margin, no per-benchmark breakdown in prose. The evidence behind it is a scatter plot — average evaluation score on the vertical axis, inference time in seconds on a log scale on the horizontal — on which MiniCPM-V 4.7 35B-A3B sits above and to the left of Qwen3.6-35B-A3B. The chart's own footnote defines the average as the mean of five benchmarks: MMStar, MMMU-Pro, CharXiv reasoning, BLINK and MathVista. Circles denote Instruct mode, diamonds denote Thinking mode.

That is a real and specific claim about a two-dimensional tradeoff, and it is the strongest thing in the release. It is also worth noting what the chart cannot tell you: there are no numeric labels on the plotted points, so you cannot read off a score or a time, only a direction. The direction, as drawn, favours MiniCPM on both axes at once.

And it was measured by the vendor. The card's evaluation figures carry the line "Results are from public reports and our local evaluation using official checkpoints." Local evaluation means OpenBMB's hardware, OpenBMB's harness, OpenBMB's mode selection. That is a normal thing for a model card to do and an abnormal thing to launder into fact. No independent party has run these two checkpoints against a shared harness. No leaderboard has indexed either result. As of this writing the claim has exactly one source, and the source sells the model.

Where the token efficiency is supposed to come from

The efficiency argument does not rest on the benchmark chart. It rests on three engineering choices, and they are worth understanding because they determine whether the win transfers to your hardware or not.

• Lookahead Expert Scheduling (LES) — the headline technique. A sparse mixture-of-experts stores far more parameters than it activates per token, and on a device that cannot hold every expert in memory, the weights get paged in and out and decoding stalls. LES uses cross-layer routing prediction to preload experts likely to be needed by the next layer, and prioritises computation for experts the real router actually selected that happen to be already loaded. OpenBMB is careful to state that the prediction drives prefetching and scheduling only; the model's token-level routing is unchanged, and experts the predictor missed are still loaded and evaluated. The card claims a 5× speedup on real devices from this, with no capability loss.

• Fine-grained layer-wise quantization — shrinks the expert weight footprint and the memory traffic, which is the other half of making an on-device load pattern fit.

• DSpark speculative sampling — a paired draft-model path, published separately as openbmb/MiniCPM-V-4.7-35B-A3B-DSpark, and integrated alongside the scheduling and quantization work.

Stacked, these produce the release's marquee number: 13-plus tokens per second using roughly 3 GB of memory on an iPhone 17 Pro Max. That is a vendor figure, on vendor hardware, with vendor software — an app OpenBMB wrote. It is the kind of claim that is either the whole product or nothing at all, and there is currently no way for anyone outside the company to check it, because reproducing it requires the on-device stack the phone demo runs.

Token efficiency is real, but it is a matrix here, not a scalar

There is a detail in this release that has been flattened out of every summary of it, and it is the one that actually governs the token economics.

• MiniCPM-V 4.7 35B-A3B supports mixed 4x and 16x visual token compression, selectable per request. The 16x setting merges visual tokens for speed; 4x keeps four times as many, for detail. The card's default is 16x, and the parameter has to be passed to both the chat template and the generate call or the placeholder count and the vision encoder disagree.

• The vendor's own vision-language comparison table records the compression setting used for each model's row. In that table, the MiniCPM-V 4.7 35B-A3B row is at 4x — the detail-preserving setting, i.e. the expensive one — and the Qwen3.6 35B-A3B row is at 16x. A 31B Gemma 4 row is listed at 9x; the two 27B Qwen rows at 4x.

• A footnote states plainly that MiniCPM-V 4.7 supports either setting while the other models in the table support only a fixed compression ratio.

Read that together and the picture changes. If the MiniCPM row is drawing its vision-language scores at the token-hungry setting while the Qwen row is drawing its scores at the token-thrifty one, then the two columns are comparing different amounts of visual detail, and the efficiency story is not "same input, fewer tokens" — it is "adjustable input, and here is the column that wins on quality." That is a more interesting and more honest claim than the tweet's, and OpenBMB published it in a footnote rather than leading with it.

It also means the number you actually care about — tokens per unit of visual detail — cannot be read off this table at all. It requires running both models at the same setting, which nobody has published.

The table, with the caveats attached

The card ships two vendor tables, one for vision-language and one for language, both in Instruct mode, both against a field that includes two 35B-A3B-class Qwen models, a 31B Gemma and two 27B Qwens. The figures below were read off the vendor's own PNG chart, and the caveat is structural: the numbers exist only as pixels in that chart, not as a table, so what follows was extracted by machine reading and small transcription errors are possible.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91.20 against Qwen3.6 35B-A3B at 90.40. A 0.8-point gap, on the vendor's own run.

• OmniDocBench v1.6 — approximately 98.2 for MiniCPM against approximately 93.3 for the Qwen model, which is the largest single gap in the table and the one that would matter most if it reproduced, since document parsing is where token budgets are usually spent.

• MMMU — approximately 80.2 against 80.0, a dead heat at the resolution of a chart image.

• MMMU-Pro — approximately 69.7 against 67.7, on a row where a 27B Qwen sits higher than both.

• Language table — the same shape, with the more striking cells on instruction-following and code. IFBench is listed around 47.7 against 35.3, and LiveCodeBench-v6 around 97.0 against 54.3. Those two are large enough that they should be treated as the least credible cells in the release until someone else runs them: a 43-point spread on a code benchmark between two similarly-sized open MoE models, measured by one of the two parties, is a claim that needs a second instrument.

Vendor-reported, vendor-harnessed, unreproduced. That is the whole of it. If these figures hold up under an independent harness, the Pareto-frontier claim is correct and the pagoda video is a footnote. If they do not, the pagoda video is all there is.

What the adoption numbers say, which is nothing about quality

One number in this comparison is not contested by anyone, and it is not a benchmark. The Hugging Face download counter, read on 13 October 2026, shows 630 for openbmb/MiniCPM-V-4.7-35B-A3Bagainst roughly 3.6 million forQwen/Qwen3.6-35B-A3B— a repository created on 15 April 2026 and therefore sitting about nine months further along the adoption curve. That gap measures time, not merit, and it is the reason the efficiency question is being asked in this direction at all: the newcomer has to argue on a per-token basis precisely because it has not had nine months to be the default.

There is also a small internal contradiction in the listing worth flagging. The repository carries the "On-Device Model" tag inherited from the rest of the family, and a 35.2-billion-parameter sparse MoE in 70.4 GB of BF16 weights is not on-device in any sense a downloader would recognise. The on-device story is real, but it runs through quantisation and expert streaming on top of the checkpoint, not through the checkpoint. Budget against the quantised build and the app, not against the tag.

What to do about it this week

The practical position is narrow and clear. If you want the efficiency claim verified, there is nothing to verify yet — it is one vendor's chart, and the one number with a per-task figure attached (10% fewer tokens, one pagoda) comes from a third party's single demo. If you want to run the model, the weights are Apache-2.0, the architecture is documented, and the downsampling setting is yours to choose, which is a genuine and underappreciated lever: 16x when throughput matters, 4x when the chart is showing you a document.

One half of this comparison is reachable through a hosted API today and the other is not, and it is worth being precise about which is which. qwen/qwen3.6-35b-a3bis a hosted model on OrcaRouter — it sits in the catalogue behind one key, at Qwen's own list price with nothing added on top, dispatching to whichever provider is healthy rather than to one you pinned. MiniCPM-V 4.7 is not hosted by us; it is an open-weights checkpoint you serve yourself. That asymmetry is the useful thing here. You can put the Qwen side of this comparison into a baseline this afternoon, run OpenBMB's harness on your own data against it, and let the vendor's chart be the hypothesis rather than the answer.

Which, given that the entire argument is about efficiency on your hardware, is the only measurement that was ever going to settle it.