MiniCPM-V 4.7 : un modèle de vision de 35B dans 3 Go — décryptage de l’affirmation des 100 tok/s

Un modèle de 35 milliards de paramètres ne peut pas tenir dans trois gigaoctets. MiniCPM-V 4.7 35B-A3B tourne pourtant dans environ trois gigaoctets, et les deux affirmations sont vraies — c’est là toute l’astuce, et la raison pour laquelle les chiffres qui circulent à propos de cette sortie méritent qu’on ralentisse. Le modèle est la première entrée de type mélange d’experts clairsemé de la gamme MiniCPM-V d’OpenBMB : 35,2 milliards de paramètres stockés, environ 3 milliards actifs par token, Apache-2.0, poids sur Hugging Face. Il lit des images, des ensembles d’images multiples et de la vidéo, et répond en texte. Depuis le 10 octobre, il tourne aussi dans llama.cpp en amont, là où la plupart des gens l’ont rencontré. Ce qui suit distingue les trois nombres que tout le monde répète — 3 Go, 35B et le chiffre de 100 tok/s — et montre lesquels ont réellement été publiés par OpenBMB. Plus de 200 modèles hébergés, une seule clé, prix catalogue du fournisseur répercuté avec 0 % de marge. Découvrez ce que route OrcaRouter Le checkpoint à poids ouverts reste sur votre matériel ; l’option hébergée de secours se résume à un seul point de terminaison. Les défaillances documentées de l’IA et les incidents d’agents derrière des sorties comme celle-ci sont recueillis dans OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, son niveau de gravité, sa note de confiance et son indicateur de contestation.

Trois gigaoctets, trente-cinq milliards de paramètres et aucune contradiction

L’arithmétique ne semble impossible que si l’on suppose que « en mémoire » signifie « la totalité ». MiniCPM-V 4.7 35B-A3B garde environ 3 milliards de paramètres résidents et charge à la volée le reste des experts à mesure que le routeur les demande — la formulation employée dans la fiche du modèle est Lookahead Expert Scheduling, un prédicteur de routage inter-couches qui précharge les experts dont la couche suivante aura probablement besoin, en chevauchant ce chargement avec le calcul déjà en cours. La fiche prend soin de préciser que la prédiction ne pilote que le préchargement et l’ordonnancement ; les tokens suivent toujours le routage réel du modèle, et un expert manqué par le prédicteur est chargé et évalué comme n’importe quel autre.

Cette distinction a une conséquence mesurable. Le dépôt GGUF publie le modèle complet dans toutes les quantifications courantes, et aucun de ces fichiers ne fait trois gigaoctets :

• Q4_K_M — 21,2 Go sur disque.

• Q8_0 — 36,9 Go.

• F16 — 69,4 Go.

• Projecteur de vision — 0,9 Go à compression 4x, 1,1 Go en f16.

Ainsi, « 3 GB » est une valeur de mémoire résidente en streaming d’experts sur un téléphone, et non une taille de téléchargement ni une exigence de VRAM pour un ordinateur de bureau. Si vous préparez un déploiement, le chiffre qui régit votre disque et votre premier chargement est 21.2 GB à Q4_K_M, et le chiffre qui régit votre empreinte en régime permanent sur un téléphone est le ~3 GB du fournisseur. Les deux figurent dans la version publiée. Ils répondent à des questions différentes, et la plupart de la couverture médiatique les a amalgamés en un seul.

D'où viennent les 100 tok/s, et d'où ils ne viennent pas

Voici le point sur lequel il faut être franc. OpenBMB ne publie pas de chiffre de 100 tok/s pour MiniCPM-V 4.7. Le chiffre indiqué sur la fiche modèle est de 13+ tokens/s, sur un iPhone 17 Pro Max, avec environ 3 Go de mémoire. C’est la seule affirmation de débit sur appareil formulée dans l’annonce, et elle est mesurée par le fournisseur sur un matériel que personne en dehors du laboratoire n’a reproduit.

Il existe bel et bien des nombres plus élevés, et ils proviennent d’un autre artefact. Le fork llama.cpp-omni d’OpenBMB — le dépôt qui porte les optimisations sur l’appareil — publie sa propre table pour la cible 35B-A3B, ventilée selon les optimisations activées :

• iPhone 18 Pro Max, 12 Go — 3,38 tok/s en référence, 11,34 avec Lookahead Expert Scheduling, 17,16 avec la précision mixte en plus, 20,51 avec en plus la tête de draft DSpark.

• iPad Pro 11 pouces M4, 16 Go — 2,97 tok/s en référence, 9,81 avec LES, 14,92 avec précision mixte, 17,39 avec DSpark.

Ce sont les chiffres publiés les plus élevés sur appareil pour ce modèle, et le haut de l’échelle est de 20,51 tok/s — un cinquième de 100. Cet écart compte parce qu’il change la finalité du modèle. À 13 tok/s, une application mobile répond à une question sur une photo en quelques secondes. À 100 tok/s, on l’envisagerait comme un lecteur de premier passage en streaming pour la vidéo. Le premier est un vrai produit. Le second n’est pas ce qui a été livré, et quiconque établit son budget sur le chiffre du tweet sera déçu d’un facteur cinq.

La lecture honnête de l’affirmation des 100 tok/s est qu’il s’agit de la compression de trois faits distincts — 3 Go, fonctionne localement, nettement plus rapide que la génération précédente — en un seul chiffre que aucune des sources ne contient. L’amélioration d’une génération à l’autre est réelle et importante : passer de 3,38 à 20,51 tok/s représente un bond de 6x sur la même catégorie d’appareil, obtenu en combinant trois techniques plutôt qu’avec une puce plus grosse.

La sortie n’a pas été qu’une seule journée, et les dates comptent.

MiniCPM-V 4.7 a fait surface comme le font désormais beaucoup de versions à poids ouverts : les fichiers d'abord, les explications ensuite, et la prise en charge des frameworks quelque part entre les deux.

• 6 octobre, 17:40 UTC — le modèle 1B et ses variantes AWQ, GPTQ et int4 apparaissent sur Hugging Face, ainsi que les builds GGUF à 18:05.

• 7 octobre, 07:07 UTC — le dépôt 35B-A3B est publié. Toujours pas de fiche modèle.

• 8 octobre — têtes de décodage spéculatif DSpark pour les deux tailles, et une version FP8 du 35B.

• 10 octobre, 18 h 42 UTC — llama.cpp fusionne la prise en charge du modèle.

• 12 octobre — OpenBMB enregistre la fiche modèle, déclare le modèle sous licence Apache-2.0 et annonce sa publication en tant que produit documenté.

• 15 octobre — les têtes DSpark sont liées depuis la carte principale, avec des ébauches GGUF pour les deux cibles.

Cet ordre explique une bonne part de la confusion dans la couverture secondaire. Quelqu'un qui a découvert le modèle via llama.cpp pendant la deuxième semaine d'octobre utilisait une version qui n'existait pas encore officiellement, sans étiquette de licence ni graphique de benchmark, et ses chiffres de débit reflètent les choix de quantification propres au framework plutôt que quoi que ce soit qu'OpenBMB ait évalué.

Prise en charge de llama.cpp : fusionnée, et pas tout à fait terminée

La pull request en amont qui a ajouté MiniCPM-V 4.7 est étonnamment claire sur ce qui a changé, et la réponse est : presque rien sur le plan architectural. Le modèle est quasi identique à MiniCPM-V 4.6 ; le delta est le RoPE 3D, une position à trois valeurs par token — temps, ligne, colonne — au lieu du scalaire unique qu’utilisent la plupart des modèles vision-langage. La prise en charge étend le chemin 4.6 existant pour porter cette dimension supplémentaire. La PR indiquait aussi le modèle comme « à venir » lors de son ouverture le 25 septembre, ce qui donne un bon indice sur le stade de circulation des poids.

Il vaut la peine de connaître ce résidu avant de construire une fonctionnalité de grounding dessus. Depuis cette fusion, upstream llama.cpp attribue aux tokens de marqueur d’image les mauvaises positions dans les prompts de MiniCPM-V 4.7 : les tokens d’image eux-mêmes sont placés correctement, mais <slice>, </slice> et les marqueurs de fin de ligne sont numérotés comme du texte brut au lieu de recevoir leurs coordonnées de coin de tuile comme le fait l’implémentation de référence get_rope_index. Le symptôme visible est que les coordonnées renvoyées sont systématiquement trop basses lorsqu’on demande où se trouve quelque chose dans une image. Un correctif avec un test unitaire existe sous forme de pull request ouverte, datée du 14 octobre, et au 20 octobre elle est toujours ouverte. Si votre charge de travail est « décrivez ceci », vous ne le remarquerez pas. Si c’est « donnez-moi la boîte englobante », vous le remarquerez, et vous devriez soit attendre la fusion, soit utiliser le fork qui contient le chemin corrigé.

Une chose de plus survit à l’aller-retour : pour le modèle 1B, le projecteur de vision est le téléchargement le plus volumineux. Les poids Q4_K_M font 672 Mo ; le projecteur f16 fait 1,11 Go. Le plus petit déploiement 1B utile représente donc environ 1,8 Go de fichiers, dont l’essentiel relève des yeux plutôt que du langage — un détail qui prend à défaut toute attente du type « 1B signifie 1 Go ».

Que lancer, et sur quoi

Si l’objectif est de l’essayer cette semaine, la voie la moins contraignante est llama.cpp ou Ollama avec les dépôts GGUF, en pointant le client multimodal vers le fichier mmproj correspondant. Sur un GPU de 24 Go, Q4_K_M à 21,2 Go laisse très peu de marge pour le contexte — une fenêtre de 8K tokens plus les tuiles d’image ne tiendront pas confortablement, donc prévoyez Q4_K_S ou une quantification plus petite si vous voulez aussi un prompt long. Sur un Mac avec 32 Go ou plus, Q8_0 est viable et c’est ce qui se rapproche le plus du comportement de référence. Sur un téléphone, seules les applications du fournisseur et le fork llama.cpp-omni prennent en charge le travail d’ordonnancement des experts ; le llama.cpp standard vous garantit l’exactitude, pas les 20 tok/s.

C’est de l’autre côté de l’appel local qu’une couche de routage justifie ici sa place. Un modèle à 3 B de paramètres actifs sur un téléphone excelle dans les situations courantes — lire ce reçu, vérifier si cette étagère semble approvisionnée, que dit ce panneau — et il tombera parfois sur une page qu’il ne peut pas terminer. OrcaRouter place plus de 200 modèles hébergés derrière une seule clé, répercute le prix catalogue de chaque fournisseur avec 0 % de marge afin qu’une modification de prix d’un fournisseur soit effective le jour même, et bascule automatiquement en cas de dégradation d’un service en amont. Le modèle qui fonctionne est la priorité au local avec une solution de repli hébergée, pas le tout-local. Le point de contrôle à poids ouverts reste à héberger chez vous ; le routeur gère tout ce que le téléphone délègue.

MiniCPM-V 4.7 n'est pas servi par OrcaRouter, et nous n'allons pas laisser entendre le contraire. C'est un checkpoint que vous exécutez.

Qu’est-ce qui permettrait de fixer les trois chiffres ?

Une mesure indépendante du modèle 35B sur un téléphone nommé, avec l'application et la quantification précisées, trancherait la question du débit — y compris de savoir si 20,51 tok/s survivent au chronomètre de quelqu'un d'autre. Une définition publiée du chiffre de 3 Go — ensemble résident, allocation de pointe, ou autre chose — trancherait la question de la mémoire. Et un tableau par benchmark avec de vrais scores, plutôt que les cinq graphiques liés que livre actuellement la fiche, permettrait de vérifier l'affirmation « meilleur que Qwen3.6 35B-A3B en moins de temps » à l'aune de la pondération choisie par OpenBMB. Rien de tout cela n'existe encore. D'ici là, la formulation exacte est la plus banale : un modèle clairsemé de 35B qui tourne sur un téléphone à un débit rapporté de plus de 13 tokens par seconde dans environ 3 Go, avec un téléchargement de 21 Go et un chemin de framework fusionné qui a encore un bug de coordonnées ouvert.