MiniCPM-V-4.7-1B-DSpark: een conceptmodel van 213M uitgebracht zonder aankondiging

MiniCPM-V-4.7-1B-DSpark is een checkpoint met 213.547.777 parameters dat geen vraag kan beantwoorden. Het leest geen afbeeldingen, het voert geen gesprek en op zichzelf ingezet levert het niets op dat de moeite van het lezen waard is. Het enige wat het doet, is vóór één model zitten — MiniCPM-V-4.7-1B — en de volgende vijftien tokens raden, zodat een klein visie-taalmodel van telefoonklasse een blok ervan in één enkele forward pass kan verifiëren in plaats van ze één voor één te genereren.

Het bestand is 0,85 GB onder Apache-2.0 en verscheen op Hugging Face om 04:26 UTC op 8 oktober 2026, in dezelfde batch als het concept voor het grotere 35B-A3B-broertje. Vier dagen later behandelt de kaart van het moedermodel het nog steeds als een voetnoot: het concept verschijnt één keer, als een rij in de gewichtentabel en achter een samengevouwen schakelaar 'Speculatief decoderen (DSpark)'. Er is geen OpenBMB-blogpost over, geen technisch rapport en geen vermelding in de eigen GitHub-documentatie van het project.

Dat stilzwijgen is het interessante deel, vanwege wat dit specifieke bestand mogelijk maakt. Het is het eerste artefact in de MiniCPM-V 4.7-familie waarvan de kernclaim — dat een 1B-visiemodel acceptabel op een telefoon draait — door iemand buiten OpenBMB kan worden gecontroleerd. Alles hieronder houdt twee stapels gescheiden: wat een bestand op schijf is dat je kunt openen, en wat een getal is dat de leverancier ernaast heeft afgedrukt.

Wat zit er eigenlijk in de repository?

Vier bestanden. Dat is alles: .gitattributes, README.md, config.json, en één enkel model.safetensors met 854.204.052 bytes aan BF16-gewichten. Er is geen tokenizer in de repository, want die is niet nodig — de draft leent die van het doelmodel, en de vocabulaire in de config is precies de 248.094 tokens van het bovenliggende model. Een drafter waarvan de tokens niet één-op-één op die van het doelmodel kunnen worden afgebeeld, kan niets voorstellen wat het doelmodel zou accepteren, dus het delen van de vocabulaire is eerder een vereiste dan een gemak.

De Hub API registreert de repository als aangemaakt op 2026-10-08T04:26:19Z en voor het laatst gewijzigd op 2026-10-12T14:29:57Z, getagd voor Engels en Chinees, gelicentieerd onder Apache-2.0, met drie likes en één download op het moment van schrijven. Het laatste getal is het getal om aan vast te houden. Eén download, na vier dagen, voor een bestand dat klein genoeg is om via een telefoonverbinding op te halen.

Het architectuurveld luidt Qwen3DSparkModel met een model_type van qwen3, wat eerder coherent dan vreemd is: de taalbasis van MiniCPM-V 4.7 stamt af van de Qwen3-lijn, dus een stub van vijf lagen die uit dezelfde familie is gesneden, is precies wat je zou verwachten. Wat geen kleinere kopie van het moedermodel is, is hoe de stub ermee praat. De config rust een dflash_config uit met projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" en markov_rank: 256. Die confidence-head is het onderdeel dat uit de DSpark-methode is overgenomen: het is het mechanisme om te schatten hoeveel van een voorgesteld blok het waard is om te verifiëren, en dat is precies de reden dat de serving-config een schakelaar biedt om adaptieve verificatie uit te zetten.

De specificatie, en waarom elk getal daar staat

Conceptzijde, van de kaart en de config, die beide overeenkomen:

• Conceptparameters — 213.547.777, allemaal BF16, in een checkpoint in één bestand van 0,85 GB

• Conceptdiepte — 5 lagen, allemaal volledige aandacht, verborgen grootte 1.024, tussenliggende grootte 3.584, SiLU-activatie

• Aandachtsgeometrie — 8 query-heads tegenover 2 key/value-heads, headdimensie 256, gegroepeerde-query-aandacht

• Tokens per forward pass — 15, in de config opgenomen als block_size: 15

• Positiebereik — RoPE theta 10.000.000 met een 256-dimensionale roterende embedding, en max_position_embeddings ingesteld op 262.144, overeenkomend met het 256K-venster van het bovenliggende model

• Taplagen — [3, 7, 11, 15, 19], van de 24 van de parent (num_target_layers: 24)

• Vocabulaire — 248.094, gekoppeld aan de tokenizer van het doel, met een speciaal mask-token op 248.076 voor de semi-autoregressieve conceptstap

Twee van die regels zijn meer dan een vluchtige blik waard. De eerste zijn de tap-lagen. Het draftmodel leest niet de laatste laag van het parent-model; het leest hidden states van vijf lagen verspreid door de diepte van het parent-model en projecteert ze via een dspark-projector. States halverwege het netwerk zijn goedkoper om op af te stemmen en bevatten nog steeds informatie die de laatste laag al heeft samengeperst tot next-token-logits. Het tweede is de head-dimensie van 256 tegenover een hidden size van 1.024. Dat is een bewust brede head op een smal model, en de configuratie schakelt tie_word_embeddings: false — de embedding-matrix wordt apart gehouden in plaats van gedeeld met de outputprojectie, dus het parameteraantal omvat beide.

Alles bij elkaar is het een draftmodel van ongeveer een vijfde van de grootte van het doelmodel, in een volledig andere vorm. Ter vergelijking: de draft van het 35B-A3B-broertje telt 389.223.169 parameters die lagen [3, 11, 19, 27, 35] van de 40 aanspreken. Twee drafts, één per doelmodel, omdat een draft alleen geldig is voor het vocabulaire en de intermediaire representatie waarmee hij is getraind.

De acceptatietabel is een modelkaart, geen meting

Hier is alle numerieke informatie die OpenBMB heeft gepubliceerd over hoe goed dit paar presteert, uitgedrukt als geaccepteerde tokens per verificatiestap, gemeten met natuurlijke EOS-beëindiging en max_new_tokens=8192:

• Vision, MMMU — 3,452 geaccepteerde tokens per stap

• Vision, MathVista — 4.333

• Vision, CharXiv-redenering (validatie) — 4,452

• Vision, OCRBench — 4.752

• Tekst, wiskunde — 5.891

• Tekst, code — 5.347

• Tekst, algemeen — 3.370

De spreiding loopt van 5,891 tot 3,370, een factor van ongeveer 1,75 tussen de makkelijkste categorie en de moeilijkste. Die ordening is op een manier niet verrassend die je iets over de cijfers vertelt: wiskunde is het meest regelmatige oppervlak dat een taalmodel produceert, algemene tekst het minst, en het succespercentage van een opsteller volgt de voorspelbaarheid van de output van het doel in plaats van de kwaliteit ervan.

Drie kanttekeningen horen in die tabel, en de kaart noemt er geen enkele uit eigen beweging.

Het is zelfgerapporteerd, en er is precies één download voor de repository. Niemand buiten OpenBMB heeft een acceptatiecijfer voor deze checkpoint geproduceerd dat iemand anders kan bekijken. De cijfers zijn van de leverancier, gemeten in de meetomgeving van de leverancier, op de taakset van de leverancier.

Acceptatielengte is een eigenschap van het paar, niet van het model. Een doelmodel dat zichzelf herhaalt, bezorgt zijn opsteller een gemakkelijke overwinning, dus een hoger getal hier is geen bewijs dat MiniCPM-V 4.7-1B ergens goed in is. Het is bewijs over hoe voorspelbaar zijn uitvoer is, wat een andere vraag is met een ander antwoord.

En het is geen versnelling. Een drafter die 15 tokens voorstelt en er 3,4 daarvan geverifieerd krijgt, verwerkt nog steeds meerdere tokens per forward pass van het doel, maar het verifiëren van een blok van 15 tokens kost meer dan het genereren van één token, en elk afgewezen voorstel wordt betaald en weggegooid. Het omzetten van een acceptatielengte naar een wall-clock-cijfer vereist de verificatiekosten, de batchgrootte en de hardware, en geen daarvan levert de kaart. Het enige servingrecept dat het wel levert, stelt --max-num-seqs 1, een configuratie die is afgestemd om te werken, niet om snel te zijn.

Afgezet tegen het zusje wordt de tabel nuttiger. De 35B-A3B-draft scoort 7,387 op code en 5,098 op MMMU; deze 1B-draft scoort 5,347 en 3,452. Kleinere doelen met kleinere drafters accepteren aanzienlijk minder tokens per stap, wat het soort detail over families heen is dat één kaart niet kan tonen en twee kaarten wel.

Training, en het detail dat het hele ontwerp verklaart

Het recept is vier regels lang: twee miljoen trainingssequenties, zes epochs, AdamW en een gecombineerde objectieffunctie van kruisentropie, een L1-term en een confidence loss. De regel die ertoe doet, is die over waar de trainingsdata vandaan kwamen — de responsen werden door MiniCPM-V-4.7-1B zelf gegenereerd, op basis van een mix van visuele en tekstuele prompts.

Dat is zelfdistillatie, en het bepaalt de ondergrens voor wat het kost om een drafter als deze te bouwen. Je kunt er geen trainen zonder eerst het doelmodel op grote schaal te draaien, over beide modaliteiten, wat betekent dat het artefact van 0,85 GB dat je kunt downloaden het goedkope residu is van een duur proces. Het verklaart ook waarom de drafter een-op-een wordt gekoppeld in plaats van gedeeld: het gedrag dat hij imiteert, is het gedrag van dit model, en de outputs van een ander doelmodel zouden een andere drafter trainen.

De paper van de methode zelf, arXiv 2607.05147, is niet van OpenBMB. Het is een paper met 33 auteurs, ingediend op 6 juli 2026, die DSpark beschrijft als een speculatief-decoderaamwerk dat een parallelle backbone koppelt aan een lichtgewicht sequentiële module en de verificatielengte plant op basis van geschatte prefix-overlevingskansen. Het rapporteert over inzet binnen een DeepSeek-V4-serversysteem, hanteert een productiebaseline genaamd MTP-1, en claimt dat generatie per gebruiker 60 tot 85 procent sneller is bij gelijke doorvoer. Die claims horen bij de paper en bij die deployment. Niets gepubliceerds verbindt ze met een vijf-laagse, 213M-draft op een 1B-visiemodel, en de acceptatietabel hierboven is de enige brug die iemand heeft aangedragen.

Waarom dit bestand belangrijker is dan zijn grootte doet vermoeden

De hoofdbewering in de MiniCPM-V 4.7-familie betreft on-device. De 1B-kaart bevat een grafiek van prestaties versus inferentietijd, een grafiek van de algehele prestaties voor de 1B-instructbuild, een niet-bewerkte schermopname gemaakt op een iPhone 17 Pro Max, en een kwalitatieve zin die stelt dat de 1B-variant aanzienlijk beter presteert dan Qwen3.5 0.8B, zowel op de algehele score als op inferentie-efficiëntie. Het vermeldt ook een quantisatiefamilie — int4, AWQ, GPTQ, GGUF, plus FP8-ondersteuning — en day-0-hardwaredoelen die zich uitstrekken over iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD en Arm.

Elk daarvan is een leveranciersclaim zonder dat er een extern cijfer aan vastzit, en een ervan is intern slordig: de kaarttekst noemt het een 1B-model, terwijl de zijbalk van de Hub een modelgrootte van 2B parameters meldt. Het DSpark-checkpoint is van een andere aard dan dat alles. Het is 0,85 GB, Apache-2.0, en het wordt geleverd met een serveercommando — wat betekent dat een buitenstaander met een consumenten-GPU het deze week kan draaien en het eerste extern gemeten cijfer van de familie kan produceren. Geen benchmarkscore, maar iets dat bijna net zo nuttig is: een gereproduceerde acceptatielengte.

Als iemand 3,45 haalt op MMMU en 3,37 op algemene tekst, is de kaart geloofwaardig en heeft het on-device-verhaal zijn eerste externe datapunt. Als de acceptatie aanzienlijk lager uitvalt, is de tabel gemeten onder omstandigheden die het gepubliceerde recept niet reproduceert, en erft de grafiek van prestatie per inferentietijd die twijfel. Welk resultaat dan ook is meer waard dan nog een leveranciersgrafiek, en dit is het enige deel van de familie waar het goedkoop is om er een te krijgen.

Het draaien ervan, en wat het kost om het te proberen

De kaart levert één recept mee en dat is een vllm serve-aanroep, geen vaag gebaar. Het laadt het doel-openbmb/MiniCPM-V-4.7-1B, serveert het onder de naam MiniCPM-V-4.7-1B, stelt --max-model-len 40960 en --max-num-batched-tokens 40960 in, en zet --attention-backend FLASH_ATTN en --mm-encoder-attn-backend FLASH_ATTN vast, geeft een multimodale processor-kwarg van {"downsample_mode": "4x"}, vertrouwt op multimodale kwargs per verzoek, en wijst een speculatieve config naar het DSpark-checkpoint met "method": "dspark", "num_speculative_tokens": 15 en adaptieve verificatie uitgeschakeld. Standaard chat-template-kwargs laten thinking uitgeschakeld.

Twee details in die regel zijn het waard om twee keer te lezen. --max-num-seqs 1 betekent dat de gepubliceerde setup één sequentie tegelijk serveert, dus het recept beschrijft een latentieconfiguratie voor één stream, geen doorvoerconfiguratie. En de 4x visuele downsamplemodus is de goedkopere van de twee die de bovenliggende kaart adverteert — dezelfde kaart biedt een gemengd 4x/16x-schema dat detail inruilt voor snelheid, en het recept kiest de kant van die afweging die snelheid bevoordeelt.

De hardware-envelop is het tegenovergestelde van de marketing van de modelfamilie. Het 1B-target is ongeveer 2 GB in BF16 plus een KV-cache, en de draft voegt daar nog 0,85 GB bovenop toe, dus dit is een single-GPU-taak — een consumentenkaart, of een workstation met genoeg unified memory — en niet een telefoontaak. Het on-device-pad in de documentatie van het bovenliggende model loopt via gekwantiseerde builds en frameworks die niet in dit recept zitten, en het DSpark-checkpoint zoals gepubliceerd is een BF16 server-side artefact.

Dat laat een gat achter waar de meeste teams tegenaan zullen lopen: de interessante versie van MiniCPM-V 4.7-1B is de on-device versie, en de versie die je vandaag kunt draaien zonder de telefoon-toolchain in huis te hebben, is een server-side versie. Als wat je nu echt nodig hebt, kleinschalige multimodale inferentie is, dan is het dichtstbijzijnde gehoste equivalent een ander model — Qwen3 VL 8B Instruct staat op OrcaRouter voor $0,18 per miljoen inputtokens en $0,70 per miljoen output, met een contextvenster van 128K en tekst-, afbeeldings- en video-invoer, geen lokale weights en geen serving-recipe om werkend te houden. MiniCPM-V 4.7 is geen gehost model op OrcaRouter en dit stuk zal niet doen alsof dat wel zo is; de eerlijke framing is dat dit twee manieren zijn om één klus te klaren, en dat er vanmiddag maar één daarvan meetbaar is vanuit de catalogus.

Waar iets als DSpark zijn nut bewijst, is in het geval van een onbewezen model, en dat is een routeringsvraagstuk, geen modelvraagstuk. Een drafter die niemand heeft gereproduceerd, is precies het soort component dat je achter een endpoint wilt hebben waarop je kunt terugvallen. Het draaien van 200+ modellen achter één sleutel, het doorgeven van lijstprijzen van providers met 0% opslag, met automatische failover wanneer een route verslechtert, betekent dat een serving-experiment dat misgaat je een retry kost in plaats van een storing — en omdat er geen opslag wordt gerekend, is een prijswijziging van een leverancier voor welk model in de catalogus dan ook dezelfde dag live in plaats van pas bij de volgende factureringscyclus.

Wat zou dit controleerbaar maken?

Er ontbreken drie dingen, en slechts één ervan vereist OpenBMB.

De leverancier heeft niets aangekondigd. De repository heeft een modelkaart, een licentie en een trainingsrecept, maar geen blogpost, geen technisch rapport en geen regel in de GitHub-documentatie van het project — die in de eerste week van de familie nog steeds de vorige generatie als de huidige beschreef. Vier dagen nadat de checkpoint was verschenen, linkt de bovenliggende 1B-kaart ernaar als een tabelrij en niets meer.

Niemand heeft de acceptatiecijfers gereproduceerd, en het aantal downloads is één. Dat is het goedkoopste gat om te dichten en het belangrijkste, want het is de enige plek waar een externe meting het verhaal van de familie wezenlijk zou veranderen.

En het kwaliteitsvraagstuk is volledig ongemoeid gelaten. Er is nergens in de release een MMMU-score, een OCRBench-resultaat, een getal voor documentbegrip of een grounding-cijfer voor MiniCPM-V 4.7-1B te vinden — de acceptatietabel is een tabel over decodering, en het lezen van een hoge acceptatielengte als een kwaliteitssignaal is precies de fout waartoe die cijfers uitnodigen.

Dus: een echt artefact, een permissieve licentie, een serveercommando dat werkt, en één werkelijk nieuw stuk bewijs over een model dat er geen had. Het volgende bestand dat het vernieuwen waard is, is nog steeds de modelkaart van het bovenliggende model.