PixelUMM et Sana pointent vers la même idée : retirer l'échafaudage des modèles de vision

Deux publications de recherche de NVIDIA ont été dévoilées à quelques jours d'intervalle, et elles partagent une même thèse. PixelUMM est apparu sans tambour ni trompette sur Hugging Face le 1er octobre à 21 h 40 UTC, un checkpoint de 15,2 milliards de paramètres, sans article de blog, sans communiqué de presse, sans diapositive de keynote. Sana, issu de chercheurs de NVIDIA, du MIT et de Tsinghua, est public depuis plus longtemps et adopte l'approche inverse face au même problème d'infrastructure.

PixelUMM : un modèle unifié sans encodeur

Le nom du dépôt dit ce qu'est le projet : nv-tlabs/PixelUMM, décrit dans son propre résumé en une ligne comme « compréhension et génération unifiées d'images et de vidéos sans encodeur ». Il repose sur un backbone Qwen3-8B avec une licence de dépôt Apache-2.0.

La partie « sans encodeur » est la revendication intéressante. La plupart des systèmes d'IA visuelle actuels enchaînent des composants distincts : un encodeur visuel pour transformer une image en tokens qu'un modèle de langage peut lire, un VAE pour compresser les données de pixels dans un espace latent dans lequel un modèle de diffusion peut travailler, et un transformer visuel pour gérer la séquence. PixelUMM a été conçu pour fonctionner sans ces étapes intermédiaires, ce qui explique pourquoi sa propre page de projet affiche encore « preview » alors que les poids sont téléchargeables.

Cet écart entre un artefact qui existe et un fournisseur qui n'a rien dit résume toute l'histoire de cette publication. Il y a un dépôt GitHub, une prépublication arXiv numérotée 2609.38597 datée du 29 septembre avec des auteurs de NVIDIA et de l'Université de Waterloo, et un checkpoint réparti sur 128 fichiers avec un index caché sans lequel les chargeurs refusent de fonctionner. Savoir si NVIDIA considère PixelUMM comme annoncé est une question à laquelle l'entreprise n'a pas répondu.

Le schéma de publication compte pour quiconque suit ce domaine. Des recherches qui arrivaient autrefois avec un article de blog, une page de démo et un cycle de presse coordonné arrivent désormais parfois sous forme de dépôt et d'article. L'artefact est public et citable tandis que la communication du fournisseur reste silencieuse, ce qui permet d'utiliser le modèle et rend impossible de citer un benchmark officiel pour celui-ci. Les équipes qui l'évaluent travaillent à partir d'un article et de leurs propres tests.

Sana : compresser la chaîne de coûts plutôt qu'un seul module

Sana attaque la même couche de la pile depuis l'autre direction. La génération d'images à partir de texte en haute résolution devient coûteuse pour une raison qui a peu à voir avec le nombre de pixels : le nombre de tokens latents entrant dans le transformer de diffusion augmente rapidement avec la résolution. L'auto-attention standard doit mettre en relation chaque token avec tous les autres, si bien que le coût, la mémoire et la latence augmentent ensemble.

Dans la propre comparaison de NVIDIA à 1024 pixels, FLUX-dev embarque 12 milliards de paramètres, tourne à 0,04 échantillon par seconde et prend 23 secondes par image. En poussant vers la 2K ou la 4K, réduire le modèle ou diminuer le nombre d'étapes d'échantillonnage ne résout pas le problème sous-jacent.

Sana compresse toute la chaîne plutôt qu'un seul composant. Un autoencodeur à compression profonde 32x réduit le nombre de tokens latents. L'attention linéaire réduit le coût de chaque couche de transformer. Un solveur efficace et une distillation en quelques étapes réduisent le nombre de passes d'échantillonnage. Le slicing, l'offloading et la quantification en basse précision réduisent la mémoire de déploiement. Les modèles publiés comprennent des versions 0,6B et 1,6B visant jusqu'à la 4K, avec Sana-1.5 allant jusqu'à 4,8B. Dans la comparaison officielle à 1024 pixels, la version 0,6B affiche une latence de 0,9 seconde.

L'approche de compression de chaîne présente une propriété attrayante qu'une correction d'un seul module n'a pas. Parce que chaque étape contribue, une équipe peut appliquer les parties adaptées à son matériel et ignorer le reste. Quelqu'un disposant d'une station de travail et sans expérience de la quantification peut adopter le solveur efficace. Quelqu'un qui déploie à grande échelle peut empiler slicing, offloading et quantification en basse précision pour tenir sur une carte beaucoup plus petite. Les compromis sont documentés par étape plutôt que regroupés dans une décision tout ou rien.

La lignée de Sana montre aussi à quelle vitesse un résultat de recherche devient une surface produit. Le modèle original visait une sortie texte-vers-vidéo en 4K. Le dépôt s'est depuis enrichi de Sana-Sprint, de la génération de vidéos, de ControlNet, de LoRA, de la quantification, d'une intégration ComfyUI et d'un service en ligne. C'est le même parcours que celui suivi par les outils d'image : d'un article à un dépôt, puis à un nœud dans l'interface que les gens utilisent déjà.

Ce que les deux approches ont en commun

Mettez les deux publications côte à côte et la direction est claire. Toutes deux cherchent à supprimer la machinerie intermédiaire qui se trouve entre les pixels et les modèles depuis les débuts du domaine. PixelUMM demande si l'encodeur est nécessaire tout court. Sana demande quelle part de la chaîne de calcul peut être compressée avant que la qualité ne se dégrade.

Le compromis est le même dans les deux cas, et aucun des laboratoires ne le cache. Supprimer un encodeur signifie que le modèle doit apprendre ce que l'encodeur fournissait auparavant, ce qui coûte du calcul d'entraînement et peut coûter de la qualité sur les tâches que l'encodeur gérait bien. Compresser agressivement la chaîne signifie que le plafond de qualité se déplace, et les propres documents de Sana sont prudents quant au matériel et aux conditions de mesure derrière ces chiffres de latence.

La raison pour laquelle les deux laboratoires s'attaquent à cette couche est que les intermédiaires sont devenus la partie coûteuse. Un encodeur visuel et un VAE sont entraînés séparément, réglés séparément et servis séparément. Chacun est un composant qui peut se désynchroniser du reste du pipeline, et chacun ajoute de la latence au début de chaque requête. Les supprimer est une simplification architecturale plutôt qu'une astuce de recherche, et cela porte ses fruits dans chaque déploiement.

Pourquoi cela compte pour quiconque construit avec des images

Pour les praticiens, la conséquence pratique est un seuil matériel plus bas. Le travail de NVIDIA sur Sana s'inscrit dans un schéma plus large cette année : des modèles qui nécessitaient autrefois une carte de centre de données sont retravaillés pour tenir sur du matériel grand public, et la communauté ouverte a commencé à considérer un seuil de 6 Go de VRAM comme une exigence plutôt qu'un bonus.

Il y a une seconde conséquence qui apparaît dans les schémas d'architecture. Lorsque l'encodeur et le VAE cessent d'être des services distincts, un pipeline qui comptait autrefois trois modèles à versionner, surveiller et payer n'en compte plus qu'un. C'est moins visible qu'un chiffre de latence, mais c'est ce qui change la charge de maintenance sur un produit réel.

Pour les équipes qui construisent sur ces modèles, la question pratique est de savoir quelle simplification elles peuvent adopter en premier. L'approche sans encodeur promet une architecture plus propre, mais exige de faire confiance au fait que la gestion des représentations par le modèle corresponde à ce qu'un encodeur spécialisé fournissait. L'approche de compression de chaîne promet des gains mesurables de vitesse et de mémoire dès aujourd'hui tout en gardant l'architecture existante intacte. L'une est un pari sur la direction que prend le domaine ; l'autre est un pari sur le matériel que vous possédez déjà.

Les deux paris sont raisonnables, et les laboratoires qui les poursuivent ne sont pas en concurrence pour le même déploiement. Le cadrage unifié de PixelUMM convient aux équipes qui veulent un seul modèle pour la compréhension et la génération. Sana convient aux équipes qui ont besoin d'une sortie haute résolution sur du matériel contraint. Le chevauchement est la partie de la pile que les deux cherchent à supprimer.

NVIDIA n'a pas indiqué si PixelUMM est terminé. Le code de Sana est disponible, et le dépôt s'est enrichi de variantes sprint, de génération de vidéos, de ControlNet, de LoRA, de quantification, du support ComfyUI et d'un service en ligne. Deux équipes de recherche, deux voies, une cible : les parties de la pile visuelle que personne ne voulait prendre en compte sont en train d'être éliminées par conception.