LFM3-VL-2B vs MiniCPM-V 4.7 35B-A3B: De kolom die niet het model is

Open de benchmarktabel voor LFM3-VL-2B en je zult een MiniCPM-kolom vinden. Die is gelabeld als MiniCPM-V 4.7 1B. Dat is het kleine broertje. Het model dat de meeste mensen bedoelen als ze MiniCPM-V 4.7 zeggen — OpenBMB's MiniCPM-V 4.7 35B-A3B, het eerste mixture-of-experts-checkpoint in de MiniCPM-V-lijn — staat helemaal niet in de tabel van Liquid AI, en op de benchmarks die beide labs publiceren komt het niet in de buurt van de 1B. Dus de vergelijking die mensen feitelijk afwegen, LFM3-VL-2B tegenover MiniCPM-V 4.7 35B-A3B, moet met de hand worden samengesteld uit twee leverancierstabellen die benchmarknamen delen, maar niet de evaluatieharnassen. Wat volgt is die samenstelling, met de naden zichtbaar gelaten.

De grootteverschillen zijn de tweede verrassing. Het ene model heeft 1,92 miljard dichte parameters en past in een paar gigabyte. Het andere slaat 35,21 miljard parameters op en raakt per token ongeveer 3 miljard daarvan aan. Als specificatieblad gelezen is dat helemaal geen wedstrijd. Gelezen als twee antwoorden op dezelfde vraag — wat kun je draaien op een apparaat dat je niet beheert — is het een oprecht interessant meningsverschil over hoe je daar komt.

Twee modellen, één naam

Het naamconflict doet echte schade aan de manier waarop deze vergelijking wordt gelezen. De modelkaart van Liquid AI is er nauwgezet over: de kolom zegt 1B, en de 1B is een legitieme tegenhanger voor een 1,92B-model. Maar zoekresultaten, aggregatiesites en terloopse verwijzingen trekken "MiniCPM-V 4.7" allemaal samen tot één geheel, en de 35B-A3B is de variant die het publiek trekt — 289.535 downloads en 1.095 likes op Hugging Face tegenover 155.428 en een paar honderd voor het 1B-zusje, per 28 oktober 2026.

Datums verklaren een deel van die kloof, maar niet de rest. De 35B-A3B-repository van OpenBMB is op 7 oktober 2026 aangemaakt, waarbij de release op 12 oktober wordt gedateerd in de eigen materialen van het project. De LFM3-VL-2B-repository van Liquid AI verscheen op 19 oktober en de LFM3-familie werd aangekondigd op 27 oktober. LFM3-VL-2B bestaat nu negen dagen publiekelijk, dus de 255 downloads zijn een kalenderfeit, geen oordeel. De likes-verhouding is de interessantere regel: 45 voor LFM3-VL-2B, 1.095 voor de MiniCPM. Mensen die laatstgenoemde hebben gedownload, vonden het leuk genoeg om dat te laten weten.

Wat elk ervan eigenlijk is

• Parameters — LFM3-VL-2B is 1,92B dense: een taalbackbone van 1,73B, een eigen vision-encoder van 164M en een projector van 25M. MiniCPM-V 4.7 35B-A3B slaat 35,21B op over 256 experts en routeert er per token 8, ongeveer 3B actief.

• Backbone — 24 LFM3-lagen, verdeeld over 13 gated short convolutions, 5 sliding-window attention-lagen en 6 global attention-lagen, tegenover 40 transformerlagen bij een verborgen grootte van 2.048.

• Vision-pad — een encoder met 14 lagen van 8 gegate dieptewijze 2D-convoluties en 6 bidirectionele attentionlagen op 16×16-patches met 2D-rotary-embeddings, tegenover een toren met 27 lagen bij hidden size 1.152, ingevoegd op laag 6 van de tekststack, met vroege tokencompressie in de encoder en omschakelbare visuele downsampling van 4× of 16×.

• Context — 128K tokens op LFM3-VL-2B, 256K op de MiniCPM, zowel invoer als uitvoer.

• Invoer — tekst, afbeeldingen en video met 2 frames per seconde voor het Liquid-model; tekst, afbeeldingen en video voor het OpenBMB-model. Geen van beide hoort audio, in geen van beide richtingen.

• Gewichten op schijf — ongeveer 3,8 GB bij BF16 versus ongeveer 65,6 GiB bij BF16.

• Licentie — LFM Open License v1.0, door Liquid beschreven als gratis voor commercieel gebruik bij een jaarlijkse omzet onder $10 miljoen, tegenover Apache 2.0 zonder omzetvoorwaarde.

Het architecturale meningsverschil is het hele verhaal. Liquid wedde erop dat een klein compact model plus een speciaal ontworpen vision-encoder een SigLIP-achtige toren verslaat op rekenkracht per afbeelding, en publiceerde een categorietabel om dat te bewijzen. OpenBMB wedde erop dat je de capaciteit van een 35B-model kunt behouden en het toch op een telefoon kunt draaien door het dure deel te streamen in plaats van permanent in het geheugen te houden. Beide zijn weddenschappen over geheugen, in tegengestelde richtingen aangegaan.

De kloof is reëel, en hij is smaller dan de framing.

Dit is wat de twee leverancierstabellen zeggen als je de juiste rijen naast elkaar zet. Het is allemaal door de labs zelf gerapporteerd, en de kanttekeningen bij de harness volgen daarna.

• MMMU — LFM3-VL-2B 55,7 met thinking aan, 48,6 met thinking uit; MiniCPM-V 4.7 35B-A3B 80,22 bij 4× visuele compressie, 80,00 bij 16×.

• MMStar — 74,4 tegen 80,67 bij 4×, 80,13 bij 16×.

• OCRBench v1 — 86,3 tegenover 91,20 bij 4×, 90,40 bij 16×.

• MathVista — 84,2 met denken, 68,5 zonder, tegenover 88,00 bij 4× en 87,30 bij 16×.

• CharXiv-redenering — 70,2 tegen 75,60 bij 4×, 69,20 bij 16×.

MMMU is waar de 35B zijn omvang rechtvaardigt: een verschil van 24,5 punt met de denkconfiguratie, en 31,6 punt met de niet-denkende. Dat is de benchmark voor multimodaal redeneren op universitair niveau, en de marge is groot genoeg om elke redelijke tegenwerping over verschillen tussen harnesses te doorstaan.

Al het andere ligt dichter bij elkaar dan de framing doet vermoeden. OCRBench is een verschil van 4,9 punten. MathVista is 3,8 punten wanneer LFM3-VL-2B nadenkt. Bij CharXiv-redenering verliest het Liquid-model 5,4 punten in denkmodus — en verslaat het de 16×-score van de 35B met een punt. Een 2B-model dat binnen vijf punten van een 35B zit op document-OCR en grafieken, is de bevinding die meer aandacht zou moeten krijgen dan de MMMU-headline.

Nu de kanttekeningen, want die doen ertoe. Liquid's cijfers komen uit één enkele run over 62 benchmarks op vLLM 0.27.1, genormaliseerd naar 0–100, met redeneermodus ingeschakeld voor elk model behalve de configuraties die anders zijn gemarkeerd. OpenBMB's vijf getallen zijn gepubliceerd als grafiekafbeeldingen in plaats van een numerieke tabel en zijn hier overgenomen uit de lezing van die grafieken door een externe aggregator, dus behandel de decimalen als benaderend. De twee labs zijn het niet eens over visuele tokenbudgetten, prompting- of decodinginstellingen, en de 4× versus 16×-opsplitsing aan OpenBMB-zijde verandert zijn scores op zichzelf al met maximaal zes punten. Dit zijn twee sets beweringen naast elkaar, geen gecontroleerd experiment.

Waar het kleine model cijfers heeft, publiceert het grote model ze niet.

Liquid publiceerde 62 rijen. OpenBMB publiceerde er vijf. Die asymmetrie is het meest onderbelichte feit in deze vergelijking, en ze valt uit ten gunste van het kleinere model.

• Visuele grounding — RefCOCO-avg 90,5, RefCOCO-M 95,2, Point-Bench 73,8, RefSpatial-Bench 49,8 voor LFM3-VL-2B. In de gepubliceerde evaluatie van MiniCPM-V 4.7 35B-A3B verschijnt geen gelijkwaardige rij.

• GUI-begrip — ScreenSpot-Pro 55,5, ScreenSpot-v2 op 94,6 desktop, 92,2 mobiel, 89,9 web. Nogmaals, aan de OpenBMB-kant is niets gepubliceerd.

• Belichaamd redeneren — EmbSpatial-Bench 82,9, RoboSpatial-Home 63,4, Where2Place 44,9. Dezelfde afwezigheid.

• Video — Video-MME 62,8 zonder ondertitels, MVBench 69,4, MLVU 71,3, ActivityNet-QA 71,2. MiniCPM-V 4.7 ondersteunt video en de kaart bespreekt dit uitvoerig, maar de numerieke tabel bevat geen videorij die we konden verifiëren.

Dit is afwezigheid van bewijs, geen automatische overwinning. Als je een robotics- of screen-agent-pijplijn bouwt, is het eerlijke standpunt dat de capaciteit van de 35B op die taken onbekend is in plaats van zwak. Maar "onbekend" is op zichzelf een inkoopprobleem: je kunt een uitrol niet plannen op basis van een getal dat niemand heeft gepubliceerd, en LFM3-VL-2B is de enige van de twee waarvan je de grounding- en GUI-prestaties kunt lezen voordat je hem downloadt.

Het geheugenargument snijdt aan twee kanten.

De gebruikelijke reden om een 2B boven een 35B te kiezen, is dat de 2B past. LFM3-VL-2B past inderdaad, volledig en voorspelbaar: ongeveer 3,8 GB in BF16, resident, geen paging, geen verrassingen wanneer het apparaat onder belasting staat. Dat is een echt sterke eigenschap voor een product dat je uitlevert op hardware die je niet zelf beheert.

{{1}}MiniCPM-V 4.7 35B-A3B{{/1}} past met {{2}}65.6 GiB{{/2}} bij lange na niet op een telefoon, en het volledige ontwerp van {{3}}OpenBMB{{/3}} bestaat juist daardoor. {{4}}Lookahead Expert Scheduling{{/4}} voorspelt de routing van de volgende laag en haalt de experts die het verwacht alvast op; {{5}}fijnmazige kwantisatie per laag{{/5}} verkleint die experts zodat ze sneller kunnen worden verplaatst; {{6}}DSpark{{/6}} speculatieve sampling vangt de haperingen bij het decoderen op. De leverancier beweert {{7}}meer dan 13 tokens per seconde{{/7}} op een {{8}}iPhone 17 Pro Max{{/8}} met ongeveer {{9}}3 GB{{/9}} geheugen, en {{10}}meer dan 17{{/10}} op een {{11}}iPad Pro M4{{/11}} met {{12}}16 GB{{/12}}.

De on-devicebewering is dus niet "de 35B is klein." Het is "de 35B streamt, en het streamen is soepel genoeg om bruikbaar te zijn." Dat zijn verschillende gokken met verschillende faalmodi. Een resident model van 3.8 GB degradeert gracieus — het is ofwel geladen, ofwel niet. Een streamend model van 65.6 GiB degradeert door flashbandbreedte, thermische throttling en latentie bij koude start, die allemaal per apparaat verschillen op manieren die een benchmark op één iPhone niet vastlegt.

De praktische afweging: als je noch de opslagsnelheid noch de thermische envelop onder controle hebt, is resident de minst risicovolle route. Als je op recente topklasse-hardware levert en de nauwkeurigheid wilt, is de aanpak van OpenBMB niet langer theoretisch — het is een uitgebracht model met een werkende fork erachter.

Tooling vanaf dag één is geen gelijkspel.

LFM3-VL-2B wordt geleverd met BF16-gewichten waarvoor transformers 5.21 of nieuwer nodig is, plus GGUF, inclusief een quantization-aware-distilled Q4_0-checkpoint, een MLX 4-bit-build en een ONNX-export. Serverondersteuning is nog niet voltooid: vLLM wordt beschreven als in uitvoering, SGLang ligt ter beoordeling bij pull request 46858, en llama.cpp ligt ter beoordeling bij pull request 31252 met een expliciete opmerking dat video-invoer nog niet wordt ondersteund. De kaart beveelt ook de qwen3 reasoning parser en qwen3_coder tool-call parser aan voor vLLM en SGLang, een detail dat laat zien hoe recent dit is aangesloten.

MiniCPM-V 4.7 35B-A3B ondersteunt SGLang, vLLM, llama.cpp en Ollama, met SWIFT en LLaMA-Factory voor fine-tuning, GGUF-, BitsAndBytes-, AWQ-, GPTQ-, FP8- en int4-builds, en day-zero-ondersteuning voor chipplatforms van Rockchip, Houmo, Intel, AMD en Arm op iOS, Android en HarmonyOS. Het on-device-traject loopt via OpenBMB's eigen llama.cpp-omni-fork in plaats van upstream llama.cpp.

Voor een productie-implementatie deze maand is dat geen twijfelgeval. Voor een onderzoeksspike, een laptopdemo of een fine-tune die je zelf wilt beheren, werkt LFM3-VL-2B vandaag al via transformers, en je bent geen week kwijt aan buildflags.

De licentieregel waar meer teams over struikelen

Apache 2.0 tegenover de LFM Open License v1.0 is een groter praktisch verschil dan de MMMU-kloof, omdat het op elke implementatie van toepassing is en niet alleen op de moeilijke gevallen. Apache 2.0 bevat geen omzetvoorwaarde, geen beperking van het gebruiksgebied en geen onduidelijkheid over de vraag of een gekwantiseerde of gedistilleerde afgeleide de voorwaarden erft. De LFM Open License v1.0 is volgens Liquid zelf gratis voor commercieel gebruik onder de 10 miljoen dollar jaaromzet, wat betekent dat een bedrijf boven die grens een licentiegoesprek voert voordat het iets op de markt brengt, niet erna.

Die ene clausule herschikt de vergelijking voor veel kopers. Een startup onder de drempel krijgt een kleiner, sneller en qua grounding beter gedocumenteerd model gratis. Een bedrijf boven de drempel krijgt een model waarvoor een handtekening nodig is — en op dat moment wordt de Apache 2.0-licentie van de 35B een kenmerk waar je op let.

Wat geen van beide leveranciers je zal vertellen

Er is geen onafhankelijke rechtstreekse vergelijking. Geen enkel laboratorium van derden heeft beide modellen op dezelfde testopstelling laten draaien, en wat het dichtst bij een neutraal scorebord komt — de eigen tabel van Liquid — vergelijkt LFM3-VL-2B met de 1B, niet met de 35B. Elk getal in dit artikel komt van het lab dat het model heeft gebouwd dat het beschrijft.

Nog twee andere hiaten zijn het vermelden waard. Geen van beide modellen heeft een prijs per token die we konden verifiëren, dus een kostenvergelijking zou hier verzonnen zijn. En geen van beide staat in de OrcaRouter-catalogus per 28 oktober 2026 — een zoekopdracht naar minicpm levert geen overeenkomende modellen op, en LFM3-VL-2B staat er ook niet bij. Daardoor is dit vandaag een beslissing over self-hosting of een leveranciers-API, geen routeringsbeslissing.

Welke moet je kiezen?

• Documenten, grafieken, dichte tekst en moeilijke multimodale redeneringen, met een serving-stack die je zelf in de hand hebt — MiniCPM-V 4.7 35B-A3B. De MMMU-marge is het enige resultaat dat groot genoeg is om de kanttekeningen bij de harness te overleven, en Apache 2.0 haalt de licentiekwestie volledig weg.

• Een apparaat dat u niet beheert, met een vast geheugenbudget en geen tolerantie voor streaminglatentie — LFM3-VL-2B. Resident op 3,8 GB, en de enige van de twee met gepubliceerde cijfers voor grounding, GUI en embodied waarop u kunt plannen.

• Agents voor schermen, robotica en ruimtelijke taken — standaard LFM3-VL-2B, omdat alleen die kant gepubliceerd bewijs heeft. Beschouw de 35B daar als onbewezen in plaats van zwak.

• Productie deze maand met minimaal integratiewerk — MiniCPM-V 4.7 35B-A3B. Ondersteuning voor SGLang, vLLM, llama.cpp en Ollama tegen drie notities met de status 'in beoordeling' of 'in uitvoering'.

• Een bedrijf met een jaaromzet van meer dan $10 miljoen — MiniCPM-V 4.7 35B-A3B, tenzij de on-device-beperking zo streng is dat een licentiegesprek gerechtvaardigd is.

Hoe OrcaRouter erin past, eerlijk gezegd

Het past nog niet, en iets anders beweren zou precies het soort uitspraak zijn waardoor een blogpost genegeerd wordt. Geen van beide modellen staat vandaag in de OrcaRouter-catalogus, dus er is geen key om je te overhandigen en geen prijs om te noemen.

Wat waar is, is wat er gebeurt wanneer een visionmodel daar wél landt: één OpenAI-compatibel endpoint voor meer dan 200 modellen, de lijstprijs van de provider tegen 0% marge doorgegeven, zodat een prijswijziging van een leverancier dezelfde dag nog live is, en automatische failover zodat een storing bij één provider je route niet platlegt. Voor een vergelijking als deze — twee modellen die het oneens zijn over geheugen, zonder onafhankelijke benchmark om dat te beslechten — is het nuttige patroon om beide achter één endpoint te draaien en op je eigen afbeeldingen te meten in plaats van te discussiëren over wiens grafiek gelijk heeft.

Wat te kijken

Vier dingen zouden dit artikel veranderen. Pull request 31252 die met video-ondersteuning wordt gemerged, waardoor het videopad van LFM3-VL-2B op standaard llama.cpp zou komen. vLLM-ondersteuning die de status "in progress" verlaat, waardoor het een serieuze servingoptie zou worden in plaats van een demo. Een onafhankelijke evaluatie die beide modellen op één harness draait — het meest waardevolle ontbrekende artefact in deze vergelijking. En dat Liquid AI de 35B aan zijn eigen vergelijkingstabel toevoegt, wat zou laten zien dat het lab het als de echte peer beschouwt.

Totdat een van die zaken werkelijkheid wordt, is de houdbare samenvatting beperkter dan de framing van beide leveranciers: de 35B wint de reasoning-benchmark die ertoe doet en verliest niets op OCR, de 2B wint op het gebied van grounding-bewijs en voorspelbaarheid, en de licentie bepaalt meer implementaties dan de benchmark.