MiniCPM-V 4.7 1B op een gewone iPhone: wat "verder gaat dan de Pro Max" eigenlijk betekent

MiniCPM-V 4.7 1B is een vision-languagemodel met 1,55 miljard parameters dat OpenBMB op 6 oktober 2026 naar Hugging Face uploadde en in zijn eigen release notes op 12 oktober dateerde. Het heeft een modelkaart, elf gekwantiseerde varianten, een Ollama-tag en een demo-app die op het toestel zelf draait. Wat het niet heeft, is een versie van het verhaal die standhoudt wanneer je de hardwarekosten meerekent. De bewering die in ontwikkelaarskringen de ronde doet — dat het model nu in een OnDeviceLLM-app op gewone iPhones draait, niet alleen op een 12GB Pro Max — is het deel dat nauwkeurig moet worden bekeken, omdat "op een telefoon draaien" en "op jouw telefoon draaien" worden gescheiden door ongeveer 3 GB aan geheugenruimte die de meeste iPhones niet hebben. De gedocumenteerde AI-fouten en agent-incidenten achter releases als deze zijn verzameld in het OrcaRouter AI Incident Archive, waar elke vermelding haar eigen bronnen, ernst, betrouwbaarheidsgraad en betwiststatus bevat.

Hier is de stand van zaken, met de naden zichtbaar. Alles hieronder is ofwel rechtstreeks uit de gewichtsbestanden gelezen, ofwel uit OpenBMB's eigen documentatie, ofwel uit Apple's gepubliceerde specificaties. Waar een getal uit een bericht van een ontwikkelaar komt in plaats van uit een reproduceerbaar artefact, zegt dit artikel dat.

Wat is daadwerkelijk bekend, en wat is alleen maar beweerd?

Het model is echt en downloadbaar. Het BF16-checkpoint heeft 1.554.476.272 parameters, wat neerkomt op ongeveer 3,1 GB op schijf. De repository bevat een volledige modelkaart — een zeldzaamheid in de recente geschiedenis van deze familie — met een Qwen3.5-tekstruggegraat, een SigLIP2-visietoren met 27 lagen bij een verborgen breedte van 1152, invoertegels van 980 pixels, een contextvenster van 262.144 tokens en Apache 2.0-licentie. OpenBMB's eigen README-vermelding dateert de release op 2026-10-12; de Hugging Face-repository is aangemaakt op 2026-10-06. De kloof van zes dagen is de vertraging tussen uploaden en aankondigen waar deze familie bekend om staat, en het is de reden dat een artikel uit oktober een repository van zes dagen oud nog steeds een stille lancering kan noemen.

Wat niet door enig artefact wordt bevestigd, is de specifieke bewering dat de 1B in OnDeviceLLM draait op "alledaagse iPhones buiten de 12GB Pro Max". Een bericht van een ontwikkelaar is de oorsprong van die framing. De openbare repository van het OnDeviceLLM-project — een starterkit voor offline chat- en vertaalapps, geen product dat in de App Store wordt uitgebracht — heeft nul sterren en is voor het laatst gepusht op 27 juli 2026. Het is tien weken ouder dan de MiniCPM-V 4.7-gewichten, dus eventuele ondersteuning voor dit model erin is recent en ongedocumenteerd. Beschouw "draait al in OnDeviceLLM" als een melding van iemand die het heeft gedaan, niet als een door de leverancier ondersteund implementatiepad.

Dat onderscheid is belangrijk, omdat de eigen on-device-cijfers van de leverancier helemaal niet over de 1B gaan.

Het 3 GB-getal hoort bij de 35B, niet bij de 1B

De hoofdclaim van OpenBMB — "13+ tokens/s met slechts 3 GB geheugen op iPhone 17 Pro Max" — is gekoppeld aan de 35B-A3B Mixture-of-Experts-variant, die draait op de grootste iPhone die Apple verkoopt. De techniek erachter, Lookahead Expert Scheduling, houdt de meeste expertgewichten op de SSD en laadt vooraf de gewichten die de volgende laag waarschijnlijk nodig heeft. Het is een indrukwekkend staaltje systeemtechniek en het is de reden dat de naam 35B steeds opduikt in berichtgeving over telefoons.

De 1B heeft dat allemaal niet nodig. Het is een dense model dat zonder meer in het geheugen past. Op papier maakt dat hem de meer democratische van de twee, en dat is waarom de "alledaagse iPhone"-invalshoek hout snijdt. Maar de rekensom is minder vriendelijk dan de framing suggereert:

• BF16-gewichten — 3,1 GB op schijf, en ongeveer evenveel geheugen bezet zodra geladen, vóór enige KV-cache of vision-activaties • Q8_0 GGUF — 1,08 GB aan gewichten, plus een vision-projector van 0,90 GB bij de 4×-compressie-instelling, of 1,11 GB bij 16× • Q4_K_M GGUF — 0,67 GB aan gewichten, met dezelfde projector-overhead • Vision-projector — dit is het deel dat mensen vergeten; het krimpt niet mee met de quantisatie van het taalmodel, en het wordt eenmalig per geladen model meegerekend • Context — op papier tot 262.144 tokens; elk token aan KV-cache is extra geheugen waar de modelkaart geen budget voor reserveert

Een Q4-build met de 16×-projector komt uit op bijna 1,8 GB aan gewichten. Voeg een werkende KV-cache toe voor een paar duizend tokens aan gesprek en afbeeldingsplaceholders, en je vraagt een app om iets in de orde van 2,2–2,8 GB. Op een 12GB Pro Max is dat comfortabel. Op een 8GB iPhone, waar het besturingssysteem en elke andere actieve app al om dezelfde geheugenpool strijden, vraagt een app die 2,5 GB vraagt om een groot deel van wat er nog over is. iOS kent het toe, of het beëindigt de app onder druk via jetsam.

Waarom de RAM-regel op een iPhone de echte specificatie is

Apple publiceert het RAM van de iPhone niet in zijn marketingspecificaties, en het heeft ontwikkelaars nooit aangemoedigd de telefoon te behandelen als een computer met adresseerbaar geheugen. Dat is de beperking waarop de claim "beyond de 12GB Pro Max" stuit. De Pro Max-tier heeft al verschillende generaties lang meer geheugen dan de standaardmodellen, en de kloof tussen "de telefoon in de reviewvideo" en "de telefoon in de zak van een lezer" is precies de kloof waarvan het on-deviceverhaal van dit model afhankelijk is.

De eerlijke versie van de bewering is beperkter en nog steeds interessant: een 1B-visiemodel dat vroeger een laptop of een high-end telefoon nodig had, past nu binnen het geheugenbudget van een middenklassetelefoon, als je 4-bitkwantisatie gebruikt en een kortere context accepteert. Dat is een echte stap terug in hardwareklasse. Het is niet hetzelfde als "draait op elke iPhone", en het verschil is het waard om duidelijk te benoemen, omdat het bepaalt of een lezer het ding kan uitbrengen.

De modelkaart geeft daar geen uitsluitsel over. Die documenteert ondersteuning voor iOS, Android en HarmonyOS, day-0-chipondersteuning van Rockchip, Houmo, Intel, AMD en Arm, en linkt naar een repository voor edge-deployment met apps en broncode. Nergens vermeldt die minimaal apparaatgeheugen, een geteste apparaatmatrix of een tokensnelheid per apparaat voor de 1B. Het enige apparaat dat in de eigen demo-assets van de 1B wordt genoemd, is een iPhone 17 Pro Max — hetzelfde apparaat als waar de 35B-headline op doelt.

Waar het model eigenlijk goed in is, bij 1B

De reden dat dit het geheugenrekenwerk waard is, is dat een 1B-model dat document- en schermbegrip op een telefoon uitvoert, een andere productcategorie is dan een chatbot. Het betekent dat een bon, formulier, menu, label of screenshot kan worden omgezet in gestructureerde tekst zonder netwerkrondreis — geen upload, geen kosten per afbeelding, geen latentieondergrens bepaald door een zendmast.

De gepubliceerde 1B-cijfers van OpenBMB – allemaal door de leverancier gerapporteerd en op het moment van schrijven geen enkele onafhankelijk gereproduceerd – stellen OCRBench op 86,1, MathVista op 74,3, CharXiv Reasoning op 48,8, LongVideoBench op 53,4 en MotionBench op 54,55. De opvallendste vergelijking van de leverancier is met Qwen3.5 0.8B, waarvan volgens de leverancier zowel de totale score als de inferentie-efficiëntie beter zijn, en met MiniCPM-V 4.6, waarop het volgens de leverancier op alle kerncapaciteiten verbetert. Dat zijn de eigen benchmarks van de leverancier, uitgevoerd door de leverancier, en de modelkaart presenteert ze als grafieken in plaats van als een tabel met details over de testopzet.

Twee architectuurdetails zijn belangrijker dan de scores voor iedereen die dit daadwerkelijk implementeert:

• Gemengde 4×/16× visuele-tokencompressie — de aanroeper kiest per verzoek of een afbeelding een gedetailleerde tokenreeks wordt of een goedkope, zodat een kassabon-scan en een thumbnail dezelfde deployment kunnen delen • Intra-ViT-vroegtijdige compressie, overgenomen van LLaVA-UHD v4 — visuele tokens worden binnen de vision-encoder afgekapt in plaats van erna, wat het 4×-pad überhaupt betaalbaar maakt • Slicing — afbeeldingen met hoge resolutie worden opgesplitst in tegels van 448×448 plus een overzicht met lage resolutie, waarbij het aantal slices een runtimeparameter is (de kaart raadt 36 aan voor afbeeldingen, 1 voor video) • Video-sampling — max_num_frames staat standaard op 128, en stack_frames stelt subframes samen tot een raster, waardoor een telefoon een schermopname kan verwerken zonder elk frame in het geheugen te houden

Voor de bon-use case die de prompt noemt, is de pipeline: vastleggen, verkleinen tot iets rond 980 pixels aan de lange zijde, draaien op 4× met een hoog aantal slices, en om gestructureerde output vragen. Het 4×-pad met 36 slices is de dure instelling; het 16×-pad gebruikt ruwweg een kwart van de tokens en is waar de telefoon responsief blijft. Of 16× genoeg is om een thermische bon te lezen, is een vraag die alleen je eigen afbeeldingen kunnen beantwoorden, en geen enkele gepubliceerde benchmark in de kaart rapporteert OCR-nauwkeurigheid per downsample-modus.

De kloof tussen "demo" en "app"

Er staan drie dingen tussen een werkende demo en een iOS-app die klaar is voor release, en geen van die drie zijn de gewichten van het model.

Het eerste is packaging. Het model wordt geleverd in de formaten Transformers, GGUF, AWQ, GPTQ en int4. Alleen GGUF heeft een volwassen on-device runner op iOS — llama.cpp en verwanten — en alleen de GGUF-repository bevat het afzonderlijke vision-projector-bestand (mmproj) dat het multimodale pad nodig heeft. Als je van het BF16-checkpoint uitgaat en verwacht dat één bestand zo kan worden ingezet, zul je ontdekken dat de projector een tweede artefact is met zijn eigen grootte.

De tweede is het thermische budget. Een 1B-model dat een paar honderd tokens genereert, is een kortstondige belasting; een 1B-model dat een pagina met 36 slices OCR't, is een aanhoudende belasting. De demo-GIF van de leverancier is een schermopname, geen thermische trace. Geen enkel gepubliceerd cijfer in de modelkaart geeft het aantal aanhoudende tokens per seconde op welke telefoon dan ook, en dat is juist het getal dat bepaalt of een scan-app bij het derde of het dertigste document direct aanvoelt.

De derde is de rest van je stack. Inferentie op het toestel verwerkt de afbeelding. Het verwerkt niet het deel waarin je de geëxtraheerde bon afstemt op een grootboek, een onduidelijke regel escaleert naar een groter model, of terugvalt wanneer de telefoon zo oud is dat de app weigert de gewichten te laden. Dat is de grens waar een router zijn plek verdient in plaats van iets te vervangen: OrcaRouter zet meer dan 200 gehoste modellen achter één OpenAI-compatibel endpoint tegen 0% opslag, waarbij de lijstprijs van elke provider rechtstreeks wordt doorgegeven, met automatische failover en een routing-DSL voor primary-and-fallback-configuraties. Een extractor aan de telefoonkant kan zijn onzekere gevallen aan een gehost visiemodel geven, en dezelfde sleutel draagt beide paden. MiniCPM-V 4.7 1B zelf staat niet in die catalogus — het is een checkpoint dat je zelf draait — dus de router is het escalatiepad, niet de manier om dit model aan te roepen.

Het quiet-releasepatroon, en waarom het steeds deze verwarring blijft veroorzaken

MiniCPM-V 4.7 verscheen zonder lanceerevenement. De 35B-A3B-repository dook op 6 oktober 2026 op zonder enige modelkaart — de kaart kwam zes dagen later, samen met de gedateerde release note. De 1B volgde hetzelfde patroon: eerst de repository, dan de documentatie, en ondertussen ontdekking door de community. In de tussentijd wordt de berichtgeving aangevuld op basis van elk artefact dat bestaat, en daarom beschreven vroege artikelen een 35B MoE-model en moesten die later worden herzien toen de 1B en zijn kaart opdoken.

Dit is geen kritiek op de engineering van OpenBMB. Het is een beschrijving van hoe informatie over dit model zich verspreidt, en het is de reden waarom een bewering als 'draait op gewone iPhones' sneller kan rondgaan dan de geheugencijfers die deze nuanceren. De repository is de primaire bron. De modelkaart is de primaire bron. Een screenshot van een ontwikkelaar van een app die op zijn telefoon werkt, is een datapunt, geen specificatie.

Wat moet ik hiermee concreet doen?

Als je een Pro Max of een iPad hebt. Download de Q8_0 GGUF en de 16×-projector, draai het via llama.cpp of Ollama, en test je eigen documenten met beide downsample-instellingen. Je hebt binnen een middag een werkend lokaal OCR- en image-QA-pad, en de 1B is klein genoeg om hem naast andere apps resident te houden.

Als je een standaard-iPhone hebt. Begin met Q4_K_M en de 16×-projector, houd het aantal slices bescheiden en meet. De geheugenberekening zegt dat het zou moeten passen; het thermische gedrag en het jetsam-gedrag bij aanhoudend gebruik is het deel dat niemand heeft gepubliceerd. Test op het oudste apparaat dat je wilt ondersteunen, niet op het nieuwste.

Als je een product bouwt. Behandel het model op het toestel als het snelle pad en een gehost model als het pad voor correctheid. De escalatie is een routeringsbeslissing, en die vanaf dag één inbouwen is goedkoper dan hem achteraf inbouwen na het eerste supportticket over een bon die de telefoon verkeerd heeft gelezen.

De bewering waarmee dit artikel begon — dat een 1B-multimodaal model nu op telefoons onder de Pro Max-tier draait — is aannemelijk op basis van de geheugenberekening en onbewezen volgens het gepubliceerde materiaal. Dat is een normale situatie voor een model dat zo jong is, en het is een reden om te testen in plaats van te wachten. De gewichten zijn Apache 2.0, de quantisaties bestaan, en het enige dat tussen jou en een antwoord staat, is een middag met je eigen hardware.

Kortom: MiniCPM-V 4.7 1B is een echt, gedocumenteerd Apache-2.0-visiemodel dat met zijn visieprojector bij Q4 in ongeveer 1,8 GB past — klein genoeg dat middenklasse telefoons een geloofwaardig doel zijn en niet alleen de 12GB Pro Max. De leverancier heeft geen apparaatmatrix of minimale geheugenwaarde gepubliceerd, en de bewering "alledaagse iPhone" komt uit een ontwikkelaarsrapport en niet uit de modelkaart. Test op je eigen apparaat voordat je daarop je plannen baseert.