De "3B Active Parameters" van MiniCPM-V 4.7 staan niet in de modelkaart — ik heb ze zelf uit de gewichten gemeten

Het meest herhaalde getal over MiniCPM-V 4.7 35B-A3B staat nergens in de eigen documentatie. De bewering — "slechts 3B actieve parameters (!) — hij draait zelfs op een iPhone" — komt uit een post van een derde partij van 13 oktober 2026, en de modelkaart, README van de repository en introductienotities van de leverancier vermelden helemaal geen aantal actieve parameters. Dat is niet zozeer kritiek op de bewering als wel een leemte die het waard is te dichten: de checkpoint codeert zijn eigen antwoord. Dus heb ik, vóór al het andere hier, de safetensors-index en elke shard-header van openbmb/MiniCPM-V-4.7-35B-A3B opgehaald en geteld. Ter vergelijking: het andere model in dezelfde post — Qwen3.8-27B, uitgebracht op 13 augustus 2026 — is een dense 27B-model en kent geen dergelijke ambiguïteit die opgelost moet worden: elke parameter is actief bij elke token. De interessante vraag is of "3B actief" het contact met de gewichten overleeft, en het antwoord is: het overleeft, maar alleen als je het woord "actief" definieert zoals de leverancier dat doet, en het eerlijke getal ligt dichter bij 4B zodra je de onderdelen meetelt die je onvermijdelijk moet laten draaien.

Het grootboek, gelezen vanaf het controlepunt zelf

Het indexbestand vermeldt 40 taallagen plus een vision tower en een projector, in totaal 35.212.875.824 parameters in BF16 — 70,43 GB aan gewichten om te downloaden. Dat komt overeen met de "35B" in de naam. De MoE-vraag is welk deel daarvan per token wordt aangeraakt:

• Totaal opgeslagen — 35,21 miljard parameters, 70,43 GB in BF16. Elke expert staat op schijf, ongeacht of hij wordt gebruikt.

• Routerbudget — 8 experts geselecteerd per token, van de 256, per MoE-laag. Geconfigureerd in config.json als num_experts_per_tok: 8. Elke expert is klein: 3,15M parameters.

• MoE-pad per laag — 8 experts (25,17M) + een gedeelde expert (3,15M) + de router-poort (0,52M) ≈ 28,83M.

• Attention-pad per laag — de architectuur is hybride: 30 van de 40 lagen gebruiken lineaire attention (elk 33,72M), 10 gebruiken volledige attention (elk 27,26M). Totaal ≈ 2,44B over alle 40 lagen voor attention plus MoE-rekenwerk, herhaald per token.

• Plus wat je niet kunt overslaan — token-embeddings 508,2M, LM-head 508,2M, vision tower 522,3M, projector 30,7M.

• De twee verdedigbare antwoorden — ~2,44 miljard actief alleen op het attention-en-MoE-pad; ~4,01 miljard als je embeddings, output head, vision tower en projector meetelt, die een vision-aanvraag wel aanspreekt.

Dus "3B active" is niet fout. Het is een naar boven afgeronde 2,44B, en het valt in de kloof tussen de twee bovenstaande getallen. Het is alleen geen cijfer dat OpenBMB heeft gepubliceerd, en het is niet hetzelfde als het achtervoegsel "A3B" — dat achtervoegsel maakt deel uit van de naam van het model, en in de eigen materialen van de leverancier wordt het nooit als een meting gebruikt.

Waarom het achtervoegsel en het nummer niet hetzelfde zijn

Naamgevingsconventies in het open-weights-ecosysteem impliceren een aantal actieve parameters: een model dat 30B-A3B of 235B-A22B heet, vertelt je dat het ongeveer zoveel parameters per token activeert. Die implicatie is doorgaans betrouwbaar — maar het is een conventie, geen contract, en MiniCPM-V 4.7 is een geval waarin niets in de kaart, de README of het lanceringsbericht de "A3B" omzet in een getal waarmee je je geheugengebruik kunt plannen. Totdat iemand telt, is het achtervoegsel een label.

De telling hierboven is rekenwerk, geen gevolgtrekking uit dat label. Het is ook de reden waarom de cijfers ~2,44 miljard en ~4,01 miljard van elkaar verschillen: of je de embeddingtabel en de output-head meetelt, is een echte beslissing, geen muggenzifterij. Bij een dense model zijn embeddings een klein deel van een budget van 27 miljard. Bij een sparse model waar het rekenpad per token slechts een paar miljard parameters omvat, zijn een embeddingtabel van 508 miljoen en een LM-head van 508 miljoen niet langer ruis — samen vormen ze ongeveer een vijfde van het actieve pad, en ze worden op volledige breedte opgeslagen terwijl de experts worden gekwantiseerd.

Eén gevolg is het waard ronduit te zeggen: de verhouding tussen opgeslagen en actieve parameters is hier ongeveer 8,8 staat tot 1 in de enge interpretatie. Dat is precies waarom een 35B-model als telefoonmodel kan worden gepresenteerd, en het is ook de reden waarom het dat niet is op de manier waarop een 3B-dense model dat is. Opslag krimpt niet wanneer de router een expert negeert.

De iPhone-bewering is een afzonderlijke bewering met een afzonderlijke bewijsbasis.

Alle concrete informatie over de prestaties op het apparaat in deze release is door de leverancier gerapporteerd en niet gereproduceerd. Het specifieke cijfer is 13+ tokens per seconde bij ongeveer 3 GB geheugen op een iPhone 17 Pro Max, waarbij hetzelfde checkpoint op een iPad M4 werd gedemonstreerd. OpenBMB schrijft dit toe aan drie technieken die samenwerken — Lookahead Expert Scheduling, dat cross-layer routing voorspelt en experts prefetcht, fijnmazige kwantisatie per laag, en DSpark speculative sampling — en beschrijft het resultaat als het eerste opensource-MoE-model dat soepel op het apparaat draait zonder aan capaciteiten in te boeten. Er is geen onafhankelijke meting van die doorvoersnelheid in de openbare bronnen, geen reproductie door derden, en geen gepubliceerde uitsplitsing van welke kwantisatie aan het 3 GB-cijfer ten grondslag ligt.

Dit is om een specifieke reden van belang: 3 GB is het getal dat bepaalt of de bewering voor jou interessant is, en het is het getal waarover we het minst weten. Een 35B MoE waarvan de expertgewichten grotendeels op flashopslag staan, is geen 3 GB-model; het is een model waarvan de residente werkset toevallig in 3 GB past zodra routeringsvoorspellingen, prefetch en een gekwantiseerde expertcache allemaal hun werk doen. Dat zijn precies de omstandigheden waaronder benchmarkdoorvoer en doorvoer in de praktijk uiteenlopen — de eerste prompt warmt de cache op, en het gedrag dat je in een demo 13 tokens per seconde oplevert, is een planning, niet een eigenschap van de gewichten.

Beschouw de 13 tokens per seconde als een bewering over een techniek, niet over het checkpoint. Het checkpoint is wat je vandaag kunt verifiëren: 35,21B opgeslagen, 8 van 256 experts per token gerouteerd, ~2,44B tot ~4,01B actief afhankelijk van wat je meetelt, Apache-2.0, day-0-kwantisaties in GGUF, AWQ, GPTQ, int4 en FP8, en een leverancierslijst van ondersteunde chips, waaronder Rockchip, Houmo, Intel, AMD en Arm.

Wat de actieve telling wel en niet bepaalt

Het aantal actieve parameters is een proxy voor de rekenbelasting. Het vertelt je hoeveel matrixvermenigvuldigingen er per token plaatsvinden, wat bepaalt hoe snel een GPU-gebonden decode draait. Het vertelt je niet hoeveel geheugen je nodig hebt om het model in het geheugen te houden; dat wordt bepaald door het totaal — 70,43 GB aan BF16-gewichten, of ongeveer een kwart daarvan bij 4-bit, voordat je rekening houdt met een KV-cache. Bij een model met een 256K-context is die cache ook geen afrondingsfout.

• Decodesnelheid — bepaald door de actieve parameters (hier ~2,44B–4,01B). Dit is waar het bij de bewering van 13 tokens/s om gaat.

• Resident geheugen — bepaald door het totale aantal parameters (35,21B opgeslagen), vervolgens verlaagd door kwantisatie en door welke expertset dan ook resident blijft.

• Opslag en laden — bepaald door de volledige 70,43 GB bij BF16. Sparse routing verkleint de download niet.

• Bandbreedte, niet flops — op een telefoon is de beperkende factor het experts door een geheugenbus heen krijgen, wat verklaart waarom de schedulingtechniek bestaat en waarom een actieve telling op zich niets voorspelt over mobiele latentie.

De praktische conclusie: als je een GPU hebt met genoeg geheugen om de gekwantiseerde gewichten te bevatten, bepaalt het aantal actieve parameters je doorvoer, en "3B active" is een goede zaak. Als jij de reden bent dat de zin "draait op een iPhone" in een bericht voorkomt, is het totale aantal parameters het getal dat bepaalt of het haalbaar is, en het planningswerk van de leverancier is het deel dat het totale aantal werkbaar maakt. Beide interpretaties van dezelfde kop zijn correct, en het zijn niet dezelfde interpretatie.

De vergelijking in dat bericht heeft twee labels nodig, niet één.

De framing die hier de ronde deed, was lokaal versus dure hardware: MiniCPM-V 4.7 35B-A3B als het model dat je dezelfde capaciteit geeft zonder de rig, tegenover Qwen3.8-27B als het model dat slimmer was maar de rig nodig had. Het capaciteitsdeel daarvan komt uit de eigen modelkaart van Qwen, en het is door de leverancier gerapporteerd, zoals alles op deze pagina. De gepubliceerde cijfers van Qwen voor Qwen3.8-27B omvatten 90,3 op LiveCodeBench v6, 89,2 op GPQA Diamond, 84,3 op OSWorld-Verified en 79,0 op QwenSWEBench, en onze eigen catalogusvermelding voor dat model merkt die aan als ongewoon sterke agentische en coderesultaten voor een 27B dense model. Of het "slimmer was dan Opus 4.6" is een claim uit de socialmediapost, en ik heb geen onafhankelijke evaluatie voor me die dat beslecht — dus ik ga het niet als feit herhalen.

Het structurele verschil is het verschil dat daadwerkelijk te controleren valt: Qwen3.8-27B is dense, dus zijn 27B-parameters zijn allemaal actief en zijn geheugenvoetafdruk en zijn rekenkosten zijn hetzelfde getal. MiniCPM-V 4.7 35B-A3B scheidt die twee getallen met ruwweg een factor negen van elkaar. Dat is het hele architectonische argument, en het is echt. Het is alleen niet hetzelfde als een benchmarkvergelijking, en de post die het beroemd maakte, vermengde de twee.

Waar een router de beslissing wel verandert, en waar niet

Er zijn hier twee dingen waar, en het loont ze te scheiden, want ze wijzen in tegengestelde richtingen.

Het eerste is dat we MiniCPM-V 4.7 niet aanbieden. Het staat niet in onze catalogus. Als je het wilt, is de weg je eigen hardware — precies waarvoor de release is ontworpen, met gewichten, quantisaties en handleidingen voor implementatie op het apparaat die er samen mee worden gepubliceerd. Een gehoste API helpt je op geen enkele manier om een model op een telefoon te draaien, en het zou misleidend zijn om iets anders te suggereren.

Het tweede is dat het model waarmee dit model wordt vergeleken, zich niet in die positie bevindt. Qwen3.8-27B is beschikbaar via onze API, self-hosted op onze eigen infrastructuur, voor $0,33 per miljoen inputtokens en $2,40 per miljoen outputtokens. Als de vraag die je eigenlijk stelt is "vervang ik mijn gehoste Qwen3.8-27B-aanroepen door een lokaal uitgerolde MiniCPM-V 4.7", dan is het eerlijke antwoord dat je het experiment moet uitvoeren voordat je je vastlegt: het on-device-doorvoercijfer is niet gereproduceerd, en de capaciteitsvergelijking komt uit de eigen kaart van de andere partij. Dat is precies de situatie waarvoor failover bestaat — leid een fractie van het verkeer langs een nieuw pad, houd het bewezen pad daarachter, en laat een slechte week je een fractie van een workload kosten in plaats van de hele workload. Een model met 0% opslag houdt ook de rekensom eerlijk: wanneer een leverancier een prijs wijzigt, beweegt het bedrag dat je betaalt dezelfde dag mee, omdat er geen margelaag zit tussen hun lijstprijs en jouw factuur.

Wat een router niet kan, is de vraag lokaal versus gehost laten verdwijnen. Die wordt bepaald door je hardware, je privacybeperkingen en of een download van 70 GB acceptabel is — en het aantal actieve parameters, hoe je het ook afrondt, verandert niets aan die drie.

Wat zou het beslechten?

Drie dingen, in aflopende volgorde van nut. Een door OpenBMB gepubliceerd cijfer voor actieve parameters, zodat het getal dat iedereen herhaalt niet langer het rekenwerk van een derde partij is — inclusief het mijne, en het mijne is reproduceerbaar op basis van de shard-headers als je het er niet mee eens bent. Een onafhankelijke meting van de 13 tokens per seconde op een telefoon, met vermelding van de kwantisatie-instellingen, want een schema-afhankelijk cijfer zonder de bijbehorende instellingen is geen specificatie. En een echte evaluatie die MiniCPM-V 4.7 35B-A3B vergelijkt met Qwen3.8-27B op dezelfde taken, aangezien de vergelijking die dit model opmerkelijk maakte momenteel een grafiek van de ene leverancier tegen de kaart van een andere leverancier is.

Tot die tijd is de veilige samenvatting beperkter dan het bericht: de gewichten zijn echt, de sparsity is echt, de download is 70,43 GB, en per token verricht het model werk ter waarde van ergens tussen 2,4 en 4 miljard parameters, afhankelijk van hoe je de onderdelen telt die je niet kunt omzeilen via routing. Dat is een echt engineeringresultaat. Het is nog geen gemeten telefoonbenchmark, en het is geen benchmarkoverwinning ten opzichte van een dense 27B.

Bronvermelding: parameters, aantallen experts, laagtypen, contextlengte en downloadgrootte zijn rechtstreeks uitgelezen uit config.json en de safetensors-shardheaders van openbmb/MiniCPM-V-4.7-35B-A3B op 13 oktober 2026. Snelheid op het apparaat, geheugenwaarde, benchmarkresultaten en de evaluatiecijfers van Qwen3.8-27B zijn door de leverancier gerapporteerd en niet gereproduceerd. De beweringen "3B actieve parameters" en "slimmer dan Opus 4.6" zijn afkomstig uit een socialmediapost van een derde partij, niet van een van beide leveranciers.

Niets daarvan is hypothetisch: de gedocumenteerde AI-fouten en agentincidenten waarin een cijfer als dit wordt aangehaald, zijn verzameld in the OrcaRouter AI Incident Archive, waar elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwist-markering heeft.