MiniCPM-V 4.7 kreeg een modelkaart: OpenBMB publiceerde de benchmarks, de licentie en de on-deviceclaim

Gedurende de eerste zes dagen van zijn bestaan was MiniCPM-V 4.7 een map van 70 GB met bfloat16-tensors zonder README — geen modelkaart, geen licentietag, geen benchmarktabel, niets dat je vertelde waarvoor het diende. Dat veranderde op 12 oktober 2026, toen OpenBMB een volledige modelkaart toevertrouwde aan openbmb/MiniCPM-V-4.7-35B-A3B, verklaarde een Apache-2.0-licentie, herschreef de README van de MiniCPM-o-repository om de nieuwe serie voorop te stellen, en kondigde het aan als een open-source MLLM-release gericht op iOS-, Android- en HarmonyOS-apparaten. Dezelfde documentatieronde raakte de 1B-variant, die nu dezelfde kaartstructuur heeft. Dit stuk gaat over de delta — wat de kaart daadwerkelijk beweert, welke van die beweringen je zelf kunt controleren, en welke vandaag de dag alleen bestaan als pixels in een door de leverancier geleverde PNG.

Wat is er op 12 oktober aangekomen, en wat was er al?

De gewichten zijn niet gewijzigd. openbmb/MiniCPM-V-4.7-1B is aangemaakt op 6 oktober 2026 om 17:40 UTC en openbmb/MiniCPM-V-4.7-35B-A3B op 7 oktober om 07:07 UTC; beide vermelden nog steeds een laatst-gewijzigd-tijdstempel van 12 oktober, omdat die laatste dag aan tekst werd besteed, niet aan parameters. Het commitlogboek op de 35B-repository voor 12 oktober is een documentatiesprint: model card toevoegen om 16:08, model card bijwerken om 16:15, 35BA3B hernoemen om 16:23, metadata toevoegen om 16:26, absolute asset-urls om 16:50, vier get started toevoegen-commits tot 17:07, en LES-doc linken om 17:09. Alles onder die regel in de geschiedenis is init. De repository ging van achttien bestanden en geen model card naar een gedocumenteerde release met afbeeldingen, evaluatiegrafieken, deployment-instructies en een licentie, in ongeveer een uur.

Dat is van belang voor hoe je de aankondiging leest, want een lanceringsbericht is niet hetzelfde als een lancering. Aan de checkpoint is op 12 oktober niets veranderd. Wat veranderde, is dat MiniCPM-V 4.7 ophield een onverklaarde upload te zijn en een product werd dat je op papier kunt beoordelen.

De twee varianten, en waarom ze niet dezelfde release zijn

De aankondiging beschrijft twee modellen, en onder de vision tower zijn ze architectonisch niet verwant — het ene is een sparse mixture-of-experts, het andere een klein dense model.

• MiniCPM-V 4.7 35B-A3B — 35,2 miljard totale parameters als een sparse MoE, 256 experts met 8 actieve per token, 40 tekstlagen, verborgen grootte 2.048, 16 query-heads tegenover 2 key/value-heads, maximale positie van 262.144 tokens, vocabulaire 248.144.

• MiniCPM-V 4.7 1B — een dense qwen3_5_text backbone, 24 lagen met verborgen grootte 1.024, 8 query-heads tegenover 2 key/value-heads, dezelfde context van 262.144 tokens, vocabulaire 248.094, één enkel safetensors-bestand van 3,1 GB.

• Gedeelde visietoren — minicpmv4_7_vision, 27 lagen met verborgen grootte 1.152, patchgrootte 14, afbeeldingsgrootte 980, ingevoegd op laag 6 van de tekststack.

• Compressie — gemengde downsampling van visuele tokens met 4x en 16x, met de intra-ViT-vroege-compressietechniek die OpenBMB toeschrijft aan LLaVA-UHD v4; de standaard is 16x, en 4x is de instelling voor fijnere details.

• Attentievorm — een drie-op-één herhalend patroon in beide varianten: drie linear_attention-lagen gevolgd door één full_attention-laag, tien keer over de 40 tekstlagen van het 35B-model.

• Licentie — Apache-2.0 voor beide, aangegeven in de front matter van de kaart, wat de eerste keer is dat een van beide repositories überhaupt voorwaarden heeft vermeld.

De 35B-A3B is degene waarmee de aankondiging opent, en het is degene met het interessante engineeringverhaal: de hele propositie is dat een sparse MoE met 35 miljard opgeslagen parameters soepel op een telefoon kan draaien.

De claim dat het op het apparaat gebeurt, is de eigenlijke nieuwigheid, en het is een planningsprobleem.

Iedereen die ooit heeft geprobeerd een MoE op een telefoon te draaien, kent de faalmodus. De totale parameters staan in opslag, slechts een handjevol wordt per token geactiveerd, en op een apparaat zonder de RAM of bandbreedte om elke expert vast te houden, worden gewichten in en uit gepagineerd. Het resultaat decodeert met een snelheid die een gesprek onmogelijk maakt. De voor de hand liggende workaround — de router vastzetten op een vaste subset experts voor de hele prompt — maakt het snel en ontneemt het stilzwijgend capaciteit, omdat tokens niet langer experts kunnen bereiken die het model anders zou hebben gekozen.

Het antwoord van OpenBMB bestaat uit drie technieken die op elkaar zijn gestapeld, en de kaart is ongewoon specifiek over wat elk van hen doet:

• Lookahead Expert Scheduling (LES) — een voorspeller voor routering over lagen heen laadt experts voor die waarschijnlijk door de volgende laag nodig zijn, geeft prioriteit aan de experts die de echte router daadwerkelijk heeft geselecteerd en laat hun berekening overlappen met het laden van al het overige dat nog nodig is. De kaart benadrukt zorgvuldig dat voorspelling alleen prefetch en planning aanstuurt; de berekening volgt nog steeds de eigen routering op tokenniveau van het model, en experts die de voorspelling heeft gemist, worden gewoon geladen en geëvalueerd.

• Fijnmazige laagsgewijze kwantisering — verkleint de voetafdruk van expertgewichten en het geheugenverkeer, zodat het laadpatroon past binnen het geheugen en de bandbreedte van het apparaat.

• DSpark speculatieve sampling — integreert het conceptmodelpad in de apparaatinferentielus, naast planning en kwantisatie.

Het opvallendste cijfer is 13+ tokens per seconde op een iPhone 17 Pro Max voor de 35B-A3B. Dat is een leveranciersmeting, op een toestel dat we niet hebben gezien, met een app die we niet hebben gedraaid, en het is het cijfer in deze release dat het meest losjes moet worden vastgehouden totdat iemand buiten het lab het reproduceert. Het is ook de bewering waarop de hele "eerste open-source MoE die soepel op het toestel draait zonder concessies te doen aan prestaties"-framing rust — een bewering die per definitie moeilijk te falsificeren is, omdat "zonder concessies te doen aan prestaties" wordt afgemeten tegen een basislijn die de leverancier kiest.

Het deel van de kaart dat echt nieuwe informatie is: de ecosysteemlijst

Vóór 12 oktober was er helemaal geen gepubliceerd servingrecept. De kaart noemt nu de frameworks waarmee het model naar verwachting zal werken, en de lijst is breed genoeg om nuttig te zijn, ongeacht hoe de benchmarks uitvallen:

• Inferentie — SGLang, vLLM, llama.cpp en Ollama, met een transformers serve-pad voor een OpenAI-compatibel lokaal eindpunt en een OpenVINO-pad voor Intel CPU, GPU en NPU.

• Fine-tuning — SWIFT en LLaMA-Factory, plus een trainingsrecept dat OpenBMB Self-Replay Fine-Tuning noemt, gepositioneerd als een goedkope manier om capaciteiten uit te breiden en tegelijk vergeten te beperken.

• Kwantificering — GGUF, BNB, AWQ, GPTQ en FP8, met afzonderlijke repositories gepubliceerd voor AWQ-, GPTQ-, int4-, FP8- en GGUF-varianten van het 35B-model.

• Hardware — geclaimde day-0-ondersteuning voor chipplatforms van Rockchip, Houmo, Intel, AMD en Arm, naast implementatie op iOS, Android en HarmonyOS.

• Tooling — een kookboek met taakgidsen voor chat met één afbeelding, chat met meerdere afbeeldingen, video, OCR, PDF-parsing en visuele grounding, plus een repository voor edge-deployment met daarin de telefoonapps.

• Speculatieve decoding — afzonderlijke DSpark-conceptcheckpoints voor zowel de 35B- als de 1B-targets.

Het praktische gevolg is dat MiniCPM-V 4.7 is opgeschoven van "je zou de loader zelf moeten schrijven" naar "er is een gedocumenteerd pad in ten minste vier serving-stacks." Als je op de kaart wachtte voordat je tijd aan een lokale proef besteedde, is het wachten voorbij; als je wachtte op onafhankelijk bewijs dat de on-device-cijfers echt zijn, dan niet.

Wat de benchmarks wel en niet aantonen

De evaluatiesectie van de kaart is eerlijk over wat het is: door de leverancier gerapporteerd, niet onafhankelijk gereproduceerd. Er worden expliciet twee vergelijkingsclaims gemaakt, en beide worden als vergelijkingen gepresenteerd in plaats van als absolute scores. In de Instruct-modus wordt beweerd dat 35B-A3B een hogere totale score behaalt in minder inferentietijd dan Qwen3.6 35B-A3B — een claim over prestatie versus latentie, niet over ruwe kwaliteit. Van de 1B-variant wordt beweerd dat deze de kerncapaciteiten van MiniCPM-V 4.6 verbetert en Qwen3.5 0.8B aanzienlijk overtreft op zowel totale score als inferentie-efficiëntie.

Dit is het deel dat het vermelden waard is. De eigenlijke cijfers staan niet in de tekst. De evaluatiesectie bestaat uit vijf gelinkte afbeeldingen — een algemene prestatiegrafiek voor de vision-language-taken van het 35B-model, een taalgrafiek, de 1B-grafiek, een prestatie-efficiëntie-frontierplot en een GIF met een on-device-snelheidsvergelijking — en de tekst eromheen bevat het verhaal, niet de cijfers. Er is geen per-benchmarktabel in de README, dus er is geen machineleesbare score om te citeren, en daarom niets wat dit artikel als getal kan aanhalen. "Hogere totaalscore dan Qwen3.6 35B-A3B" is op dit moment het meest precieze dat de openbare informatie biedt.

Hieruit volgen twee consequenties. Ten eerste heeft MiniCPM-V 4.7 geen vermelding op de neutrale leaderboards van derden waarnaar we normaal gesproken zouden gaan voor een geauditeerde vergelijking — geen reasoning-index, geen agentic-index, geen onafhankelijk beoordeelde multimodale score. Ten tweede is het aggregaat dat OpenBMB uitzet de eigen composiet van de leverancier over door hem geselecteerde benchmarkgroepen, wat betekent dat de claim van de "hogere totaalscore" alleen zo betekenisvol is als de weging erachter, en die weging is evenmin gepubliceerd. Niets hiervan maakt de cijfers onjuist. Het maakt ze niet-geauditeerd, wat iets anders is, en het onderscheid is juist het belangrijkst precies daar waar de cijfers het sterkst zijn.

Wat je vandaag zelf kunt verifiëren

Strip de marketing weg en er blijft een solide, controleerbare kern over, allemaal leesbaar vanuit de repository zonder iemand te vertrouwen:

• Gewicht in bytes — zestien safetensors-shards in het 35B-model met in totaal 70,425,903,448 bytes, consistent met een BF16 35,2B-checkpoint; het 1B-model is één enkel bestand van 3,1 GB.

• Architectuur — elk structureel cijfer hierboven staat in config.json, openbaar gepubliceerd, en komt overeen met de tekst van de kaart.

• Licentie — Apache-2.0, vermeld in de front matter van de kaart en nu ondubbelzinnig. Voor commercieel gebruik is dit de allerbelangrijkste regel in de release, en hij is nieuw.

• Gekwantiseerde varianten — AWQ-, GPTQ-, int4-, FP8- en GGUF-repositories bestaan en zijn te downloaden, dus het deploymentverhaal is op gewichtniveau niet theoretisch.

• Adoptie-signalen — de 35B-repository staat op ongeveer 166 downloads en 38 likes per 13 oktober, een stap omhoog ten opzichte van de bijna-nul cijfers die erbij hoorden toen het nog een onverklaarde upload was, maar nog steeds een klein aantal voor een vermeende Pareto-frontier-release.

Wat je niet kunt verifiëren, is de bewering waarop de release berust: dat dit de eerste open-source MoE is die op een telefoon draait zonder dat je iets hoeft op te geven, met 13-plus tokens per seconde. Dat wacht op een derde partij met een iPhone en een stopwatch.

Waar een router past, en waar niet

MiniCPM-V 4.7 wordt niet geserveerd door OrcaRouter. Het is een open-weights-checkpoint, wat betekent dat het model zelf iets is dat jij host — op een workstation, op een GPU-box of op de telefoon waarop de kaart is gericht. De plek waar een routeringslaag zijn meerwaarde bewijst, ligt aan de andere kant van die regeling: het punt waarop een zelfgehost visionmodel besluit dat het boven zijn macht gaat en het lastige frame aan iets groters overdraagt. OrcaRouter zet meer dan 200 gehoste modellen achter één sleutel, geeft de lijstprijs van elke provider door met 0% opslag zodat een prijswijziging van een leverancier dezelfde dag nog live is, en schakelt automatisch over wanneer een provider verslechtert — precies de vorm die een hybride opzet nodig heeft, waarbij het goedkope lokale model het routinewerk doet en een gehost model de gevallen opvangt die het niet aankan.

Wat nu te kijken

Drie dingen zouden deze release veranderen van een gedocumenteerde bewering in een vaststaand feit. Een onafhankelijke meting op het toestel zelf van het 35B-model — iemand met een iPhone 17 Pro Max, de gepubliceerde app en zijn eigen timing — zou het getal waarop de hele pitch rust, beslechten. Een tabel per benchmark met werkelijke scores, in plaats van grafieken, zou het Pareto-argument controleerbaar maken tegen de baseline die het noemt. En een run op een neutrale leaderboard zou MiniCPM-V 4.7 naast modellen plaatsen die zijn geëvalueerd onder omstandigheden die het zelf niet heeft gekozen. Tot dan is de eerlijke samenvatting dat OpenBMB een echt, Apache-2.0, goed gedocumenteerd model heeft uitgebracht met een geloofwaardig en onbewezen efficiëntieverhaal, en dat het verschil tussen die twee precies het verschil is tussen een kaart en een benchmark.