MiniCPM-V 4.7-35B-A3B-DSpark: OpenBMB's 389M-draftmodel verschijnt met een modelkaart die zijn basismodel nooit kreeg

MiniCPM-V-4.7-35B-A3B-DSpark is een conceptmodel met 389.223.169 parameters. Het beantwoordt geen vragen, het ziet geen afbeeldingen, en op zichzelf is het nutteloos. Zijn enige taak is om de volgende vijftien tokens te raden, zodat MiniCPM-V-4.7-35B-A3B een heel blok kan verifiëren in één forward pass in plaats van telkens één token te genereren. Dat is speculatieve decoding, en OpenBMB bracht elf dagen geleden een conceptmodel uit voor zijn nieuwe 35B visie-taal-model, zonder er in het openbaar een woord over te zeggen.

Wat het een pagina waard maakt, is niet het concept. Het is het papierwerk dat erbij zat. De DSpark-checkpoint heeft een modelkaart: een licentie, een specificatietabel, een trainingsrecept en een acceptatielengtetabel voor zeven taakcategorieën. Zijn moedermodel met 35 miljard parameters had dat allemaal niet toen het verscheen. Dus voor het eerst zijn er echte cijfers verbonden aan een MiniCPM-V 4.7-release — en het zijn cijfers over het moedermodel, indirect gemeten, door een bestand van 0,78 GB waarvan het verklaarde doel is om het sneller te laten gaan.

Alles hieronder scheidt wat op de kaart staat van wat de kaart niet vaststelt. De acceptatiecijfers zijn die van OpenBMB zelf en niemand buiten het lab heeft ze gereproduceerd. De benchmarktabel van het basismodel bestaat nog steeds niet.

Wat de DSpark-checkpoint eigenlijk is

De repository openbmb/MiniCPM-V-4.7-35B-A3B-DSpark dateert van 8 oktober 2026. Het is een checkpoint met één bestand — model.safetensors, plus een config.json en een README — onder Apache-2.0, getagd voor Engels en Chinees. Een tweede concept, openbmb/MiniCPM-V-4.7-1B-DSpark, werd één seconde eerder aangemaakt, dus de twee werden in dezelfde batch naar de hub gepusht in plaats van één voor één te worden ontdekt.

Elk draftmodel staat vóór één doelmodel en alleen dat doelmodel. De kaart zegt het ronduit: deze checkpoint is "getraind voor exacte koppeling met MiniCPM-V-4.7-35B-A3B en zijn tokenizer." De vocabulaire is die van het bovenliggende model, alle 248.144 tokens ervan, wat een vereiste is en geen optimalisatie — een draftmodel waarvan de tokens niet één-op-één op die van het doelmodel kunnen worden afgebeeld, kan niets voorstellen dat het doelmodel zou kunnen accepteren. Dezelfde beperking is de reden dat het zuster-draftmodel apart bestaat in plaats van dat één draftmodel de familie bedient.

De architectuur is geen kleinere kopie van het moedermodel. Het is een attention-stack van vijf lagen, 2.048 verborgen breedte, 8 query-heads tegenover 2 key/value-heads, een tussenliggende grootte van 6.144, en RoPE met een theta van 10.000.000. architectures-veld leest Qwen3DSparkModel — dezelfde Qwen3-familie-backbone waar de taalstack van het moedermodel vandaan komt, teruggebracht tot een stub.

Het interessante deel is hoe de stub met het doel communiceert. Hij leest de laatste laag van het doel niet. Hij haalt verborgen toestanden uit vijf tussenliggende lagen — [3, 11, 19, 27, 35] van de 40 van de parent — en projecteert ze via een dspark-type projector. Putten uit het midden van de stack in plaats van het einde is bewust: toestanden midden in het netwerk zijn goedkoper om op uit te lijnen en dragen informatie die de laatste laag al in next-token-logits heeft gecomprimeerd. De config rust ook een confidence head uit met een Markov-component van rang 256, de machinerie uit de DSpark-paper om te beslissen hoeveel van een voorgesteld blok de moeite waard is om te verifiëren.

De acceptatietabel is een kaart, geen meting.

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

• Vision, MMMU — 5,098 geaccepteerde tokens per stap.

• Visie, MathVista — 6.126.

• Vision, CharXiv-redeneren (validatie) — 5.479.

• Vision, OCRBench — 5.407.

• Tekst, Wiskunde — 6,687.

• Tekst, Code — 7.387.

• Tekst, Algemeen — 3.501.

Over die tabel zijn drie dingen het waard om hardop te zeggen. Ten eerste is die zelfgerapporteerd. Niemand buiten OpenBMB heeft deze checkpoint gedraaid en een getal gepost, en met één geregistreerde download op de repo heeft niemand buiten OpenBMB deze überhaupt gedraaid. Ten tweede is acceptatielengte een eigenschap van het paar, niet van het model — die meet hoe voorspelbaar de output van MiniCPM-V-4.7-35B-A3B is, niet hoe goed die output is. Een target dat zichzelf herhaalt, bezorgt een drafter een makkelijke overwinning. Ten derde is de spreiding het verhaal: 7,387 op code tegenover 3,501 op algemene tekst is een factor twee tussen de beste en slechtste categorie, en dat code het makkelijkst is, weerspiegelt het laag-entropische, zeer repetitieve oppervlak van code meer dan enige kracht in de modellen.

Er is ook een puur rekenkundige lezing die de kaart impliciet laat. Een drafter die 15 tokens voorstelt en er 5 tot 7 geaccepteerd krijgt, verplaatst nog steeds meerdere tokens per target forward pass, dus het plafond hier is een grote doorvoerwinst — maar het is niet de naïeve "5× sneller"-claim, omdat het verifiëren van een blok van 15 tokens meer kost dan het genereren van één token, en de afgewezen voorstellen worden betaald en weggegooid. Dat gat is precies waar de DSpark-paper over gaat, en daarom biedt de configuratie een schakelaar om adaptieve verificatie uit te schakelen.

Wat het concept ons per ongeluk vertelt over het basismodel

MiniCPM-V 4.7 bestempelde zijn release als stilletjes uitgebracht — gewichten, geen aankondigingsbericht. Dat is nu veranderd, op een kleine maar reële manier. De bovenliggende repository op openbmb/MiniCPM-V-4.7-35B-A3B werd op 7 oktober 2026 aangemaakt. Op 12 oktober bevatte deze een volledige modelkaart met een README, een releasepagina in Hugging Face-stijl, een lijst met claims, een on-device-sectie en een tabel met gewichten. De repository is sindsdien uitgebreid met een kwantisatiefamilie — FP8-, int4-, AWQ-, GPTQ- en GGUF-builds, elk in een eigen repo, allemaal bijgewerkt op 12 oktober — en 27 likes tegenover 166 downloads.

Het precieze beeld is dus een tweefasige release, geen stille. De gewichten verschenen op 6 en 7 oktober. De concept-checkpoints volgden op 8 oktober. De documentatie, de kwantisaties en het on-device-verhaal waren er uiterlijk 12 oktober. OpenBMB heeft nog steeds geen blogpost of technisch rapport voor de familie uitgebracht, en er staat nog altijd geen benchmarktabel op de bovenliggende kaart — de prestatieclaims staan in gelinkte grafiekafbeeldingen in plaats van als tekst die een lezer kan citeren.

De bewering die wél in de tekst voorkomt, is de hoofdbewering: met Lookahead Expert Scheduling, laagsgewijze kwantisatie en "DSpark speculative sampling integration", wordt het 35B-A3B-model beschreven als het eerste open-source MoE-model dat soepel op het toestel zelf draait, met 13-plus tokens per seconde op een iPhone 17 Pro Max. Dat cijfer is door de leverancier gerapporteerd, niet gereproduceerd en niet nader gespecificeerd — geen kwantisatieformaat, geen build, geen prompt, geen meetmethode. Het DSpark-checkpoint is een van de drie technieken waarop die bewering steunt, waardoor het de enige van de drie is die je kunt downloaden en inspecteren. Het is ook de techniek waarvan het bewijs uit één enkele ongelezen benchmarkrij per taak bestaat.

Het uitvoeren, als je wilt

Op de kaart staat één recept en dat is een vLLM-commando, geen vage bewering. Het serveert het doel op tensor-parallelgrootte 2 met een maximale modellengte van 40.960, FLASH_ATTN op zowel de taal- als de multimodale encoder-attentionbackends, een visuele downsamplemodus van 4x, enable_thinking ingesteld op false, en de speculatieve configuratie gericht op de DSpark-checkpoint met 15 speculatieve tokens en adaptieve verificatie uitgeschakeld. Twee details in die regel zijn op zichzelf het opmerken waard: --max-num-seqs 1 betekent dat de gepubliceerde opzet één sequentie tegelijk serveert, en --disable-custom-all-reduce met de all-reduce-fusiepass uitgeschakeld betekent dat dit een configuratie is die is afgestemd om te werken, niet om maximaal snel te zijn. Behandel het recept als een startpunt dat OpenBMB aan de praat kreeg, niet als een doorvoerclaim.

De hardware-envelop is de echte barrière. Het doel is ongeveer 70 GB aan BF16-gewichten vóór de KV-cache, en het draftmodel voegt daar nog ongeveer 0,78 GB aan toe. Het genoemde minimum is twee acceleratoren, waardoor dit ruim buiten de telefoon valt waarop de marketing van de familie leunt — een implementatie op het apparaat zelf voor een 35B-A3B-model betekent agressieve kwantisatie en offloading, en dat is waar het werk aan LES en laagsgewijze kwantisatie voor bedoeld is, en geen van beide staat in het bovenstaande vLLM-recept.

Die asymmetrie is de praktische beslissing voor de meeste teams. Het serveren van MiniCPM-V 4.7 kost twee GPU's die je bezit; het aanroepen van een vergelijkbare gehoste multimodale MoE kost vooraf niets. Qwen3.6 35B A3B is de dichtstbijzijnde directe vergelijking — dezelfde 35B-totale, 3B-actieve vorm, dezelfde 262K-context, beeld- en video-invoer — en wordt via OrcaRouter aangeboden vanaf $0,248 per miljoen invoertokens en $1,485 per miljoen uitvoertokens, afhankelijk van de providerroute, met automatische failover als een van die routes verslechtert. MiniCPM-V 4.7 is geen gehost model op OrcaRouter en dit artikel zal niet doen alsof dat wel zo is; de eerlijke framing is dat de twee alternatieven op een beslissingspunt zijn, en de gehoste is degene die je vanmiddag kunt meten.

Wat zou dit controleerbaar maken?

De DSpark-checkpoint is Apache-2.0, is minder dan een gigabyte groot en wordt geleverd met een serveercommando dat iemand met twee GPU's vandaag in een terminal kan plakken. Die combinatie maakt het de goedkoopste route naar een onafhankelijk getal voor MiniCPM-V 4.7 — geen benchmarkscore, maar iets dat bijna net zo nuttig is: een gereproduceerde acceptatielengte. Als een externe partij 5,1 op MMMU en 3,5 op algemene tekst evenaart, is de kaart geloofwaardig en krijgt het efficiëntieverhaal van de familie zijn eerste externe datapunt. Als de acceptatie wezenlijk lager uitvalt, is de gepubliceerde tabel gemeten onder omstandigheden die het recept niet reproduceert, en erft de claim van 13 tokens per seconde die twijfel.

Wat nog ontbreekt, is precies datgene waarvoor een modelkaart normaal gesproken dient. Er is geen MMMU-score, geen OCRBench-score, geen resultaat op documentbegrip, geen groundinggetal en geen latentiecijfer voor MiniCPM-V 4.7 zelf — niets dat antwoord geeft op de vraag of dit model goed is. De tabel van het conceptmodel kan dat niet vervangen, en een hoge acceptatielengte opvatten als kwaliteitssignaal is precies de fout waartoe de cijfers verleiden. Een voorspelling in ChatGPT-vorm is gemakkelijk voor een conceptmodel en zegt niets over de vraag of de voorspelling juist was.

Dus: een echt artefact, een echte licentie, één werkelijk nieuw stuk gepubliceerd bewijs over een model dat er geen had — en een evaluatiekloof die precies even groot is als op 7 oktober. Het volgende bestand dat vernieuwd moet worden, is nog steeds de modelkaart van het bovenliggende model.