MiniCPM-V-4.7-1B-DSpark : un modèle draft de 213M livré sans aucune annonce

MiniCPM-V-4.7-1B-DSpark est un checkpoint de 213 547 777 paramètres qui ne peut pas répondre à une question. Il ne lit pas d’images, il ne tient pas une conversation et, servi seul, il ne produit rien qui vaille la peine d’être lu. Son unique rôle est de se placer devant un modèle — MiniCPM-V-4.7-1B — et de deviner les quinze tokens suivants afin qu’un petit modèle vision-langage de classe téléphone puisse vérifier un bloc de ceux-ci en une seule passe avant, au lieu de les générer un par un.

Le fichier fait 0,85 Go sous Apache-2.0, et il est apparu sur Hugging Face à 04:26 UTC le 8 octobre 2026, dans le même lot que le modèle draft du plus grand frère 35B-A3B. Quatre jours plus tard, la fiche du modèle parent le traite encore comme une note de bas de page : le modèle draft n'apparaît qu'une seule fois, sous forme de ligne dans le tableau des poids et derrière un bouton bascule replié « Décodage spéculatif (DSpark) ». Il n'existe ni article de blog OpenBMB à son sujet, ni rapport technique, ni entrée dans la documentation GitHub du projet lui-même.

Ce silence est la partie intéressante, en raison de ce que ce fichier particulier rend possible. C’est le premier artefact de la famille MiniCPM-V 4.7 dont l’affirmation centrale — à savoir qu’un modèle de vision 1B tourne de façon acceptable sur un téléphone — peut être vérifiée par quelqu’un d’extérieur à OpenBMB. Tout ce qui suit garde deux piles distinctes : ce qui est un fichier sur disque que vous pouvez ouvrir, et ce qui est un nombre que le fournisseur a imprimé à côté.

Qu'y a-t-il réellement dans le dépôt ?

Quatre fichiers. C'est tout : .gitattributes, README.md, config.json, et un seul model.safetensors contenant 854 204 052 octets de poids BF16. Il n'y a pas de tokeniseur dans le dépôt, car il n'y a pas besoin qu'il y en ait un — le modèle de draft emprunte celui du modèle cible, et le vocabulaire dans sa configuration est exactement celui du parent : 248 094 tokens. Un modèle de draft dont les tokens ne correspondent pas un à un à ceux du modèle cible ne peut rien proposer que le modèle cible accepterait, donc partager le vocabulaire est une exigence plutôt qu'une commodité.

L’API Hub indique que le dépôt a été créé le 2026-10-08T04:26:19Z et modifié pour la dernière fois le 2026-10-12T14:29:57Z, étiqueté pour l’anglais et le chinois, sous licence Apache-2.0, avec trois likes et un téléchargement au moment de la rédaction. Le dernier nombre est celui qu’il faut retenir. Un seul téléchargement, quatre jours après, pour un fichier assez petit pour être récupéré via une connexion téléphonique.

Le champ d'architecture indique Qwen3DSparkModel avec un model_type de qwen3, ce qui est cohérent plutôt qu'étrange : le squelette linguistique de MiniCPM-V 4.7 descend de la lignée Qwen3, donc un stub de cinq couches issu de la même famille est bien ce à quoi on peut s'attendre. Ce qui n'est pas une copie réduite du parent, c'est la façon dont le stub communique avec lui. La configuration arme un dflash_config avec projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" et markov_rank: 256. Cette tête de confiance est l'élément repris de la méthode DSpark : c'est le mécanisme qui sert à estimer quelle part d'un bloc proposé mérite d'être vérifiée, ce qui est précisément la raison pour laquelle la configuration de serving expose un interrupteur pour désactiver la vérification adaptative.

La spécification, et pourquoi chaque nombre s'y trouve.

Côté draft, d’après la carte et la config, qui concordent toutes les deux :

• Paramètres du draft — 213 547 777, tous en BF16, dans un checkpoint en un seul fichier de 0,85 Go

• Profondeur du brouillon — 5 couches, toutes en attention complète, taille cachée 1 024, taille intermédiaire 3 584, activation SiLU

• Géométrie de l'attention — 8 têtes de requête face à 2 têtes clé/valeur, dimension de tête 256, attention à requêtes groupées

• Tokens par passe avant — 15, indiqué dans la configuration sous la forme block_size: 15

• Plage de positions — RoPE theta 10 000 000 avec un embedding rotatif de dimension 256, et max_position_embeddings défini sur 262 144, correspondant à la fenêtre de 256K du parent

• Couches sélectionnées — [3, 7, 11, 15, 19], sur les 24 du parent (num_target_layers: 24)

• Vocabulaire — 248,094, lié au tokenizer de la cible, avec un token de masque dédié à 248,076 pour l’étape d’ébauche semi-autorégressive

Deux de ces lignes méritent plus qu'un coup d'œil. La première, ce sont les couches de prélèvement. Le draft ne lit pas la couche finale du parent ; il lit les états cachés de cinq couches réparties dans la profondeur du parent et les projette via un dspark projecteur. Les états du milieu du réseau sont moins coûteux à aligner et portent encore une information que la dernière couche a déjà effondrée en logits du token suivant. La seconde, c'est la dimension de tête de 256 face à une taille cachée de 1 024. C'est une tête délibérément large sur un modèle étroit, et la configuration bascule tie_word_embeddings: false — la matrice d'embedding est gardée séparée plutôt que partagée avec la projection de sortie, donc le nombre de paramètres inclut les deux.

L'ensemble constitue un drafteur d'environ un cinquième de la taille de la cible, mais d'une forme entièrement différente. À titre de comparaison, le draft du frère 35B-A3B compte 389 223 169 paramètres puisant dans les couches [3, 11, 19, 27, 35] sur 40. Deux drafts, un par cible, car un draft n'est jamais valide que pour le vocabulaire et la représentation intermédiaire sur lesquels il a été entraîné.

Le tableau d’acceptation est une fiche de modèle, pas une mesure.

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

• Vision, MMMU — 3,452 tokens acceptés par étape

• Vision, MathVista — 4,333

• Vision, raisonnement CharXiv (validation) — 4.452

• Vision, OCRBench — 4.752

• Texte, mathématiques — 5.891

• Texte, code — 5.347

• Texte, général — 3.370

L’écart s’étend de 5,891 à 3,370, soit un facteur d’environ 1,75 entre la catégorie la plus facile et la plus difficile. Cet ordre n’est pas surprenant d’une manière qui vous dit quelque chose sur les chiffres : les mathématiques sont la surface la plus régulière qu’un modèle de langage produise, le texte général la moins régulière, et le taux de réussite d’un modèle de rédaction suit la prévisibilité de la sortie du modèle cible plutôt que sa qualité.

Trois mises en garde devraient figurer sur ce tableau, et la carte n’en mentionne aucune de sa propre initiative.

Il s'agit de données autodéclarées, et il y a exactement un téléchargement pour le dépôt. Personne en dehors d'OpenBMB n'a produit de chiffre d'acceptation pour ce checkpoint que quiconque d'autre puisse consulter. Les chiffres sont ceux du fournisseur, mesurés dans le harnais du fournisseur, sur le jeu de tâches du fournisseur.

La longueur d'acceptation est une propriété de la paire, pas du modèle. Une cible qui se répète offre à son générateur de brouillons une victoire facile, donc un chiffre plus élevé ici n'est pas la preuve que MiniCPM-V 4.7-1B excelle en quoi que ce soit. C'est une indication sur la prévisibilité de sa sortie, ce qui est une autre question, avec une autre réponse.

Et ce n'est pas une accélération. Un drafteur qui propose 15 jetons et en fait valider 3,4 fait certes avancer plusieurs jetons par passe avant de la cible, mais valider un bloc de 15 jetons coûte plus cher que générer un seul jeton, et chaque proposition rejetée est payée puis jetée. Convertir une longueur d'acceptation en une durée réelle exige le coût de validation, la taille du lot et le matériel, dont la fiche ne fournit aucun. La seule recette de service qu'elle fournit définit --max-num-seqs 1, une configuration réglée pour fonctionner plutôt que pour être rapide.

Comparé à son homologue, le tableau devient plus utile. Le draft 35B-A3B obtient 7,387 en code et 5,098 sur MMMU ; ce draft 1B obtient 5,347 et 3,452. Les cibles plus petites avec des drafters plus petits acceptent nettement moins de tokens par étape, un détail inter-familles qu’une seule fiche ne peut pas montrer et que deux fiches peuvent.

Formation, et le détail qui explique toute la conception

La recette tient en quatre lignes : deux millions de séquences d’entraînement, six époques, AdamW, et un objectif combiné composé de l’entropie croisée, d’un terme L1 et d’une perte de confiance. La ligne qui compte est celle qui porte sur la provenance des données d’entraînement — les réponses ont été générées par MiniCPM-V-4.7-1B lui-même, à partir d’un mélange de prompts visuels et textuels.

C'est de l'auto-distillation, et cela fixe le coût plancher de la construction d'un modèle de brouillon comme celui-ci. On ne peut pas en entraîner un sans d'abord faire tourner le modèle cible à grande échelle, sur les deux modalités, ce qui signifie que l'artefact de 0,85 Go que vous pouvez télécharger est le résidu bon marché d'un processus coûteux. Cela explique aussi pourquoi le modèle de brouillon est apparié un à un plutôt que partagé : le comportement qu'il imite est celui de ce modèle, et les sorties d'une cible différente entraîneraient un modèle de brouillon différent.

L’article propre à la méthode, arXiv 2607.05147, n’est pas celui d’OpenBMB. Il s’agit d’un article à 33 auteurs, soumis le 6 juillet 2026, qui décrit DSpark comme un cadre de décodage spéculatif qui associe un backbone parallèle à un module séquentiel léger et planifie la longueur de vérification à partir de probabilités estimées de survie des préfixes. Il rapporte un déploiement au sein d’un système de service DeepSeek-V4, prend une référence de production appelée MTP-1 et revendique une génération par utilisateur 60 à 85 % plus rapide à débit égal. Ces affirmations appartiennent à l’article et à ce déploiement. Rien de publié ne les relie à un draft à cinq couches et 213M sur un modèle de vision de 1B, et le tableau d’acceptation ci-dessus est le seul pont que quiconque ait proposé.

Pourquoi ce fichier compte plus que sa taille ne le suggère

La revendication phare de la famille MiniCPM-V 4.7 concerne l’exécution embarquée. La fiche du 1B propose un graphique de performance en fonction du temps d’inférence, un graphique de performance globale pour la version instruct du 1B, un enregistrement d’écran non retouché capturé sur un iPhone 17 Pro Max, et une phrase qualitative indiquant que la variante 1B surpasse nettement Qwen3.5 0.8B à la fois sur le score global et sur l’efficacité d’inférence. Elle répertorie aussi une famille de quantification — int4, AWQ, GPTQ, GGUF, ainsi qu’une prise en charge de FP8 — et des cibles matérielles dès le jour 0 couvrant iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD et Arm.

Chacune de ces affirmations est une revendication de fournisseur sans chiffre externe à l’appui, et l’une d’elles est incohérente en interne : le texte de la fiche l’appelle un modèle 1B, tandis que la barre latérale du Hub indique une taille de modèle de 2B paramètres. Le checkpoint DSpark est d’une nature différente de tout cela. Il fait 0,85 GB, sous Apache-2.0, et il est fourni avec une commande de service — ce qui signifie qu’un tiers disposant d’un GPU grand public peut l’exécuter cette semaine et produire le premier chiffre mesuré en externe de la famille. Pas un score de benchmark, mais quelque chose de presque aussi utile : une longueur d’acceptation reproduite.

Si quelqu'un obtient 3,45 sur MMMU et 3,37 sur du texte général, la carte est crédible et l'histoire de l'exécution sur appareil dispose de son premier point de données externe. Si l'acceptation ressort nettement plus faible, le tableau a été mesuré dans des conditions que la recette publiée ne reproduit pas, et le graphique de performance par temps d'inférence hérite de ce doute. L'un ou l'autre résultat vaut plus qu'un autre graphique de fournisseur, et c'est la seule partie de la famille où en obtenir un est bon marché.

Le faire tourner, et ce qu’il en coûte d’essayer

La carte embarque une seule recette et il s'agit d'un appel vllm serve, pas d'une approximation. Elle charge la cible openbmb/MiniCPM-V-4.7-1B, la sert sous le nom MiniCPM-V-4.7-1B, définit --max-model-len 40960 et --max-num-batched-tokens 40960, fixe --attention-backend FLASH_ATTN et --mm-encoder-attn-backend FLASH_ATTN, passe un kwarg de processeur multimodal de {"downsample_mode": "4x"}, fait confiance aux kwargs multimodaux par requête, et pointe une configuration spéculative vers le checkpoint DSpark avec "method": "dspark", "num_speculative_tokens": 15 et la vérification adaptative désactivée. Les kwargs par défaut du template de chat laissent la réflexion désactivée.

Deux détails dans cette ligne méritent une double lecture. --max-num-seqs 1signifie que la configuration publiée sert une séquence à la fois, donc la recette décrit une configuration de latence à flux unique, et non une configuration de débit. Et le mode de sous-échantillonnage visuel 4x est le moins coûteux des deux que la fiche parente annonce — la même fiche propose un schéma mixte 4x/16x qui troque du détail contre de la vitesse, et la recette choisit le côté de ce compromis qui privilégie la vitesse.

L'enveloppe matérielle est à l'opposé du marketing de la famille. La cible 1B fait environ 2 Go en BF16 plus un cache KV, et le draft ajoute 0,85 Go par-dessus, il s'agit donc d'une tâche sur un seul GPU — carte grand public, ou station de travail avec suffisamment de mémoire unifiée — plutôt que d'une tâche sur téléphone. La voie sur appareil dans la documentation du parent passe par des builds quantifiés et des frameworks qui ne figurent pas dans cette recette, et le checkpoint DSpark tel que publié est un artefact BF16 côté serveur.

Cela laisse un écart que la plupart des équipes rencontreront : la version intéressante de MiniCPM-V 4.7-1B est celle embarquée, et la version que vous pouvez exécuter aujourd'hui sans posséder la chaîne d'outils du téléphone est celle côté serveur. Si ce dont vous avez réellement besoin, c'est d'inférence multimodale de petite taille maintenant, l'équivalent hébergé le plus proche est un autre modèle — Qwen3 VL 8B Instruct est disponible sur OrcaRouter à 0,18 $ par million de jetons d'entrée et 0,70 $ par million de jetons de sortie, avec une fenêtre de contexte de 128 K et une entrée texte, image et vidéo, aucun poids local et aucune recette de service à maintenir en fonctionnement. MiniCPM-V 4.7 n'est pas un modèle hébergé sur OrcaRouter et cet article ne prétendra pas le contraire ; la présentation honnête est qu'il s'agit de deux façons de faire un même travail, et qu'une seule d'entre elles est mesurable depuis le catalogue cet après-midi.

Là où quelque chose comme DSpark gagne sa place, c'est dans le cas d'un modèle non éprouvé, et c'est une question de routage plutôt qu'une question de modèle. Un modèle de brouillon que personne n'a reproduit est exactement le type de composant que l'on veut derrière un point de terminaison vers lequel on peut se rabattre. Faire tourner plus de 200 modèles derrière une seule clé, les prix catalogue des fournisseurs répercutés avec 0 % de marge, avec basculement automatique lorsqu'une route se dégrade, signifie qu'une expérience de serving qui tourne mal vous coûte une nouvelle tentative plutôt qu'une panne — et comme rien n'est majoré, un changement de prix d'un fournisseur sur n'importe quel modèle du catalogue est effectif le jour même plutôt qu'au cycle de facturation suivant.

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

Trois choses manquent, et une seule d'entre elles nécessite OpenBMB.

Le fournisseur n'a rien annoncé. Le dépôt contient une fiche de modèle, une licence et une recette d'entraînement, mais aucun article de blog, aucun rapport technique, et pas une ligne dans la documentation GitHub du projet — qui, à la première semaine de la famille, décrivait encore la génération précédente comme la génération actuelle. Quatre jours après l'arrivée du checkpoint, la fiche du parent 1B ne le référence que comme une ligne de tableau, rien de plus.

Personne n'a reproduit les chiffres d'acceptation, et le nombre de téléchargements est de un. C'est l'écart le moins coûteux à combler et celui qui compte le plus, car c'est le seul endroit où une mesure externe pourrait réellement faire évoluer l'histoire de la famille.

Et la question de la qualité n’est absolument pas abordée. On ne trouve nulle part dans la publication de score MMMU, de résultat OCRBench, de chiffre de compréhension de documents ni de donnée de grounding pour MiniCPM-V 4.7-1B — le tableau d’acceptation est un tableau sur le décodage, et lire une longueur d’acceptation élevée comme un signal de qualité est exactement l’erreur que ces chiffres invitent à commettre.

Donc : un véritable artefact, une licence permissive, une commande de serving qui fonctionne, et un élément de preuve véritablement nouveau au sujet d’un modèle qui n’en avait aucun. Le prochain fichier qui vaut la peine d’être actualisé reste encore la fiche de modèle du parent.