LFM3-Omni-2B vs MiniCPM-V 4.7 1B : quand le modèle plus petit lit mieux

Sur le papier, ce n'est pas un combat équitable. LFM3-Omni-2B compte 2,17 milliards de paramètres ; MiniCPM-V 4.7 1B est présenté comme un modèle 1B. Le modèle le plus grand devrait gagner sur les benchmarks de vision. Ce n'est pas le cas. MiniCPM obtient 86,1 sur OCRBench contre 80,6, 69,5 sur MMStar contre 55,67, 56,9 sur MMMU contre 42,44, et 74,3 sur MathVista contre 62,5. Chaque benchmark de vision que partagent les deux fiches favorise le modèle au nom plus petit, généralement avec une large marge, et MiniCPM dispose en outre d'une fenêtre de contexte huit fois plus grande. La fusion coûte plus cher par appel que le routage vers un seul modèle. Elle est facturée au prix catalogue du fournisseur sans marge ajoutée.

Trois choses expliquent cela, et aucune n’est un défaut de l’un ou l’autre modèle. MiniCPM-V 4.7 1B est un spécialiste qui a consacré tout son budget de paramètres à la vision. LFM3-Omni-2B est un généraliste qui a consacré son budget à la vision, à l’audition et à la parole. Et le chiffre MiniCPM qui compte le plus — 86,1 sur OCRBench — a été mesuré avec son réglage de 4× jetons visuels, qui troque du calcul contre du détail d’une manière qu’un plafond de 2 048 jetons par image ne peut pas. Comprendre ce compromis, c’est tout l’enjeu de la décision.

Pourquoi le modèle plus petit se lit mieux

MiniCPM-V 4.7 1B repose sur une idée unique : compresser les tokens visuels en amont et laisser l'utilisateur choisir l'intensité de la compression. Le modèle applique une compression des tokens de 4× ou 16× au sein de l'encodeur visuel, avant que le modèle de langage n'ait accès à quoi que ce soit. À 16×, il est économique et rapide, adapté à la génération de légendes et à la description de scènes. À 4×, il conserve quatre fois plus de tokens, ce dont ont besoin l'OCR de documents et la lecture de graphiques denses. Les chiffres phares d'OpenBMB sont rapportés au réglage 4×.

LFM3-Omni-2B adopte l’approche inverse. Il traite les images à leur résolution native, mais plafonne le budget visuel à 2 048 tokens par image, et ce plafond est partagé avec un encodeur audio, une voie vidéo et un décodeur vocal au sein d’un réseau dense de 2,17 B. Le plafond de 2 048 tokens est un choix raisonnable pour un modèle qui doit tenir sur un téléphone aux côtés de trois autres modalités. Il s’agit d’un plafond strict sur la quantité de détails de page pouvant atteindre le modèle de langage, et DocVQA 92,47 suggère que le modèle en tire beaucoup — mais OCRBench 80,6 indique que cela ne suffit pas à battre un spécialiste capable de dépenser 4× plus de tokens sur la même page.

Il existe un second facteur, plus discret. La fenêtre de contexte de MiniCPM est de 262 144 tokens. Celle de LFM3-Omni-2B est de 32 768. Pour une seule capture d’écran, ni l’une ni l’autre n’a d’importance. Pour un PDF de 40 pages, une longue vidéo ou une conversation documentaire à plusieurs tours, la différence n’est pas une ligne de benchmark — c’est la possibilité même d’accomplir la tâche.

Spécifications, sans les arrondis marketing

Un chiffre doit être corrigé avant toute comparaison. MiniCPM-V 4.7 1B est présenté comme un modèle 1B, et son nombre de paramètres denses est d’environ 1,3 à 1,55 milliard selon la façon dont on compte la tour de vision. La barre latérale de Hugging Face l’arrondit à « 2B params », ce qui explique comment un modèle 1B finit par ressembler à un modèle 2B dans un catalogue. La taille du fichier est le guide honnête : environ 3,1 Go en BF16, contre 4,3 Go pour LFM3-Omni-2B.

• Paramètres — 2,17 Md de paramètres denses pour LFM3-Omni-2B, contre environ 1,3 Md à 1,55 Md de paramètres denses pour MiniCPM-V 4.7 1B.

• Entrées — texte, image, vidéo avec audio, audio 16 kHz vs texte, image, multi-images et vidéo.

• Sorties — texte et parole à 24 kHz vs texte seul.

• Contexte — 32 768 jetons contre 262 144 jetons.

• Tokens visuels — plafonnés à 2 048 par image, contre une compression commutable de 4× ou 16× à l’intérieur de l’encodeur.

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

• Sortie — 27 octobre 2026 vs 12 octobre 2026.

• Empreinte — environ 4,3 Go en BF16 contre environ 3,1 Go en BF16, soit environ 5 Go de VRAM pour le servir.

Chaque ligne que les deux cartes ont en commun

La comparaison est inhabituellement propre pour un tableau entre laboratoires, car les deux fournisseurs rapportent les mêmes quatre jeux de données de vision et les deux sont des modèles sans raisonnement évalués en mode instruct. Il s’agit néanmoins toujours de deux évaluations de fournisseurs, et aucune n’a été reproduite indépendamment.

• OCRBench — 80,6 pour LFM3-Omni-2B (806 sur 1 000) contre 86,1 pour MiniCPM-V 4.7 1B. Un écart de 5,5 points sur la reconnaissance de texte dans les documents.

• MMStar — 55,67 contre 69,5. Un écart de 13,8 points, le plus grand de l'ensemble.

• MMMU validation — 42,44 contre 56,9. Un écart de 14,5 points sur le raisonnement multimodal de niveau universitaire.

• MathVista mini — 62,50 vs 74,3. Un écart de 11,8 points en mathématiques visuelles.

Quatre lignes, quatre défaites, des écarts entre cinq et quinze points. Il n’y a aucune ligne où le modèle omni l’emporte, ce qui est un résultat plus net que celui produit par la comparaison LFM3 contre LFM2.5 et plus difficile à expliquer. L’interprétation la plus défendable est qu’un spécialiste de 1,4 B avec un contexte de 256 K et un budget de 4× jetons est simplement un meilleur lecteur qu’un généraliste de 2,17 B avec un contexte de 32 K et une limite d’image de 2 048 jetons. À cette échelle, la capacité consacrée à une seule modalité l’emporte sur une capacité répartie sur quatre.

Deux réserves vont de pair, car aucune des deux fiches ne les mentionne spontanément. Le 86,1 de MiniCPM est mesuré à une compression de 4×, et le même modèle à son réglage par défaut de 16× obtiendrait un score inférieur tout en coûtant moins cher à l’exécution — la fiche ne publie pas ce chiffre. Et la fiche modèle d’OpenBMB ne comporte aucune table de benchmarks ; les chiffres apparaissent sous forme de prose et d’images de graphiques sur la page produit, ce qui constitue une forme de publication plus faible qu’un tableau accompagné d’une note méthodologique. Les deux séries de chiffres sont des affirmations du fournisseur. L’orientation de l’écart est suffisamment constante pour qu’elle survive probablement à des tests indépendants ; son ampleur exacte, probablement pas.

Le contexte est la ligne qui détermine les charges de travail réelles.

Un contexte de 32K est généreux pour une seule image et à l'étroit pour un document. À environ 2 048 tokens visuels par image, LFM3-Omni-2B peut contenir une douzaine d'images complètes dans sa fenêtre avant que l'historique de la conversation ne commence à se disputer l'espace. Les 262 144 tokens de MiniCPM-V 4.7 1B ne constituent pas une modeste amélioration ; c'est une autre catégorie de charge de travail. Les longs PDF, les formulaires de plusieurs pages, les résumés de vidéos d'une heure et les boucles d'agents qui gardent des captures d'écran en contexte sont tous réalisables à 256K et tous contraints à 32K.

C’est la différence la moins discutée et la plus lourde de conséquences entre les deux modèles. Les tableaux de benchmarks récompensent la précision sur une seule image ; les pipelines de documents en production échouent à la quatorzième page. Si votre cas d’usage implique plus qu’une poignée d’images par conversation, la fenêtre de 32K constitue une limite plus contraignante que n’importe lequel des quatre écarts de benchmark ci-dessus.

Ce que MiniCPM ne peut pas faire

Il ne peut pas entendre. Il n’existe aucune voie d’entrée audio, aucune sortie vocale et aucun traitement de la piste audio vidéo. Si l’application consiste pour une personne à parler à un appareil de ce que la caméra voit, MiniCPM-V 4.7 1B est un composant d’une chaîne de traitement qui nécessite au moins deux modèles supplémentaires — un système ASR et un système TTS — ainsi que la logique de liaison permettant de faire circuler le texte entre eux.

LFM3-Omni-2B réduit ce pipeline à un seul checkpoint de 4,3 Go. Ses scores audio sont sans relief à côté de modèles vocaux dédiés — taux d'erreur de mots de 6,36 en ASR anglais, 64,73 sur VoiceBench — mais ils existent dans la même passe avant que la voie vision, ce qui signifie que le modèle peut répondre à une question orale sur une image sans qu'une transcription soit jamais écrite. Pour un outil de terrain mains libres ou une borne interactive, c'est la fonctionnalité clé. Pour un pipeline documentaire, c'est un poids mort dans le budget de paramètres.

La fusion de modèles d'OrcaRouterest l'autre moyen d'obtenir les deux comportements : un panel où un spécialiste des documents et un modèle omni répondent au même prompt et où la réponse est composée à partir des deux. C'est une capacité produit plutôt qu'une affirmation sur ces deux checkpoints — aucun des deux n'est dans notre catalogue aujourd'hui — mais c'est la réponse architecturale à une confrontation où chaque modèle est clairement meilleur sur une moitié différente du travail. La fusion coûte plus cher par appel que le routage vers un seul modèle, et elle en vaut exactement la peine quand une mauvaise réponse coûte plus que les tokens.

La décision

Si le travail consiste à lire — OCR, factures, formulaires, graphiques, captures d'écran, longs PDF, interfaces denses — MiniCPM-V 4.7 1B est le meilleur modèle sur toutes les mesures publiées, il dispose de huit fois plus de contexte, il est sous Apache-2.0 au lieu d'une licence personnalisée avec un seuil de revenus, et il est plus petit sur disque. Ce n'est pas une mince affaire, et le fait qu'il soit appelé un modèle 1B ne devrait pas le masquer.

Si le travail consiste en une conversation avec un appareil doté d'une caméra et d'un microphone, LFM3-Omni-2B est le seul des deux à pouvoir y participer. Il lit moins bien, retient moins de contexte et est distribué selon des conditions plus strictes, et rien de tout cela n'a d'importance si l'alternative exige trois modèles et un pipeline.

Il existe un troisième cas qui mérite d'être nommé : un produit qui a besoin des deux, où le parcours document et le parcours vocal sont des fonctionnalités distinctes. Dans ce cas, l'architecture correcte n'est pas un seul modèle mais deux, aiguillés selon le type de requête — le lecteur pour les documents, le modèle omni pour la voix — et la seule question est de savoir si vous voulez exécuter les deux ou laisser un point de terminaison unique décider. C'est la question à laquelle cette série de comparaisons ne cesse d'aboutir, et c'est la bonne. Les modèles sont suffisamment proches en empreinte pour que l'exécution des deux soit une option réaliste ; ils sont suffisamment éloignés en capacités pour que n'en exécuter qu'un seul constitue un compromis, quel que soit votre choix.

Ce qui changerait le verdict, c’est une évaluation indépendante de l’un ou l’autre des modèles, et plus précisément une évaluation qui teste MiniCPM à sa compression par défaut de 16× plutôt qu’au réglage 4× utilisé pour ses chiffres phares. Ce seul chiffre pourrait combler la majeure partie de l’écart — ou l’élargir. Tant que personne ne le publie, les tableaux des fournisseurs sont tout ce que nous avons, et ils pointent dans une seule direction.