MiniCPM5-2B contre 4B : pourquoi un système d’exploitation agentiel raconte une histoire différente

Un modèle de 2,5 milliards de paramètres qui prétend surpasser ses concurrents de 4 milliards de paramètres sur des benchmarks de programmation d’élite semble être une affaire intéressante. Cependant, lorsqu’on l’intègre dans un système d’agent à plusieurs tours réel, ses performances chutent jusqu’à trois fois. Les évaluations en une seule tentative ne donnent qu’une faible idée de la réalité complexe de l’ingénierie logicielle en production. En regardant au-delà des scores d’indice globaux et en reproduisant les performances localement, on obtient un cadre concret pour déterminer quand ce modèle est l’outil adapté.

La prétention

OpenBMB a publié MiniCPM5-2B le 7 septembre 2026. Il s’agit d’un modèle linguistique causal dense comptant 2,516 milliards de paramètres, sous licence Apache 2.0, avec un contexte natif de 131 072 tokens. Selon la publication, c’est le meilleur modèle open source inférieur à 4 milliards de paramètres, obtenant en moyenne 53,9 points sur 34 benchmarks, devançant ainsi plusieurs concurrents de la catégorie 4B, y compris Qwen3.5-4B, avec les scores suivants : 94,6 pour MATH-500, 86,5 pour AIME 2026, 69,1 pour LiveCodeBench v6 et 46,4 pour SWE-bench Verified.

Personne ne brandit ici une capture d’écran du classement soigneusement sélectionnée. Le lancement a été organisé et sérieux : huit artefacts sont arrivés en même temps. Cette collection comprend des points de contrôle pour la phase de base, la phase intermédiaire de formation ainsi que la phase SFT seule, puis le modèle final affiné à l’aide de RL et OPD, des conversions GGUF et MLX, une version GPTQ en 4 bits, ainsi qu’un modèle de décodage spéculatif nommé MiniCPM5-2B-DSpark. Un laboratoire qui teste discrètement un benchmark ne le lance pas de cette manière. Celui-ci semble s’attendre à être examiné en détail et arrive accompagné de fichiers pour chaque environnement de exécution cible, allant de llama.cpp et Ollama à LM Studio, vLLM et SGLang, en passant par Transformers, MLX et FlagOS multi-chip.

Selon les affirmations, lorsqu’il fonctionne à pleine capacité, un modèle environ 44 % plus petit que Qwen3.5-4B le surpasse dans les tests de mathématiques, de codage et d’ingénierie logicielle. Si cela était vrai sans réserves, ce serait un indicateur significatif concernant l’échelle de développement des modèles axés sur le raisonnement après entraînement. Cependant, cela n’est pas vrai sans réserves, et l’aspect intéressant réside justement dans les points où cela échoue et pourquoi.

Qu’y a-t-il en arrière-plan ?

Connaître ce qui est réellement exécuté est utile, car l’architecture prend en compte à la fois les forces et les points faibles du modèle. MiniCPM5-2B est un décodeur conçu de manière similaire à LlamaForCausalLM : 42 couches de transformateur utilisant une attention par requête groupée, avec 16 têtes de requête partageant 2 têtes de clé/valeur. Un rapport de 8 à 1 est remarquable pour un modèle de cette taille. Cela réduit considérablement la mémoire cache KV par token, ce qui est avantageux lorsque des historiques longs de appels d’outils doivent être conservés ou lorsque de nombreuses sessions d’agent partagent une seule GPU. Aucune attention spéculaire ou linéaire exotique n’est utilisée, bien que des modèles apparentés de la famille MiniCPM, tels que MiniCPM-SALA et MiniCPM4, aient expérimenté des hybrides. L’équipe a préféré rester sur ce mécanisme familier et a investi ailleurs.

Cela dépend de la longueur du contexte et de la sélection des données d’entraînement. Un nombre natif de 131 072 tokens est inhabituel pour des modèles ayant moins de 3 milliards de paramètres, la plupart des modèles de cette taille atteignant un maximum d’environ 32 000 à 64 000 tokens avant que la qualité ne diminue. Dans les tâches nécessitant une capacité d’action autonome, où le modèle doit gérer un journal de plus en plus long contenant des appels, des différences et des sorties de shell, cette marge est plus importante que le simple nombre de paramètres.

Le modèle ne gère que l’anglais et le chinois, sans fonctionnalités de vision ni d’audio. Il s’agit d’une restriction délibérée et non d’une erreur, car chaque paramètre consacré à l’alignement multimodal est un paramètre qui n’est pas utilisé pour le raisonnement ou l’utilisation d’outils. OpenBMB a également publié les données post-entraînement : UltraData-SFT-Agent-2609 contenant 500 000 échantillons de trajectoires d’agents, ainsi que UltraData-RL-2609 avec plus de 80 000 échantillons d’apprentissage par renforcement. C’est là une véritable transparence, car le comportement des agents intégré au modèle peut être examiné directement, au lieu d’être deviné à partir des écarts observés dans les benchmarks.

Lorsque l’architecture est comprise, les affirmations issues des benchmarks se transforment en hypothèses testables concernant un décodeur spécifique et une méthode d’entraînement précise.

La première percée : 23 contre 15

Des problèmes sont apparus moins d’une journée après le lancement. L’annonce d’OpenBMB citait un score d’indice d’intelligence d’analyse artificielle de 23 pour le modèle, tandis que le suivi indépendant d’Artificial Analysis indiquait 15. Une révision ultérieure de l’indice a ramené cette valeur à environ 13. La réaction prévisible a été de se demander si OpenBMB avait gonflé ses propres chiffres.

Ce n’était pas le cas, et cette affaire mérite une étude approfondie, car l’indignation immédiate est la mauvaise réponse à une disparité de référence, tout en étant aussi la plus courante. La note méthodologique d’Artificial Analysis explique cette différence. En résumé, la différence ne provient pas d’une détérioration du modèle. L’évaluation a changé : les ensembles de test privés pèsent désormais 40 % du poids total, contre moins dans les versions précédentes, et la version 4.2 a ajouté deux nouveaux éléments, l’évaluation agente AA-Briefcase et un test de contexte long.

Le chiffre de 23 indiqué par OpenBMB a été obtenu avec l’indice d’intelligence v4.1.1. Lorsque les gens ont comparé ces chiffres, la version utilisée par le suivi public était déjà passée à v4.2, avec une pondération différente et deux composantes absentes lors de la calcul du chiffre initial. Comparer 23 à une version et 15 à une autre ne révèle pas de mensonge ; il s’agit simplement de comparer deux instruments de mesure différents, puis de s’étonner de leurs divergences.

La véritable erreur revient aux premiers articles qui ont présenté les deux chiffres côte à côte sans préciser qu’ils provenaient de versions différentes de l’indice, ce qui a conduit à des conclusions erronées que les données ne justifiaient pas. Tout article citant un score d’indice global doit indiquer la version correspondante. Sans cela, 23 et 15 ne peuvent pas être comparés ; il s’agit en réalité de deux questions distinctes partageant le même titre.

Cette première faille peut être résolue. Une seconde, en revanche, ne peut pas être corrigée de manière aussi simple.

Le véritable écart : les outils d’agentivité

Le chiffre qui devrait changer la façon dont ce modèle est perçu provient de Terminal-Bench v2.1. MiniCPM5-2B y obtient des scores compris entre 8,6 et 9, tandis que Qwen3.5-4B atteint 25,8. Cela représente un écart d’environ trois fois, ce qui a placé MiniCPM5-2B en huitième position sur cet ensemble de tests, bien qu’il occupe la première place dans l’Index d’intelligence parmi les modèles de sa taille. SWE-bench Pro montre la même tendance, avec 14,4 pour MiniCPM5-2B contre 28,2 pour Qwen3.5-4B, soit un écart d’environ deux fois.

Placiez cela à côté de l’affirmation concernant le lancement. Le résultat de 46,4 obtenu par OpenBMB sur SWE-bench Verified, présenté comme une performance supérieure à celle de Qwen3.5-4B, constitue l’un des piliers de l’annonce sur les performances de beats-4B. Cependant, SWE-bench Pro n’est pas simplement le même test sous un nom plus effrayant : il utilise un ensemble plus large et plus contraignant d’issues réelles de dépôts de code, et fonctionne via un système d’agent véritable, où le mode Verified correspond davantage à une génération de correctifs en une seule tentative. Terminal-Bench est encore plus éloigné d’une évaluation en une seule tentative : il s’agit d’un environnement de terminal en temps réel dans lequel le modèle doit planifier, exécuter des commandes, lire les résultats et se remettre de ses propres erreurs au fil de plusieurs tentatives.

Une évaluation indépendante menée par MindStudio l’a formulé sans détour : le modèle montre du potentiel sur certains benchmarks d’agents, mais reste nettement en retrait de Qwen sur les tests d’agents plus difficiles, à savoir SWE-bench Pro et Terminal-Bench.

Ce résultat, bien plus que le déséquilibre entre l’index et la version, devrait ajuster les attentes. Les récompenses obtenues pour rédiger un correctif adéquat à une tâche bien structurée, qui correspond à une génération en une seule étape présentée comme une activité d’ingénierie, sont significatives. Terminal-Bench et SWE-bench Pro récompensent également le fait de rester dans la bonne voie au cours de multiples utilisations de l’outil, de se remettre d’une commande shell qui a échoué, et d’éviter un échec dès les trois premières étapes d’un plan. Le modèle est manifestement performant pour le premier type de tâche, mais nettement moins efficace pour le second. Toute personne qui l’utilise comme un sous-agent de codage autonome, à la place d’un outil de rédaction de correctifs en une seule étape, fera face aux difficultés liées au second type de tâche.

Cette différence est réelle et non résolue, et aucun artefact méthodologique ne peut l’expliquer ; il convient donc de la vérifier manuellement plutôt que de se fier aux moyennes fournies par l’une ou l’autre partie.

Le reproduire localement

Aucun rapport ne semble avoir été publié pour présenter de manière systématique le nombre de tokens par seconde en fonction du niveau de quantification sur du matériel réel. Les informations disponibles se limitent le plus souvent à la table de benchmarks de la version publiée ou à une seule valeur de vitesse indicative. Les chiffres présentés ci-dessous correspondent à des essais uniques, et non à des tests contrôlés effectués avec différentes valeurs de paramètres, ce qui les rend pertinents uniquement comme point de départ pour des mesures locales, et non comme conclusion définitive.

Empreinte mémoire en fonction du niveau de quantification avec un contexte de 8K :

• Q4_K_M : environ 2,78 GB
• Q8_0 : environ 3,7 GB
• BF16/FP16 : environ 6,3 GB

Productivité rapportée par des sources indépendantes : environ 144,23 tokens par seconde sur une RTX 3070 Ti dotée de 8 Go de VRAM, en utilisant le quantification Q4 dans LM Studio avec un seul flux, il s’agissant d’une carte grand public modeste. Au niveau haut de gamme, une discussion sur Hacker News concernant cette sortie mentionnait 32 sous-agents fonctionnant simultanément sur un DGX Spark, atteignant en moyenne 931 tokens par seconde au total et un pic à 1 364 tokens par seconde. Ce deuxième chiffre correspond à l’usage prévu ; il ne s’agit pas de gagner une course de latence avec un seul flux. Le rapport GQA et la petite taille de l’architecture sont conçus pour gérer de nombreuses sessions en même temps, et 32 agents partageant un nœud conviennent parfaitement à ces objectifs.

Le moyen le plus rapide pour reproduire quoi que ce soit est Ollama :

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.com/install.sh | sh

# Recommended flags for flash attention + quantized KV cache
OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve &

# Run directly from Ollama's registry
ollama run openbmb/minicpm5-2b

Pour une quantification spécifique tirée de Hugging Face et intégrée dans llama.cpp :

huggingface-cli download openbmb/MiniCPM5-2B-GGUF \
  MiniCPM5-2B-Q4_K_M.gguf \
  --local-dir ./minicpm5-2b-gguf

Et pour un déploiement à grande échelle compatible avec OpenAI, vLLM :

pip install vllm

vllm serve openbmb/MiniCPM5-2B \
  --max-model-len 131072 \
  --dtype bfloat16 \
  --port 8000

# Query it like any OpenAI chat completion endpoint
curl http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "openbmb/MiniCPM5-2B", "messages": [{"role": "user", "content": "Write a quicksort in Rust"}]}'

La qualité varie d’une tâche à l’autre de manières que les benchmarks globaux ne révèlent pas. Les tests pratiques de GGUF effectués par MindStudio ont montré que le modèle Q8_0 gérait bien le codage autonome ainsi que les raisonnements mathématiques et physiques vérifiables, mais échouait gravement à une tâche de débogage SQL spécifique à un schéma et à la traduction multilingue, fournissant des réponses assurées mais factuellement erronées.

Ces comportements erronés mais assurés pèsent plus lourd que n’importe quel pourcentage d’exactitude. Les échecs évidents sont faciles à détecter lors de la revue, mais c’est justement à travers des erreurs présentées avec certitude qu’une migration SQL défectueuse parvient en production. La reproductibilité présente également un piège : llama.cpp se comporte de manière assez différente en fonction de sa version de compilation et de la façon dont l’interface applique le modèle de chat. Lorsque les résultats locaux diffèrent de ceux d’autrui, vérifiez la version de compilation avant de conclure que le modèle a changé.

Dans l’ensemble, les données locales confirment l’écart observé sur Terminal-Bench et SWE-bench Pro. Les tâches délimitées et vérifiables se déroulent bien, tandis que la situation devient plus incertaine là où une connaissance précise d’un schéma externe ou un jugement multi-étapes ouvert est requis. Des sources indépendantes confirment ce schéma de manière suffisamment cohérente pour pouvoir s’y fier, ce qui permet de prendre la décision qui est réellement en jeu.

Quand ce modèle est le choix idéal

Une fois le débat autour des benchmarks écarté, un cadre de décision utile reste, sans pour autant constituer un jugement de qualité positive ou négative.

Cas d’adéquation parfaite :

• Des groupes de nombreux sous-agents fonctionnant simultanément. L’efficacité mémoire offerte par GQA, ainsi que les 931 tokens par seconde générés par 32 agents sur un DGX Spark, sont les critères importants, bien plus que le score d’indexation.
• Déploiement sur appareil et au niveau du périphérique. Une taille de 2,78 GB en quatrième trimestre fonctionne sans problème sur du matériel grand public, des téléphones et des mini-PC via GGUF ou MLX.
• Flux de travail qui conservent de longs journaux d’outils ou des documents et utilisent réellement la fenêtre de 131 K, sans couche de récupération distincte.
• Inférence locale où la latence est cruciale, en utilisant MiniCPM5-2B-DSpark comme modèle de base pour un décodage spéculatif.

Cas d’application limités :

• Génération de code libre ou créatif. Les tests externes ont montré des résultats inférieurs à ceux des modèles dédiés au codage pour des tâches telles que la création de pages HTML ou d’œuvres SVG, car la force du modèle réside dans le raisonnement, les mathématiques, l’utilisation d’outils et l’appel de fonctions.
• Débogage SQL spécifique à un schéma et traduction multilingue, domaines où il a montré des échecs fréquents et peu élégants.

Tout ce qui est géré via un système d’agentisation plus complexe. Un agent de codage en environnement de production confronté à des sessions terminales à plusieurs tours ou à des tâches de type SWE-bench de niveau Pro présente un retard deux à trois fois supérieur par rapport à Qwen3.5-4B, et il ne s’agit pas d’une erreur d’arrondi.

Par équité, et puisque les opinions tranchées l’omettent souvent : l’objection selon laquelle les comparaisons utiliseraient des références obsolètes comme Qwen2.5-2B ou Gemma-2B relève du commentaire secondaire et non de la fiche officielle du modèle. Cette dernière compare le modèle avec des versions plus récentes, à savoir Qwen3.5-2B, Gemma-4-E2B-it, granite-4.2-3B et LFM2.5-2.6B. Les critiques portées sur cette version devraient viser son véritable point faible, à savoir le retard lié au système d’agentisation, et éviter des reproches concernant des références que la source principale réfute déjà.

Les affirmations relatives aux benchmarks sont spécifiques à chaque benchmark

En regardant au-delà de ce seul modèle, c’est la leçon plus générale qui mérite d’être retenue. L’affirmation concernant beats-4B est vraie mais limitée. Elle repose sur les calculs d’OpenBMB ainsi que sur les suites de tests de codage à une seule tentative, AIME, LiveCodeBench et SWE-bench Verified, et également sur l’agrégat Artificial Analysis une fois sa version corrigée. Elle échoue cependant sur Terminal-Bench et SWE-bench Pro, où Qwen3.5-4B est deux à trois fois supérieur. Tout cela est en même temps exact.

La procédure à suivre pour toute future affirmation concernant des modèles de moins de 4 milliards de paramètres : soumettre le modèle à au moins un benchmark adverse simulant des tâches réelles, comme Terminal-Bench, SWE-bench Pro ou un équivalent, avant de laisser une suite de tests à une seule tentative prédire les performances de l’agent. Créer un correctif et accomplir une tâche en plusieurs étapes sont des compétences distinctes, et un modèle peut exceller dans la première tout en étant moyen dans la seconde. L’agrégat mentionné sur Twitter ne précise jamais laquelle de ces compétences est évaluée.

Pour tout index agrégé dont la version est fixée, que ce soit issu d’Artificial Analysis ou d’une autre source, le numéro de version n’est pas un métadonnée optionnel. Il permet de distinguer une véritable disparité d’une disparité artificielle. L’affaire des 23 contre 15 a ressemblé à un scandale pendant environ un jour, jusqu’à ce que les notes méthodologiques révèlent une simple mise à jour de version. La prochaine controverse liée aux benchmarks pourrait se résoudre de la même manière ou non, et la seule façon de le savoir est de vérifier.

Points clés

Malgré ses dimensions, MiniCPM5-2B est véritablement bien conçu : il compte 42 couches, un rapport GQA de 8 à 1, 131 K de contexte natif, des données d’entraînement ouvertes, ainsi que huit artefacts coordonnés couvrant des appareils allant d’un DGX Spark à un ordinateur portable. Le fait que certaines performances soient bonnes sur certains benchmarks et mauvaises sur d’autres n’efface en rien ces qualités. Les benchmarks sont des outils restreints, chacun mesurant un aspect précis, et un score global ne raconte jamais toute l’histoire.

Avant d’adopter le prochain petit modèle qui semble trop bon pour être vrai, reproduisez au moins un benchmark d’agentialité adversaire et vérifiez la version se cachant derrière tout score d’indice global. Un seul chiffre présenté dans un titre ne devrait pas déterminer le choix d’une architecture.