MiniCPM-V 4.7: OpenBMB heeft een 35B-A3B Vision-Language Model geüpload zonder modelkaart, zonder licentie en zonder benchmarks

MiniCPM-V 4.7 verscheen op de avond van 6 oktober 2026 op Hugging Face als de repository openbmb/MiniCPM-V-4.7-35B-A3B — en het is een van de vreemdste dingen die de MiniCPM-serie ooit heeft uitgebracht, want er is bijna niets meegeleverd. Er is geen modelkaart. Er is geen README. Er is geen licentie opgegeven. Er zijn geen benchmarktabellen, geen lanceringsbericht, geen technisch rapport en geen vermelding in de eigen GitHub-documentatie van OpenBMB, die deze week nog steeds MiniCPM-V 4.6 "het nieuwste en meest efficiënte model in de MiniCPM-V-serie" noemt. Wat wel bestaat, zijn 16 shards bfloat16-gewichten, 70,4 GB ervan, die een vision-language mixture-of-experts-model met 35,2 miljard parameters beschrijven, met een contextvenster van 256K en een ongewoon agressief hybride-attentieontwerp. Dat is genoeg om te zeggen wat het model is. Het is nog niet genoeg om te zeggen waar het goed in is, en dit stuk houdt die twee dingen strikt gescheiden.

Wat er daadwerkelijk is terechtgekomen, byte voor byte

De repository werd aangemaakt op 6 oktober 2026 om 18:36 UTC en had zijn laatste commit twaalf minuten later, om 18:48 UTC. In de tussentijd heeft de uploader de weightbestanden en de configuratie die een Transformers-loader nodig heeft gepusht, en toen stopte hij. De volledige bestandslijst telt achttien vermeldingen:

• Gewichten — zestien safetensors-shards met de naam model-00001-of-00016 tot model-00016-of-00016, met het indexbestand model.safetensors.index.json dat een totale tensoromvang van 70.425.751.648 bytes rapporteert.

• Aantal parameters — de Hugging Face API leest 35.212.875.824 parameters, allemaal in BF16. Merk op dat dit het totale aantal is, wat voor een sparse MoE niet het aantal parameters is dat actief is op een gegeven token.

• Configuratie — config.json (2.984 bytes), generation_config.json (186 bytes), preprocessor_config.json, processor_config.json.

• Tokenizer — tokenizer.json (20 MB), tokenizer_config.json en chat_template.jinja (7.250 bytes).

• Ontbreekt — README.md. Een directe fetch van het onbewerkte bestand retourneert HTTP 404. Op Hugging Face betekent een ontbrekende README geen modelkaart, wat betekent geen licentieveld, wat betekent dat de repo helemaal geen license:-tag bevat.

De repository heeft drie likes, nul downloads en een leeg discussietabblad. Een door de community geüploade checkpoint van 70 GB trekt meestal binnen enkele uren reacties — vragen over quants, over serving, over wat de licentie is. Deze niet, wat strookt met het feit dat hij is opgemerkt door een handjevol mensen die de openbmb-organisatie in de gaten houden, in plaats van aan wie dan ook aangekondigd te zijn.

De architectuur, rechtstreeks afgelezen van config.json

Omdat er geen modelkaart is om te parafraseren, is het configuratiebestand de primaire bron, en het is ongewoon informatief. De klasse is MiniCPMV4_7ForConditionalGeneration, het modeltype is minicpmv4_7, en het is opgeslagen door Transformers 5.2.0 — die allemaal aangeven dat dit een first-party OpenBMB-checkpoint in de hoofdlijn van de MiniCPM-V-reeks is, geen community-finetune die de naam draagt.

• Taalbackbone — model_type: qwen3_5_moe_text. Een Qwen3.5-afgeleide sparse MoE, de eerste keer dat de MiniCPM-V-reeks een Qwen-MoE-tekststack heeft gebruikt in plaats van de kleine dense Qwen-varianten die MiniCPM-V 4.5 en 4.6 aandreven.

• Spaarzaamheid — 256 experts, 8 geselecteerd per token, met een tussenliggende expertgrootte van 512 en een gedeelde expert van dezelfde grootte. Een totaalcheckpoint van 35B op een 8-van-256 routeringspatroon activeert een kleine fractie daarvan per forward pass, wat het hele punt van de A3B-naam is: de gewichten zijn groot, de rekenkracht niet.

• Diepte en breedte — 40 verborgen lagen, verborgen grootte 2048, 16 attention heads met 2 key/value-heads en een head-dimensie van 256.

• Hybride aandacht — de layer_types-array is 40 items lang en 4 linear_attention-lagen op elke full_attention-laag met een vast interval van 4. Tien van de veertig lagen gebruiken conventionele aandacht; de andere dertig gebruiken een lineair pad in Mamba-stijl met een convolutiekernel van 4. Dit is de meest verstrekkende ontwerpkeuze in het bestand, en het is dezelfde richting die het bredere vakgebied gedurende 2026 is ingeslagen.

Positionele codering — RoPE met een theta van 10.000.000 en partial_rotary_factor: 0.25, wat betekent dat slechts een kwart van de dimensies van elke head wordt geroteerd. Multimodale RoPE is ingeschakeld met mrope_interleaved: true, een sectieopsplitsing van [11, 11, 10], en mrope_mode: canvas.

• Context — max_position_embeddings: 262144, en de model_max_length van de tokenizer komt overeen. 256K tokens.

• Voorspelling van meerdere tokens — mtp_num_hidden_layers: 1, één enkele speculatieve-decodering-head, dezelfde truc die MiniCPM-V 4.6 gebruikte.

• Visietoren — minicpmv4_7_vision, verborgen grootte 1152, 27 lagen, GELU-tanh-activaties, patchgrootte 14 met een image_size van 980, en een insert_layer_id van 6, wat de plek is waar de visuele embeddings in de taalstack worden ingevoegd. De vorm van de toren lijkt sterk op die in MiniCPM-V 4.6, dus de visiekant is eerder een evolutie dan een herbouw.

• Beeldcompressie — downsample_mode: "16x" en max_slice_nums: 9 in de afbeeldingsprocessor. MiniCPM-V 4.6 introduceerde een omschakelbaar 4x/16x token-compressieschema; de 4.7-configuratie presenteert de 16x-instelling als de standaard, waarbij de slicer tot negen subafbeeldingen toestaat voor invoer met hoge resolutie.

• Vocabulaire — 248.144 tokens, met <|image_pad|> op id 248.056 en <|video_pad|> op 248.057. Video is een eersteklas invoer, precies zoals het dat is sinds MiniCPM-V 4.5.

• Een curieus overblijfsel — de tokenizerconfig declareert nog steeds <|audio_start|>, <|audio_end|> en <|audio_pad|>. Dit betekent vrijwel zeker dat het vocabulaire wordt gedeeld met de omni MiniCPM-o-tak, en niet dat MiniCPM-V 4.7 audio spreekt. Het interpreteren als een audiofunctie zou een fout zijn die de config op zichzelf niet kan uitsluiten.

Wat de familie ons vertelt, vertelt deze repository niet

De 4.6-generatie is het referentiepunt, en de tegenstelling is het verhaal. MiniCPM-V 4.6 werd op 11 mei 2026 uitgebracht als een model met 1,3 miljard parameters, gebouwd op een SigLIP2-400M vision-encoder en een Qwen3.5-0.8B-taalmodel, onder Apache-2.0, met een expliciete propositie: het scoort 13 op de Artificial Analysis Intelligence Index — een door de leverancier gerapporteerd cijfer — terwijl het drastisch minder tokens verbruikt dan vergelijkbare kleine modellen, en het draait op iOS, Android en HarmonyOS, met de edge-adaptatiecode open-source gemaakt. De hele identiteit was "klein, efficiënt, on-device."

MiniCPM-V 4.7 is 1,3 miljard vermenigvuldigd met ongeveer 27. De naam 35B-A3B plaatst het in de categorie die wordt ingenomen door sparse topmodellen, niet door telefoons. Of OpenBMB het bedoelt als server-side metgezel voor de edge-lijn, als leraar voor een toekomstig klein model, of als een test van het capaciteitsplafond, wordt nergens vermeld, en de repository bevat geen enkele aanwijzing in welke richting dan ook.

Wat echt nieuw is, en de moeite waard om te signaleren voor iedereen die de serie volgt, is de Qwen-MoE-backbone plus de 3:1-verhouding tussen lineaire en volledige attention. Beide zijn afwijkingen van het gebruikelijke. Alles wat OpenBMB over de familie publiceert, is nog steeds rond 4.6 geschreven, dus deze checkpoint loopt voor op zijn eigen documentatie.

Wat nog niet kenbaar is — en waarom die lijst ertoe doet

Het is de moeite waard om ronduit te zijn over de omvang van het gat hier, want bij een checkpoint van 70 GB is de verleiding groot om het op te vullen met plausibele gevolgtrekkingen.

• Geen licentie. Dit is geen formaliteit. MiniCPM-V 4.6 is Apache-2.0, en de community is dat van deze lijn gaan verwachten. Een repo zonder licentie: tag geldt in de meeste rechtsgebieden standaard als alle rechten voorbehouden — je kunt er niet veilig op voortbouwen totdat de tag verschijnt. Dat ene ontbrekende bestand is de meest verstrekkende leemte in de repository.

• Geen benchmarks, door de leverancier gerapporteerd of anderszins. Er is geen enkel cijfer om over te discussiëren. Iedereen die vandaag een MMMU- of OCRBench-score voor MiniCPM-V 4.7 citeert, citeert iets dat niet in de bron bestaat.

• Geen onafhankelijke evaluatie. Artificial Analysis en vergelijkbare trackers indexeren modellen op naam; een checkpoint zonder kaart en zonder aankondiging blijft doorgaans een tijdje ongemeten.

• Geen serveerrecept. Of de vrijgegeven gewichten out-of-the-box werken in vLLM, SGLang of llama.cpp is door niemand buiten OpenBMB getest. De aangepaste codepaden (MiniCPMV4_7ForConditionalGeneration, MiniCPMV4_7Processor, MiniCPMV4_7ImageProcessor, MiniCPMV4_7VideoProcessor) vereisen allemaal trust_remote_code, en de combinatie van MoE plus lineaire aandacht is geen vorm waarvoor elke inference-engine een kernel heeft.

• Geen quantisaties. MiniCPM-V 4.6 werd geleverd met GGUF-, AWQ-, GPTQ- en BNB-varianten en bereikte in juni 2026 de bibliotheek van Ollama. Voor 4.7 bestaan die niet. Voor een model van 35B is dit het verschil tussen een laptop en een cluster.

• Geen relatie met 4.6 vermeld. OpenBMB zou de edge-lijn kunnen vervangen, uitbreiden of iets orthogonaals kunnen testen. De repository zegt dat niet, en de GitHub README ook niet, die nog steeds 4.6 als de huidige release vermeldt in de commit van 8 september 2026.

Er is ook een plausibele maar onbevestigde lezing van de tijdlijn: het gat van twaalf minuten tussen het aanmaken van de repo en de laatste commit, het ontbreken van een kaart en het ontbreken van welke post dan ook zijn hoe een checkpoint eruitziet wanneer het wordt klaargezet voor een lancering in plaats van erna. Dat is een hypothese over intentie, geen feit over het artefact, en het moet ook als zodanig worden behandeld.

Hoe je het daadwerkelijk zou uitvoeren, wanneer er iets uit te voeren is

Niets hiervan is nog citeerbaar als een ondersteund pad, maar de config beperkt de opties wel. Een BF16-checkpoint van 35B parameters heeft grofweg 70 GB acceleratorgeheugen nodig vóór de KV-cache, dus een hobbyistimplementatie op één GPU is van tafel totdat er kwantisaties verschijnen. De context van 256K en de 3:1-verhouding voor linear attention betekenen dat de KV-cache veel trager groeit dan bij een conventionele transformer met dezelfde diepte, en dat is precies waarom die architectuur de complexiteit waard is — multimodaal werk met een lange context is waar het ontwerp zichzelf terugverdient. Wanneer er een kaart opduikt, zijn de eerste dingen die je moet controleren de licentie, of er een officieel vLLM- of SGLang-recept is gepubliceerd, en of de standaard downsampling van 16x kan worden ingeruild voor de 4x-instelling die 4.6 heeft blootgelegd.

Voor teams die een model als dit willen evalueren op het moment dat het bruikbaar wordt, is het praktische probleem niet de gewichten, maar de infrastructuur eromheen. Een model dat op je eigen GPU draait, heeft nog steeds alles eromheen nodig — een router die meer dan 200 gehoste modellen achter één sleutel plaatst, tegen de lijstprijs van elke aanbieder, zonder dat wij er een opslag bovenop doen, en die automatisch overneemt wanneer een aanbieder verslechtert. Daar is OrcaRouter voor bedoeld, en het is goed om ronduit te zeggen dat MiniCPM-V 4.7 zelf geen gehost model is: het is een open-weights-checkpoint dat je zelf host. De router is hier van belang als de andere helft van de architectuur — het frontier-model waaraan je 4.7-box de moeilijke gevallen doorspeelt, bereikbaar via dezelfde client die je al hebt geschreven.

De stand van zaken, en het enige bestand dat vernieuwd moet worden

MiniCPM-V 4.7 bestaat. De gewichten zijn vandaag downloadbaar, het aantal gewichten is exact, en de ontwerpkeuzes uit het trainingstijdperk — sparse MoE, 3:1 lineaire attention, 256K-context, 16x visuele compressie — zijn allemaal af te lezen uit het configuratiebestand. Wat niet bestaat, is enige uitspraak van OpenBMB over wat het model doet, wat het in de praktijk kost om te draaien, of wat je ermee mag doen. Voor een lab waarvan het laatste visionmodel een 1.3B Apache-2.0 edge-release met een volledige vergelijkingstabel was, is dat een pijnlijke kloof, en de verstandige houding is om de repository in de gaten te houden in plaats van het discours. Het enige bestand dat je moet blijven verversen, is README.md: zodra het verschijnt, zal het de licentie, de benchmarks en waarschijnlijk de uitleg bevatten van wat een 35B MiniCPM-V doet in een serie die op kleine modellen is gebouwd.

Tot die tijd is de eerlijke samenvatting de saaie. Dit is een echte checkpoint uit een echt lab, stilletjes geüpload, en de interessante vraag — is het eigenlijk goed — heeft geen gepubliceerd antwoord.

OrcaRouter bereikt meer dan 200 gehoste modellen via één sleutel, waarbij de lijstprijs van elke provider rechtstreeks wordt doorgegeven tegen 0% opslag en automatische failover tussen providers. lijstprijs van provider doorgegeven tegen 0% opslag MiniCPM-V 4.7 hoort daar niet bij - het is een open-weights-checkpoint dat je zelf serveert, en de router staat aan de andere kant van de overdracht.