MiniCPM-V 4.7-35B-A3B-DSpark: OpenBMB's 389M Draft Lands With a Card Its Base Model Never Got

MiniCPM-V-4.7-35B-A3B-DSpark is a 389,223,169-parameter draft model. It does not answer questions, it does not see images, and on its own it is useless. Its entire job is to guess the next fifteen tokens so that MiniCPM-V-4.7-35B-A3B can verify a whole block in one forward pass instead of generating one token at a time. That is speculative decoding, and OpenBMB shipped a draft for its new 35B vision-language model eleven days ago without saying a word about it publicly.

What makes it worth a page is not the draft. It is the paperwork that came with it. The DSpark checkpoint has a model card: a licence, a spec table, a training recipe, and an acceptance-length table for seven task categories. Its 35-billion-parameter parent had none of that when it appeared. So for the first time, there are actual numbers attached to a MiniCPM-V 4.7 release — and they are numbers about the parent model, measured indirectly, by a 0.78 GB file whose stated purpose is to make it go faster.

Everything below separates what is on the card from what the card does not establish. The acceptance figures are OpenBMB's own and nobody outside the lab has reproduced them. The base model's benchmark table still does not exist.

What the DSpark checkpoint actually is

The repository openbmb/MiniCPM-V-4.7-35B-A3B-DSpark dates to October 8, 2026. It is a single-file checkpoint — model.safetensors, plus a config.json and a README — under Apache-2.0, tagged for English and Chinese. A second draft, openbmb/MiniCPM-V-4.7-1B-DSpark, was created one second earlier, so the two were pushed to the hub in the same batch rather than discovered one at a time.

Each draft sits in front of one target and only that target. The card says it plainly: this checkpoint is "trained for exact pairing with MiniCPM-V-4.7-35B-A3B and its tokenizer." The vocabulary is the parent's, all 248,144 tokens of it, which is a requirement rather than an optimisation — a drafter whose tokens do not map one-to-one onto the target's cannot propose anything the target could accept. The same constraint is why the sibling draft exists separately instead of one drafter serving the family.

The architecture is not a smaller copy of the parent. It is a five-layer attention stack, 2,048 hidden width, 8 query heads against 2 key/value heads, a 6,144 intermediate size, and RoPE at a theta of 10,000,000. The architectures field reads Qwen3DSparkModel — the same Qwen3-family backbone the parent's language stack comes from, cut down to a stub.

The interesting part is how the stub talks to the target. It does not read the target's final layer. It taps hidden states from five intermediate layers — [3, 11, 19, 27, 35] of the parent's 40 — and projects them through a dspark-type projector. Pulling from the middle of the stack rather than the end is deliberate: mid-network states are cheaper to align to and carry information the final layer has already compressed into next-token logits. The config also arms a confidence head with a Markov component of rank 256, which is the machinery from the DSpark paper for deciding how much of a proposed block is worth verifying.

The acceptance table is a card, not a measurement

Here is everything numeric that OpenBMB published about how well this pair works, expressed as accepted tokens per verification step, with natural EOS termination and max_new_tokens=8192:

• Vision, MMMU — 5.098 accepted tokens per step.

• Vision, MathVista — 6.126.

• Vision, CharXiv reasoning (validation) — 5.479.

• Vision, OCRBench — 5.407.

• Text, Math — 6.687.

• Text, Code — 7.387.

• Text, General — 3.501.

Three things about that table are worth stating out loud. First, it is self-reported. Nobody outside OpenBMB has run this checkpoint and posted a number, and with one download recorded on the repo, nobody outside OpenBMB has run it at all. Second, acceptance length is a property of the pair, not of the model — it measures how predictable MiniCPM-V-4.7-35B-A3B's output is, not how good that output is. A target that repeats itself hands a drafter an easy win. Third, the spread is the story: 7.387 on code against 3.501 on general text is a factor of two between the best and worst category, and code being the easiest reflects code's low-entropy, highly repetitive surface more than any strength in the models.

There is also a plain-arithmetic reading that the card leaves implicit. A drafter that proposes 15 tokens and gets 5 to 7 accepted is still moving several tokens per target forward pass, so the ceiling here is a large throughput gain — but it is not the naive "5× faster" claim, because verifying a 15-token block costs more than generating one token, and the rejected proposals are paid for and thrown away. That gap is exactly what the DSpark paper is about, and it is why the config exposes a switch to turn adaptive verification off.

What the draft accidentally tells us about the base model

MiniCPM-V 4.7 labelled its release as shipped quietly — weights, no launch post. That has now changed, in a small but real way. The parent repository at openbmb/MiniCPM-V-4.7-35B-A3B was created on October 7, 2026. By October 12 it carried a full model card with a README, a hugging-face-style release page, a claims list, an on-device section, and a weights table. The repository has since grown a quantisation family — FP8, int4, AWQ, GPTQ and GGUF builds, each on its own repo, all touched on October 12 — and 27 likes against 166 downloads.

So the accurate picture is a two-stage release, not a silent one. The weights landed on October 6 and 7. The draft checkpoints followed on October 8. The documentation, the quants, and the on-device story arrived by October 12. OpenBMB still has not issued a blog post or a technical report for the family, and there is still no benchmark table on the parent card — the performance claims sit inside linked chart images rather than as text a reader can quote.

The claim that does appear in text is the headline one: with Lookahead Expert Scheduling, layer-wise quantisation, and "DSpark speculative sampling integration," the 35B-A3B model is described as the first open-source MoE model to run smoothly on-device, at 13-plus tokens per second on an iPhone 17 Pro Max. That figure is vendor-reported, unreproduced, and unqualified — no quantisation format, no build, no prompt, no measurement method. The DSpark checkpoint is one of the three techniques that claim rests on, which makes it the only one of the three you can download and inspect. It is also the one whose evidence is a single unread benchmark row per task.

Running it, if you want to

The card ships one recipe and it is a vLLM command, not a hand-wave. It serves the target at tensor-parallel size 2 with a maximum model length of 40,960, FLASH_ATTN on both the language and multimodal encoder attention backends, a visual downsample mode of 4x, enable_thinking set to false, and the speculative config pointed at the DSpark checkpoint with 15 speculative tokens and adaptive verification switched off. Two details in that line are worth noticing on their own: --max-num-seqs 1 means the published setup serves one sequence at a time, and --disable-custom-all-reduce with the all-reduce fusion pass turned off means this is a configuration that was tuned to work rather than to be maximally fast. Treat the recipe as a starting point that OpenBMB got running, not as a throughput claim.

The hardware envelope is the real barrier. The target is roughly 70 GB of BF16 weights before KV cache, and the draft adds about 0.78 GB on top. Two accelerators is the stated minimum, which puts this well outside the phone the family's marketing leans on — an on-device deployment for a 35B-A3B model means aggressive quantisation and offloading, which is what the LES and layer-wise quantisation work is for, and neither of those is in the vLLM recipe above.

That asymmetry is the practical decision for most teams. Serving MiniCPM-V 4.7 costs two GPUs you own; calling a comparable hosted multimodal MoE costs nothing upfront. Qwen3.6 35B A3B is the closest direct comparison — same 35B-total, 3B-active shape, same 262K context, image and video input — and it is served through OrcaRouter from $0.248 per million input tokens and $1.485 per million output tokens depending on the provider route, with automatic failover if one of those routes degrades. MiniCPM-V 4.7 is not a hosted model on OrcaRouter and this article is not going to pretend otherwise; the honest framing is that the two are alternatives at a decision point, and the hosted one is the one you can measure this afternoon.

What would make this checkable

The DSpark checkpoint is Apache-2.0, it is under a gigabyte, and it comes with a serving command that someone with two GPUs could paste into a terminal today. That combination makes it the cheapest route to an independent number on MiniCPM-V 4.7 — not a benchmark score, but something almost as useful: a reproduced acceptance length. If an outside party matches 5.1 on MMMU and 3.5 on general text, the card is credible and the family's efficiency story gains its first external datapoint. If acceptance comes in materially lower, the published table was measured under conditions the recipe does not reproduce, and the 13-tokens-per-second claim inherits that doubt.

What is still missing is the thing a model card is normally for. There is no MMMU score, no OCRBench score, no document-understanding result, no grounding number and no latency figure for MiniCPM-V 4.7 itself — nothing that answers whether this model is good. The draft model's table cannot substitute for that, and reading a high acceptance length as a quality signal is precisely the mistake the numbers invite. ChatGPT-shaped prediction is easy for a drafter and says nothing about whether the prediction was right.

So: a real artifact, a real licence, one genuinely new piece of published evidence about a model that had none — and an evaluation gap that is exactly as wide as it was on October 7. The next file to refresh is still the parent's model card.