MiniCPM-V-4.7-1B-DSpark: A 213M Draft Model Shipped With No Announcement

MiniCPM-V-4.7-1B-DSpark is a 213,547,777-parameter checkpoint that cannot answer a question. It does not read images, it does not hold a conversation, and served on its own it produces nothing worth reading. Its entire job is to sit in front of one model — MiniCPM-V-4.7-1B — and guess the next fifteen tokens so that a small, phone-class vision-language model can verify a block of them in a single forward pass instead of generating them one at a time.

The file is 0.85 GB under Apache-2.0, and it appeared on Hugging Face at 04:26 UTC on October 8, 2026, in the same batch as the draft for the larger 35B-A3B sibling. Four days later the parent card still treats it as a footnote: the draft appears once, as a row in the weights table and behind a collapsed "Speculative decoding (DSpark)" toggle. There is no OpenBMB blog post for it, no technical report, and no entry in the project's own GitHub documentation.

That silence is the interesting part, because of what this particular file makes possible. It is the first artifact in the MiniCPM-V 4.7 family whose central claim — that a 1B vision model runs acceptably on a phone — can be checked by someone outside OpenBMB. Everything below keeps two piles separate: what is a file on disk you can open, and what is a number the vendor printed next to it.

What is actually in the repository

Four files. That is the whole thing: .gitattributes, README.md, config.json, and a single model.safetensors holding 854,204,052 bytes of BF16 weights. There is no tokenizer in the repository, because there does not need to be one — the draft borrows the target's, and the vocabulary in its config is the parent's 248,094 tokens exactly. A drafter whose tokens do not map one-to-one onto the target's cannot propose anything the target would accept, so sharing the vocabulary is a requirement rather than a convenience.

The Hub API records the repository as created at 2026-10-08T04:26:19Z and last modified 2026-10-12T14:29:57Z, tagged for English and Chinese, licensed Apache-2.0, with three likes and one download at the time of writing. The last number is the one to hold onto. One download, four days in, on a file small enough to fetch over a phone connection.

The architecture field reads Qwen3DSparkModel with a model_type of qwen3, which is coherent rather than odd: MiniCPM-V 4.7's language backbone descends from the Qwen3 line, so a five-layer stub cut from the same family is what you would expect. What is not a smaller copy of the parent is how the stub talks to it. The config arms a dflash_config with projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" and markov_rank: 256. That confidence head is the part lifted from the DSpark method: it is the machinery for estimating how much of a proposed block is worth verifying, which is the whole reason the serving config exposes a switch to turn adaptive verification off.

The specification, and why each number is there

Draft-side, from the card and the config, both of which agree:

• Draft parameters — 213,547,777, all BF16, in a single-file checkpoint of 0.85 GB

• Draft depth — 5 layers, all full attention, hidden size 1,024, intermediate size 3,584, SiLU activation

• Attention geometry — 8 query heads against 2 key/value heads, head dimension 256, grouped-query attention

• Tokens per forward pass — 15, carried in the config as block_size: 15

• Position range — RoPE theta 10,000,000 with a 256-dimension rotary embedding, and max_position_embeddings set to 262,144, matching the parent's 256K window

• Tap layers — [3, 7, 11, 15, 19], out of the parent's 24 (num_target_layers: 24)

• Vocabulary — 248,094, tied to the target's tokenizer, with a dedicated mask token at 248,076 for the semi-autoregressive drafting step

Two of those lines are worth more than a glance. The first is the tap layers. The draft does not read the parent's final layer; it reads hidden states from five layers scattered through the parent's depth and projects them through a dspark projector. Mid-network states are cheaper to align to and still carry information the last layer has already collapsed into next-token logits. The second is the head dimension of 256 against a hidden size of 1,024. That is a deliberately wide head on a narrow model, and the config toggles tie_word_embeddings: false — the embedding matrix is kept separate rather than shared with the output projection, so the parameter count includes both.

The sum of it is a drafter at roughly a fifth of the target's size in a different shape entirely. For comparison, the 35B-A3B sibling's draft is 389,223,169 parameters tapping layers [3, 11, 19, 27, 35] of 40. Two drafts, one per target, because a draft is only ever valid for the vocabulary and intermediate representation it was trained against.

The acceptance table is a model card, not a measurement

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

• Vision, MMMU — 3.452 accepted tokens per step

• Vision, MathVista — 4.333

• Vision, CharXiv reasoning (validation) — 4.452

• Vision, OCRBench — 4.752

• Text, math — 5.891

• Text, code — 5.347

• Text, general — 3.370

The spread runs from 5.891 down to 3.370, a factor of about 1.75 between the easiest category and the hardest. That ordering is unsurprising in a way that tells you something about the numbers: math is the most regular surface a language model produces, general text the least, and a drafter's success rate tracks the predictability of the target's output rather than the quality of it.

Three caveats belong on that table, and the card does not volunteer any of them.

It is self-reported, and there is exactly one download against the repository. Nobody outside OpenBMB has produced an acceptance number for this checkpoint that anyone else can look at. The figures are the vendor's, measured in the vendor's harness, on the vendor's task set.

Acceptance length is a property of the pair, not of the model. A target that repeats itself hands its drafter an easy win, so a higher number here is not evidence that MiniCPM-V 4.7-1B is good at anything. It is evidence about how predictable its output is, which is a different question with a different answer.

And it is not a speedup. A drafter proposing 15 tokens and getting 3.4 of them verified is still moving several tokens per target forward pass, but verifying a 15-token block costs more than generating one token, and every rejected proposal is paid for and discarded. Converting an acceptance length into a wall-clock figure requires the verification cost, the batch size and the hardware, none of which the card supplies. The one serving recipe it does supply sets --max-num-seqs 1, which is a configuration tuned to work rather than one tuned to be fast.

Read against the sibling, the table gets more useful. The 35B-A3B draft posts 7.387 on code and 5.098 on MMMU; this 1B draft posts 5.347 and 3.452. Smaller targets with smaller drafters accept markedly fewer tokens per step, which is the kind of cross-family detail a single card cannot show and two cards can.

Training, and the detail that explains the whole design

The recipe is four lines long: two million training sequences, six epochs, AdamW, and a combined objective of cross-entropy, an L1 term and a confidence loss. The line that matters is the one about where the training data came from — responses were generated by MiniCPM-V-4.7-1B itself, from a mix of vision and text prompts.

That is self-distillation, and it sets the floor on what a drafter like this costs to build. You cannot train one without running the target model at volume first, across both modalities, which means the 0.85 GB artifact you can download is the cheap residue of an expensive process. It also explains why the drafter is paired one-to-one rather than shared: the behaviour it is imitating is this model's behaviour, and a different target's outputs would train a different drafter.

The method's own paper, arXiv 2607.05147, is not OpenBMB's. It is a 33-author paper submitted on July 6, 2026 describing DSpark as a speculative-decoding framework that pairs a parallel backbone with a lightweight sequential module and schedules verification length from estimated prefix-survival probabilities. It reports deployment inside a DeepSeek-V4 serving system, takes a production baseline called MTP-1, and claims per-user generation 60 to 85 percent faster at matched throughput. Those claims belong to the paper and to that deployment. Nothing published connects them to a five-layer, 213M draft on a 1B vision model, and the acceptance table above is the only bridge anyone has offered.

Why this file matters more than its size suggests

The headline claim in the MiniCPM-V 4.7 family is an on-device one. The 1B card ships a performance-versus-inference-time chart, an overall-performance chart for the 1B instruct build, an unedited screen recording captured on an iPhone 17 Pro Max, and a qualitative sentence saying the 1B variant substantially outperforms Qwen3.5 0.8B on both overall score and inference efficiency. It also lists a quantisation family — int4, AWQ, GPTQ, GGUF, plus FP8 support — and day-0 hardware targets spanning iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD and Arm.

Every one of those is a vendor claim with no outside number attached, and one of them is internally untidy: the card text calls it a 1B model while the Hub sidebar reports a model size of 2B parameters. The DSpark checkpoint is different in kind from all of it. It is 0.85 GB, Apache-2.0, and it comes with a serving command — which means an outside party with a consumer GPU can run it this week and produce the family's first externally measured figure. Not a benchmark score, but something nearly as useful: a reproduced acceptance length.

If somebody matches 3.45 on MMMU and 3.37 on general text, the card is credible and the on-device story has its first external datapoint. If acceptance comes in materially lower, the table was measured under conditions the published recipe does not reproduce, and the performance-per-inference-time chart inherits that doubt. Either result is worth more than another vendor chart, and this is the only part of the family where getting one is cheap.

Running it, and what it costs to try

The card ships one recipe and it is a vllm serve invocation, not a hand-wave. It loads the target openbmb/MiniCPM-V-4.7-1B, serves it under the name MiniCPM-V-4.7-1B, sets --max-model-len 40960 and --max-num-batched-tokens 40960, pins --attention-backend FLASH_ATTN and --mm-encoder-attn-backend FLASH_ATTN, passes a multimodal processor kwarg of {"downsample_mode": "4x"}, trusts per-request multimodal kwargs, and points a speculative config at the DSpark checkpoint with "method": "dspark", "num_speculative_tokens": 15 and adaptive verification switched off. Default chat-template kwargs leave thinking disabled.

Two details in that line are worth reading twice. --max-num-seqs 1 means the published setup serves one sequence at a time, so the recipe describes a single-stream latency configuration, not a throughput configuration. And the 4x visual downsample mode is the cheaper of the two the parent card advertises — the same card offers a mixed 4x/16x scheme that trades detail for speed, and the recipe selects the side of that trade that favours speed.

The hardware envelope is the opposite of the family's marketing. The 1B target is roughly 2 GB in BF16 plus a KV cache, and the draft adds 0.85 GB on top, so this is a single-GPU job — consumer card, or a workstation with enough unified memory — rather than a phone job. The on-device path in the parent's documentation runs through quantised builds and frameworks that are not in this recipe, and the DSpark checkpoint as published is a BF16 server-side artifact.

That leaves a gap most teams will hit: the interesting version of MiniCPM-V 4.7-1B is the on-device one, and the version you can run today without owning the phone toolchain is a server-side one. If what you actually need is small multimodal inference now, the nearest hosted equivalent is a different model — Qwen3 VL 8B Instruct is on OrcaRouter at $0.18 per million input tokens and $0.70 per million output, with a 128K context window and text, image and video input, no local weights and no serving recipe to keep working. MiniCPM-V 4.7 is not a hosted model on OrcaRouter and this piece will not pretend otherwise; the honest framing is that these are two ways to do one job, and only one of them is measurable from the catalogue this afternoon.

Where something like DSpark earns its keep is the unproven-model case, and that is a routing question rather than a model question. A drafter nobody has reproduced is exactly the kind of component you want behind an endpoint you can fall back from. Running 200+ models behind one key, provider list prices passed through with 0% markup, with automatic failover when a route degrades, means a serving experiment that goes wrong costs you a retry rather than an outage — and because nothing is marked up, a vendor price change on any model in the catalogue is live the same day rather than at the next billing cycle.

What would make this checkable

Three things are missing, and only one of them requires OpenBMB.

The vendor has not announced anything. The repository has a model card, a licence and a training recipe, but no blog post, no technical report, and no line in the project's GitHub documentation — which, as of the family's first week, was still describing the previous generation as the current one. Four days after the checkpoint landed, the parent 1B card links it as a table row and nothing more.

Nobody has reproduced the acceptance figures, and the download count is one. That is the cheapest gap to close and the one that matters most, because it is the only place where an outside measurement would meaningfully move the family's story.

And the quality question is entirely untouched. There is no MMMU score, no OCRBench result, no document-understanding number and no grounding figure for MiniCPM-V 4.7-1B anywhere in the release — the acceptance table is a table about decoding, and reading a high acceptance length as a quality signal is exactly the mistake those numbers invite.

So: a real artifact, a permissive licence, a serving command that works, and one genuinely new piece of evidence about a model that had none. The next file worth refreshing is still the parent's model card.