MiniCPM-V 4.7 35B-A3B vs MiniCPM-V 4.7: Een van deze namen is geen model

Zoek naar MiniCPM-V 4.7 en je vindt een modelkaart, een benchmarktabel, een telefoondemo en een downloadknop. Zoek naar MiniCPM-V 4.7 35B-A3B en je vindt dezelfde dingen, want het is dezelfde release — en dat is precies de hele moeilijkheid bij het vergelijken ervan. De modelkaart van OpenBMB opent met de regel die de knoop doorhakt: MiniCPM-V 4.7 is het nieuwste model in de reeks, beschikbaar in een 35B-A3B-variant, en 35B-A3B is de eerste MoE in die reeks. De kale naam is een banier. De naam met suffix is een checkpoint. Zet een sparse mixture-of-experts met 35 miljard parameters aan de ene kant en een banier aan de andere, en je hebt geen vergelijking, maar een vraag over welk artefact je bedoelde te downloaden. Beantwoord die vraag en de rest van deze pagina is een specificatieblad.

De namen, opgelost

Drie dingen luisteren naar de naam "MiniCPM-V 4.7", en slechts twee ervan zijn downloadbaar.

• openbmb/MiniCPM-V-4.7 — bestaat niet. De URL geeft een autorisatiefout, geen pagina met gewichten. Er heeft nooit een kaal checkpoint onder deze naam bestaan, en berichtgeving die de ene reeks cijfers onder het label van de andere citeert, citeert de 35B-cijfers onder een naam waar geen repository achter zit.

• De serie — een Hugging Face-collectie die OpenBMB onderhoudt, met dertien repositories onder de 4.7-vlag: het basis-35B-A3B-checkpoint, een GGUF-build, FP8-, AWQ-, GPTQ- en int4-quantisaties ervan, een gekoppelde DSpark speculatieve draft-head, en opnieuw dezelfde zesdelige ladder voor het kleine model. Die collectie is wat "MiniCPM-V 4.7" aanduidt wanneer het als productlijn wordt gebruikt.

• openbmb/MiniCPM-V-4.7-35B-A3B — het checkpoint waarover de aankondiging gaat, aangemaakt op 7 oktober 2026 om 07:07 UTC, gelicentieerd onder Apache-2.0, met een volledige modelkaart toegevoegd op 12 oktober. Dit is het enige binnen de familie dat momenteel benchmarktabellen van de leverancier bevat.

Het eerlijke antwoord op "MiniCPM-V 4.7 vs MiniCPM-V 4.7 35B-A3B" is dus dat de vraag neerkomt op een variantkeuze binnen één serie, en de serienaam alleen levert je geen bestand op. Het enige bestand dat je er wel mee krijgt, is de 35B-A3B, en daarom komen lezers binnen met de gedachte dat het om hetzelfde gaat.

Wat de lancering eigenlijk inhoudt

De eigen README van OpenBMB beschrijft twee varianten en één gedeelde vision tower, en dateert de release op 12 oktober 2026 — vijf en zes dagen nadat de gewichten zijn geüpload. Dat verschil is van belang als je een releasedatum citeert. De repositories zijn aangemaakt op 6 en 7 oktober; de kaart, de licentietag, de grafieken en de aankondiging verschenen allemaal op de 12e. De parameters veranderden niet op de 12e. De documentatie wel.

Wat de documentatie behandelt, voor beide varianten:

• Twee checkpoints — een 35B-A3B sparse MoE en een 1B dense model, die een lineage-naam en een vision tower delen, en verder niets daaronder.

• Een gedeeld visueel pad — de eigen minicpmv4_7_vision-toren van de familie, 27 lagen met een verborgen grootte van 1.152, patchgrootte 14, afbeeldingsgrootte 980, ingevoegd in de taalstack op laag 6, met de vroege intra-ViT-compressie die OpenBMB toeschrijft aan LLaVA-UHD v4, ervoor.

• Gemengde 4x/16x visuele tokencompressie — per verzoek selecteerbaar, standaard 16x voor doorvoer en 4x voor detail. De kaart merkt op dat geen enkel ander model in zijn vergelijkingstabel deze keuze biedt, en dat de instelling aan zowel de chat-template als de generate-aanroep moet worden doorgegeven, anders komen het aantal placeholders en de vision-encoder niet overeen.

• Een deploymentverhaal dat niet meer over gewichten gaat — iOS-, Android- en HarmonyOS-targets, chipondersteuning vanaf dag 0 van Rockchip, Houmo, Intel, AMD en Arm, OpenVINO voor Intel CPU/GPU/NPU, en frameworkondersteuning voor SGLang, vLLM, llama.cpp en Ollama. De app en de gekwantiseerde builds zijn hier het product, niet de BF16-download.

De twee controlepunten, dimensie voor dimensie

Zes dimensies, aan beide zijden, met een opmerking over wat elk getal werkelijk waard is.

• Parameters en vorm — MiniCPM-V 4.7 35B-A3B: 35,212,875,824 opgeslagen parameters, sparse, 256 experts met 8 actief per token bij een intermediaire grootte van 512 per expert plus een gedeelde expert van dezelfde grootte. De 1B-variant van MiniCPM-V 4.7: 1,554,476,272 parameters, dense, elk ervan actief op elk token. De twee totalen zijn niet dezelfde grootheid, en het active-per-token-budget van de MoE is niet gepubliceerd, dus lees de "A3B" als onderdeel van de naam en niet als een meetwaarde die je kunt vergelijken met het dense model.

• Downloadvoetafdruk — MiniCPM-V 4.7 35B-A3B: 70,4 GB verdeeld over zestien safetensors-shards in BF16, vóór enige KV-cache. MiniCPM-V 4.7 1B: ongeveer 3,1 GB in één gewichtsbestand. Tweeëntwintig keer de download aan de ene kant, en de eerlijke maatstaf voor welke van deze out of the box een handsetmodel is — geen van beide, totdat je een kwantisatie van de ladder neemt.

• Tekst-backbone en diepte — MiniCPM-V 4.7 35B-A3B: een sparse MoE-tekststack uit de Qwen-familie, 40 lagen bij verborgen grootte 2,048, zestien query-heads tegen twee key/value-heads, vocabulaire 248,144. MiniCPM-V 4.7 1B: een dense tekststack uit de Qwen-familie, 24 lagen bij verborgen grootte 1,024, acht query-heads tegen twee key/value-heads, vocabulaire 248,094. Hetzelfde ontwerpidee, een trede lager.

• Aandacht — beide: een vaste verhouding van drie tegen één van lineaire aandacht ten opzichte van volledige aandacht. Dertig van de veertig lagen van de 35B nemen het lineaire pad, tegenover tien conventionele; achttien van de vierentwintig van de 1B tegenover zes. Dit is de dimensie waarin de twee modellen echt dezelfde architectuur zijn, alleen opgeschaald, en het is de reden dat beide een 256K-context aankunnen zonder dat de KV-cache explodeert.

• Context — beide: 262.144 maximale posities, met dezelfde canvas multimodale roterende-embeddingmodus. Geen varianttoeslag, geen truncatie op het kleine model.

• Licentie — beide: Apache-2.0, gedeclareerd in de front matter van de repository en bevestigd in de README. Beide zijn ook beschikbaar op Hugging Face en op ModelScope. Er is geen verschil in voorwaarden om af te wegen.

De benchmarktabel bestaat voor een van hen.

Hier is de asymmetrie die daadwerkelijk vormgeeft aan een beslissing. De 35B-A3B-checkpoint bevat de vergelijkingstabellen van OpenBMB — MMMU rond 80,2, OCRBench rond 91,2, OmniDocBench v1.6 in de hoge 90, CharXiv-redenering in de midden-70, TextVQA in de midden-80 — afgezet tegen twee Qwen-modellen uit de 35B-A3B-klasse, een 31B Gemma en twee 27B Qwens, in Instruct-modus. Dit artikel behandelde wat die tabellen waard zijn toen de release werd gedocumenteerd; de korte versie is: door de leverancier gerapporteerd, met de eigen testomgeving van de leverancier geëvalueerd, niet gereproduceerd, en gehaald uit PNG-grafieken in plaats van een gepubliceerde scoretabel.

De 1B heeft zijn eigen grafiek in hetzelfde document, en de vergelijking daar is met een kleiner veld. Als je tussen de twee groottes kiest, is het nuttige dat de kaarten je geven geen score — het is dat het grotere checkpoint het exemplaar is waarvoor het efficiëntieargument is geschreven. Het on-device-getal dat de hele release verankert, 13-plus tokens per seconde bij ongeveer 3 GB geheugen op een iPhone 17 Pro Max, is een 35B-A3B-getal, geproduceerd met Lookahead Expert Scheduling, dat experts over lagen heen prefetcht via gekwantiseerde gewichten. Het kleine dense model heeft die machinerie niet nodig, omdat 1,55 miljard dense parameters in het werkgeheugen van een telefoon passen zonder dat daar iets van nodig is.

Dat is de omkering die het waard is om bij stil te staan: het kleine model is eenvoudig en niet gedocumenteerd in benchmarktermen; het grote model is zwaar gedocumenteerd en moeilijk te draaien. Geen van beide posities is duidelijk beter.

Welke downloaden mensen eigenlijk?

De tellers van Hugging Face voegen een feit toe dat geen van beide modelkaarten vermeldt, en dat pleit voor het grotere model. Afgelezen op 13 oktober 2026 toont de basisopenbmb/MiniCPM-V-4.7-35B-A3Brepository 630 downloads; de -ggufbuild van dezelfde checkpoint toont ruim 10.000, ongeveer zestien keer zoveel verkeer. Voor de 1B staan de basisrepository en de bijbehorende GGUF-build op respectievelijk 263 en 2.064, een vergelijkbare verhouding op een veel kleinere absolute schaal.

Twee interpretaties, beide consistent met de data. Ofwel halen mensen eerst de gekwantiseerde build binnen omdat die draait, ofwel lopen de BF16-cijfers simpelweg achter omdat de BF16-checkpoint niet is wat iemand uitrolt. Hoe dan ook, de downloadteller meet welk artefact ertoe doet — en dat is niet het artefact waarvan de grootte in de naam staat. Als je een inschatting voor deze beslissing wilt maken, maak die dan op basis van de GGUF- of de AWQ-build, niet op basis van 70,4 GB.

Er is nog één detail in de listing dat de andere kant op gaat. Beide repositories dragen de tag "On-Device Model" die is geërfd van de rest van de MiniCPM-V-familie, wat op een 70 GB BF16-MoE pas betekent wat de tag op het 3,1 GB-bestand van de 1B betekent, en dan alleen na quantisatie en expert-streaming. Beschouw de tag als een familielabel, niet als een specificatie.

Wanneer een gehoste API de vraag verandert

Geen van beide checkpoints wordt gehost op OrcaRouter, en voor deze vergelijking blijkt dat het beslissende structurele feit te zijn. Beide zijn open gewichten die je zelf serveert, wat betekent dat de 35B-A3B hardware vereist die je waarschijnlijk niet hebt en de 1B hardware die je zeker wel hebt — en de kloof tussen 'een of andere GPU' en 'een telefoon' is de werkelijke inhoud van '35B-A3B vs 4.7'.

De plek waar een router zijn bestaansrecht verdient, is de grens. Als je de 1B kiest en die is niet genoeg voor een verzoek, moet het werk ergens naartoe, en dat ergens is meestal een gehost model dat je liever niet provider voor provider wilt beheren: OrcaRouter dekt een paar honderd gehoste modellen achter één sleutel, tegen de lijstprijs van elke provider zonder dat er iets bovenop komt, en schakelt over tussen providers wanneer er één verslechtert. Een van die gehoste id's, qwen/qwen3.6-35b-a3b, is de directe gehoste tegenhanger van de checkpoint waar dit artikel over gaat — dezelfde 35B-A3B-vorm, toegankelijk zonder dat je de accelerator bezit, wat het de natuurlijke bovengrens maakt om tegen te testen voordat je 70 GB van je eigen schijf inzet voor de lokale versie.

Dat is een routeringsbeslissing, geen tweede integratie, en het is het enige onderdeel van deze keuze dat niets kost om terug te draaien.

De keuze

Als de beperking een telefoon, een laptop of één enkele kleine GPU is, is de 1B de enige kandidaat — 3,1 GB, een licentie die commercieel gebruik toestaat, en een kwantisatieladder die al sinds de eerste week wordt uitgeleverd. Als het doel het efficiëntieresultaat is waar OpenBMB het eigenlijk over heeft, wil je de 35B-A3B, en dan in een gekwantiseerde build in plaats van het origineel van 70 GB, want dat is wat elke andere downloader heeft genomen en waarop de on-device claim is gemeten.

Wat je niet moet doen, is de twee namen als uitwisselbaar behandelen. Een van de twee is een checkpoint dat je vanmiddag kunt draaien. De andere is een label dat de modelkaart van 35B-A3B blijft teruggeven, ongeacht welke van de twee je bedoelde.