MiniCPM5-2B-DSpark : OpenBMB ouvre discrètement les poids de MiniCPM5-2B, avec un modèle draft conçu pour la vitesse

Il y a six semaines, MiniCPM5-2B n’était qu’une promesse. Dévoilé à la conférence WAIC à Shanghai le 2026-07-19 comme le modèle sous-4B en tête de l’Artificial Analysis Index, il était accompagné d’une feuille de route indiquant que les poids ouverts arriveraient « bientôt ». « Bientôt » est arrivé cette semaine, sans tambour ni trompette. Le 2026-09-06, OpenBMB a poussé le dépôt principal MiniCPM5-2B sur Hugging Face sous licence Apache-2.0, et vingt et une minutes plus tard, il a poussé MiniCPM5-2B-DSpark — un checkpoint draft de 323,8 millions de paramètres dont le seul rôle est d’accélérer le décodage de MiniCPM5-2B avec l’algorithme de décodage spéculatif DSpark. Une version GPTQ a suivi le 2026-09-07. Au moment où nous écrivons ces lignes, aucune annonce, aucun post de lancement ni aucune entrée de journal des modifications que nous ayons pu trouver ; la sortie s’est manifestée par des dépôts rendus publics discrètement sur une fenêtre de onze jours.

Voici un point sur ce que l'on sait pour l'instant, et le cadrage compte. MiniCPM5-2B-DSpark n'est pas un chatbot autonome ni un nouveau modèle phare — c'est un accélérateur : un petit modèle rapide qui propose des jetons en avance sur MiniCPM5-2B, lequel les vérifie ensuite en parallèle. Il est inutile sans sa cible, et sa cible est la raison de s'y intéresser. La sortie open-weight de MiniCPM5-2B qu'OpenBMB avait promise en juillet est désormais réellement disponible sur Hugging Face, et le modèle draft livré avec elle est le mécanisme que l'éditeur recommande pour l'exécuter à une vitesse utile. Tout ce qui n'est pas explicitement attribué ci-dessous est lu directement à partir des deux fiches de modèles et de leurs dépôts.

Qu'est-ce qui a été livré, et quand ?

La famille 2B est sortie via un drop progressif non annoncé, les plus récentes d'abord :

• 2026-08-27 — MiniCPM5-2B-Base et MiniCPM5-2B-SFT apparaissent, respectivement les checkpoints bruts pré-entraînés et affinés sous supervision.

• 2026-09-01 — MiniCPM5-2B-Midtrain, l’étape d’entraînement intermédiaire agentique.

• 2026-09-05 — MiniCPM5-2B-MLX et MiniCPM5-2B-GGUF, les formats Apple-Silicon et llama.cpp.

• 2026-09-06 — le dépôt phare MiniCPM5-2B, puis MiniCPM5-2B-DSpark vingt et une minutes plus tard.

• 2026-09-07 — MiniCPM5-2B-GPTQ, le format de service quantifié.

Tous portent la licence Apache-2.0 que ModelBest utilisait pour la famille MiniCPM5-1B en mai dernier, et les premiers checkpoints de la séquence ne montrent toujours essentiellement aucun signal communautaire — une poignée de téléchargements et de likes chacun. C'est la marque d'une diffusion de poids en cours plutôt que d'un lancement coordonné : les artefacts apparaissent dans l'ordre des dépendances (base et SFT d'abord, formats quantifiés et draft en dernier), sans qu'un jour précis ne serve de date de sortie.

Ce qu'est réellement MiniCPM5-2B-DSpark

Le décodage spéculatif décompose la génération en un proposeur peu coûteux et un vérificateur coûteux. Un petit modèle de brouillon devine les prochains tokens ; le grand modèle vérifie toutes les propositions en une seule passe forward et accepte celles avec lesquelles il est d'accord. Lorsque la proposition est bien calibrée, on obtient la sortie du grand modèle à une fraction du coût, et lorsqu'elle est fausse, on ne gaspille qu'une seule étape de vérification. DSpark est une recette spécifique de cette idée, tirée d'un article déposé le 6 juillet 2026 (arXiv 2607.05147, « Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation »). Deux choix de conception la distinguent : elle couple un backbone de proposition parallèle à un module séquentiel léger, de sorte que les tokens d'un bloc proposé dépendent les uns des autres plutôt que de perdre en précision vers la fin du bloc ; et elle dimensionne chaque exécution de vérification par requête en fonction d'estimations de confiance et du débit du moteur, plutôt que de toujours vérifier un bloc de longueur fixe.

Le brouillon DSpark publié par OpenBMB est un transformateur à cinq couches de 323,8 millions de paramètres en BF16 (environ 648 Mo). Il s'inscrit dans la famille d'architectures Q​wen3 mais comporte des ajouts spécifiques à DSpark : un projecteur qui lit les états cachés de MiniCPM5-2B depuis cinq des couches de la cible (1, 10, 20, 30 et 39), une tête de confiance, et une petite tête de Markov qui modélise la distribution du prochain jeton. Sa configuration propose un bloc de sept jetons par passe avant. Avec environ un huitième des 2,5 milliards de paramètres de MiniCPM5-2B, c'est l'un des plus petits modèles de brouillon publiés pour un checkpoint ouvert grand public — c'est tout l'intérêt d'un modèle orienté périphérie, où le brouillon doit être suffisamment léger pour que l'exécution de deux modèles sur un même appareil reste plus efficace que celle d'un seul.

Le dépôt ci-dessus constitue l’intégralité de la surface publique du modèle provisoire : un README, une configuration, un seul fichier safetensors et une fiche de modèle dont la description de l’entraînement indique 1 959 525 séquences (7,05 milliards de tokens) générées par MiniCPM5-2B à partir de prompts généraux, de mathématiques et de code, entraîné sur six époques avec un objectif combinant entropie croisée, L1 et confiance. Le checkpoint n’est pas utilisé comme modèle génératif autonome.

Les chiffres publiés par OpenBMB, honnêtement étiquetés

La fiche du modèle draft indique un chiffre qui compte — la longueur d'acceptation, soit le nombre moyen de jetons proposés que le modèle cible accepte dans chaque bloc de sept jetons. L'évaluation a été menée sur les sorties de MiniCPM5-2B dans trois domaines, avec jusqu'à 4 096 jetons générés :

• Math — 6.05 tokens acceptés en moyenne avec décodage glouton (T=0) ; 4.61 avec échantillonnage à T=1.0.

• Code — 6.11 glouton ; 4.44 échantillonné.

• Général — 4,16 glouton ; 3,10 échantillonné.

• Global — 5,52 (glouton) ; 4,05 (échantillonnage), sur un maximum de sept.

Ces chiffres proviennent de la fiche modèle publiée par le fournisseur et n’ont pas été reproduits de manière indépendante. Ils décrivent également le taux de succès du draft, et non une accélération en temps réel : la vitesse est une mesure de serving qui dépend du coût de la passe de vérification de la cible par rapport à la passe de proposition du draft, du taux d’occupation des lots, et de la réduction de la longueur de vérification effectuée par le planificateur de confiance de DSpark. OpenBMB n’a publié aucun chiffre de tokens par seconde pour cette paire. Pour situer le plafond de la méthode, l’article DSpark rapporte une génération par utilisateur 60 à 85 % plus rapide à débit équivalent par rapport à la référence MTP-1 dans le système de serving en direct de Deep​Seek — un point de référence utile pour ce que l’algorithme a accompli ailleurs, mais pas une affirmation sur MiniCPM5-2B sur votre matériel.

Le tableau de bord ci-dessus est la fiche de spécifications propre à la version. Lisez le chiffre d'acceptation comme un taux de réussite préliminaire ; le multiplicateur sur le débit réel reste à mesurer lors d'une exécution SGLang indépendante.

Le modèle que le brouillon accélère

MiniCPM5-2B est un Transformer dense de 2,5 milliards de paramètres — 2 516 756 480 au total — doté de 42 couches, de 16 têtes de requête et de 2 têtes KV, d’un vocabulaire de 130 560 jetons et d’une fenêtre de contexte de 131 072 jetons, en BF16, pour environ 5 Go. Sur le plan architectural, il est délibérément banal : un LlamaForCausalLM standard, sans kernels personnalisés ni fork du code du modèle, ce qui explique précisément pourquoi il est aussi simple à porter sur un si grand nombre d’environnements d’exécution et de cibles matérielles. Dans la suite de benchmarks interne d’OpenBMB, la fiche lui attribue une moyenne de 53,9 sur le raisonnement, le suivi d’instructions, les connaissances, le contexte long, l’utilisation d’outils, le codage et les tâches d’agent de recherche — devant Qwen3.5-4B (51,1) et granite-4.2-3B (42,7) dans le même tableau, plusieurs cellules (GPQA-Diamond 70,2, HLE 8,9 et diverses lignes sur le contexte long et les tâches agentiques) étant signalées comme issues d’Artificial Analysis plutôt que reproduites en interne. Les résultats phares par tâche incluent notamment MATH-500 à 94,6, AIME 2025 et 2026 à 86,5, IFEval à 86,7, MMLU-Pro à 70,8 et SWE-bench Verified à 46,4. Il s’agit des chiffres du fournisseur obtenus sur la suite du fournisseur, et la fiche précise explicitement que certaines lignes proviennent de tiers ; il convient donc de traiter ce mélange en conséquence.

Lors du dévoilement de juillet, les supports de lancement de ModelBest citaient un indice Artificial Analysis de 17 — premier parmi les modèles de moins de 4B paramètres — et les articles de juillet mentionnaient une fenêtre de 512K tokens. Les checkpoints réellement publiés configurent 131 072 tokens de contexte. Lorsqu’un chiffre marketing du jour du lancement et une configuration publiée divergent, c’est la configuration qui détermine ce que vous pouvez exécuter, et l’écart mérite d’être connu avant de planifier une charge de travail à long contexte sur la base du chiffre marketing.

Exécution de MiniCPM5-2B avec son brouillon.

Le chemin prévu est SGLang, qui prend en charge l’algorithme DSpark en amont depuis la v0.5.16 — la version minimale demandée par la fiche du modèle. La commande de service complète de la fiche :

python -m sglang.launch_server --model-path openbmb/MiniCPM5-2B --speculative-algorithm DSPARK --speculative-draft-model-path openbmb/MiniCPM5-2B-DSpark --speculative-dspark-block-size 7

En décodage glouton (T=0), la vérification DSpark est sans perte : la sortie est identique à celle obtenue en servant MiniCPM5-2B seul, si bien que le modèle draft n'apporte qu'un pur gain de latence. Avec l'échantillonnage activé, DSpark dans SGLang utilise par défaut un échantillonnage limité au modèle cible, avec un échantillonnage par rejet optionnel. OpenBMB documente également le chargement standard via Transformers (transformers ≥ 5.6) et le service du modèle cible seul via vLLM ≥ 0.21, ainsi qu'un analyseur d'appels d'outils minicpm5 pour les charges de travail agentiques ; le chemin spéculatif DSPARK, en revanche, est propre à SGLang.

L'arithmétique matérielle est la vraie histoire pour une paire de classe edge : environ 5 Go pour MiniCPM5-2B en BF16 plus environ 0,65 Go pour le draft. La combinaison draft-plus-cible tient confortablement partout où le modèle 2B seul était déjà viable, ce qui est toute la raison d'expédier un draft aussi petit plutôt qu'un second modèle plus grand.

Qu'est-ce qui n'est pas confirmé ?

• Nous n'avons trouvé aucune annonce — ni blog d'OpenBMB ou de ModelBest, ni publication sur les réseaux sociaux en anglais ou en chinois. La formulation « quietly shipped » est littérale, et la seule surface publique est la collection Hugging Face.

• Aucune évaluation indépendante. Les longueurs d’acceptation du brouillon et la moyenne de 53,9 de la suite de MiniCPM5-2B sont rapportées par le fournisseur et non reproduites ; les cellules marquées AA proviennent de tiers, mais ce sont des valeurs ponctuelles, et non des exécutions de ces poids exacts.

• Aucune API hébergée n'est disponible où que ce soit, donc l'adoption aujourd'hui implique d'exécuter les checkpoints vous-même. Un miroir ModelScope, promis dans la couverture de juillet du dévoilement, n'était pas visible au moment de la rédaction.

• Aucune mesure d'accélération en temps réel n'est fournie pour la paire DSPARK. Une longueur d'acceptation de 5,52 constitue un taux de réussite élevé, mais « combien de fois plus rapide » sur un GPU donné est précisément le chiffre qu'OpenBMB n'a pas publié.

• L'ambiguïté ci-dessus concernant la fenêtre de contexte : les supports marketing indiquaient 512K, la configuration livrée indique 131 072, et rien dans les dépôts ne fait le lien entre les deux.

Où une sortie discrète de modèle open-weight s'insère dans une stack

La lecture honnête de MiniCPM5-2B aujourd'hui est qu'il s'agit d'un pari : des chiffres fournisseur solides, zéro exécution indépendante, aucun historique de service, et un modèle draft dont l'accélération réelle n'est pas mesurée. C'est précisément la situation pour laquelle une couche de routage existe. Une équipe qui veut tester si les sorties d'un petit modèle open source peuvent remplacer un modèle hébergé qu'elle appelle déjà peut effectuer cette comparaison depuis une seule API — OrcaRouter donne accès à plus de 200 modèles hébergés au prix catalogue du fournisseur, sans marge, donc une semaine d'évaluation ne coûte rien à mettre en place, et le basculement automatique fait qu'un checkpoint vieux de quelques jours n'a jamais à tenir une voie de production en otage pendant qu'il fait ses preuves. Rien de tout cela n'exige que MiniCPM5-2B soit hébergé quelque part ; c'est le filet de sécurité autour des modèles dont vous dépendez déjà pendant que vous décidez si un 2B auto-hébergé vaut le GPU.

À surveiller, par ordre d’importance : une exécution indépendante SGLang DSPARK qui rapporte les véritables jetons par seconde pour la paire, car la longueur d’acceptation est un proxy plutôt qu’un benchmark ; une annonce officielle ou un miroir ModelScope confirmant que la version est définitive ; et un hébergeur qui propose MiniCPM5-2B — si c’est le cas, le prix que vous payez de notre côté est le prix catalogue de l’hébergeur lui-même, le jour même, car c’est ce que signifie le pass-through. En attendant, le modèle draft est le plus intéressant des deux artefacts. Un proposeur à cinq couches dont le modèle cible accepte cinq jetons et demi sur sept, c’est la différence entre un petit modèle edge qui semble petit et un modèle qui semble être un plus gros modèle tournant sur le même appareil.