Een voxel-pagoda, 10% minder tokens, en de ene zin waar OpenBMB daadwerkelijk achter staat

De meest geciteerde zin over MiniCPM-V 4.7 35B-A3B deze week staat niet in de modelkaart. Het is een tweet, geplaatst op 13 oktober 2026, die luidt: "MiniCPM-V 4.7 35B-A3B gebruikte niet alleen minder tokens, maar produceerde ook een betere voxel-pagode dan Qwen 3.6 35B-A3." De demonstratie waarnaar het verwijst is een video van twee taalmodellen die elk de code schrijven voor een Japanse pagode in 3D-voxels, naast elkaar gerenderd. Het is een echt interessant artefact — het laat een visie-taalmodel een gebouwde structuur in drie dimensies reproduceren op basis van een afbeeldingsprompt, wat een moeilijkere taak is dan er een bijschrift bij te maken. Maar het is de moeite waard om te scheiden wat die tweet wel is van wat hij niet is, want drie verschillende beweringen zijn in één regel samengesmolten, en ze hebben drie verschillende niveaus van onderbouwing. MiniCPM-V 4.7 35B-A3B is een echte checkpoint van OpenBMB en is ongeveer een week oud; Qwen3.6-35B-A3B is een negen maanden oude open-weights-rivaal, ook Apache-2.0, ook een sparse mixture-of-experts met dezelfde headline-grootte. Alles hieronder gaat erover welke van de efficiëntieclaims eromheen controleerbaar is, en welke een JPEG van een grafiek is.

Drie beweringen in één zin gehuld

De tweet bundelt drie scheidbare dingen, en die verdienen het om gescheiden te worden, omdat slechts één ervan gedocumenteerd is.

• "Minder tokens gebruikt" — dit is een meetbare uitspraak over tokenverbruik voor één taak. Het cijfer dat naast de demo circuleert, is 10% minder tokens dan Qwen3.6 35B-A3B. Dat aantal is afkomstig van de externe maker die de vergelijking heeft uitgevoerd, niet van de evaluatie van OpenBMB, en het is één enkel promptpaar, geen benchmark.

• "Produceerde een betere voxelpagode" — dit is een beoordeling, gemaakt door naar twee gerenderde pagodes te kijken. Er is geen rubric, geen scoringsinstrument en geen onafhankelijke partij. Het is het soort bewering dat een mens in drie seconden maakt en een benchmark helemaal niet kan maken, omdat "betere pagode" geen ground truth heeft.

• "Efficiëntie plus kwaliteit is het echte slagveld" — dat deel is een these, en het is toevallig degene die OpenBMB wél schriftelijk beargumenteert, met cijfers erbij, in de modelkaart. Het is alleen niet de zin die de ronde deed.

Dit is belangrijk omdat de eerste twee claims de memorabele zijn en de derde de verdedigbare. Als je moet beslissen of je 70 GB aan download aan een checkpoint wilt besteden, wil je de derde.

Wat OpenBMB daadwerkelijk schreef, en wanneer

Eerst de tijdlijn, want die is door het navertellen samengeperst. De gewichten verschenen geruisloos: openbmb/MiniCPM-V-4.7-1Bwerd aangemaakt op 6 oktober 2026 om 17:40 UTC,openbmb/MiniCPM-V-4.7-35B-A3Bop 7 oktober om 07:07 UTC. Geen van beide had op dat moment een modelkaart, een licentietag of een benchmark — dit kwam hier destijds aan bod, en het was een vreemde gang van zaken voor een upload van 35 miljard parameters. Zes dagen later, op 12 oktober 2026, voegde OpenBMB de documentatie in één keer toe: modelkaart, Apache-2.0-licentie, evaluatiegrafieken, een herschreven README voor de repository met de nieuwe serie voorop, en een aankondiging. De parameters veranderden die dag niet. De uitleg wel.

Dus de eerlijke manier om het te formuleren is niet "MiniCPM-V 4.7 35B-A3B is deze week gelanceerd." Het is "MiniCPM-V 4.7 35B-A3B werd deze week leesbaar." Alles erover dat nu citeerbaar is, was ofwel geüpload op de 6e en 7e maar niet gedocumenteerd, ofwel geschreven op de 12e en is een leveranciersclaim.

De bewering die de modelkaart wel maakt

Hier is de zin, woordelijk van de kaart, en hij is beperkter dan de tweet: in de Instruct-modus behaalt de 35B-A3B-variant "een hogere totaalscore in minder inferentietijd dan Qwen3.6 35B-A3B." Dat is alles. Geen tokentelling, geen marge, geen uitsplitsing per benchmark in lopende tekst. Het bewijs erachter is een spreidingsdiagram — gemiddelde evaluatiescore op de verticale as, inferentietijd in seconden op een logaritmische schaal op de horizontale as — waarop MiniCPM-V 4.7 35B-A3B zich boven en links van Qwen3.6-35B-A3B bevindt. De eigen voetnoot van de grafiek definieert het gemiddelde als het rekenkundig gemiddelde van vijf benchmarks: MMStar, MMMU-Pro, CharXiv reasoning, BLINK en MathVista. Cirkels duiden op de Instruct-modus, ruiten op de Thinking-modus.

Dat is een echte en specifieke bewering over een tweedimensionale afweging, en het is het sterkste punt in de release. Het is ook het vermelden waard wat de grafiek je niet kan vertellen: er staan geen numerieke labels op de uitgezette punten, dus je kunt geen score of tijd aflezen, alleen een richting. De richting, zoals getekend, bevoordeelt MiniCPM op beide assen tegelijk.

En het is gemeten door de leverancier. De evaluatiecijfers op de kaart bevatten de regel: "Resultaten zijn afkomstig uit openbare rapporten en onze lokale evaluatie met officiële checkpoints." Lokale evaluatie betekent OpenBMB's hardware, OpenBMB's harness, OpenBMB's modusselectie. Dat is normaal voor een modelkaart, en abnormaal om tot een feit te witwassen. Geen enkele onafhankelijke partij heeft deze twee checkpoints tegen een gedeelde harness laten lopen. Geen enkel leaderboard heeft een van beide resultaten geïndexeerd. Op het moment van schrijven heeft de bewering precies één bron, en de bron verkoopt het model.

Waar de token-efficiëntie vandaan zou moeten komen

Het efficiëntieargument berust niet op de benchmarkgrafiek. Het berust op drie technische keuzes, en die zijn het waard om te begrijpen, want ze bepalen of de winst zich al dan niet naar jouw hardware vertaalt.

• Lookahead Expert Scheduling (LES) — de belangrijkste techniek. Een sparse mixture-of-experts slaat veel meer parameters op dan hij per token activeert, en op een apparaat dat niet elke expert in het geheugen kan houden, worden de gewichten in en uit gepagineerd en stokt het decoderen. LES gebruikt cross-layer routeringsvoorspelling om experts die waarschijnlijk door de volgende laag nodig zijn vooraf te laden, en geeft voorrang aan berekeningen voor experts die de echte router daadwerkelijk heeft geselecteerd en die toevallig al geladen zijn. OpenBMB benadrukt zorgvuldig dat de voorspelling alleen prefetching en scheduling aanstuurt; de routering van het model op tokenniveau blijft ongewijzigd, en experts die de voorspeller heeft gemist, worden nog steeds geladen en geëvalueerd. De kaart claimt hiermee een 5× versnelling op echte apparaten, zonder verlies van capaciteiten.

• Fijnmazige kwantisatie per laag — verkleint de voetafdruk van de expertgewichten en het geheugenverkeer, wat de andere helft is van het passend maken van een laadpatroon op het apparaat.

• DSpark speculatieve sampling — een gekoppeld conceptmodel-pad, afzonderlijk gepubliceerd als openbmb/MiniCPM-V-4.7-35B-A3B-DSpark, en geïntegreerd naast het plannings- en kwantisatiewerk.

Bij elkaar opgeteld leveren deze het meest in het oog springende cijfer van de release op: 13-plus tokens per seconde met ongeveer 3 GB geheugen op een iPhone 17 Pro Max. Dat is een cijfer van de leverancier, op hardware van de leverancier, met software van de leverancier — een app die OpenBMB heeft geschreven. Het is zo'n bewering die ofwel het hele product is of helemaal niets, en momenteel is er voor niemand buiten het bedrijf een manier om die te verifiëren, omdat het reproduceren ervan de on-device-stack vereist waarop de telefoondemo draait.

Token-efficiëntie is reëel, maar het is hier een matrix, geen scalair.

Er is een detail in deze release dat uit elke samenvatting ervan is weggelaten, en het is precies het detail dat de token-economie daadwerkelijk bepaalt.

• MiniCPM-V 4.7 35B-A3B ondersteunt gemengde 4x- en 16x-compressie van visuele tokens, per verzoek selecteerbaar. De 16x-instelling voegt visuele tokens samen voor snelheid; 4x behoudt er vier keer zoveel, voor detail. De standaardwaarde van de kaart is 16x, en de parameter moet zowel aan de chat-template als aan de generate-aanroep worden doorgegeven, anders komen het aantal placeholders en de vision-encoder niet overeen.

• De eigen vision-language-vergelijkingstabel van de leverancier vermeldt de compressie-instelling die voor de rij van elk model is gebruikt. In die tabel staat de rij MiniCPM-V 4.7 35B-A3B op 4x — de detailbehoudende instelling, d.w.z. de dure — en de rij Qwen3.6 35B-A3B staat op 16x. Een 31B Gemma 4-rij staat vermeld op 9x; de twee 27B Qwen-rijen op 4x.

• Een voetnoot stelt duidelijk dat MiniCPM-V 4.7 beide instellingen ondersteunt, terwijl de andere modellen in de tabel alleen een vaste compressieverhouding ondersteunen.

Lees je dat samen, dan verandert het beeld. Als de MiniCPM-rij zijn vision-language-scores haalt bij de token-hongerige instelling terwijl de Qwen-rij zijn scores haalt bij de token-zuinige instelling, dan vergelijken de twee kolommen verschillende hoeveelheden visueel detail, en het efficiëntieverhaal is niet "dezelfde input, minder tokens" — het is "aanpasbare input, en dit is de kolom die wint op kwaliteit." Dat is een interessantere en eerlijkere bewering dan die van de tweet, en OpenBMB publiceerde die in een voetnoot in plaats van er vooraan mee te komen.

Het betekent ook dat het getal waar je echt om geeft — tokens per eenheid visueel detail — helemaal niet uit deze tabel valt af te lezen. Het vereist dat beide modellen op dezelfde instelling worden gedraaid, wat niemand heeft gepubliceerd.

De tabel, met de bijbehorende voorbehouden

De kaart wordt geleverd met twee tabellen van de leverancier, één voor vision-language en één voor taal, beide in Instruct-modus, beide tegen een veld dat twee Qwen-modellen uit de 35B-A3B-klasse, een 31B Gemma en twee 27B Qwens bevat. De onderstaande cijfers zijn afgelezen van de eigen PNG-grafiek van de leverancier, en het voorbehoud is structureel: de getallen bestaan alleen als pixels in die grafiek, niet als een tabel, dus wat volgt is geëxtraheerd via machinelezing en kleine transcriptiefouten zijn mogelijk.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91,20 tegenover Qwen3.6 35B-A3B met 90,40. Een verschil van 0,8 punt, op basis van de eigen run van de leverancier.

• OmniDocBench v1.6 — ongeveer 98,2 voor MiniCPM tegenover ongeveer 93,3 voor het Qwen-model, het grootste afzonderlijke verschil in de tabel en het verschil dat er het meest toe zou doen als het gereproduceerd kon worden, aangezien documentparsing doorgaans is waar tokenbudgetten aan worden besteed.

• MMMU — ongeveer 80,2 tegen 80,0, een nek-aan-nekrace op de resolutie van een grafiekafbeelding.

• MMMU-Pro — ongeveer 69,7 tegen 67,7, op een regel waar een 27B Qwen hoger uitkomt dan beide.

• Taaltabel — dezelfde vorm, met de opvallendere cellen voor instructieopvolging en code. IFBench staat vermeld rond 47,7 tegen 35,3, en LiveCodeBench-v6 rond 97,0 tegen 54,3. Die twee zijn zo groot dat ze moeten worden beschouwd als de minst geloofwaardige cellen in de release, totdat iemand anders ze heeft gedraaid: een spreiding van 43 punten op een codebenchmark tussen twee vergelijkbaar grote open MoE-modellen, gemeten door een van de twee partijen, is een bewering die een tweede meetinstrument vereist.

Door de leverancier gerapporteerd, met eigen testharnas, niet gereproduceerd. Dat is het hele verhaal. Als deze cijfers standhouden onder een onafhankelijk testharnas, klopt de Pareto-frontierclaim en is de pagodevideo een voetnoot. Als ze dat niet doen, is de pagodevideo alles wat er is.

Wat de adoptiecijfers zeggen, heeft niets met kwaliteit te maken.

Eén getal in deze vergelijking wordt door niemand betwist, en het is geen benchmark. De downloadteller van Hugging Face, uitgelezen op 13 oktober 2026, toont 630 voor openbmb/MiniCPM-V-4.7-35B-A3Btegenover ongeveer 3,6 miljoen voorQwen/Qwen3.6-35B-A3B— een repository die op 15 april 2026 is aangemaakt en dus ongeveer negen maanden verder op de adoptiecurve zit. Dat verschil meet tijd, niet verdienste, en het is de reden dat de efficiëntievraag überhaupt in deze richting wordt gesteld: de nieuwkomer moet op per-tokenbasis argumenteren, juist omdat hij niet negen maanden de tijd heeft gehad om de standaard te zijn.

Er zit ook een kleine interne tegenstrijdigheid in de listing die het vermelden waard is. De repository draagt de tag 'On-Device Model', geërfd van de rest van de familie, en een sparse MoE met 35,2 miljard parameters in 70,4 GB aan BF16-gewichten is niet on-device in welke zin een downloader dan ook zou herkennen. Het on-device-verhaal is echt, maar het loopt via kwantisatie en expert-streaming bovenop het checkpoint, niet via het checkpoint. Begroot op basis van de gekwantiseerde build en de app, niet op basis van de tag.

Wat je er deze week aan kunt doen

De praktische positie is beperkt en duidelijk. Als je de efficiëntieclaim wilt laten verifiëren, valt er nog niets te verifiëren — het is de grafiek van één leverancier, en het enige getal met een per-taakcijfer eraan gekoppeld (10% minder tokens, één pagode) komt uit één enkele demo van een derde partij. Als je het model wilt draaien, vallen de gewichten onder Apache-2.0, is de architectuur gedocumenteerd, en kun je de downsampling-instelling zelf kiezen, wat een echte en ondergewaardeerde hefboom is: 16x wanneer doorvoer belangrijk is, 4x wanneer de grafiek je een document toont.

De ene helft van deze vergelijking is vandaag bereikbaar via een gehoste API en de andere niet, en het loont om precies te zijn over welke welke is. qwen/qwen3.6-35b-a3bis een gehost model op OrcaRouter — het staat in de catalogus achter één sleutel, tegen Qwens eigen lijstprijs zonder dat er iets bovenop komt, en stuurt door naar de provider die op dat moment gezond is in plaats van naar een die je hebt vastgezet. MiniCPM-V 4.7 wordt niet door ons gehost; het is een checkpoint met open gewichten dat je zelf serveert. Die asymmetrie is hier het nuttige. Je kunt de Qwen-kant van deze vergelijking vanmiddag in een baseline zetten, de harness van OpenBMB op je eigen data ertegen draaien, en de grafiek van de leverancier de hypothese laten zijn in plaats van het antwoord.

Wat, aangezien de hele discussie over efficiëntie op jouw hardware gaat, de enige meting is die dit ooit zou kunnen beslechten.