Carte de titre indiquant ZoomGain-4B vs MiniCPM5 2B, avec pour sous-titre « tous deux sont petits, un seul a été conçu pour fonctionner partout », et trois puces : 4,54B vs 2,52B, Vision vs texte uniquement, Neuf runtimes vs un.
Guides & Insights

ZoomGain-4B vs MiniCPM5 2B : la portabilité est le benchmark que personne ne publie

Auteur

Rowan Sterling

Date de publication

Derniers modèles · 20Voir tous les modèles →
Benchmarks : Artificial Analysis · mis à jour quotidiennement
Retour à tous les articles

Il manque un chiffre sur les deux fiches de modèle, et c'est celui qui décide de la plupart des déploiements. MiniCPM5-2B est livré en versions GGUF, MLX, GPTQ et LiteRT, dispose d'un modèle draft DSpark pour le décodage spéculatif, et — le détail le plus révélateur — propose des builds FlagOS pour neuf familles d'accélérateurs différentes, dont Ascend, Hygon, Kunlunxin et Metax. ZoomGain-4B est livré en GGUF à trois précisions et exige, selon les propres termes de sa fiche, « un build llama.cpp avec prise en charge multimodale de Qwen3.5 ». L'un de ces modèles tourne presque partout. L'autre tourne là où vous pouvez compiler un runtime spécifique. Aucune des deux fiches ne qualifie cela de benchmark, et pour quiconque doit réellement exploiter un modèle plutôt que le citer, c'est la ligne qui compte davantage que la colonne de précision de l'un ou l'autre modèle.

Cette formulation n’est pas une manière d’esquiver la comparaison de précision — elle vient plus tard, et cette comparaison s’avère moins décisive qu’elle n’en a l’air, car les deux modèles ne sont pas mesurés sur le même axe et ne peuvent pas l’être. MiniCPM5-2B d’OpenBMB est un modèle textuel : 2,52 milliards de paramètres, publié le 6 septembre 2026, optimisé pour les agents, les appels d’outils, le code et le contexte long. ZoomGain-4B d’inclusionAI est un spécialiste vision-langage publié le 11 novembre 2026, entraîné par apprentissage par renforcement sur des questions portant sur des détails visuels fins. Ce qui suit présente ce sur quoi chacun est mesuré, ce que coûte la mise en place de chacun, et où se situe la véritable ligne de démarcation.

La ligne manquante : ce qu’il faut pour exécuter chacune d’elles

Commencez par la liste des artefacts, car c’est la chose la plus concrète que l’un ou l’autre des éditeurs vous ait donnée.

• MiniCPM5-2B. Un transformateur causal dense sur la classe standard LlamaForCausalLM — 42 couches, GQA avec 16 têtes de requête et 2 têtes KV, un contexte de 131 072 jetons, 2 516 756 480 paramètres au total, dont 1 981 982 720 hors embeddings. Comme l’architecture est standard, il hérite de tous les chemins de serving déjà écrits par quiconque pour les modèles de type Llama. L’organisation publie les variantes SFT, Midtrain et Base dans des dépôts séparés, ainsi que des quantifications GGUF, MLX et GPTQ, ainsi qu’un modèle draft DSpark pour le décodage spéculatif, ainsi que LiteRT pour Android embarqué, ainsi qu’un homologue 1B avec le même ensemble de variantes.

• ZoomGain-4B. 4 539 265 536 paramètres en BF16 répartis entre un modèle de langage et un encodeur visuel distinct. Trois précisions GGUF — Q4_K_M à 2,71 Go, Q8_0 à 4,48 Go, F16 à 8,42 Go — chacune associée à un fichier projecteur mmproj que la fiche indique comme obligatoire pour l’entrée d’images. Pas de build MLX, pas de GPTQ, pas d’ONNX, pas de modèle de draft. Le seul runtime nommé est llama.cpp avec prise en charge multimodale de Qwen3.5, ce qui est une exigence plus restrictive qu’elle n’en a l’air : il faut une build suffisamment récente pour connaître l’architecture qwen35, et la fiche vous demande de fournir explicitement les deux fichiers plutôt que de pointer vers un chemin tout prêt.

L’asymétrie ne constitue pas une critique d’inclusionAI. On ne s’attend pas à ce qu’un modèle de vision publié il y a neuf jours et jamais annoncé dispose d’un runtime Android. C’est simplement l’état des choses, et cela signifie que les deux modèles ne sont pas interchangeables sur la dimension qui coûte de l’argent : MiniCPM5-2B fonctionnera sur le matériel que vous possédez déjà, y compris un téléphone ; ZoomGain-4B fonctionnera sur un GPU, dans un runtime que vous devrez peut-être compiler, et nulle part ailleurs.

Screenshot of OpenBMB's MiniCPM5-2B model card on Hugging Face, captured 11 November 2026, showing the repository header, the parameter metadata and the opening of the model card text.

Deux définitions différentes de « petit »

Tous deux sont appelés petits modèles, et le mot fait un travail différent dans chaque cas.

• Des paramètres, honnêtement comptés. MiniCPM5-2B compte 1,98 milliard de paramètres hors embeddings — le nombre qui régit le calcul par token — sur un total de 2,52 milliards. ZoomGain-4B totalise 4,54 milliards, et environ un demi-milliard de ce total correspond à l’encodeur visuel et au projecteur. En retirant la partie vision, les deux backbones linguistiques font pratiquement la même taille, à l’arrondi près. La différence de comportement vient de ce qui a été entraîné par-dessus, pas de l’échelle.

• L'objectif de la formation. La fiche de MiniCPM5-2B indique que ses points forts sont le raisonnement en code et en mathématiques, la compréhension de longs contextes, l'utilisation d'outils et les tâches agentiques, et désigne comme cibles les assistants locaux, les agents de codage et le déploiement sur l'appareil. La fiche de ZoomGain-4B ne porte que sur une chose : la capacité d'un modèle à répondre à une question dont la réponse n'est visible qu'en zoomant dans l'image.

• Ce que chaque éditeur a choisi de transmettre. OpenBMB a publié toute la gamme de variantes de MiniCPM5 — base, midtrained, SFT, final RL-plus-OPD, ainsi qu’un modèle draft et des binaires précompilés pour neuf familles de puces. inclusionAI a publié trois dépôts de modèles, deux jeux de données et un dépôt de code contenant le pipeline de construction des données et les lanceurs GRPO. L’un est une gamme de produits ; l’autre est une version de recherche avec le carnet de laboratoire annexé.

• Licence. MiniCPM5-2B est sous Apache 2.0 sur la carte, appliquée à la fois au dépôt et aux poids. Le code de ZoomGain est sous Apache 2.0 et les conditions du checkpoint sont renvoyées au dépôt du checkpoint, qui, à ce jour cette semaine, ne porte aucune balise de licence dans ses métadonnées. Lisez le fichier avant de livrer.

Two-column scoreboard titled ZoomGain-4B vs MiniCPM5 2B, left column ZoomGain-4B with Parameters 4.54B, Quantised builds GGUF Q4/Q8/F16, Extra file needed mmproj projector, Speculative decoding none published, Context not stated on card, Benchmark 55.81 on its own held-in suite; right column MiniCPM5 2B with Parameters 2.52B, Quantised builds GGUF, MLX, GPTQ and LiteRT, Extra file needed none, Speculative decoding DSpark draft, Context 131,072 tokens, Benchmark 53.9 suite average.

Les colonnes de référence, et pourquoi elles ne sont pas conformes

Il n’existe aucun benchmark commun à ces deux modèles. Pas un seul. ZoomGainBench est un ensemble de questions sur des photographies, et MiniCPM5-2B n’a pas d’encodeur d’images ; tous les autres benchmarks du tableau de MiniCPM5 sont textuels et ZoomGain-4B n’a jamais été évalué sur aucun d’eux. Ainsi, plutôt qu’une comparaison directe, voici ce que chaque éditeur a réellement mesuré, volontairement présenté séparément.

MiniCPM5-2B, selon le fournisseur, moyenne de 53,9 sur l'ensemble de sa suite :

• Code — LiveCodeBench v6 69,1, OJBench 32,5, SWE-bench Verified 46,4.

• Mathématiques — AIME 2025 86,5, AIME 2026 86,5, MATH-500 94,6.

• Connaissances — MMLU-Pro 70,8, GPQA-Diamond 70,2.

• Contexte long — AA-LCR 59,0, NoLiMa 68,1, LongBench v2 43,7.

• Utilisation d’outils et agents — τ²-Bench Telecom 97,1, BFCL v4 66,6, BrowseComp-ZH 43,5, GAIA Text-103 88,7.

ZoomGain-4B, rapporté par le fournisseur :

• Perception, benchmark interne — 55,81 sur ZoomGainBench contre 30,03 pour son modèle parent Qwen3.5-4B.

• Perception, moyenne hors échantillon — 60,96 sur dix benchmarks que l’entraînement n’a jamais vus, contre 54,20 pour le parent. C’est le gain de 6,76 points qui mérite d’être cité.

• Progrès individuels sur des benchmarks réservés — Visual Probe : de 43,30 à 57,28 ; O3-Bench : de 54,20 à 63,19 ; HR-Bench 4K : de 81,25 à 87,25 ; MME-RealWorld-Lite : de 57,89 à 61,59.

Lisez ces deux listes côte à côte et l’orientation de la décision devient évidente. MiniCPM5-2B a été testé sur dix-sept aspects qui comptent pour un développeur et obtient des scores honorables sur presque tous ; les chiffres de 97,1 au τ²-Bench Telecom et de 88,7 à GAIA Text-103 sont les résultats les plus marquants, et ce sont ceux sur lesquels repose son positionnement. ZoomGain-4B a été testé sur la perception et pratiquement rien d’autre, et le gain qu’il apporte — environ sept points en moyenne, sur des benchmarks jamais vus — est réel mais limité.

S’il ne fallait qu’une phrase : MiniCPM5-2B est un petit modèle généraliste doté d’une fiche de benchmarks d’une profondeur inhabituelle, et ZoomGain-4B est un spécialiste dont le gain moyen de sept points passerait inaperçu sur un classement généraliste, car ce classement généraliste ne contient pas les questions dans lesquelles il excelle.

Là où les deux coexisteraient réellement

Les charges de travail où les deux constituent la bonne réponse partagent un même schéma : un document, une capture d'écran, une photo, un formulaire. Quelque chose doit examiner l'image et en extraire une valeur, et quelque chose doit accomplir tout le reste — analyser le schéma, appeler le bon outil, valider, réessayer, orienter vers un humain.

L’extraction est de type ZoomGain. Petit texte, recadrages serrés, une réponse qui est soit correcte soit fausse, et un modèle qui a été explicitement entraîné sur la différence entre lire une étiquette dans un recadrage et lire la même étiquette dans une image complète. Les chiffres de ZoomGain-4B sur données de validation pour HR-Bench 4K (81,25 à 87,25 après entraînement) et MME-RealWorld-Lite correspondent exactement au profil d’un modèle qui s’est amélioré sur les détails denses sans régresser sur tout le reste.

Le reste est à l’image de MiniCPM5, et en matière d’utilisation d’outils, il est étonnamment solide pour sa taille — τ²-Bench Telecom à 97,1 est un score que la plupart des modèles trois fois plus grands n’atteignent pas, et BFCL v4 à 66,6 montre que l’appel de fonctions n’est pas une simple démo.

Exécuter les deux signifie deux environnements d’exécution, deux licences et une deuxième chose susceptible de tomber en panne. C’est aussi là qu’un routeur justifie son utilité plutôt que de rester un slogan : l’appel d’image va vers le point de terminaison de vision, le tour d’appel d’outil va vers celui de texte économique, et un blocage sur l’un ou l’autre bascule automatiquement vers l’autre au lieu de se manifester par une 504 dans votre pipeline. Une seule clé, une seule facture, et la logique de basculement à un seul endroit plutôt que dupliquée dans deux SDK.

Il vaut la peine d’être explicite sur ce que nous proposons et ce que nous ne proposons pas. MiniCPM5-2B ne figure pas dans notre catalogue aujourd’hui. Nous hébergeons bien la famille Q​wen3.5 — le 35B-A3B à 0,057 $ en entrée et 0,459 $ en sortie par million de tokens, le 27B à 0,086 $ et 0,688 $, tous deux multimodaux — et cette famille est la base à partir de laquelle ZoomGain-4B a été entraîné, ce qui en fait l’approximation hébergée la plus proche si vous voulez tester si l’approche « recadrer puis demander » améliore votre précision avant de vous engager sur un 4B auto-hébergé. Pour le volet appel d’outils, le même catalogue vous donne de quoi effectuer des appels dès aujourd’hui. Ce que nous ne pouvons pas faire, c’est héberger ZoomGain-4B, et aucun routage ne peut y changer quoi que ce soit : c’est un téléchargement, pas une API.

Screenshot of the inclusionAI/ZoomGain-4B model card on Hugging Face, captured 11 November 2026, showing the repository header, the parameter metadata and the opening of the model card text.

Le verdict honnête

Choisissez MiniCPM5-2B si vous voulez un petit modèle que vous pouvez déployer cette semaine sur du matériel que vous possédez déjà, dans un environnement d'exécution qui existe déjà, sous licence Apache 2.0, avec une fiche de benchmarks suffisamment large pour prédire son comportement. C'est l'objet abouti des deux. Ses 1,98 milliard de paramètres hors embeddings le rendent peu coûteux par token, ses chiffres en appel d'outils sont ce qu'il y a de meilleur dans sa colonne, et les builds des fabricants de puces signifient qu'il n'est pas réservé aux datacenters.

Choisissez ZoomGain-4B si l’erreur précise que vous cherchez à éliminer est visuelle et fine, et que vous êtes prêt à faire tourner un GPU avec une compilation llama.cpp de niche pour la corriger. Son argument repose sur un chiffre crédible — un gain moyen de 6,76 points sur dix benchmarks de perception tenus à l’écart, à partir de 9 000 échantillons d’entraînement — et sur un benchmark, des données et un harnais qui vous permettent de vérifier vous-même cette affirmation plutôt que de la croire sur parole.

N'en choisissez aucun des deux si vous n'avez pas encore mesuré ce que votre pipeline fait de travers. Les résultats publiés les plus faibles de MiniCPM5-2B concernent les agents de recherche et le raisonnement sur documents longs (BrowseComp-ZH 43,5, LongBench v2 43,7), et ZoomGain-4B n'a jamais été interrogé sur autre chose qu'une image. Acheter l'un ou l'autre pour résoudre un problème que vous n'avez pas caractérisé, c'est ainsi que des modèles de trois milliards de paramètres finissent en production sans rien faire.

La conclusion peu glamour : les deux modèles ne sont pas des rivaux, ils sont deux étapes adjacentes d’un même travail, et si cette comparaison continue d’être présentée comme un concours, c’est parce qu’il est plus facile de publier des benchmarks que de la portabilité. MiniCPM5-2B l’emporte dans la colonne qui est publiée. ZoomGain-4B l’emporte dans une colonne qui n’existe pas encore, sur une seule tâche, d’environ sept points, et s’accompagne d’une contrainte d’exécution qui arrêterait la plupart des équipes dès le départ.