LFM3-Omni-2B vs MiniCPM-V 4.7 1B: När den mindre modellen läser bättre

På pappret är detta inte en rättvis kamp. LFM3-Omni-2B har 2,17 miljarder parametrar; MiniCPM-V 4.7 1B marknadsförs som en 1B-modell. Den större modellen borde vinna visionsbenchmarkarna. Det gör den inte. MiniCPM får 86,1 på OCRBench mot 80,6, 69,5 på MMStar mot 55,67, 56,9 på MMMU mot 42,44 och 74,3 på MathVista mot 62,5. Varje visionsbenchmark som de två korten delar gynnar modellen med det mindre namnet, vanligtvis med bred marginal, och MiniCPM har också åtta gånger så stort kontextfönster. Fusion kostar mer per anrop än att routa till en enda modell. Den faktureras enligt leverantörens listpris utan något påslag.

Tre saker förklarar det, och ingen av dem är en defekt i någon av modellerna. MiniCPM-V 4.7 1B är en specialist som lade hela sin parameterbudget på att se. LFM3-Omni-2B är en generalist som lade sin budget på att se, höra och tala. Och den MiniCPM-siffra som betyder mest – 86,1 på OCRBench – mättes med dess inställning för 4× visuella token, som byter beräkningskraft mot detalj på ett sätt som en gräns på 2 048 token per bild inte kan. Att förstå den avvägningen är hela beslutet.

Varför den mindre modellen läser bättre

MiniCPM-V 4.7 1B är byggd kring en enda idé: komprimera visuella token tidigt och låt användaren välja hur hårt komprimeringen ska ske. Modellen tillämpar 4× eller 16× tokenkomprimering i vision-encodern, innan språkmodellen ser något. Vid 16× är den billig och snabb, lämplig för bildtexter och scenbeskrivningar. Vid 4× behåller den fyra gånger så många token, vilket är vad dokument-OCR och läsning av täta diagram behöver. OpenBMB:s huvudsiffror rapporteras vid 4×-inställningen.

LFM3-Omni-2B går motsatt väg. Den bearbetar bilder i ursprunglig upplösning men begränsar den visuella budgeten till 2 048 token per bild, och den gränsen delas med en ljudkodare, en videoväg och en talkodare i ett tätt 2,17B-nätverk. Taket på 2 048 token är ett rimligt val för en modell som måste få plats i en telefon tillsammans med tre andra modaliteter. Det är ett hårt tak för hur mycket sidinformation som kan nå språkmodellen, och DocVQA 92.47 antyder att modellen får ut mycket av det — men OCRBench 80.6 säger att det inte räcker för att slå en specialist som kan använda 4× så många token på samma sida.

Det finns en andra, tystare faktor. MiniCPMs kontextfönster är 262 144 tokens. LFM3-Omni-2B:s är 32 768. För en enda skärmbild spelar ingen av dem någon roll. För en PDF på 40 sidor, en lång video eller en dokumentkonversation över flera turer är skillnaden inte en rad i ett benchmark — det är huruvida uppgiften överhuvudtaget är möjlig.

Specifikation, utan marknadsföringens avrundning

Ett nummer behöver korrigeras innan någon jämförelse. MiniCPM-V 4.7 1B kallas en 1B-modell, och dess täta parameterantal är ungefär 1,3 till 1,55 miljarder beroende på hur man räknar visionsmodulen. Hugging Faces sidopanel avrundar det till "2B params", och det är så en 1B-modell kan se ut som en 2B-modell i en katalog. Filstorleken är den ärliga vägledningen: cirka 3,1 GB i BF16, mot 4,3 GB för LFM3-Omni-2B.

• Parametrar — 2,17B täta för LFM3-Omni-2B jämfört med ungefär 1,3B till 1,55B täta för MiniCPM-V 4.7 1B.

• Indata — text, bild, video med ljud, 16 kHz-ljud kontra text, bild, flera bilder och video.

• Utdata — text och 24 kHz-tal jämfört med enbart text.

• Kontext — 32 768 token jämfört med 262 144 token.

• Visuella tokens — begränsat till 2 048 per bild jämfört med växlingsbar 4× eller 16× komprimering inuti kodaren.

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

• Utgåva – 27 oktober 2026 vs 12 oktober 2026.

• Minnesavtryck — cirka 4,3 GB BF16 jämfört med cirka 3,1 GB BF16, ungefär 5 GB VRAM för att serva.

Varje rad som de två korten har gemensamt

Jämförelsen är ovanligt ren för en tabell mellan labb, eftersom båda leverantörerna rapporterar samma fyra bilddatamängder och båda är icke-resonerande modeller som utvärderats i instruct-läge. Det är fortfarande två leverantörsutvärderingar, och ingen av dem har reproducerats oberoende.

• OCRBench — 80,6 för LFM3-Omni-2B (806 av 1 000) jämfört med 86,1 för MiniCPM-V 4.7 1B. En skillnad på 5,5 poäng när det gäller textigenkänning i dokument.

• MMStar — 55,67 mot 69,5. En skillnad på 13,8 punkter, den största i uppsättningen.

• MMMU-validering — 42,44 mot 56,9. En skillnad på 14,5 punkter i multimodalt resonemang på universitetsnivå.

• MathVista mini — 62.50 vs 74.3. En lucka på 11,8 poäng inom visuell matematik.

Fyra rader, fyra förluster, gap mellan fem och femton poäng. Det finns ingen rad där omni-modellen vinner, vilket är ett renare resultat än jämförelsen LFM3 mot LFM2.5 gav och ett svårare att bortförklara. Den mest försvarbara tolkningen är att en 1,4B-specialist med 256K kontext och en 4× tokenbudget helt enkelt är en bättre läsare än en 2,17B-generalist med 32K kontext och ett bildtak på 2 048 token. Kapacitet som satsas på en modalitet slår kapacitet som delas på fyra, i den här skalan.

Två förbehåll hör hemma i samma andetag, eftersom inget av korten frivilligt nämner dem. MiniCPM:s 86,1 mäts vid 4× komprimering, och samma modell vid standardinställningen 16× skulle få lägre poäng och vara billigare att köra — kortet publicerar inte den siffran. Och OpenBMB:s modellkort innehåller ingen benchmarktabell alls; siffrorna förekommer som löptext och diagrambilder på produktsidan, vilket är en svagare form av publicering än en tabell med en metodbeskrivning. Båda uppsättningarna siffror är leverantörens påståenden. Skillnadens riktning är tillräckligt konsekvent för att den förmodligen står sig i oberoende tester; den exakta storleken gör det förmodligen inte.

Kontext är raden som avgör verkliga arbetsbelastningar

Ett 32K-kontext är generöst för en enskild bild och trångt för ett dokument. Vid ungefär 2 048 visuella tokens per bild kan LFM3-Omni-2B rymma ett drygt dussin fullständiga bilder i sitt fönster innan konversationshistoriken börjar konkurrera om utrymmet. MiniCPM-V 4.7 1B:s 262 144 tokens är ingen blygsam förbättring; det är en annan klass av arbetsbelastning. Långa PDF:er, flersidiga formulär, timslånga videosammanfattningar och agentloopar som behåller skärmbilder i kontexten är alla genomförbara vid 256K och alla begränsade vid 32K.

Detta är den minst diskuterade och mest konsekvensrika skillnaden mellan de två modellerna. Benchmarktabeller belönar noggrannhet på enstaka bilder; produktionsdokumentpipelines misslyckas på den fjortonde sidan. Om ditt användningsfall omfattar mer än en handfull bilder per konversation är 32K-fönstret en hårdare gräns än något av de fyra benchmarkglappen ovan.

Vad MiniCPM inte kan göra

Den kan inte höra. Det finns ingen väg för ljudinmatning, ingen talutmatning och ingen hantering av videoljudspår. Om applikationen är en person som talar till en enhet om vad kameran ser, är MiniCPM-V 4.7 1B en komponent i en pipeline som behöver minst två modeller till – ett ASR-system och ett TTS-system – plus klistret som flyttar text mellan dem.

LFM3-Omni-2B pressar samman den pipelinen till en enda checkpoint på 4,3 GB. Dess ljudresultat är intetsägande bredvid dedikerade talmodeller – engelsk ASR 6,36 i ordfelsfrekvens, VoiceBench 64,73 – men de finns i samma framåtpass som visionsvägen, vilket innebär att modellen kan svara på en talad fråga om en bild utan att någon transkription någonsin skrivs. För ett handsfree-fältverktyg eller en kiosk är det själva funktionen. För en dokumentpipeline är det dödvikt i parameterbudgeten.

OrcaRouter's modellsammanslagning är det andra sättet att få båda beteendena: en panel där en dokumentspecialist och en allroundmodell svarar på samma prompt och svaret komponeras från båda. Det är en produktkapacitet snarare än ett påstående om dessa två checkpoints – ingen av dem finns i vår katalog i dag – men det är det arkitektoniska svaret på en matchning där varje modell är klart bättre på en varsin hälft av jobbet. Sammanslagning kostar mer per anrop än att routa till en enda modell, och det är värt det precis när ett felaktigt svar kostar mer än tokens.

Beslutet

Om arbetet består i att läsa – OCR, fakturor, formulär, diagram, skärmbilder, långa PDF:er, täta gränssnitt – är MiniCPM-V 4.7 1B den bättre modellen enligt varje publicerat mått, den har åtta gånger så stor kontext, den är Apache-2.0 i stället för en anpassad licens med en intäktströskel, och den är mindre på disk. Det är inte ens nära, och att den kallas en 1B-modell bör inte skymma det.

Om arbetet är en konversation med en enhet som har en kamera och en mikrofon är LFM3-Omni-2B den enda av de två som kan delta. Den läser sämre, behåller mindre kontext och levereras under strängare villkor, och inget av det spelar någon roll om alternativet kräver tre modeller och en pipeline.

Det finns ett tredje fall som är värt att nämna: en produkt som behöver båda, där dokumentvägen och röstvägen är separata funktioner. Då är den korrekta arkitekturen inte en modell utan två, dirigerade efter begärandetyp – läsaren för dokument, omni-modellen för röst – och den enda frågan är om du vill köra båda eller låta en enda slutpunkt avgöra. Det är frågan som den här omgången jämförelser ständigt landar i, och det är rätt fråga. Modellerna ligger tillräckligt nära varandra i fotavtryck för att det är ett realistiskt alternativ att köra båda; de skiljer sig tillräckligt mycket i kapacitet för att det är en kompromiss att köra bara en, oavsett vilken du väljer.

Det som skulle förändra domen är en oberoende utvärdering av någon av modellerna, och särskilt en som testar MiniCPM vid dess standardkomprimering på 16× i stället för den 4×-inställning som dess rubriksiffror använder. Den enda siffran skulle kunna minska större delen av gapet — eller öka det. Tills någon publicerar den är leverantörstabellerna det vi har, och de pekar i en riktning.