Une pagode en voxels, 10 % de tokens en moins, et l’unique phrase qu’OpenBMB assume vraiment

La phrase la plus citée cette semaine à propos de MiniCPM-V 4.7 35B-A3B ne figure pas dans sa fiche de modèle. C’est un tweet, publié le 13 octobre 2026, qui dit : « MiniCPM-V 4.7 35B-A3B n’a non seulement utilisé moins de tokens, mais a aussi produit une meilleure pagode en voxels que Qwen 3.6 35B-A3. » La démonstration à laquelle il renvoie est une vidéo de deux modèles de langage écrivant chacun le code d’une pagode japonaise en voxels 3D, rendus côte à côte. C’est un artefact réellement intéressant — il montre un modèle vision-langage reproduire en trois dimensions une structure bâtie à partir d’un prompt image, ce qui est une tâche plus difficile que de légender une image. Mais il vaut la peine de distinguer ce que ce tweet est de ce qu’il n’est pas, parce que trois affirmations différentes ont été fusionnées en une seule ligne, et qu’elles ont trois niveaux de preuve différents. MiniCPM-V 4.7 35B-A3B est un véritable checkpoint d’OpenBMB et il a environ une semaine ; Qwen3.6-35B-A3B est un rival à poids ouverts vieux de neuf mois, également Apache-2.0, également un mélange d’experts clairsemé à la même taille annoncée. Tout ce qui suit vise à déterminer lesquelles des affirmations d’efficacité qui les entourent sont vérifiables, et lesquelles sont un JPEG d’un graphique.

Trois affirmations sous une seule phrase

Le tweet regroupe trois choses séparables, et elles méritent d’être séparées car une seule d’entre elles est documentée.

• « A utilisé moins de tokens » — il s’agit d’une affirmation mesurable concernant la consommation de tokens pour une tâche. Le chiffre qui circule aux côtés de la démo est de 10 % de tokens en moins que Qwen3.6 35B-A3B. Ce chiffre provient du créateur tiers qui a réalisé la comparaison, et non de l’évaluation d’OpenBMB, et il correspond à une seule paire de prompts, pas à un benchmark.

• « Production d'une meilleure pagode en voxels » — il s'agit d'un jugement, porté en regardant deux pagodes rendues. Il n'y a ni grille d'évaluation, ni dispositif de notation, ni tiers indépendant. C'est le genre d'affirmation qu'un humain fait en trois secondes et qu'un benchmark ne peut pas faire du tout, parce que « meilleure pagode » n'a pas de vérité terrain.

« Efficacité plus qualité : voilà le vrai champ de bataille » — cette partie est une thèse, et il se trouve que c’est celle qu’OpenBMB défend effectivement par écrit, chiffres à l’appui, dans la fiche du modèle. Ce n’est simplement pas la phrase qui a circulé.

Cela compte parce que les deux premières affirmations sont celles dont on se souvient et que la troisième est celle qui est défendable. Si vous devez décider si vous consacrez 70 Go de téléchargement à un checkpoint, c’est la troisième qu’il vous faut.

Ce qu'OpenBMB a réellement écrit, et quand

La chronologie d'abord, car elle a été compressée par les reprises successives. Les poids ont été mis en ligne discrètement : openbmb/MiniCPM-V-4.7-1Ba été créé le 6 octobre 2026 à 17h40 UTC,openbmb/MiniCPM-V-4.7-35B-A3Ble 7 octobre à 07h07 UTC. Aucun des deux ne comportait de fiche de modèle, d'étiquette de licence ni de benchmark à ce moment-là — cela a été traité ici à l'époque, et c'était une situation étrange pour une mise en ligne de 35 milliards de paramètres. Six jours plus tard, le 12 octobre 2026, OpenBMB a publié la documentation d'un seul coup : fiche de modèle, licence Apache-2.0, graphiques d'évaluation, un README de dépôt réécrit mettant en avant la nouvelle série, et une annonce. Les paramètres n'ont pas changé ce jour-là. L'explication, si.

Donc la formulation honnête n’est pas « MiniCPM-V 4.7 35B-A3B a été lancé cette semaine ». C’est « MiniCPM-V 4.7 35B-A3B est devenu lisible cette semaine ». Tout ce qui, à son sujet, est désormais citable a soit été mis en ligne le 6 et le 7 mais sans documentation, soit rédigé le 12 et relève d’une affirmation de fournisseur.

L'affirmation que la model card fait bel et bien

Voici la phrase, mot pour mot depuis la fiche, et elle est plus restrictive que le tweet : en mode Instruct, la variante 35B-A3B « obtient un score global plus élevé en moins de temps d'inférence que Qwen3.6 35B-A3B ». C'est tout. Aucun nombre de tokens, aucune marge, aucune ventilation par benchmark en prose. Les éléments de preuve qui l'étayent sont un nuage de points — score d'évaluation moyen sur l'axe vertical, temps d'inférence en secondes sur une échelle logarithmique à l'horizontale — sur lequel MiniCPM-V 4.7 35B-A3B se situe au-dessus et à gauche de Qwen3.6-35B-A3B. La note de bas de page du graphique définit elle-même la moyenne comme étant celle de cinq benchmarks : MMStar, MMMU-Pro, le raisonnement CharXiv, BLINK et MathVista. Les cercles désignent le mode Instruct, les losanges le mode Thinking.

Il s’agit d’une affirmation réelle et précise concernant un compromis à deux dimensions, et c’est l’élément le plus fort de la publication. Il convient également de noter ce que le graphique ne peut pas vous dire : il n’y a aucune étiquette numérique sur les points tracés, de sorte que vous ne pouvez pas y relever un score ni un temps, seulement une direction. La direction, telle qu’elle est dessinée, favorise MiniCPM sur les deux axes à la fois.

Et il a été mesuré par le fournisseur. Les chiffres d'évaluation de la fiche portent la mention « Les résultats proviennent de rapports publics et de notre évaluation locale à l'aide de points de contrôle officiels. » Évaluation locale signifie le matériel d'OpenBMB, le harnais d'OpenBMB, la sélection de mode d'OpenBMB. C'est une pratique normale pour une fiche de modèle, et une pratique anormale que de la faire passer pour un fait établi. Aucun tiers indépendant n'a exécuté ces deux points de contrôle sur un harnais commun. Aucun classement n'a répertorié l'un ou l'autre de ces résultats. À l'heure où nous écrivons, cette affirmation n'a qu'une seule source, et cette source vend le modèle.

D'où est censée venir l'efficacité des tokens

L'argument de l'efficacité ne repose pas sur le graphique de référence. Il repose sur trois choix d'ingénierie, et ils méritent d'être compris, car ils déterminent si le gain se transpose à votre matériel ou non.

• Planification anticipée des experts (LES) — la technique phare. Un mélange d'experts clairsemé stocke bien plus de paramètres qu'il n'en active par token, et sur un appareil qui ne peut pas contenir tous les experts en mémoire, les poids sont paginés en entrée et en sortie et le décodage se bloque. LES utilise la prédiction de routage inter-couches pour précharger les experts susceptibles d'être nécessaires à la couche suivante, et donne la priorité aux calculs pour les experts que le routeur réel a effectivement sélectionnés et qui se trouvent déjà chargés. OpenBMB prend soin de préciser que la prédiction ne pilote que le préchargement et l'ordonnancement ; le routage au niveau des tokens du modèle reste inchangé, et les experts manqués par le prédicteur sont quand même chargés et évalués. La fiche revendique une accélération de 5× sur des appareils réels grâce à cela, sans perte de capacité.

• Quantification fine couche par couche — réduit l'empreinte des poids des experts et le trafic mémoire, ce qui constitue l'autre moitié de la mise en adéquation d'un schéma de chargement embarqué.

• Échantillonnage spéculatif DSpark — une voie de modèle brouillon appariée, publiée séparément sous openbmb/MiniCPM-V-4.7-35B-A3B-DSpark, et intégrée aux côtés des travaux de planification et de quantification.

Empilés, ces éléments produisent le chiffre phare de la version : plus de 13 tokens par seconde en utilisant environ 3 Go de mémoire sur un iPhone 17 Pro Max. C'est un chiffre de fournisseur, sur du matériel de fournisseur, avec un logiciel de fournisseur — une application écrite par OpenBMB. C'est le genre d'affirmation qui représente soit tout le produit, soit rien du tout, et il n'existe actuellement aucun moyen pour quiconque en dehors de l'entreprise de la vérifier, car pour la reproduire, il faut la pile embarquée que fait tourner la démo sur téléphone.

L'efficacité des tokens est réelle, mais ici, c'est une matrice, pas un scalaire.

Il y a dans cette release un détail qui a été gommé de tous les résumés qui en ont été faits, et c’est celui qui régit réellement l’économie des tokens.

• MiniCPM-V 4.7 35B-A3B prend en charge une compression mixte des tokens visuels en 4x et 16x, sélectionnable par requête. Le réglage 16x fusionne les tokens visuels pour gagner en vitesse ; le 4x en conserve quatre fois plus, pour le détail. La valeur par défaut de la carte est 16x, et le paramètre doit être transmis à la fois au template de chat et à l'appel generate, sinon le nombre de placeholders et l'encodeur vision ne concordent pas.

• Le tableau comparatif vision-langage du fournisseur lui-même indique le réglage de compression utilisé pour la ligne de chaque modèle. Dans ce tableau, la ligne MiniCPM-V 4.7 35B-A3B est à 4x — le réglage qui préserve les détails, c'est-à-dire le plus coûteux — et la ligne Qwen3.6 35B-A3B est à 16x. Une ligne Gemma 4 31B est indiquée à 9x ; les deux lignes Qwen 27B à 4x.

• Une note de bas de page indique clairement que MiniCPM-V 4.7 prend en charge l’un ou l’autre réglage, tandis que les autres modèles du tableau ne prennent en charge qu’un taux de compression fixe.

Si l’on lit cela ensemble, le tableau change. Si la ligne MiniCPM tire ses scores vision-langage du réglage gourmand en tokens tandis que la ligne Qwen tire les siens du réglage économe en tokens, alors les deux colonnes comparent des quantités différentes de détail visuel, et l’histoire d’efficacité n’est pas « même entrée, moins de tokens » — c’est « entrée ajustable, et voici la colonne qui l’emporte en qualité ». C’est une affirmation plus intéressante et plus honnête que celle du tweet, et OpenBMB l’a publiée dans une note de bas de page plutôt que de la mettre en avant.

Cela signifie aussi que le nombre qui vous importe vraiment — les tokens par unité de détail visuel — ne peut pas du tout être lu dans ce tableau. Cela nécessite d’exécuter les deux modèles avec le même réglage, ce que personne n’a publié.

Le tableau, avec les réserves qui y sont attachées.

La carte livre deux tableaux de fournisseurs, l'un pour la vision-langage et l'autre pour le langage, tous deux en mode Instruct, tous deux face à un panel qui comprend deux modèles Qwen de classe 35B-A3B, un Gemma 31B et deux Qwens 27B. Les chiffres ci-dessous ont été lus sur le propre graphique PNG du fournisseur, et la mise en garde est structurelle : les nombres n'existent que sous forme de pixels dans ce graphique, pas sous forme de tableau, donc ce qui suit a été extrait par lecture automatique et de petites erreurs de transcription sont possibles.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91,20 contre Qwen3.6 35B-A3B à 90,40. Un écart de 0,8 point, sur l’exécution du fournisseur lui-même.

• OmniDocBench v1.6 — environ 98,2 pour MiniCPM contre environ 93,3 pour le modèle Qwen, soit l'écart isolé le plus important du tableau et celui qui compterait le plus s'il se reproduisait, car c'est dans l'analyse de documents que les budgets de tokens sont généralement dépensés.

• MMMU — environ 80,2 contre 80,0, une égalité parfaite à la résolution d’une image de graphique.

• MMMU-Pro — environ 69,7 contre 67,7, sur une ligne où un Qwen 27B se trouve plus haut que les deux.

• Tableau des langues — la même forme, avec les cellules les plus frappantes sur le suivi d’instructions et le code. IFBench est indiqué autour de 47,7 contre 35,3, et LiveCodeBench-v6 autour de 97,0 contre 54,3. Ces deux écarts sont suffisamment importants pour qu’ils soient considérés comme les cellules les moins crédibles de la publication tant que quelqu’un d’autre ne les a pas reproduits : un écart de 43 points sur un benchmark de code entre deux modèles MoE ouverts de taille similaire, mesuré par l’une des deux parties, est une affirmation qui nécessite un second instrument.

Rapportés par le fournisseur, évalués avec le harnais du fournisseur, non reproduits. Voilà tout ce qu'il y a à dire. Si ces chiffres tiennent face à un harnais indépendant, l'affirmation de la frontière de Pareto est correcte et la vidéo de la pagode est une note de bas de page. S'ils ne tiennent pas, la vidéo de la pagode est tout ce qu'il y a.

Ce que disent les chiffres d’adoption, ce qui n’a rien à voir avec la qualité.

Un chiffre dans cette comparaison n'est contesté par personne, et ce n'est pas un benchmark. Le compteur de téléchargements de Hugging Face, relevé le 13 octobre 2026, affiche 630 pour openbmb/MiniCPM-V-4.7-35B-A3B contre environ 3,6 millions pour Qwen/Qwen3.6-35B-A3B — un dépôt créé le 15 avril 2026 et donc situé environ neuf mois plus loin sur la courbe d'adoption. Cet écart mesure le temps, pas le mérite, et c'est la raison pour laquelle la question de l'efficacité est posée dans ce sens : le nouveau venu doit argumenter sur une base par token précisément parce qu'il n'a pas eu neuf mois pour être le choix par défaut.

Il y a aussi une petite contradiction interne dans la fiche qu’il vaut la peine de signaler. Le dépôt porte la balise « On-Device Model » héritée du reste de la famille, et un MoE clairsemé de 35,2 milliards de paramètres, avec 70,4 Go de poids BF16, n’est pas on-device au sens où l’entendrait une personne qui télécharge. L’histoire du on-device est réelle, mais elle passe par la quantification et le streaming d’experts par-dessus le checkpoint, pas par le checkpoint. Établissez le budget en fonction de la version quantifiée et de l’application, pas de la balise.

Que faire à ce sujet cette semaine

La position pratique est étroite et claire. Si vous voulez faire vérifier l'affirmation d'efficacité, il n'y a encore rien à vérifier — c'est le graphique d'un seul fournisseur, et le seul chiffre accompagné d'une valeur par tâche (10 % de tokens en moins, un pagoda) provient d'une seule démo réalisée par un tiers. Si vous voulez exécuter le modèle, les poids sont sous Apache-2.0, l'architecture est documentée, et c'est à vous de choisir le paramètre de sous-échantillonnage, ce qui est un véritable levier encore trop peu apprécié : 16x quand le débit compte, 4x quand le graphique vous montre un document.

Une moitié de cette comparaison est accessible dès aujourd'hui via une API hébergée, et l'autre non, et il vaut la peine de préciser laquelle est laquelle. qwen/qwen3.6-35b-a3best un modèle hébergé sur OrcaRouter — il figure au catalogue derrière une seule clé, au prix catalogue de Qwen, sans rien ajouté par-dessus, et il est acheminé vers le fournisseur en bonne santé plutôt que vers celui que vous avez épinglé. MiniCPM-V 4.7 n'est pas hébergé par nous ; c'est un checkpoint à poids ouverts que vous servez vous-même. Cette asymétrie est ce qui est utile ici. Vous pouvez mettre le volet Qwen de cette comparaison dans une baseline cet après-midi, exécuter le harnais d'OpenBMB sur vos propres données pour le confronter, et laisser le graphique du fournisseur être l'hypothèse plutôt que la réponse.

Ce qui, étant donné que tout le débat porte sur l’efficacité sur votre matériel, est la seule mesure qui allait un jour trancher.