MiniCPM-V 4.7 35B-A3B vs PixelUMM : une licence décide de cela avant même que les benchmarks ne le fassent

Il y a une décision que vous pouvez prendre entre MiniCPM-V 4.7 35B-A3B et PixelUMM sans lire le moindre benchmark, et c'est probablement la décision qui compte le plus. MiniCPM-V 4.7 35B-A3B est sous Apache-2.0. Le checkpoint de modèle de PixelUMM ne l'est pas — il est distribué sous la licence One-Way Noncommercial de NVIDIA, qui n'autorise que la recherche et l'évaluation, sur un checkpoint dont NVIDIA affirme lui-même qu'il « n'a pas été validé pour la production ou les usages à enjeux élevés ». Si vous construisez quelque chose que vous avez l'intention de vendre, l'un de ces deux modèles est à écarter d'emblée et le reste de la comparaison est académique. Si vous faites de la recherche, le champ s'ouvre, et la question intéressante devient de savoir contre quoi la conception sans encodeur de NVIDIA parie réellement — car elle parie exactement contre l'architecture qu'utilise MiniCPM-V 4.7.

Les deux modèles sont sortis discrètement. Les poids de PixelUMM ont été publiés sur Hugging Face à 21 h 40 UTC le 1er octobre 2026, sans article de blog, sans communiqué de presse et sans keynote ; l’URL de la page du projet affiche encore « preview ». MiniCPM-V 4.7 est apparu le 6 octobre de la même manière, et OpenBMB ne lui a ajouté une fiche de modèle, une licence ou une section de revendications que le 12 octobre. Aucun des deux n’a été évalué de manière indépendante par qui que ce soit, et aucun ne dispose d’un tableau de benchmarks qu’un lecteur peut citer — la fiche de PixelUMM ne rapporte aucun score, et les affirmations de performance de MiniCPM-V 4.7 figurent dans des images de graphiques plutôt que dans du texte. Ce qui suit distingue ce que les dépôts déclarent de ce que personne en dehors des deux laboratoires n’a encore confirmé.

Ce qu’est PixelUMM, en un paragraphe

PixelUMM est un Transformer décodeur uniquement de 15 199 672 064 paramètres avec une tête de génération de pixels itérative, construit sur une base Qwen3-8B épinglée à une révision spécifique. Sa thèse est énoncée dans la première ligne de la fiche du modèle et elle est véritablement à contre-courant : pas de VAE et pas d'encodeur visuel. Là où un modèle unifié conventionnel comporte deux interfaces visuelles — un transformer visuel produisant des caractéristiques sémantiques pour la compréhension et un autoencodeur variationnel produisant des latents de reconstruction pour la génération — PixelUMM n'en comporte aucune. Les images sont découpées en patchs de 16 par 16 pixels, la vidéo en tubelets spatio-temporels de quatre images, et les deux atteignent la base par rien de plus que des projections linéaires à une seule couche, le débruitage itératif effectuant le travail de génération. L'article le décrit comme un Mixture-of-Transformers associant une attention partagée à des paramètres spécifiques à la tâche. Il gère le texte-vers-image, la génération de texte conditionnée par l'image, la compréhension conditionnée par la vidéo et la génération vidéo, y compris le texte-vers-vidéo à 96 images, 24 ips et quatre secondes.

La piste autour de lui a duré environ quatre semaines, tout cela sans bruit. Le dépôt GitHub nv-tlabs/PixelUMM a été créé le 4 septembre 2026 sous Apache-2.0 et est resté avec un seul commit pendant la majeure partie du mois. Les 28 et 29 septembre, le commit initial est arrivé et arXiv a attribué la prépublication 2609.38597, dont la liste d'auteurs s'étend sur NVIDIA et l'Université de Waterloo. Le dépôt du modèle lui-même est apparu à 21 h 40 UTC le 1er octobre, huit minutes après un dernier commit GitHub ajoutant la citation de l'article. L'article ne comporte aucune mention de lieu — pas de conférence, pas de « accepté à » — ce qui se lit comme une équipe de recherche mettant un artefact en ligne plutôt qu'un lancement de produit, bien qu'il s'agisse d'une observation sur les preuves et non d'une affirmation sur l'intention.

Ce qu'est MiniCPM-V 4.7 35B-A3B

MiniCPM-V 4.7 35B-A3B est la première entrée MoE d'OpenBMB dans la série MiniCPM-V : 256 experts avec 8 actifs par token, 40 couches, une fenêtre de contexte de 262 144 tokens et un vocabulaire de 248 144 tokens, soit environ 3 milliards de paramètres actifs sur 35,2 milliards au total. La vision passe par un module SigLIP2 avec compression précoce intra-ViT LLaVA-UHD v4 et un mode de compression de tokens visuels mixte 4x/16x sélectionnable — 16x par défaut pour le débit, 4x lorsque les détails fins comptent. Il comprend les images uniques, les images multiples et la vidéo, et il répond en texte. Il ne génère pas d'images.

L'affirmation phare de la fiche est qu'il s'agit du premier modèle MoE open source doté d'une inférence sur appareil sans perte et fluide, rendue possible par le Lookahead Expert Scheduling, une quantification fine couche par couche et un échantillonnage spéculatif via les brouillons DSpark séparés, à une vitesse annoncée de plus de 13 jetons par seconde sur un iPhone 17 Pro Max. Ce chiffre est déclaré par le fournisseur, non reproduit et sans réserves. La fiche affirme également un score global en mode Instruct supérieur à celui de Qwen3.6 35B-A3B avec un temps d'inférence moindre — une affirmation qui figure à l'intérieur d'une image de graphique, ce qui signifie qu'il ne s'agit pas d'un chiffre citable et qu'il ne doit pas être traité comme tel.

Là où MiniCPM-V 4.7 est indiscutablement en avance, ce n’est sur aucun tableau de scores, mais dans la distribution qui l’accompagne, dont l’ensemble est bien réel et téléchargeable : des poids base, FP8, int4, AWQ, GPTQ et GGUF ; une prise en charge par SGLang, vLLM, llama.cpp, Ollama et OpenVINO ; des applications iOS, Android et HarmonyOS ; et Rockchip, Houmo, Intel, AMD et Arm référencés pour un support silicium dès le jour zéro. Il y a six semaines, la critique honnête que l’on pouvait faire de ce modèle était qu’il s’agissait d’un checkpoint non documenté. Ce n’est plus le cas — c’est un checkpoint documenté, mais sans benchmarks. Un problème différent, plus petit.

L'argument architectural qui se cache derrière la comparaison

Les deux modèles sont en désaccord sur un point fondamental, et il vaut la peine de le nommer, car c'est l'aspect de cette confrontation dont la durée de vie dépasse celle de l'un comme de l'autre modèle.

• Comment la vision atteint le modèle de langage — PixelUMM utilise des pixels bruts et une unique projection linéaire, sans aucun encodeur visuel pré-entraîné nulle part dans la pile ; MiniCPM-V 4.7 utilise un encodeur SigLIP2 avec compression précoce intra-ViT et un taux de sous-échantillonnage configurable.

• Comment fonctionne la génération — PixelUMM prédit les pixels de façon itérative au moyen d'une tête de flow matching entraînée conjointement à la prédiction de texte autorégressive ; MiniCPM-V 4.7 génère du texte, et rien d'autre.

• Ce que cela permet d’obtenir — PixelUMM obtient un seul ensemble de poids qui à la fois décrit une image et en produit une, au prix d’une licence réservée à la recherche et de l’absence de validation en production ; MiniCPM-V 4.7 obtient un petit modèle quantifiable et déployable sur téléphone, capable de lire le monde mais pas de le redessiner.

• Nombre de paramètres — 15,2 B de paramètres plutôt denses contre 35,2 B au total, avec 3 B actifs. C’est le nombre de paramètres actifs qui prédit le coût d’inférence, et sur cet axe, le modèle MiniCPM est le plus petit des deux d’un ordre de grandeur.

• Poids sur disque — le dépôt de PixelUMM contient 491 fichiers répartis sur quatre variantes de checkpoints ; la version de base de MiniCPM-V 4.7 se compose de seize fragments BF16 d'environ 70 Go.

• Licence — Apache-2.0 par rapport à NVIDIA One-Way Noncommercial pour le checkpoint, Apache-2.0 ne s’appliquant qu’au code source de PixelUMM et la base Qwen3-8B étant séparément sous Apache-2.0. La fiche PixelUMM indique également qu’elle inclut du code modifié dérivé de BAGEL, de sorte que les conditions en amont s’appliquent en sus.

• Évaluation publique — aucune, des deux côtés. MiniCPM-V 4.7 formule au moins des revendications de performance ; la fiche de PixelUMM n'indique absolument aucun chiffre de benchmark.

Lequel peut-on réellement mettre devant un utilisateur ?

Suivez à la fois la licence et le scénario de déploiement, et le choix se fait en grande partie de lui-même.

PixelUMM est l'artefact de recherche le plus intéressant et le produit le moins utilisable. Un checkpoint non commercial bloque d'emblée les usages commerciaux évidents, il n'y a aucune recette de déploiement sur la fiche, aucune version quantifiée, aucun chiffre de longueur de contexte, et 83 likes contre zéro téléchargement enregistré signifie que pratiquement personne en dehors des auteurs ne l'a exécuté. Sa valeur, à l'heure actuelle, réside dans le fait qu'il constitue un argument solide et publié selon lequel les encodeurs visuels pourraient être inutiles dans les modèles unifiés. Cet argument vaut la peine d'être suivi, que vous chargiez ou non un jour les poids.

MiniCPM-V 4.7 est celui qui dispose d’un chemin vers la production, et ce chemin est étroit mais réel. Apache-2.0 élimine la question de la licence. Six formats de quantification et cinq environnements d’exécution d’inférence signifient que vous n’avez pas à écrire de noyaux personnalisés. Deux GPU ou plus pour la version non quantifiée constituent l’obstacle ; les versions quantifiées et le scénario sur appareil sont la solution de contournement, et l’affirmation sur appareil est précisément celle qui n’a pas été vérifiée de manière indépendante. Considérez-le comme un modèle que vous pouvez exécuter dès aujourd’hui et comme une affirmation de performance sur laquelle vous ne pouvez pas encore compter.

Pour les équipes dont la réponse est « ni l’un ni l’autre, nous appellerons quelque chose », l’équivalent hébergé le plus proche de la configuration MiniCPM est Qwen3.6 35B A3B — mêmes 35B au total, mêmes 3B actifs, même contexte de 262K, même entrée texte-image-vidéo — et il est servi via OrcaRouter au prix catalogue du fournisseur, sans marge, 0,25 $ par million de jetons d’entrée et 1,48 $ par million de jetons de sortie, avec basculement automatique si une route de fournisseur se dégrade. Ce n’est pas un substitut à l’un ou l’autre des modèles de cet article ; c’est le groupe témoin qui vous dit ce que vous apporte réellement l’auto-hébergement d’un MoE multimodal creux de 70 Go.

Où cela atterrit

Retirez l’architecture et il reste deux sorties discrètes qui pointent dans des directions opposées. NVIDIA a publié un artefact de qualité académique sous une licence qui empêche la plupart des gens de l’utiliser, et un dépôt sans recette, sans benchmarks et sans téléchargements. OpenBMB a publié un modèle documenté, sous licence permissive et multi-runtime, avec une affirmation d’efficacité séduisante et aucun tableau d’évaluation pour l’étayer.

La seule chose qui permettrait de trancher pour chacun : pour PixelUMM, n'importe quelle reproduction indépendante, même une seule — 0 téléchargement signifie qu'aucun point de données extérieur n'existe, et la thèse de l'absence d'encodeur est exactement le genre d'affirmation qui tient ou s'effondre au contact d'une seconde implémentation. Pour MiniCPM-V 4.7, un tableau de benchmarks, ou une longueur d'acceptation reproduite sur le draft DSpark, qui est la seule partie de la famille à porter des chiffres publiés. Ni l'un ni l'autre n'existe encore. Tous deux sont la raison pour laquelle ces deux modèles méritent encore d'être surveillés plutôt que rangés dans un tiroir — ils en sont à un stade plus précoce de leur vie publique que ne le suggère la couverture, et aucun n'a été qualifié de lancement par le laboratoire qui l'a créé.