MiniCPM-V 4.7 : OpenBMB a mis en ligne un modèle vision-langage 35B-A3B sans fiche de modèle, sans licence et sans benchmarks

MiniCPM-V 4.7 est apparu sur Hugging Face le soir du 6 octobre 2026 sous la forme du dépôt openbmb/MiniCPM-V-4.7-35B-A3B — et c’est l’une des choses les plus étranges que la série MiniCPM ait jamais livrées, car presque rien n’a été livré avec lui. Il n’y a pas de fiche modèle. Il n’y a pas de README. Il n’y a pas de licence déclarée. Il n’y a pas de tableaux de benchmarks, pas d’article de lancement, pas de rapport technique, et aucune entrée dans la documentation GitHub d’OpenBMB, qui, cette semaine encore, qualifie MiniCPM-V 4.6 de « le modèle le plus récent et le plus efficace de la série MiniCPM-V ». Ce qui existe, ce sont 16 shards de poids bfloat16, 70,4 Go, décrivant un modèle vision-langage à mélange d’experts de 35,2 milliards de paramètres avec une fenêtre de contexte de 256K et une conception d’attention hybride inhabituellement agressive. Cela suffit pour dire ce que le modèle est. Cela ne suffit pas encore pour dire ce en quoi il est bon, et cet article garde ces deux choses strictement séparées.

Ce qui a réellement été livré, octet pour octet

Le dépôt a été créé le 6 octobre 2026 à 18:36 UTC et son dernier commit a eu lieu douze minutes plus tard, à 18:48 UTC. Entre-temps, l'uploadeur a poussé les fichiers de poids et la configuration dont un loader Transformers a besoin, puis s'est arrêté. La liste complète des fichiers comporte dix-huit entrées :

• Poids — seize fragments safetensors nommés model-00001-of-00016 à model-00016-of-00016, avec le fichier d'index model.safetensors.index.json indiquant une taille totale des tenseurs de 70 425 751 648 octets.

• Nombre de paramètres — l’API Hugging Face lit 35 212 875 824 paramètres, tous en BF16. Notez qu’il s’agit du total de paramètres, ce qui, pour un MoE épars, n’est pas le nombre de paramètres actifs pour un token donné.

• Configuration — config.json (2 984 octets), generation_config.json (186 octets), preprocessor_config.json, processor_config.json.

• Tokeniseur — tokenizer.json (20 Mo), tokenizer_config.json et chat_template.jinja (7 250 octets).

• Manquant — README.md. Une requête directe sur le fichier brut renvoie HTTP 404. Sur Hugging Face, un README manquant signifie qu'il n'y a pas de fiche de modèle, ce qui signifie qu'il n'y a pas de champ de licence, ce qui signifie que le dépôt ne porte aucune balise license: du tout.

Le dépôt a trois likes, zéro téléchargement et un onglet de discussion vide. Un téléversement communautaire d'un checkpoint de 70 Go attire généralement des commentaires en quelques heures — des questions sur les quantifications, sur le serving, sur ce qu'est la licence. Celui-ci ne l'a pas fait, ce qui est cohérent avec le fait qu'il ait été repéré par une poignée de personnes surveillant l'openbmb organisation plutôt qu'annoncé à qui que ce soit.

L'architecture, lue à même config.json

Comme il n'y a pas de fiche à paraphraser, le fichier de configuration est la source principale, et il est particulièrement instructif. La classe est MiniCPMV4_7ForConditionalGeneration, le type de modèle est minicpmv4_7, et il a été enregistré par Transformers 5.2.0 — tout cela indique qu'il s'agit d'un checkpoint officiel OpenBMB dans la lignée principale MiniCPM-V, et non d'un fine-tuning communautaire qui se pare de ce nom.

• Colonne vertébrale linguistique — model_type: qwen3_5_moe_text. Un MoE clairsemé dérivé de Qwen3.5, la première fois que la gamme MiniCPM-V utilise une pile de texte Qwen-MoE plutôt que les petites variantes Qwen denses qui animaient MiniCPM-V 4.5 et 4.6.

• Parcimonie — 256 experts, 8 sélectionnés par token, avec une taille intermédiaire d’expert de 512 et un expert partagé de même taille. Un checkpoint total de 35B sur un schéma de routage 8 sur 256 n’active qu’une petite fraction de celui-ci à chaque passe avant, ce qui est tout l’intérêt du nom A3B : les poids sont volumineux, le calcul ne l’est pas.

• Profondeur et largeur — 40 couches cachées, taille cachée 2048, 16 têtes d’attention avec 2 têtes clé/valeur et une dimension de tête de 256.

• Attention hybride — le tableau layer_types compte 40 entrées et enchaîne trois linear_attention couches pour une couche full_attention à intervalle fixe de 4. Dix des quarante couches effectuent une attention conventionnelle ; les trente autres utilisent un chemin linéaire de type Mamba avec un noyau de convolution de 4. C'est le choix de conception le plus lourd de conséquences du fichier, et c'est la même direction que celle prise par l'ensemble du domaine jusqu'en 2026.

• Encodage positionnel — RoPE avec un thêta de 10 000 000 et partial_rotary_factor: 0.25, ce qui signifie que seulement un quart des dimensions de chaque tête est soumis à rotation. Le RoPE multimodal est activé avec mrope_interleaved: true, une répartition des sections de [11, 11, 10], et mrope_mode: canvas.

• Contexte — max_position_embeddings: 262144, et le model_max_length du tokenizer concorde. 256K tokens.

• Prédiction multi-token — mtp_num_hidden_layers: 1, une seule tête de décodage spéculatif, la même astuce que portait MiniCPM-V 4.6.

• Tour de vision — minicpmv4_7_vision, taille cachée 1152, 27 couches, activations GELU-tanh, taille de patch 14 avec un image_size de 980, et un insert_layer_id de 6, où les embeddings visuels sont intégrés à la pile linguistique. La forme de la tour est proche de celle de MiniCPM-V 4.6, donc le côté vision est une évolution plutôt qu'une reconstruction.

• Compression de la vision — downsample_mode : « 16x » et max_slice_nums : 9 dans le processeur d'images. MiniCPM-V 4.6 a introduit un schéma de compression de tokens 4x/16x commutable ; la configuration 4.7 annonce le réglage 16x comme valeur par défaut, le découpeur autorisant jusqu'à neuf sous-images pour les entrées haute résolution.

• Vocabulaire — 248 144 tokens, avec <|image_pad|> à l'id 248 056 et <|video_pad|> à 248 057. La vidéo est une entrée de premier ordre, exactement comme elle l'est depuis MiniCPM-V 4.5.

• Un curieux vestige — la configuration du tokenizer déclare encore <|audio_start|>, <|audio_end|> et <|audio_pad|>. Cela signifie presque certainement que le vocabulaire est partagé avec la branche omni MiniCPM-o, et non que MiniCPM-V 4.7 parle audio. L'interpréter comme une fonctionnalité audio serait une erreur que la configuration seule ne peut pas écarter.

Ce que la famille nous dit que ce dépôt ne nous dit pas

La génération 4.6 constitue le point de référence, et tout l’intérêt réside dans le contraste. MiniCPM-V 4.6 a été publié le 11 mai 2026 en tant que modèle de 1,3 milliard de paramètres, construit sur un encodeur visuel SigLIP2-400M et un modèle de langage Qwen3.5-0.8B, sous licence Apache-2.0, avec un discours explicite : il obtient un score de 13 à l’Artificial Analysis Intelligence Index — un chiffre rapporté par le fournisseur — tout en utilisant nettement moins de tokens que des petits modèles comparables, et il fonctionne sur iOS, Android et HarmonyOS, avec le code d’adaptation edge publié en open source. Toute son identité était « petit, efficace, embarqué ».

MiniCPM-V 4.7, c'est 1,3B multiplié par environ 27. Le nom 35B-A3B le place dans la catégorie des modèles phares à activation éparse, et non dans celle des téléphones. Que OpenBMB le destine à être un compagnon côté serveur de la gamme edge, un enseignant pour un futur petit modèle, ou un test de plafond de capacités n'est indiqué nulle part, et le dépôt ne contient aucun indice dans un sens ou dans l'autre.

Ce qui est véritablement nouveau, et qu’il vaut la peine de signaler à quiconque suit la série, c’est le backbone Qwen-MoE, ainsi que le ratio de 3:1 entre attention linéaire et attention complète. Ces deux éléments marquent une rupture. Tout ce qu’OpenBMB publie sur cette famille est encore rédigé autour de la version 4.6, si bien que ce checkpoint est en avance sur sa propre documentation.

Ce qui n'est pas encore connaissable — et pourquoi cette liste importe

Il vaut la peine d’être direct sur la taille du trou ici, car avec un checkpoint de 70 Go, la tentation est de le combler par une inférence plausible.

• Pas de licence. Ce n'est pas une formalité. MiniCPM-V 4.6 est sous Apache-2.0, et la communauté en est venue à s'attendre à cela de cette gamme. Un dépôt sans licence : tag est, par défaut, tous droits réservés dans la plupart des juridictions — vous ne pouvez pas construire dessus en toute sécurité tant que le tag n'apparaît pas. Ce seul fichier manquant est l'absence la plus lourde de conséquences du dépôt.

• Aucun benchmark, qu'il soit rapporté par le fournisseur ou non. Il n'y a pas un seul chiffre dont on puisse débattre. Quiconque cite aujourd'hui un score MMMU ou OCRBench pour MiniCPM-V 4.7 cite quelque chose qui n'existe pas dans la source.

• Aucune évaluation indépendante. Artificial Analysis et les outils de suivi similaires indexent les modèles par leur nom ; un checkpoint sans fiche ni annonce reste généralement non mesuré pendant un certain temps.

• Aucune recette de service. Que les poids publiés fonctionnent tels quels dans vLLM, SGLang ou llama.cpp n'a été testé par personne en dehors d'OpenBMB. Les chemins de code personnalisés (MiniCPMV4_7ForConditionalGeneration, MiniCPMV4_7Processor, MiniCPMV4_7ImageProcessor, MiniCPMV4_7VideoProcessor) exigent tous trust_remote_code, et la combinaison MoE plus attention linéaire n'est pas une forme pour laquelle chaque moteur d'inférence dispose d'un noyau.

• Aucune quantification. MiniCPM-V 4.6 est arrivé avec des variantes GGUF, AWQ, GPTQ et BNB, et a rejoint la bibliothèque d'Ollama en juin 2026. Aucune n'existe pour 4.7. Pour un modèle 35B, c'est la différence entre un ordinateur portable et un cluster.

• Aucune relation avec 4.6 n’est indiquée. OpenBMB pourrait remplacer la gamme edge, la prolonger ou tester quelque chose d’orthogonal. Le dépôt ne le précise pas, et le README GitHub non plus, qui, dans son commit du 8 septembre 2026, répertorie encore 4.6 comme version actuelle.

Il existe également une interprétation plausible mais non confirmée de la chronologie : l’intervalle de douze minutes entre la création du dépôt et le dernier commit, l’absence d’une carte et l’absence de toute publication sont ce à quoi ressemble un point de contrôle lorsqu’il est préparé pour un lancement plutôt qu’après celui-ci. Il s’agit d’une hypothèse sur l’intention, et non d’un fait concernant l’artefact, et elle doit être traitée comme telle.

Comment vous l’exécuteriez réellement, quand il y a quelque chose à exécuter

Rien ici ne peut encore être cité comme une voie prise en charge, mais la configuration contraint bel et bien les options. Un checkpoint BF16 de 35 milliards de paramètres a besoin d'environ 70 Go de mémoire d'accélérateur avant le cache KV, donc un déploiement amateur sur un seul GPU est exclu tant que les quantifications ne seront pas disponibles. Le contexte de 256K et le ratio d'attention linéaire de 3:1 font que le cache KV croît bien plus lentement qu'un transformer classique de même profondeur, ce qui explique précisément pourquoi cette architecture mérite la complexité — c'est dans le travail multimodal à long contexte que la conception se rentabilise. Quand une carte apparaît, les premières choses à vérifier sont la licence, si une recette officielle vLLM ou SGLang est publiée, et si la valeur par défaut de sous-échantillonnage 16x peut être échangée contre le réglage 4x que 4.6 a exposé.

Pour les équipes qui veulent évaluer un modèle comme celui-ci dès qu’il devient utilisable, le problème pratique ne réside pas dans les poids, mais dans l’infrastructure qui les entoure. Un modèle qui tourne sur votre propre GPU a toujours besoin de tout ce qui l’entoure — un routeur qui place plus de 200 modèles hébergés derrière une seule clé, au prix catalogue de chaque fournisseur, sans marge de notre part ajoutée par-dessus, et qui bascule automatiquement en cas de dégradation d’un fournisseur. C’est à cela que sert OrcaRouter, et il vaut la peine de dire clairement que MiniCPM-V 4.7 lui-même n’est pas un modèle hébergé : c’est un checkpoint à poids ouverts que vous servez vous-même. Le routeur compte ici comme l’autre moitié de l’architecture — le modèle de pointe auquel votre machine 4.7 confie les cas difficiles, accessible via le même client que vous avez déjà écrit.

L'état des lieux, et l'unique fichier à actualiser

MiniCPM-V 4.7 existe. Ses poids sont téléchargeables dès aujourd'hui, leur nombre est exact, et ses choix de conception datant de l'époque de l'entraînement — MoE clairsemé, attention linéaire 3:1, contexte de 256K, compression visuelle 16x — sont tous lisibles dans le fichier de configuration. Ce qui n'existe pas, en revanche, c'est la moindre déclaration d'OpenBMB sur ce que fait le modèle, ce qu'il coûte à exécuter en pratique, ou ce que vous êtes autorisé à en faire. Pour un laboratoire dont le dernier modèle de vision était une version edge de 1,3B sous Apache-2.0 accompagnée d'un tableau comparatif complet, l'écart est déroutant, et la posture raisonnable consiste à surveiller le dépôt plutôt que le discours. Le seul fichier qu'il faut actualiser sans cesse est README.md : dès qu'il apparaîtra, il portera la licence, les benchmarks, et probablement l'explication de ce qu'un MiniCPM-V 35B vient faire dans une série bâtie sur de petits modèles.

D'ici là, le résumé honnête est le plus ennuyeux qui soit. Il s'agit d'un véritable checkpoint issu d'un vrai laboratoire, mis en ligne discrètement, et la question intéressante — vaut-il quelque chose — n'a pas de réponse.

OrcaRouter donne accès à plus de 200 modèles hébergés au moyen d'une seule clé, avec le prix catalogue de chaque fournisseur répercuté directement, sans aucune marge, et un basculement automatique entre fournisseurs. prix catalogue du fournisseur répercuté sans aucune marge MiniCPM-V 4.7 n'en fait pas partie : c'est un checkpoint à poids ouverts que vous hébergez vous-même, et le routeur est ce qui se trouve de l'autre côté de la passation.