LFM3-Omni-2B vs MiniCPM-V 4.7 1B: quando il modello più piccolo legge meglio

Sulla carta non è una sfida ad armi pari. LFM3-Omni-2B ha 2,17 miliardi di parametri; MiniCPM-V 4.7 1B viene commercializzato come modello 1B. Il modello più grande dovrebbe vincere i benchmark di visione. Non succede. MiniCPM ottiene 86,1 su OCRBench contro 80,6, 69,5 su MMStar contro 55,67, 56,9 su MMMU contro 42,44 e 74,3 su MathVista contro 62,5. Ogni benchmark di visione condiviso dalle due schede favorisce il modello con il nome più piccolo, di solito con un ampio margine, e MiniCPM ha anche una finestra di contesto otto volte più grande. La fusione costa più per chiamata rispetto all'instradamento verso un singolo modello. Viene fatturata al prezzo di listino del provider senza alcun ricarico aggiunto.

Tre cose lo spiegano, e nessuna delle tre è un difetto di nessuno dei due modelli. MiniCPM-V 4.7 1B è uno specialista che ha speso l'intero budget di parametri per la visione. LFM3-Omni-2B è un generalista che ha speso il suo budget per vedere, sentire e parlare. E il dato di MiniCPM che conta di più — 86,1 su OCRBench — è stato misurato con la sua impostazione dei token visivi 4×, che baratta calcolo con dettaglio in un modo che un limite di 2.048 token per immagine non può. Comprendere questo compromesso è l'intera decisione.

Perché il modello più piccolo legge meglio

MiniCPM-V 4.7 1B è costruito attorno a un'unica idea: comprimere presto i token visivi e lasciare che l'utente scelga con quanta intensità comprimere. Il modello applica una compressione dei token di 4× o 16× all'interno dell'encoder visivo, prima che il modello linguistico veda qualcosa. A 16× è economico e veloce, adatto alla generazione di didascalie e alla descrizione di scene. A 4× mantiene quattro volte più token, ed è ciò di cui necessitano l'OCR dei documenti e la lettura di grafici densi. I numeri principali di OpenBMB sono riportati con l'impostazione 4×.

LFM3-Omni-2B adotta l'approccio opposto. Elabora le immagini alla risoluzione nativa ma limita il budget visivo a 2.048 token per immagine, e tale limite è condiviso con un encoder audio, un percorso video e un decoder vocale all'interno di una rete densa da 2,17 miliardi di parametri. Il tetto di 2.048 token è una scelta ragionevole per un modello che deve stare su un telefono insieme ad altre tre modalità. È un tetto rigido sulla quantità di dettaglio della pagina che può raggiungere il modello linguistico, e DocVQA 92,47 suggerisce che il modello ne sfrutta molto — ma OCRBench 80,6 indica che non basta per battere uno specialista che può spendere 4× i token sulla stessa pagina.

C'è un secondo fattore, più silenzioso. La finestra di contesto di MiniCPM è di 262.144 token. Quella di LFM3-Omni-2B è di 32.768. Per un singolo screenshot non conta nessuna delle due. Per un PDF di 40 pagine, un video lungo o una conversazione multi-turno su un documento, la differenza non è una riga di benchmark — è se il compito sia possibile o meno.

Specifiche, senza arrotondamenti di marketing

Un numero va corretto prima di qualsiasi confronto. MiniCPM-V 4.7 1B viene chiamato modello 1B, e il suo conteggio dei parametri densi è di circa 1,3–1,55 miliardi a seconda di come si conta la torre visiva. La barra laterale di Hugging Face lo arrotonda a "2B params", ed è così che un modello 1B finisce per sembrare un modello 2B in un catalogo. La dimensione del file è l'indicatore più affidabile: circa 3,1 GB in BF16, contro 4,3 GB per LFM3-Omni-2B.

• Parametri — 2,17B densi per LFM3-Omni-2B rispetto a circa 1,3B–1,55B densi per MiniCPM-V 4.7 1B.

• Input — testo, immagine, video con audio, audio a 16 kHz vs testo, immagine, multi-immagine e video.

• Output — testo e parlato a 24 kHz rispetto al solo testo.

• Contesto — 32.768 token rispetto a 262.144 token.

• Token visivi — limitati a 2,048 per immagine rispetto alla compressione commutabile 4× o 16× all'interno dell'encoder.

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

• Rilascio — 27 ottobre 2026 vs 12 ottobre 2026.

• Ingombro — circa 4,3 GB in BF16 rispetto a circa 3,1 GB in BF16, circa 5 GB di VRAM per servire il modello.

Ogni riga che le due carte hanno in comune

Il confronto è insolitamente pulito per una tabella inter-laboratori, perché entrambi i fornitori riportano gli stessi quattro dataset di visione ed entrambi sono modelli non di ragionamento valutati in modalità instruct. Restano comunque due valutazioni di fornitori, e nessuna delle due è stata riprodotta in modo indipendente.

• OCRBench — 80,6 per LFM3-Omni-2B (806 su 1.000) rispetto a 86,1 per MiniCPM-V 4.7 1B. Un divario di 5,5 punti nel riconoscimento del testo nei documenti.

• MMStar — 55,67 vs 69,5. Un divario di 13,8 punti, il più ampio del set.

• Validazione MMMU — 42,44 vs 56,9. Un divario di 14,5 punti nel ragionamento multimodale a livello universitario.

• MathVista mini — 62.50 vs 74.3. Un divario di 11,8 punti nella matematica visiva.

Quattro righe, quattro sconfitte, divari tra cinque e quindici punti. Non c'è alcuna riga in cui il modello omni vinca, un risultato più pulito di quello prodotto dal confronto LFM3 contro LFM2.5 e più difficile da spiegare via. L'interpretazione più difendibile è che uno specialista da 1,4B con un contesto da 256K e un budget di token 4× sia semplicemente un lettore migliore di un generalista da 2,17B con un contesto da 32K e un limite immagine di 2.048 token. La capacità spesa su una sola modalità batte la capacità divisa tra quattro, a questa scala.

Due avvertenze vanno fatte insieme, perché nessuna delle due schede le rende note spontaneamente. L'86,1 di MiniCPM è misurato con compressione 4×, e lo stesso modello con l'impostazione predefinita a 16× otterrebbe un punteggio inferiore e costerebbe meno — la scheda non pubblica quel numero. Inoltre, la scheda modello di OpenBMB non riporta alcuna tabella di benchmark; i dati compaiono come testo e immagini di grafici sulla pagina prodotto, una forma di pubblicazione più debole rispetto a una tabella con una nota metodologica. Entrambe le serie di numeri sono dichiarazioni del fornitore. La direzione del divario è sufficientemente coerente da resistere probabilmente a test indipendenti; la dimensione esatta probabilmente no.

Il contesto è la riga che decide i carichi di lavoro reali.

Un contesto di 32K è generoso per una singola immagine e ridotto per un documento. A circa 2.048 token visivi per immagine, LFM3-Omni-2B può contenere nella propria finestra circa una dozzina di immagini complete prima che la cronologia della conversazione inizi a competere per lo spazio. I 262.144 token di MiniCPM-V 4.7 1B non rappresentano un miglioramento modesto; sono una classe di carico di lavoro diversa. PDF lunghi, moduli multipagina, riepiloghi video di un'ora e cicli di agenti che mantengono gli screenshot nel contesto sono tutti fattibili a 256K e tutti limitati a 32K.

Questa è la differenza meno discussa e più rilevante tra i due modelli. Le tabelle di benchmark premiano la precisione su una singola immagine; le pipeline documentali in produzione falliscono alla quattordicesima pagina. Se il tuo caso d'uso prevede più di una manciata di immagini per conversazione, la finestra da 32K è un limite più stringente di qualsiasi dei quattro divari di benchmark sopra indicati.

Cosa MiniCPM non può fare

Non può sentire. Non esiste alcun percorso di input audio, alcuna uscita vocale e alcuna gestione della traccia audio video. Se l'applicazione consiste in una persona che parla a un dispositivo di ciò che vede la fotocamera, MiniCPM-V 4.7 1B è un componente di una pipeline che necessita di almeno altri due modelli — un sistema ASR e un sistema TTS — oltre alla logica di collegamento per far passare il testo tra di essi.

LFM3-Omni-2B condensa quella pipeline in un unico checkpoint da 4,3 GB. I suoi punteggi audio non hanno niente di eccezionale rispetto ai modelli vocali dedicati — WER dell'ASR inglese 6,36, VoiceBench 64,73 — ma esistono all'interno dello stesso forward pass del percorso visivo, il che significa che il modello può rispondere a una domanda parlata su un'immagine senza che venga mai scritta una trascrizione. Per uno strumento da campo a mani libere o un chiosco, questa è la funzione. Per una pipeline documentale, è peso morto nel budget dei parametri.

La fusione di modelli di OrcaRouter è l'altro modo per ottenere entrambi i comportamenti: un pannello in cui uno specialista di documenti e un modello omni rispondono allo stesso prompt e la risposta viene composta da entrambi. Si tratta di una capacità del prodotto più che di un'affermazione su questi due checkpoint — nessuno dei due è oggi nel nostro catalogo — ma è la risposta architetturale a un confronto in cui ciascun modello è chiaramente migliore in una metà diversa del lavoro. La fusione costa di più per chiamata rispetto all'instradamento verso un singolo modello, e vale la pena esattamente quando una risposta sbagliata costa più dei token.

La decisione

Se il lavoro consiste nella lettura — OCR, fatture, moduli, grafici, screenshot, PDF lunghi, UI dense — MiniCPM-V 4.7 1B è il modello migliore su ogni metrica pubblicata, ha una finestra di contesto otto volte più ampia, è Apache-2.0 invece di una licenza personalizzata con una soglia di fatturato ed è più piccolo su disco. Non c'è partita, e il fatto che sia chiamato modello 1B non deve oscurare questo aspetto.

Se il lavoro è una conversazione con un dispositivo dotato di fotocamera e microfono, LFM3-Omni-2B è l'unico dei due in grado di partecipare. Legge meno bene, mantiene meno contesto e viene distribuito con condizioni più restrittive, e nulla di tutto ciò conta se l'alternativa richiede tre modelli e una pipeline.

C'è un terzo caso che merita di essere menzionato: un prodotto che necessita di entrambi, in cui il percorso documenti e il percorso voce sono funzionalità separate. Allora l'architettura corretta non è un solo modello ma due, instradati in base al tipo di richiesta — il lettore per i documenti, il modello omni per la voce — e l'unica domanda è se vuoi eseguirli entrambi o lasciare che sia un singolo endpoint a decidere. È la domanda a cui continua ad arrivare questo lotto di confronti, ed è quella giusta. I modelli sono abbastanza vicini in termini di impronta da rendere l'esecuzione di entrambi un'opzione reale; sono abbastanza distanti in capacità che eseguirne solo uno è un compromesso, qualunque tu scelga.

Ciò che cambierebbe il verdetto è una valutazione indipendente di uno qualsiasi dei due modelli, e in particolare una che testi MiniCPM alla sua compressione predefinita di 16× anziché all'impostazione di 4× usata nei suoi numeri di punta. Quel singolo dato potrebbe colmare gran parte del divario — o ampliarlo. Finché qualcuno non lo pubblica, le tabelle dei fornitori sono ciò che abbiamo, e puntano in una sola direzione.