Les « 3 milliards de paramètres actifs » de MiniCPM-V 4.7 ne figurent pas dans la fiche de modèle — je les ai mesurés à partir des poids

Le nombre le plus répété au sujet de MiniCPM-V 4.7 35B-A3B n'est indiqué nulle part dans sa propre documentation. L'affirmation — « seulement 3B de paramètres actifs (!) — il tourne même sur un iPhone » — provient d'une publication tierce du 13 octobre 2026, et la fiche modèle du fournisseur, le README du dépôt et les notes de lancement ne donnent jamais de chiffre de paramètres actifs, tout simplement. Ce n'est pas tant une critique de cette affirmation qu'une lacune qui mérite d'être comblée : le checkpoint encode sa propre réponse. Donc, avant toute autre chose ici, j'ai récupéré l'index safetensors et l'en-tête de chaque shard pour openbmb/MiniCPM-V-4.7-35B-A3B, et j'ai compté. Pour comparaison, l'autre modèle de la même publication — Qwen3.8-27B, publié le 13 août 2026 — est un modèle dense de 27B et n'a aucune ambiguïté de ce genre à résoudre : chaque paramètre est actif sur chaque token. La question intéressante est de savoir si « 3B actifs » survit au contact des poids, et la réponse est : cela survit, mais seulement si l'on définit le mot « actif » à la manière du fournisseur, et le chiffre honnête est plus proche de 4B dès que l'on compte les parties que l'on ne peut pas éviter d'exécuter.

Le registre, lu depuis le point de contrôle lui-même

Le fichier d'index répertorie 40 couches linguistiques ainsi qu'une tour de vision et un projecteur, soit 35 212 875 824 paramètres au total en BF16 — 70,43 Go de poids à télécharger. Cela correspond au « 35B » du nom. La question MoE est de savoir quelle fraction de tout cela est sollicitée par token :

• Total stocké — 35,21 milliards de paramètres, 70,43 Go en BF16. Chaque expert est sur disque, qu’il soit utilisé ou non.

• Budget du routeur — 8 experts sélectionnés par token, sur 256, par couche MoE. Configuré dans config.json via num_experts_per_tok : 8. Chaque expert est petit : 3,15 M de paramètres.

• Chemin MoE par couche — 8 experts (25,17 M) + un expert partagé (3,15 M) + la porte du routeur (0,52 M) ≈ 28,83 M.

• Chemin d'attention par couche — l'architecture est hybride : 30 des 40 couches utilisent l'attention linéaire (33,72 M chacune), 10 utilisent l'attention complète (27,26 M chacune). Total ≈ 2,44 B sur l'ensemble des 40 couches pour l'attention plus l'arithmétique MoE, répété par token.

• De plus, ce que vous ne pouvez pas omettre — les embeddings de tokens 508,2 M, la tête LM 508,2 M, la tour de vision 522,3 M, le projecteur 30,7 M.

• Les deux réponses défendables — ~2,44 B actifs sur le seul chemin attention-et-MoE ; ~4,01 B si l’on compte les embeddings, la tête de sortie, la tour de vision et le projecteur, qu’une requête de vision sollicite bel et bien.

Donc « 3B active » n'est pas faux. C'est un arrondi de 2,44B vers le haut, et cela se situe dans l'écart entre les deux nombres ci-dessus. Ce n'est simplement pas un chiffre publié par OpenBMB, et ce n'est pas la même chose que le suffixe « A3B » — ce suffixe fait partie du nom du modèle, et les documents du fournisseur lui-même n'en font jamais une mesure.

Pourquoi le suffixe et le nombre ne sont pas la même chose

Les conventions de nommage dans l’écosystème open-weights impliquent un nombre de paramètres actifs : un modèle appelé 30B-A3B, ou 235B-A22B, vous indique qu’il active environ ce nombre de paramètres par token. Cette implication est généralement fiable — mais il s’agit d’une convention, pas d’un contrat, et MiniCPM-V 4.7 est un cas où rien dans la fiche, le README ou l’annonce de lancement ne convertit le « A3B » en un nombre autour duquel planifier la mémoire. Tant que quelqu’un n’a pas compté, le suffixe est une étiquette.

Le décompte ci-dessus relève de l'arithmétique, non d'une déduction à partir de cette étiquette. C'est aussi la raison pour laquelle les chiffres d'environ 2,44 Md et 4,01 Md diffèrent : compter ou non la table d'embeddings et la tête de sortie est un véritable choix, pas du pinaillage. Sur un modèle dense, les embeddings ne représentent qu'une petite part d'un budget de 27 Md. Sur un modèle creux où le chemin de calcul par token ne fait que quelques milliards de paramètres, une table d'embeddings de 508 M et une tête LM de 508 M ne sont plus du bruit : ensemble, elles représentent environ un cinquième du chemin actif, et elles sont stockées en pleine largeur tandis que les experts sont quantifiés.

Une conséquence qu’il vaut la peine d’énoncer clairement : le rapport entre paramètres stockés et paramètres actifs y est d’environ 8,8 pour 1 dans l’interprétation stricte. C’est toute la raison pour laquelle un modèle 35B peut être présenté comme un modèle de téléphone, et c’est aussi la raison pour laquelle il n’en est pas un de la manière dont un modèle dense 3B l’est. Le stockage ne diminue pas lorsque le routeur ignore un expert.

L’affirmation concernant l’iPhone est une affirmation distincte avec une base de preuves distincte.

Tout ce qui est concret concernant les performances sur appareil dans cette version provient du fournisseur et n’est pas reproduit. Le chiffre précis est de 13+ tokens par seconde avec environ 3 Go de mémoire sur un iPhone 17 Pro Max, le même checkpoint étant démontré sur un iPad M4. OpenBMB l’attribue à trois techniques qui fonctionnent ensemble — Lookahead Expert Scheduling, qui prédit le routage inter-couches et précharge les experts, une quantification fine couche par couche, et l’échantillonnage spéculatif DSpark — et décrit le résultat comme le premier modèle MoE open source à fonctionner de manière fluide sur appareil sans perdre en capacités. Il n’existe aucune mesure indépendante de ce débit dans les sources publiques, aucune reproduction par un tiers, et aucune décomposition publiée de la quantification que suppose le chiffre de 3 Go.

Cela compte pour une raison précise : 3 GB est le nombre qui détermine si l’affirmation est intéressante pour vous, et c’est le nombre que nous connaissons le moins. Un MoE 35B dont les poids des experts résident principalement sur du stockage flash n’est pas un modèle de 3 GB, c’est un modèle dont l’ensemble de travail résident se trouve tenir dans 3 GB une fois que les prédictions de routage, le préchargement et un cache d’experts quantifié font tous leur travail. Ce sont exactement les conditions dans lesquelles le débit en benchmark et le débit en conditions réelles divergent — le premier prompt réchauffe le cache, et le comportement qui vous donne 13 tokens par seconde sur une démo est un ordonnancement, pas une propriété des poids.

Considérez les 13 tokens par seconde comme une affirmation concernant une technique, et non concernant le checkpoint. Le checkpoint est ce que vous pouvez vérifier aujourd'hui : 35,21 B stockés, 8 experts sur 256 routés par token, ~2,44 B à ~4,01 B actifs selon ce que vous comptez, Apache-2.0, des quantifications day-0 en GGUF, AWQ, GPTQ, int4 et FP8, et une liste de fournisseurs de puces prises en charge qui inclut Rockchip, Houmo, Intel, AMD et Arm.

Ce que le compte actif décide et ne décide pas

Le nombre de paramètres actifs est un indicateur indirect de la charge de calcul. Il indique la quantité de multiplications matricielles effectuées par token, ce qui permet d’estimer la vitesse à laquelle s’exécute un décodage limité par le GPU. Il ne vous indique pas la quantité de mémoire nécessaire pour héberger le modèle, laquelle est régie par le total — 70,43 Go de poids BF16, soit environ un quart de cela en 4 bits, avant même de tenir compte d’un cache KV. Sur un modèle à contexte de 256K, ce cache n’est pas non plus un détail négligeable.

• Vitesse de décodage — déterminée par les paramètres actifs (~2,44 B–4,01 B ici). C’est ce à quoi se rapporte l’affirmation de 13 tokens/s.

• Mémoire résidente — déterminée par le nombre total de paramètres (35,21 B stockés), puis réduite par la quantification et par l’ensemble d’experts qui reste résident.

• Stockage et chargement — régis par la totalité des 70,43 GB en BF16. Le routage sparse ne réduit pas le téléchargement.

• La bande passante, pas les flops — sur un téléphone, la contrainte déterminante est de faire passer les experts par un bus mémoire, c’est pourquoi la technique d’ordonnancement existe et pourquoi le seul nombre d’experts actifs ne prédit rien de la latence mobile.

En pratique : si vous disposez d’un GPU avec suffisamment de mémoire pour contenir les poids quantifiés, c’est le nombre de paramètres actifs qui détermine votre débit, et « 3B active » est une bonne chose. Si c’est vous qui êtes la raison pour laquelle l’expression « tourne sur un iPhone » apparaît dans un post, c’est le nombre total qui décide de la faisabilité, et le travail d’ordonnancement du fournisseur est ce qui rend le nombre total viable. Les deux lectures d’un même titre sont correctes, et ce ne sont pas les mêmes lectures.

La comparaison dans ce post a besoin de deux étiquettes, pas d’une.

Le cadrage retenu cette fois-ci opposait le matériel local au matériel coûteux : MiniCPM-V 4.7 35B-A3B comme le modèle qui offre les mêmes capacités sans la machine, face à Qwen3.8-27B comme le modèle plus intelligent mais qui nécessitait la machine. La part « capacités » de ce cadrage vient de la fiche modèle de Qwen elle-même, et elle est déclarée par le fournisseur comme tout le reste sur cette page. Les chiffres publiés par Qwen pour Qwen3.8-27B incluent 90,3 sur LiveCodeBench v6, 89,2 sur GPQA Diamond, 84,3 sur OSWorld-Verified et 79,0 sur QwenSWEBench, et notre propre fiche catalogue pour ce modèle les présente comme des résultats agentiques et de codage exceptionnellement solides pour un modèle dense de 27B. Qu'il ait été « plus intelligent qu'Opus 4.6 » est une affirmation tirée de la publication sur les réseaux sociaux, et je n'ai sous les yeux aucune évaluation indépendante qui permette de trancher — je ne vais donc pas la présenter comme un fait.

La différence structurelle est celle qui est réellement vérifiable : Qwen3.8-27B est dense, donc ses 27B de paramètres sont tous actifs et son empreinte mémoire et sa facture de calcul correspondent au même nombre. MiniCPM-V 4.7 35B-A3B sépare ces deux nombres d'un facteur d'environ neuf. C'est tout l'argument architectural, et il est bien réel. Ce n'est simplement pas la même chose qu'une comparaison de benchmarks, et le post qui l'a rendu célèbre a mélangé les deux.

Là où un routeur modifie la décision, et là où il ne le fait pas

Deux choses sont vraies ici et méritent d’être distinguées, car elles pointent dans des directions opposées.

Le premier point est que nous ne proposons pas MiniCPM-V 4.7. Il ne figure pas dans notre catalogue. Si vous le voulez, la voie à suivre est votre propre matériel — ce pour quoi cette version est précisément conçue, avec les poids, les quantifications et les guides de déploiement sur appareil publiés en parallèle. Une API hébergée n’aide en rien à exécuter un modèle sur un téléphone, et il serait trompeur de suggérer le contraire.

Le second est que le modèle par rapport auquel celui-ci est mesuré n'est pas dans cette position. Qwen3.8-27B est disponible via notre API, auto-hébergé sur notre propre infrastructure, à 0,33 $ par million de tokens d'entrée et 2,40 $ par million de tokens de sortie. Si la question que vous posez réellement est « dois-je remplacer mes appels à Qwen3.8-27B hébergé par un MiniCPM-V 4.7 déployé localement », la version honnête de la réponse est que vous devriez mener l'expérience avant de vous engager : le chiffre de débit sur appareil n'est pas reproduit, et la comparaison des capacités provient de la propre fiche de l'autre partie. C'est la situation pour laquelle le basculement existe — acheminez une fraction du trafic vers un nouveau chemin, gardez celui qui a fait ses preuves derrière lui, et laissez une mauvaise semaine vous coûter une fraction d'une charge de travail plutôt que la charge de travail entière. Un modèle à 0 % de marge garde aussi l'arithmétique honnête : lorsqu'un fournisseur modifie un prix, le montant que vous payez change le jour même, parce que il n'y a pas de couche de marge entre leur prix catalogue et votre facture.

Ce qu'un routeur ne peut pas faire, c'est faire disparaître la question du local ou de l'hébergé. Celle-ci est décidée par votre matériel, vos contraintes de confidentialité et le fait qu'un téléchargement de 70 Go soit acceptable ou non — et le nombre de paramètres actifs, quelle que soit la façon dont vous l'arrondissez, ne change rien à aucun de ces trois points.

Qu'est-ce qui le réglerait

Trois choses, par ordre décroissant d’utilité. Un chiffre de paramètres actifs publié par OpenBMB, afin que le nombre que tout le monde répète cesse d’être l’arithmétique d’un tiers — y compris la mienne, et la mienne est reproductible à partir des en-têtes de shard si vous n’êtes pas d’accord avec elle. Une mesure indépendante des 13 tokens par seconde sur un téléphone, avec les paramètres de quantification indiqués, car un chiffre dépendant de l’ordonnancement sans ses paramètres n’est pas une spécification. Et une véritable évaluation comparant MiniCPM-V 4.7 35B-A3B à Qwen3.8-27B sur les mêmes tâches, puisque la comparaison qui a rendu ce modèle remarquable est actuellement le graphique d’un fournisseur face à la fiche d’un autre fournisseur.

En attendant, le résumé prudent est plus restrictif que l’article : les poids sont réels, la parcimonie est réelle, le téléchargement fait 70,43 Go, et par token le modèle effectue un travail équivalent à entre 2,4 et 4 milliards de paramètres, selon la façon dont on compte les parties que l’on ne peut pas contourner. C’est un véritable résultat d’ingénierie. Ce n’est pas encore un benchmark mesuré sur téléphone, et ce n’est pas une victoire de benchmark face à un 27B dense.

Sources : les paramètres, le nombre d'experts, les types de couches, la longueur de contexte et la taille du téléchargement ont été lus directement dans config.json et les en-têtes des fragments safetensors de openbmb/MiniCPM-V-4.7-35B-A3B le 13 octobre 2026. La vitesse sur l'appareil, l'empreinte mémoire, les résultats de benchmark et les chiffres d'évaluation de Qwen3.8-27B sont déclarés par le fournisseur et non reproduits. Les affirmations « 3B de paramètres actifs » et « plus intelligent qu'Opus 4.6 » proviennent d'une publication sur les réseaux sociaux d'un tiers, et non de l'un ou l'autre des fournisseurs.

Rien de tout cela n'est hypothétique : les défaillances documentées de l'IA et les incidents liés aux agents dans lesquels un chiffre comme celui-ci est cité sont recensés dans the 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.