MiniCPM-V 4.7 stopt een 35B-visiemodel in 3 GB: de claim van 100 tok/s ontrafeld

Een model met 35 miljard parameters past niet in drie gigabyte. MiniCPM-V 4.7 35B-A3B draait toch in ongeveer drie gigabyte, en beide uitspraken zijn waar — dat is precies de truc, en de reden om even stil te staan bij de cijfers die over deze release rondgaan. Het model is OpenBMB's eerste sparse mixture-of-experts-model in de MiniCPM-V-lijn: 35,2 miljard opgeslagen parameters, ongeveer 3 miljard actief per token, Apache-2.0, gewichten op Hugging Face. Het leest afbeeldingen, sets met meerdere afbeeldingen en video, en antwoordt in tekst. Sinds 10 oktober draait het ook in upstream llama.cpp, waar de meeste mensen het tegenkwamen. Wat volgt onderscheidt de drie cijfers die iedereen herhaalt — 3 GB, 35B en het cijfer van 100 tok/s — en laat zien welke daarvan OpenBMB daadwerkelijk heeft gepubliceerd. Meer dan 200 gehoste modellen, één sleutel, de lijstprijs van de provider tegen 0% markup doorgegeven. Bekijk wat OrcaRouter routeert De open-weight checkpoint blijft op je hardware; de gehoste ontsnappingsroute is één endpoint. De gedocumenteerde AI-fouten en agentincidenten achter releases zoals deze zijn verzameld in het OrcaRouter AI Incident Archive waar elke vermelding eigen bronnen, ernst, betrouwbaarheidsgraad en betwist-markering bevat.

Drie gigabyte, vijfendertig miljard parameters, en geen tegenstrijdigheid

De rekensom lijkt alleen onmogelijk als je aanneemt dat "in het geheugen" betekent "alles ervan". MiniCPM-V 4.7 35B-A3B houdt ongeveer 3 miljard parameters resident en streamt de overige experts binnen wanneer de router erom vraagt — de eigen formulering van de modelkaart is Lookahead Expert Scheduling, een routeringsvoorspeller over lagen heen die de experts voorspelt die de volgende laag waarschijnlijk nodig heeft en die het laden daarvan overlapt met berekeningen die al gaande zijn. De kaart benadrukt zorgvuldig dat voorspelling alleen prefetch en scheduling aanstuurt; tokens volgen nog steeds de echte routering van het model, en een expert die de voorspeller heeft gemist, wordt geladen en geëvalueerd zoals elke andere.

Dat onderscheid heeft een meetbaar gevolg. De GGUF-repository publiceert het volledige model in elke gangbare kwantisatie, en geen van die bestanden is drie gigabyte:

• Q4_K_M — 21,2 GB op schijf.

• Q8_0 — 36,9 GB.

• F16 — 69,4 GB.

• Vision-projector — 0,9 GB bij 4x-compressie, 1,1 GB bij f16.

Dus "3 GB" is een cijfer voor resident geheugengebruik bij expert-streaming op een telefoon, geen downloadgrootte en geen VRAM-vereiste voor een desktop. Als je een deployment plant, is het getal dat je schijf en je eerste laadbeurt bepaalt 21,2 GB bij Q4_K_M, en het getal dat je stabiele voetafdruk op een telefoon bepaalt is de ~3 GB van de leverancier. Beide staan in de release. Ze beantwoorden verschillende vragen, en het grootste deel van de berichtgeving heeft ze tot één getal samengevoegd.

Waar 100 tok/s vandaan komt, en waar niet

Dit is het punt waarop we eerlijk moeten zijn. OpenBMB publiceert geen cijfer van 100 tok/s voor MiniCPM-V 4.7. Het getal op de modelkaart is 13+ tokens/s, op een iPhone 17 Pro Max, bij ongeveer 3 GB geheugen. Dat is de enige claim over on-device doorvoer in de release, en die is door de leverancier gemeten op hardware die niemand buiten het lab heeft gereproduceerd.

Er bestaan wel hogere getallen, en die komen uit een ander artefact. OpenBMB's llama.cpp-omni-fork — de repository die de on-device-optimalisaties bevat — publiceert zijn eigen tabel voor het 35B-A3B-doel, met een uitsplitsing naar welke optimalisaties zijn ingeschakeld:

• iPhone 18 Pro Max, 12 GB — 3,38 tok/s als baseline, 11,34 met {{1}}Lookahead Expert Scheduling{{/1}}, 17,16 met toegevoegde gemengde precisie, en 20,51 met daarbij ook de {{2}}DSpark draft head{{/2}}.

• iPad Pro 11-inch M4, 16 GB — 2,97 tok/s basislijn, 9,81 met LES, 14,92 met gemengde precisie, 17,39 met DSpark.

Dat zijn de hoogste gepubliceerde cijfers op het apparaat voor dit model, en de top van de ladder is 20,51 tok/s — een vijfde van 100. Het verschil is belangrijk omdat het verandert waarvoor het model dient. Bij 13 tok/s beantwoordt een telefoonapp een vraag over een foto in een paar seconden. Bij 100 tok/s zou je het overwegen als een streaming eerste-pass-lezer voor video. Het eerste is een echt product. Het tweede is niet wat er is uitgeleverd, en iedereen die zijn planning op het getal uit de tweet baseert, zal met een factor vijf teleurgesteld worden.

De eerlijke interpretatie van de bewering van 100 tok/s is dat het een samenvatting is van drie afzonderlijke feiten — 3 GB, draait lokaal, veel sneller dan de vorige generatie — in één getal dat geen van de bronnen bevat. De verbetering generatie op generatie is echt en groot: 3,38 naar 20,51 tok/s is een 6x-verbetering op hetzelfde type apparaat, bereikt door drie technieken te combineren in plaats van door een grotere chip.

De release was niet één dag, en de data doen ertoe.

MiniCPM-V 4.7 dook op zoals veel open-weight releases tegenwoordig: eerst de bestanden, later de uitleg, en de frameworkondersteuning ergens daartussenin.

• 6 oktober, 17:40 UTC — het 1B-model en zijn AWQ-, GPTQ- en int4-varianten verschijnen op Hugging Face, plus de GGUF-builds om 18:05.

• 7 oktober, 07:07 UTC — de 35B-A3B-repository verschijnt. Nog steeds geen modelkaart.

• 8 oktober — DSpark-heads voor speculatieve decoding voor beide groottes, en een FP8-build van de 35B.

• 10 oktober, 18:42 UTC — llama.cpp voegt modelondersteuning samen.

• 12 oktober — OpenBMB committet de modelkaart, verklaart Apache-2.0 en kondigt de release aan als een gedocumenteerd product.

• 15 oktober — de DSpark-heads zijn gelinkt vanaf de hoofdcard, met GGUF-drafts voor beide targets.

Die volgorde verklaart veel van de verwarring in de secundaire berichtgeving. Wie het model in de tweede week van oktober via llama.cpp tegenkwam, draaide een release die officieel nog niet bestond, zonder licentielabel en zonder benchmarkgrafiek, en hun doorvoercijfers weerspiegelen de eigen quantisatiekeuzes van het framework in plaats van wat dan ook dat OpenBMB had gebenchmarkt.

llama.cpp-ondersteuning: samengevoegd, en nog niet helemaal afgerond

De upstream pull request die MiniCPM-V 4.7 toevoegde, is opvallend duidelijk over wat er is veranderd, en het antwoord is: architectonisch bijna niets. Het model is bijna identiek aan MiniCPM-V 4.6; het verschil is 3D RoPE, een positie met drie waarden per token — tijd, rij, kolom — in plaats van de enkele scalair die de meeste vision-language-modellen gebruiken. De ondersteuning breidt het bestaande 4.6-pad uit om die extra dimensie mee te dragen. De PR vermeldde het model ook als "aankomend" toen deze op 25 september werd geopend, wat een goede aanwijzing is voor hoe vroeg de gewichten in omloop waren.

Deze erfenis is het kennen waard voordat je er een grounding-functie op bouwt. Sinds die merge kent upstream llama.cpp de image-markertokens de verkeerde posities toe in MiniCPM-V 4.7-prompts: de image-tokens zelf komen correct terecht, maar <slice>, </slice> en de markers voor het einde van een rij worden genummerd als platte tekst in plaats van dat ze hun tegelhoekcoördinaten krijgen zoals de referentie-implementatie get_rope_index doet. Het zichtbare symptoom is dat geretourneerde coördinaten systematisch te laag uitvallen wanneer je vraagt waar iets in een afbeelding staat. Een oplossing met een unit test bestaat als een open pull request, gedateerd 14 oktober, en per 20 oktober is die nog steeds open. Als je workload 'beschrijf dit' is, zul je het niet merken. Is die 'geef me de bounding box', dan wel, en dan kun je beter wachten op de merge of de fork gebruiken die het gecorrigeerde pad bevat.

Nog één ding overleeft de round trip: voor het 1B-model is de vision-projector de grotere download. De Q4_K_M-gewichten zijn 672 MB; de f16-projector is 1,11 GB. De kleinste bruikbare 1B-deployment is dus ongeveer 1,8 GB aan bestanden, waarvan het grootste deel uit ogen in plaats van taal bestaat — een detail dat elke verwachting dat "1B 1 GB betekent" verkeerd krijgt.

Wat uit te voeren, en waarop

Als het doel is om het deze week uit te proberen, is het pad met de minste frictie llama.cpp of Ollama tegen de GGUF-repositories, waarbij je de multimodale client op het bijpassende mmproj-bestand richt. Op een GPU van 24 GB laat Q4_K_M met 21,2 GB heel weinig ruimte over voor context — een venster van 8K tokens plus afbeeldingstegels past niet comfortabel, dus reken op Q4_K_S of een kleinere kwantisatie als je ook een lange prompt wilt. Op een Mac met 32 GB of meer is Q8_0 haalbaar en dat komt het dichtst bij het referentiegedrag. Op een telefoon beschikken alleen de eigen apps van de leverancier en de llama.cpp-omni-fork over het expert-schedulingwerk; standaard llama.cpp levert je correctheid, niet de 20 tok/s.

Waar een routeringslaag hier zijn bestaansrecht verdient, is aan de andere kant van de lokale aanroep. Een model met 3B actieve parameters op een telefoon is uitstekend in het routinewerk — lees deze bon, ziet dit schap er gevuld uit, wat staat er op dit bord — en af en toe krijgt het een pagina die het niet afgemaakt krijgt. OrcaRouter zet meer dan 200 gehoste modellen achter één sleutel, geeft de lijstprijs van elke provider door tegen 0% markup zodat een prijswijziging van een leverancier dezelfde dag live is, en schakelt automatisch over wanneer een upstream terugloopt. Het patroon dat werkt is lokaal-eerst met een gehoste terugvaloptie, niet uitsluitend lokaal. Het open-weight checkpoint blijft van jou om te hosten; de router regelt alles wat de telefoon overdraagt.

MiniCPM-V 4.7 wordt niet aangeboden door OrcaRouter, en we gaan niet suggereren dat dat wel zo is. Het is een checkpoint die je zelf draait.

Wat zou de drie getallen bepalen?

Een onafhankelijke meting van het 35B-model op een bij naam genoemde telefoon, met vermelding van de app en de quantisatie, zou de doorvoervraag beslechten — inclusief of 20,51 tok/s de stopwatch van iemand anders doorstaat. Een gepubliceerde definitie van het 3 GB-cijfer — resident set, piekallocatie of iets anders — zou de geheugenvraag beslechten. En een tabel per benchmark met echte scores, in plaats van de vijf gelinkte grafieken die de kaart momenteel meelevert, zou het mogelijk maken de claim "beter dan Qwen3.6 35B-A3B in minder tijd" te toetsen aan de weging die OpenBMB koos. Niets daarvan bestaat nog. Totdat dat wel zo is, is de accurate zin de saaie: een 35B-spaarmodel dat op een telefoon draait met een gerapporteerde snelheid van ruim 13 tokens per seconde in ongeveer 3 GB, met een download van 21 GB en een samengevoegd frameworkpad dat nog steeds één open coördinatenbug heeft.