MiniCPM-V 4.7-35B-A3B-DSpark : le draft de 389 M d'OpenBMB débarque avec une fiche que son modèle de base n'a jamais eue

MiniCPM-V-4.7-35B-A3B-DSpark est un modèle de draft de 389 223 169 paramètres. Il ne répond pas aux questions, il ne voit pas les images et, à lui seul, il est inutile. Son unique rôle est de deviner les quinze tokens suivants afin que MiniCPM-V-4.7-35B-A3B puisse vérifier tout un bloc en une seule passe avant au lieu de générer un token à la fois. C'est le décodage spéculatif, et OpenBMB a publié il y a onze jours un draft pour son nouveau modèle vision-langage de 35B sans en dire un mot publiquement.

Ce qui lui vaut une page, ce n’est pas le modèle draft. C’est la documentation qui l’accompagne. Le checkpoint DSpark dispose d’une fiche de modèle : une licence, un tableau de spécifications, une recette d’entraînement et un tableau des longueurs d’acceptation pour sept catégories de tâches. Son parent à 35 milliards de paramètres n’avait rien de tout cela lorsqu’il est apparu. Ainsi, pour la première fois, de vrais chiffres accompagnent une publication de MiniCPM-V 4.7 — et ce sont des chiffres sur le modèle parent, mesurés indirectement, par un fichier de 0,78 Go dont l’objectif déclaré est de l’accélérer.

Tout ce qui suit sépare ce qui figure sur la fiche de ce que la fiche n'établit pas. Les chiffres d'acceptation sont ceux d'OpenBMB et personne en dehors du laboratoire ne les a reproduits. Le tableau de benchmarks du modèle de base n'existe toujours pas.

Ce qu'est réellement le checkpoint DSpark

Le dépôt openbmb/MiniCPM-V-4.7-35B-A3B-DSpark date du 8 octobre 2026. Il s'agit d'un checkpoint à fichier unique — model.safetensors, ainsi qu'un config.json et un README — sous Apache-2.0, étiqueté pour l'anglais et le chinois. Un deuxième brouillon, openbmb/MiniCPM-V-4.7-1B-DSpark, a été créé une seconde plus tôt, de sorte que les deux ont été poussés vers le hub dans le même lot plutôt que découverts un par un.

Chaque draft se tient devant une cible, et uniquement celle-ci. La fiche le dit clairement : ce checkpoint est « entraîné pour un appariement exact avec MiniCPM-V-4.7-35B-A3B et son tokenizer ». Le vocabulaire est celui du parent, ses 248 144 tokens, ce qui est une exigence plutôt qu'une optimisation — un drafter dont les tokens ne correspondent pas un à un à ceux de la cible ne peut rien proposer que la cible pourrait accepter. C'est la même contrainte qui explique que le draft frère existe séparément plutôt qu'un seul drafter servant toute la famille.

L’architecture n’est pas une copie réduite du modèle parent. C’est un empilement d’attention à cinq couches, une largeur cachée de 2 048, 8 têtes de requête contre 2 têtes clé/valeur, une taille intermédiaire de 6 144, et RoPE avec un thêta de 10 000 000. Le architectures lit Qwen3DSparkModel — le même squelette de la famille Qwen3 dont provient la pile linguistique du modèle parent, réduit à l’état de stub.

La partie intéressante, c'est la façon dont le stub parle à la cible. Il ne lit pas la couche finale de la cible. Il prélève des états cachés de cinq couches intermédiaires — [3, 11, 19, 27, 35] sur les 40 du parent — et les projette à travers un projecteur de type dspark. Extraire du milieu de la pile plutôt que de la fin est délibéré : les états du milieu du réseau sont plus faciles à aligner et portent des informations que la couche finale a déjà compressées en logits du prochain token. La configuration arme aussi une tête de confiance avec une composante de Markov de rang 256, qui est le mécanisme de l'article DSpark pour décider quelle part d'un bloc proposé vaut la peine d'être vérifiée.

La table d'acceptation est une carte, et non une mesure

Voici toutes les données numériques qu'OpenBMB a publiées sur la performance de cette paire, exprimées en tokens acceptés par étape de vérification, avec une terminaison EOS naturelle et max_new_tokens=8192:

• Vision, MMMU — 5,098 jetons acceptés par étape.

• Vision, MathVista — 6,126.

• Vision, raisonnement CharXiv (validation) — 5.479.

• Vision, OCRBench — 5,407.

• Texte, Maths — 6,687.

• Texte, Code — 7.387.

• Texte, Général — 3.501.

Trois choses au sujet de ce tableau méritent d’être dites tout haut. Premièrement, il est auto-déclaré. Personne en dehors d’OpenBMB n’a exécuté ce checkpoint et publié un chiffre, et avec un seul téléchargement enregistré sur le dépôt, personne en dehors d’OpenBMB ne l’a exécuté du tout. Deuxièmement, la longueur d’acceptation est une propriété du couple, pas du modèle — elle mesure à quel point la sortie de MiniCPM-V-4.7-35B-A3B est prévisible, et non à quel point cette sortie est bonne. Une cible qui se répète donne au modèle brouillon une victoire facile. Troisièmement, tout est dans l’écart : 7,387 sur le code contre 3,501 sur le texte général, c’est un facteur deux entre la meilleure et la pire catégorie, et le fait que le code soit le plus facile reflète davantage la surface à faible entropie et hautement répétitive du code que quelque force que ce soit dans les modèles.

Il existe aussi une lecture purement arithmétique que la fiche laisse implicite. Un drafter qui propose 15 tokens et dont 5 à 7 sont acceptés fait tout de même avancer plusieurs tokens par passe avant de la cible, donc le plafond ici est un gain de débit important — mais ce n’est pas l’affirmation naïve « 5× plus rapide », car vérifier un bloc de 15 tokens coûte plus cher que générer un seul token, et les propositions rejetées sont payées puis jetées. Cet écart est exactement le sujet de l’article DSpark, et c’est pourquoi la config expose un commutateur pour désactiver la vérification adaptative.

Ce que le brouillon nous apprend accidentellement sur le modèle de base

MiniCPM-V 4.7 a qualifié sa sortie de discrète — des poids, aucune publication de lancement. Cela a désormais changé, de manière modeste mais bien réelle. Le dépôt parent sur openbmb/MiniCPM-V-4.7-35B-A3B a été créé le 7 octobre 2026. Au 12 octobre, il comportait une fiche de modèle complète avec un README, une page de publication à la Hugging Face, une liste d'affirmations, une section sur l'appareil et un tableau de poids. Le dépôt s'est depuis enrichi d'une famille de quantification — des versions FP8, int4, AWQ, GPTQ et GGUF, chacune dans son propre dépôt, toutes modifiées le 12 octobre — et compte 27 mentions J'aime pour 166 téléchargements.

Donc le tableau exact est celui d’une publication en deux étapes, et non d’une sortie silencieuse. Les poids sont arrivés les 6 et 7 octobre. Les checkpoints provisoires ont suivi le 8 octobre. La documentation, les quants et les informations sur l’exécution sur appareil sont arrivés au plus tard le 12 octobre. OpenBMB n’a toujours pas publié d’article de blog ni de rapport technique pour la famille, et il n’y a toujours pas de tableau de benchmarks sur la fiche du modèle parent — les affirmations de performance se trouvent dans des images de graphiques liées, plutôt que sous forme de texte qu’un lecteur peut citer.

L'affirmation qui figure effectivement dans le texte est l'affirmation phare : avec Lookahead Expert Scheduling, la quantification par couches et « DSpark speculative sampling integration », le modèle 35B-A3B est décrit comme le premier modèle MoE open source à fonctionner de manière fluide sur l'appareil, à plus de 13 jetons par seconde sur un iPhone 17 Pro Max. Ce chiffre est rapporté par le fournisseur, non reproduit et sans précisions — aucun format de quantification, aucune version de compilation, aucun prompt, aucune méthode de mesure. Le checkpoint DSpark est l'une des trois techniques sur lesquelles repose cette affirmation, ce qui en fait la seule des trois que vous pouvez télécharger et inspecter. C'est aussi celle dont la preuve est une unique ligne de benchmark non lue par tâche.

Je le lance, si tu veux.

La fiche fournit une recette et c'est une commande vLLM, pas une approximation. Elle sert la cible avec une taille de parallélisme tensoriel de 2, une longueur maximale de modèle de 40 960, FLASH_ATTN sur les backends d'attention de l'encodeur linguistique et multimodal, un mode de sous-échantillonnage visuel de 4x, enable_thinking défini sur false, et la configuration spéculative pointée vers le checkpoint DSpark avec 15 jetons spéculatifs et la vérification adaptative désactivée. Deux détails dans cette ligne méritent d'être remarqués en eux-mêmes : --max-num-seqs 1 signifie que la configuration publiée sert une séquence à la fois, et --disable-custom-all-reduce avec la passe de fusion all-reduce désactivée signifie qu'il s'agit d'une configuration qui a été ajustée pour fonctionner plutôt que pour être la plus rapide possible. Considérez la recette comme un point de départ qu'OpenBMB a réussi à faire tourner, et non comme une affirmation de débit.

L'enveloppe matérielle est la véritable barrière. La cible est d'environ 70 Go de poids BF16 avant le cache KV, et le draft ajoute environ 0,78 Go en plus. Deux accélérateurs constituent le minimum annoncé, ce qui place cela bien au-delà du téléphone sur lequel s'appuie le marketing de la famille — un déploiement embarqué pour un modèle 35B-A3B implique une quantification agressive et du déport, ce à quoi servent les travaux sur LES et la quantification couche par couche, et ni l'un ni l'autre ne figure dans la recette vLLM ci-dessus.

Cette asymétrie constitue la décision pratique pour la plupart des équipes. Servir MiniCPM-V 4.7 coûte deux GPU que vous possédez ; appeler un MoE multimodal hébergé comparable ne coûte rien au départ. Qwen3.6 35B A3B est la comparaison directe la plus proche — même format de 35B au total, 3B actifs, même contexte de 262K, entrée image et vidéo — et il est servi via OrcaRouter à partir de 0,248 $ par million de tokens d'entrée et de 1,485 $ par million de tokens de sortie selon la route du fournisseur, avec basculement automatique si l'une de ces routes se dégrade. MiniCPM-V 4.7 n'est pas un modèle hébergé sur OrcaRouter, et cet article ne va pas prétendre le contraire ; la présentation honnête est que les deux sont des alternatives à un point de décision, et que celui qui est hébergé est celui que vous pouvez mesurer cet après-midi.

Qu’est-ce qui rendrait cela vérifiable ?

Le checkpoint DSpark est sous Apache-2.0, il pèse moins d'un gigaoctet, et il est fourni avec une commande de service que quelqu'un disposant de deux GPU pourrait coller dans un terminal dès aujourd'hui. Cette combinaison en fait la voie la moins coûteuse vers un chiffre indépendant sur MiniCPM-V 4.7 — pas un score de benchmark, mais quelque chose de presque aussi utile : une longueur d'acceptation reproduite. Si un tiers extérieur atteint 5,1 sur MMMU et 3,5 en texte général, la fiche est crédible et l'histoire d'efficacité de la famille gagne son premier point de données externe. Si l'acceptation s'avère nettement plus faible, le tableau publié a été mesuré dans des conditions que la recette ne reproduit pas, et l'affirmation de 13 jetons par seconde hérite de ce doute.

Ce qui manque encore, c’est ce à quoi sert normalement une fiche de modèle. Il n’y a pas de score MMMU, pas de score OCRBench, pas de résultat de compréhension de documents, pas de métrique de grounding et pas de chiffre de latence pour MiniCPM-V 4.7 lui-même — rien qui réponde à la question de savoir si ce modèle est bon. Le tableau du modèle de draft ne peut pas remplacer cela, et lire une longueur d’acceptation élevée comme un signal de qualité est précisément l’erreur dans laquelle ces chiffres incitent à tomber. Une prédiction de type ChatGPT est facile pour un modèle de draft et ne dit rien sur le fait de savoir si la prédiction était juste.

Donc : un véritable artefact, une véritable licence, un élément de preuve publié véritablement nouveau au sujet d’un modèle qui n’en avait aucun — et un écart d’évaluation exactement aussi large qu’il l’était le 7 octobre. Le prochain fichier à actualiser reste la fiche de modèle du parent.