LFM3-Omni-2B vs MiniCPM-V 4.7 1B: Wanneer het kleinere model beter leest

Op papier is dit geen eerlijke strijd. LFM3-Omni-2B heeft 2,17 miljard parameters; MiniCPM-V 4.7 1B wordt op de markt gebracht als een 1B-model. Het grotere model zou de vision-benchmarks moeten winnen. Dat doet het niet. MiniCPM scoort 86,1 op OCRBench tegenover 80,6, 69,5 op MMStar tegenover 55,67, 56,9 op MMMU tegenover 42,44 en 74,3 op MathVista tegenover 62,5. Elke vision-benchmark die de twee modelkaarten gemeen hebben, valt in het voordeel uit van het model met de kleinere naam, meestal met een ruime marge, en MiniCPM heeft bovendien acht keer zo'n groot contextvenster. Fusion kost meer per aanroep dan routering naar één model. Het wordt gefactureerd tegen de lijstprijs van de provider zonder dat er een opslag wordt toegevoegd.

Drie dingen verklaren dat, en geen ervan is een defect in een van beide modellen. MiniCPM-V 4.7 1B is een specialist die zijn hele parameterbudget aan zien heeft besteed. LFM3-Omni-2B is een generalist die zijn budget aan zien, horen en spreken heeft besteed. En het MiniCPM-getal dat er het meest toe doet — 86,1 op OCRBench — is gemeten met de instelling van 4× visuele tokens, die rekenkracht inruilt voor detail op een manier die een limiet van 2.048 tokens per afbeelding niet kan. Die afweging begrijpen is de hele beslissing.

Waarom het kleinere model beter leest

MiniCPM-V 4.7 1B is gebouwd rond één idee: visuele tokens vroeg comprimeren en de gebruiker laten kiezen hoe sterk er wordt gecomprimeerd. Het model past 4× of 16× tokencompressie toe in de visie-encoder, voordat het taalmodel iets te zien krijgt. Bij 16× is het goedkoop en snel, geschikt voor beeldbeschrijving en scènebeschrijving. Bij 4× behoudt het vier keer zoveel tokens, wat nodig is voor document-OCR en het lezen van dichte grafieken. De belangrijkste cijfers van OpenBMB worden gerapporteerd bij de 4×-instelling.

LFM3-Omni-2B neemt de tegenovergestelde aanpak. Het verwerkt afbeeldingen op oorspronkelijke resolutie, maar beperkt het visuele budget tot 2,048 tokens per afbeelding, en die limiet wordt gedeeld met een audio-encoder, een videopad en een spraakdecoder binnen een dense netwerk van 2.17B. Het plafond van 2,048 tokens is een redelijke keuze voor een model dat op een telefoon moet passen naast drie andere modaliteiten. Het is een hard plafond voor hoeveel paginadetail het taalmodel kan bereiken, en DocVQA 92.47 suggereert dat het model er veel uit haalt — maar OCRBench 80.6 zegt dat het niet genoeg is om een specialist te verslaan die 4× de tokens aan dezelfde pagina kan besteden.

Er is een tweede, stiller factor. Het contextvenster van MiniCPM is 262,144 tokens. Dat van LFM3-Omni-2B is 32,768. Voor één screenshot maakt geen van beide uit. Voor een PDF van 40 pagina's, een lange video of een meerbeurtig gesprek over een document is het verschil geen benchmarkrij — het bepaalt of de taak überhaupt mogelijk is.

Specificatie, zonder de marketingafronding

Er moet één getal worden gecorrigeerd voordat je kunt vergelijken. MiniCPM-V 4.7 1B wordt een 1B-model genoemd, en het aantal dense parameters ligt ruwweg tussen 1,3 en 1,55 miljard, afhankelijk van hoe je de visiontoren meetelt. In de zijbalk van Hugging Face wordt het afgerond naar "2B params", waardoor een 1B-model in een catalogus als een 2B-model kan lijken. De bestandsgrootte is de betrouwbare leidraad: ongeveer 3,1 GB in BF16, tegenover 4,3 GB voor LFM3-Omni-2B.

• Parameters — 2,17B dense voor LFM3-Omni-2B versus ongeveer 1,3B tot 1,55B dense voor MiniCPM-V 4.7 1B.

• Invoer — tekst, afbeelding, video met audio, 16 kHz audio versus tekst, afbeelding, meerdere afbeeldingen en video.

• Uitvoer — tekst en 24 kHz-spraak versus alleen tekst.

• Context — 32.768 tokens vs. 262.144 tokens.

• Visuele tokens — beperkt tot 2.048 per afbeelding versus schakelbare 4×- of 16×-compressie binnen de encoder.

• Licentie — LFM Open License v1.0 vs Apache-2.0.

• Uitgave — 27 oktober 2026 vs 12 oktober 2026.

• Voetafdruk — ongeveer 4,3 GB BF16 versus ongeveer 3,1 GB BF16, ruwweg 5 GB VRAM om te serveren.

Elke rij die de twee kaarten delen

De vergelijking is ongewoon zuiver voor een cross-labtabel, omdat beide leveranciers dezelfde vier vision-datasets rapporteren en beide non-reasoningmodellen zijn die in instructmodus zijn geëvalueerd. Het zijn nog steeds twee leveranciersevaluaties, en geen van beide is onafhankelijk gereproduceerd.

• OCRBench — 80,6 voor LFM3-Omni-2B (806 van 1.000) tegenover 86,1 voor MiniCPM-V 4.7 1B. Een verschil van 5,5 punten bij tekstherkenning in documenten.

• MMStar — 55,67 vs 69,5. Een verschil van 13,8 punten, het grootste in de set.

• MMMU-validatie — 42,44 vs 56,9. Een verschil van 14,5 punt op multimodaal redeneren op universitair niveau.

• MathVista mini — 62,50 vs 74,3. Een verschil van 11,8 punten op visuele wiskunde.

Vier rijen, vier verliezen, verschillen tussen vijf en vijftien punten. Er is geen rij waarin het omni-model wint, wat een zuiverder resultaat is dan de vergelijking LFM3-versus-LFM2.5 opleverde en een moeilijker weg te verklaren resultaat. De meest verdedigbare interpretatie is dat een 1,4B-specialist met een 256K-context en een 4× tokenbudget simpelweg een betere lezer is dan een 2,17B-generalist met een 32K-context en een limiet van 2.048 tokens per afbeelding. Capaciteit die aan één modaliteit wordt besteed, verslaat capaciteit die over vier modaliteiten wordt verdeeld, op deze schaal.

Twee voorbehouden horen in één adem genoemd te worden, want geen van beide kaarten vermeldt ze uit zichzelf. MiniCPM's 86,1 is gemeten bij 4× compressie, en hetzelfde model zou bij zijn standaardinstelling van 16× lager scoren en goedkoper draaien — de kaart publiceert dat getal niet. En de modelkaart van OpenBMB bevat helemaal geen benchmarktabel; de cijfers verschijnen als proza en grafiekafbeeldingen op de productpagina, wat een zwakkere vorm van publicatie is dan een tabel met een methodologieopmerking. Beide sets cijfers zijn leveranciersclaims. De richting van het verschil is consistent genoeg dat het waarschijnlijk standhoudt bij onafhankelijk testen; de exacte grootte waarschijnlijk niet.

Context is de rij die echte workloads bepaalt.

Een context van 32K is royaal voor één afbeelding en krap voor een document. Met ruwweg 2.048 visuele tokens per afbeelding kan LFM3-Omni-2B ongeveer een dozijn volledige afbeeldingen in zijn venster houden voordat de gespreksgeschiedenis om ruimte begint te concurreren. De 262.144 tokens van MiniCPM-V 4.7 1B zijn geen bescheiden verbetering; het is een andere klasse van workloads. Lange pdf's, formulieren van meerdere pagina's, samenvattingen van video's van een uur en agentlussen die screenshots in context houden, zijn allemaal haalbaar bij 256K en allemaal beperkt bij 32K.

Dit is het minst besproken en meest ingrijpende verschil tussen de twee modellen. Benchmarktabellen belonen nauwkeurigheid op één afbeelding; productiepijplijnen voor documenten falen op de veertiende pagina. Als uw gebruiksscenario meer dan een handvol afbeeldingen per gesprek omvat, is het venster van 32K een strengere beperking dan elk van de vier benchmarkverschillen hierboven.

Wat MiniCPM niet kan doen

Het kan niet horen. Er is geen audiostreaminvoerpad, geen spraakuitvoer en geen verwerking van videogeluidssporen. Als de toepassing erin bestaat dat een persoon tegen een apparaat praat over wat de camera ziet, is MiniCPM-V 4.7 1B één onderdeel van een pipeline waarvoor nog minstens twee modellen nodig zijn — een ASR-systeem en een TTS-systeem — plus de lijm om tekst tussen hen te verplaatsen.

LFM3-Omni-2B vouwt die pipeline samen tot één checkpoint van 4,3 GB. De audioscores zijn onopvallend naast gespecialiseerde spraakmodellen — Engelse ASR 6,36 woordfoutpercentage, VoiceBench 64,73 — maar ze bestaan binnen dezelfde forward pass als het visiepad, wat betekent dat het model een gesproken vraag over een afbeelding kan beantwoorden zonder dat ooit een transcript wordt geschreven. Voor een handsfree veldhulpmiddel of een kiosk is dat juist de functie. Voor een documentpipeline is het dode ballast in het parameterbudget.

OrcaRouter's modelfusie is de andere manier om beide gedragingen te krijgen: een panel waarin een documentspecialist en een omni-model op dezelfde prompt antwoorden en het antwoord uit beide wordt samengesteld. Dat is een productcapaciteit en geen bewering over deze twee checkpoints — geen van beide staat vandaag in onze catalogus — maar het is het architectonische antwoord op een krachtmeting waarin elk model duidelijk beter is in een andere helft van de taak. Fusie kost meer per aanroep dan routeren naar één model, en het is precies de moeite waard wanneer een fout antwoord meer kost dan de tokens.

De beslissing

Als het werk lezen is — OCR, facturen, formulieren, grafieken, screenshots, lange pdf's, dichte UI — dan is MiniCPM-V 4.7 1B het betere model op elke gepubliceerde maatstaf, het heeft acht keer zoveel context, het is Apache-2.0 in plaats van een aangepaste licentie met een omzetdrempel, en het is kleiner op schijf. Dat is geen twijfelgeval, en het feit dat het een 1B-model wordt genoemd, mag dat niet verdoezelen.

Als het werk een gesprek is met een apparaat met een camera en een microfoon, is LFM3-Omni-2B de enige van de twee die kan deelnemen. Het leest minder goed, houdt minder context vast en wordt onder striktere voorwaarden geleverd, en niets daarvan maakt uit als het alternatief drie modellen en een pipeline vereist.

Er is nog een derde geval dat het benoemen waard is: een product dat beide nodig heeft, waarbij het documentpad en het spraakpad afzonderlijke functies zijn. Dan is de juiste architectuur niet één model maar twee, gerouteerd op aanvraagtype — de reader voor documenten, het omni-model voor spraak — en de enige vraag is of je beide wilt draaien of een enkel endpoint wilt laten beslissen. Dat is de vraag waar deze reeks vergelijkingen steeds op uitkomt, en het is de juiste. De modellen liggen qua voetafdruk dicht genoeg bij elkaar dat beide draaien een reële optie is; ze verschillen qua capaciteiten ver genoeg van elkaar dat slechts één draaien een compromis is, welke je ook kiest.

Wat het oordeel zou veranderen, is een onafhankelijke evaluatie van een van beide modellen, en dan specifiek een die MiniCPM test bij de standaardcompressie van 16× in plaats van de 4×-instelling waarop de kopcijfers zijn gebaseerd. Dat ene cijfer zou het grootste deel van de kloof kunnen dichten — of juist vergroten. Totdat iemand het publiceert, zijn de leverancierstabellen alles wat we hebben, en die wijzen in één richting.