MiniCPM-V 4.7 obtient une fiche de modèle : OpenBMB publie les benchmarks, la licence et la promesse d'exécution sur appareil

Pendant les six premiers jours de son existence, MiniCPM-V 4.7 était un dossier de 70 Go de tenseurs bfloat16 sans README — pas de fiche de modèle, pas d'étiquette de licence, pas de tableau de benchmarks, rien qui indiquait à quoi il servait. Cela a changé le 12 octobre 2026, lorsque OpenBMB a déposé une fiche de modèle complète dans openbmb/MiniCPM-V-4.7-35B-A3B, a déclaré une licence Apache-2.0, réécrit le README du dépôt MiniCPM-o pour mettre en avant la nouvelle série, et l'a annoncé comme une version MLLM open source destinée aux appareils iOS, Android et HarmonyOS. La même passe de documentation a touché le frère 1B, qui porte désormais la structure de fiche identique. Cet article porte sur le delta — ce que la fiche affirme réellement, lesquelles de ces affirmations vous pouvez vérifier vous-même, et lesquelles n'existent aujourd'hui que sous forme de pixels dans un PNG fourni par l'éditeur.

Qu'est-ce qui est arrivé le 12 octobre, et qu'est-ce qui était déjà là ?

Les poids n'ont pas bougé. openbmb/MiniCPM-V-4.7-1B a été créé le 6 octobre 2026 à 17:40 UTC et openbmb/MiniCPM-V-4.7-35B-A3B le 7 octobre à 07:07 UTC ; les deux affichent toujours un horodatage de dernière modification au 12 octobre, car cette dernière journée a été consacrée à la prose, pas aux paramètres. Le journal des commits du dépôt 35B pour le 12 octobre est un sprint de documentation : ajout de la fiche du modèle à 16:08, mise à jour de la fiche du modèle à 16:15, renommage de 35BA3B à 16:23, ajout de métadonnées à 16:26, URL absolues des ressources à 16:50, quatre commits « ajout de la prise en main » jusqu'à 17:07, et lien vers la doc LES à 17:09. Tout ce qui se trouve sous cette ligne dans l'historique est l'initialisation Le dépôt est passé de dix-huit fichiers et aucune fiche à une version documentée avec des images, des graphiques d'évaluation, des instructions de déploiement et une licence, en l'espace d'environ une heure.

Cela compte pour la façon dont vous lisez l’annonce, car un article de lancement n’est pas la même chose qu’un lancement. Rien n’a changé concernant le checkpoint le 12 octobre. Ce qui a changé, c’est que MiniCPM-V 4.7 a cessé d’être un téléversement inexpliqué pour devenir un produit que vous pouvez évaluer sur le papier.

Les deux variantes, et pourquoi elles ne constituent pas la même version

L'annonce décrit deux modèles, et ils sont architecturalement sans lien sous la tour de vision — l'un est un mélange d'experts clairsemé, l'autre un petit modèle dense.

• MiniCPM-V 4.7 35B-A3B — 35,2 milliards de paramètres au total sous forme de MoE clairsemé, 256 experts avec 8 actifs par token, 40 couches de texte, taille cachée 2,048, 16 têtes de requête contre 2 têtes clé/valeur, position maximale de 262,144 tokens, vocabulaire de 248,144.

• MiniCPM-V 4.7 1B — un squelette dense qwen3_5_text, 24 couches à une taille cachée de 1 024, 8 têtes de requête contre 2 têtes clé/valeur, le même contexte de 262 144 tokens, vocabulaire de 248 094, un seul fichier safetensors de 3,1 Go.

• Tour de vision partagée — minicpmv4_7_vision, 27 couches à une taille cachée de 1 152, une taille de patch de 14, une taille d’image de 980, insérée à la couche 6 de la pile de texte.

• Compression — sous-échantillonnage mixte des tokens visuels en 4x et 16x, avec la technique de compression précoce intra-ViT qu'OpenBMB attribue à LLaVA-UHD v4 ; la valeur par défaut est 16x, et 4x est le réglage offrant les détails les plus fins.

• Forme de l’attention — un motif répétitif de trois pour un dans les deux variantes : trois linear_attention couches, chacune suivie d’une full_attention couche, dix fois sur les 40 couches de texte du modèle 35B.

• Licence — Apache-2.0 pour les deux, déclarée dans l’en-tête de la fiche, ce qui est la première fois que l’un ou l’autre des dépôts énonce des conditions, tout court.

Le 35B-A3B est celui que l’annonce met en avant, et c’est celui qui porte l’histoire d’ingénierie intéressante : tout l’argument est qu’un MoE parcimonieux avec 35 milliards de paramètres stockés peut être rendu suffisamment fluide pour tourner sur un téléphone.

La revendication d'un traitement sur l'appareil constitue la véritable nouveauté, et c'est un problème d'ordonnancement.

Quiconque a déjà essayé de faire tourner un MoE sur un téléphone connaît le mode de défaillance. Le nombre total de paramètres réside dans le stockage, seule une poignée s’active par token, et sur un appareil dépourvu de la RAM ou de la bande passante nécessaires pour contenir tous les experts, les poids sont paginés en entrée et en sortie. Le décodage qui en résulte se fait à une vitesse qui rend toute conversation impossible. Le contournement évident — verrouiller le routeur sur un sous-ensemble fixe d’experts pour toute l’invite — le rend rapide tout en amputant discrètement ses capacités, car les tokens ne peuvent plus atteindre les experts que le modèle aurait autrement choisis.

La réponse d'OpenBMB consiste en trois techniques superposées, et la fiche est étonnamment précise sur ce que fait chacune d'elles :

• Lookahead Expert Scheduling (LES) — un prédicteur de routage inter-couches précharge les experts susceptibles d’être nécessaires à la couche suivante, en donnant la priorité, parmi les experts, à ceux que le routeur réel a effectivement sélectionnés, et en chevauchant leur calcul avec le chargement de tout ce qui est encore requis. La carte prend soin de préciser que la prédiction ne pilote que le préchargement et l’ordonnancement ; le calcul suit toujours le routage au niveau des tokens propre au modèle, et les experts manqués par la prédiction sont chargés et évalués normalement.

• Quantification à grain fin, couche par couche — réduit l'empreinte des poids des experts et le trafic mémoire afin que le schéma de chargement tienne dans la mémoire et la bande passante de l'appareil.

• Échantillonnage spéculatif DSpark — intègre le chemin du modèle de brouillon dans la boucle d’inférence de l’appareil, aux côtés de l’ordonnancement et de la quantification.

Le chiffre phare est de 13+ tokens par seconde sur un iPhone 17 Pro Max pour le 35B-A3B. Il s'agit d'une mesure du fournisseur, sur un appareil que nous n'avons pas vu, à l'aide d'une application que nous n'avons pas exécutée, et c'est le seul chiffre de cette publication qui mérite le plus d'être pris avec prudence jusqu'à ce que quelqu'un extérieur au laboratoire le reproduise. C'est aussi l'affirmation sur laquelle repose tout le cadrage « premier MoE open source à s'exécuter de manière fluide sur l'appareil sans compromettre les performances » — une affirmation difficile à falsifier par définition, car « sans compromettre les performances » se mesure à l'aune d'une référence choisie par le fournisseur.

La partie de la carte qui constitue véritablement une information nouvelle : la liste des écosystèmes

Avant le 12 octobre, il n’existait absolument aucune recette de serving publiée. La fiche nomme désormais les frameworks avec lesquels le modèle est censé fonctionner, et la liste est assez large pour être utile, quel que soit le résultat des benchmarks :

• Inférence — SGLang, vLLM, llama.cpp et Ollama, avec un transformers serve chemin pour un point de terminaison local compatible OpenAI et un chemin OpenVINO pour les CPU, GPU et NPU Intel.

• Fine-tuning — SWIFT et LLaMA-Factory, ainsi qu'une recette d'entraînement qu'OpenBMB appelle Self-Replay Fine-Tuning, présentée comme un moyen peu coûteux d'étendre les capacités tout en limitant l'oubli.

• Quantification — GGUF, BNB, AWQ, GPTQ et FP8, avec des dépôts distincts publiés pour les variantes AWQ, GPTQ, int4, FP8 et GGUF du modèle 35B.

• Matériel — prise en charge day-0 annoncée pour les plateformes de puces Rockchip, Houmo, Intel, AMD et Arm, ainsi que pour le déploiement sur iOS, Android et HarmonyOS.

• Outillage — un recueil de recettes avec des guides de tâches pour le dialogue à image unique, le dialogue multi-images, la vidéo, l’OCR, l’analyse de PDF et l’ancrage visuel, ainsi qu’un dépôt de déploiement en périphérie contenant les applications mobiles.

• Décodage spéculatif — des checkpoints de draft DSpark distincts pour les cibles 35B et 1B.

L’effet pratique est que MiniCPM-V 4.7 est passé de « il vous faudrait écrire le loader vous-même » à « il existe un chemin documenté dans au moins quatre stacks de serving ». Si vous attendiez la carte avant de consacrer du temps à un essai local, l’attente est terminée ; si vous attendiez des preuves indépendantes que les chiffres sur l’appareil sont réels, elle ne l’est pas.

Ce que les benchmarks établissent et n'établissent pas

La section d’évaluation de la fiche est honnête sur ce qu’elle est : des données rapportées par le fournisseur, non reproduites indépendamment. Deux affirmations comparatives sont formulées explicitement, et toutes deux sont présentées comme des comparaisons plutôt que comme des scores absolus. En mode Instruct, le 35B-A3B est annoncé comme atteignant un score global plus élevé en moins de temps d’inférence que le Qwen3.6 35B-A3B — une affirmation de performance par rapport à la latence, et non une affirmation de qualité brute. La variante 1B est annoncée comme améliorant les capacités fondamentales de MiniCPM-V 4.6 et surpassant nettement le Qwen3.5 0.8B à la fois sur le score global et sur l’efficacité d’inférence.

Voici l’élément qui mérite d’être signalé. Les chiffres réels ne figurent pas dans le texte. La section d’évaluation se compose de cinq images liées — un graphique de performance globale pour les tâches vision-langage du modèle 35B, un graphique linguistique, le graphique du 1B, une courbe de frontière performance-efficacité et un GIF de comparaison de vitesse sur appareil — et le texte qui les entoure porte le récit, pas les chiffres. Il n’y a pas de tableau par benchmark dans le README, donc il n’y a pas de score lisible par machine à citer, et par conséquent rien pour que cet article cite un chiffre. « Un score global plus élevé que Qwen3.6 35B-A3B » est aussi précis que le dossier public le permet actuellement.

Deux conséquences en découlent. Premièrement, MiniCPM-V 4.7 n’a aucune entrée sur les classements tiers neutres vers lesquels nous nous tournerions normalement pour une comparaison auditée — pas d’indice de raisonnement, pas d’indice agentique, pas de score multimodal évalué de manière indépendante. Deuxièmement, l’agrégat qu’OpenBMB trace est le composite propre du fournisseur à travers les groupes de benchmarks qu’il a sélectionnés, ce qui signifie que l’affirmation d’un « score global plus élevé » n’a de sens que dans la mesure de la pondération qui la sous-tend, et cette pondération n’est pas publiée non plus. Rien de tout cela ne rend les chiffres faux. Cela les rend non audités, ce qui est une autre chose, et la distinction importe le plus précisément là où les chiffres sont les plus forts.

Ce que vous pouvez vérifier vous-même, aujourd’hui

Enlevez le marketing, et il reste un noyau solide et vérifiable, entièrement lisible depuis le dépôt sans avoir à faire confiance à personne :

• Octets de poids — seize fragments safetensors sur le modèle 35B totalisant 70 425 903 448 octets, ce qui correspond à un checkpoint BF16 de 35,2B ; le modèle 1B est un fichier unique de 3,1 Go.

• Architecture — chaque chiffre structurel ci-dessus se trouve dans config.json, publié ouvertement, et correspond à la prose de la carte.

• Licence — Apache-2.0, déclarée dans l'en-tête de la fiche et désormais sans ambiguïté. Pour un usage commercial, c'est la ligne la plus importante de cette version, et elle est nouvelle.

• Variantes quantifiées — Les dépôts AWQ, GPTQ, int4, FP8 et GGUF existent et sont téléchargeables, donc le scénario de déploiement n'a rien de théorique au niveau des poids.

• Signaux d'adoption — le dépôt 35B affiche environ 166 téléchargements et 38 mentions J'aime au 13 octobre, en progression par rapport aux chiffres proches de zéro qu'il affichait lorsqu'il s'agissait d'un envoi inexpliqué, mais cela reste un petit nombre pour une publication revendiquant la frontière de Pareto.

Ce que vous ne pouvez pas vérifier, c’est l’affirmation qui porte cette publication : qu’il s’agit du premier MoE open source qui tourne sur un téléphone sans rien sacrifier, à plus de 13 tokens par seconde. Cela dépend d’un tiers disposant d’un iPhone et d’un chronomètre.

Là où un routeur a sa place, et où il ne l'a pas

MiniCPM-V 4.7 n'est pas servi par OrcaRouter. C'est un checkpoint à poids ouverts, ce qui signifie que le modèle lui-même est quelque chose que vous hébergez — sur une station de travail, sur une machine GPU, ou sur le téléphone auquel la fiche s'adresse. Là où une couche de routage justifie son existence, c'est de l'autre côté de cet arrangement : le point où un modèle de vision auto-hébergé décide qu'il est dépassé et confie l'image difficile à quelque chose de plus grand. OrcaRouter place plus de 200 modèles hébergés derrière une seule clé, rétrocède le prix catalogue de chaque fournisseur à 0 % de marge afin qu'un changement de prix d'un fournisseur soit effectif le jour même, et bascule automatiquement en cas de dégradation d'un fournisseur — ce qui correspond à la configuration hybride recherchée, avec le modèle local bon marché qui fait le travail de routine et un modèle hébergé qui absorbe les cas qu'il ne peut pas prendre en charge.

Que regarder ensuite

Trois choses feraient passer cette version du statut d’affirmation documentée à celui de fait établi. Une mesure indépendante sur l’appareil du modèle 35B — quelqu’un disposant d’un iPhone 17 Pro Max, de l’application publiée et de son propre chronométrage — établirait le chiffre sur lequel repose tout le discours. Un tableau par benchmark avec les scores réels, plutôt que des graphiques, permettrait de vérifier l’affirmation de Pareto par rapport à la référence qu’elle nomme. Et une exécution sur un classement neutre placerait MiniCPM-V 4.7 aux côtés de modèles évalués dans des conditions qu’il n’a pas choisies. D’ici là, le résumé honnête est qu’OpenBMB a livré un vrai modèle, Apache-2.0, bien documenté, avec un argumentaire d’efficacité crédible et non prouvé, et que la différence entre ces deux choses est exactement la différence entre une carte et un benchmark.