← Zurück zum Blog
Aica. 6 Min. Lesezeit

PixelUMM und Sana deuten auf dieselbe Idee hin: Das Gerüst aus den Vision-Modellen entfernen

Veröffentlicht 7. Okt. 2026
PixelUMM und Sana deuten auf dieselbe Idee hin: Das Gerüst aus den Vision-Modellen entfernen

Zwei NVIDIA-Forschungsveröffentlichungen folgten innerhalb weniger Tage aufeinander und teilen eine These. PixelUMM tauchte ohne großes Aufheben am 1. Oktober um 21:40 UTC auf Hugging Face auf, ein Checkpoint mit 15,2 Milliarden Parametern, ohne Blogbeitrag, ohne Pressemitteilung, ohne Keynote-Folie. Sana, von Forschern von NVIDIA, MIT und Tsinghua, ist schon länger öffentlich und verfolgt den entgegengesetzten Ansatz für dasselbe Infrastrukturproblem.

PixelUMM: ein einheitliches Modell ohne Encoder

Der Repository-Name verrät, worum es bei dem Projekt geht: nv-tlabs/PixelUMM, in der eigenen einzeiligen Zusammenfassung als „encoderfreies einheitliches Verstehen und Generieren von Bildern und Videos“ beschrieben. Es basiert auf einem Qwen3-8B-Backbone und steht unter einer Apache-2.0-Repository-Lizenz.

Der Teil „encoderfrei“ ist die interessante Behauptung. Die meisten visuellen KI-Systeme verketten heute separate Komponenten: einen Vision-Encoder, der ein Bild in Token umwandelt, die ein Sprachmodell lesen kann, einen VAE, der Pixeldaten in einen latenten Raum komprimiert, in dem ein Diffusionsmodell arbeiten kann, und einen visuellen Transformer, der die Sequenz verarbeitet. PixelUMM wurde so gebaut, dass es ohne diese Zwischenstufen arbeitet, weshalb die eigene Projektseite noch immer „preview“ anzeigt, während die Gewichte herunterladbar sind.

Diese Lücke zwischen einem Artefakt, das existiert, und einem Anbieter, der nichts gesagt hat, ist die ganze Geschichte der Veröffentlichung. Es gibt ein GitHub-Repo, einen arXiv-Preprint mit der Nummer 2609.38597 vom 29. September mit Autoren von NVIDIA und der University of Waterloo sowie einen Checkpoint, der auf 128 Dateien aufgeteilt ist, mit einem versteckten Index, ohne den Loader die Ausführung verweigern. Ob NVIDIA PixelUMM als angekündigt betrachtet, ist eine Frage, die das Unternehmen nicht beantwortet hat.

Das Veröffentlichungsmuster ist für alle wichtig, die dieses Feld verfolgen. Forschung, die früher mit einem Blogbeitrag, einer Demo-Seite und einem koordinierten Pressezyklus ankam, erscheint heute manchmal als Repository und Paper. Das Artefakt ist öffentlich und zitierbar, während die Kommunikation des Anbieters schweigt, was es möglich macht, das Modell zu nutzen, aber unmöglich, einen offiziellen Benchmark dafür zu zitieren. Teams, die es evaluieren, arbeiten mit einem Paper und ihren eigenen Tests.

Sana: die Kostenkette komprimieren statt eines einzelnen Moduls

Sana greift dieselbe Ebene des Stacks aus der anderen Richtung an. Hochauflösendes Text-zu-Bild wird teuer aus einem Grund, der wenig mit der Pixelanzahl zu tun hat: Die Anzahl latenter Token, die in den Diffusions-Transformer eingehen, wächst schnell mit der Auflösung. Standard-Self-Attention muss jeden Token mit jedem anderen Token in Beziehung setzen, sodass Kosten, Speicher und Latenz gemeinsam steigen.

In NVIDIAs eigenem Vergleich bei 1024 Pixeln hat FLUX-dev 12 Milliarden Parameter, läuft mit 0,04 Samples pro Sekunde und braucht 23 Sekunden pro Bild. Wenn man in Richtung 2K oder 4K geht, das Modell verkleinert oder Sampling-Schritte reduziert, behebt das nicht das zugrunde liegende Problem.

Sana komprimiert die gesamte Kette statt einer einzelnen Komponente. Ein 32-facher Deep-Compression-Autoencoder verringert die Anzahl latenter Token. Lineare Attention reduziert die Kosten jeder Transformer-Schicht. Ein effizienter Solver und Few-Step-Distillation senken die Anzahl der Sampling-Durchläufe. Slicing, Offloading und Low-Bit-Quantisierung reduzieren den Deployment-Speicher. Die veröffentlichten Modelle umfassen 0,6B- und 1,6B-Versionen für bis zu 4K, wobei Sana-1.5 auf 4,8B erweitert wird. Im offiziellen 1024-Pixel-Vergleich läuft die 0,6B-Version mit 0,9 Sekunden Latenz.

Der Ansatz der Kettenkompression hat eine attraktive Eigenschaft, die eine Einzelmodul-Korrektur nicht hat. Weil jede Stufe beiträgt, kann ein Team die Teile anwenden, die zu seiner Hardware passen, und den Rest überspringen. Jemand mit einer Workstation und ohne Quantisierungserfahrung kann den effizienten Solver nutzen. Wer im großen Maßstab deployt, kann Slicing, Offloading und Low-Bit-Quantisierung kombinieren, um auf eine viel kleinere Karte zu passen. Die Trade-offs sind pro Stufe dokumentiert, statt in eine Alles-oder-nichts-Entscheidung gebündelt zu werden.

Sanos Entwicklungslinie zeigt auch, wie schnell ein Forschungsergebnis zu einer Produktoberfläche wird. Das ursprüngliche Modell zielte auf 4K-Text-zu-Video-Ausgabe ab. Das Repository ist seitdem um Sana-Sprint, Videogenerierung, ControlNet, LoRA, Quantisierung, ComfyUI-Integration und einen Onlinedienst gewachsen. Das ist derselbe Bogen, den die Bildwerkzeuge genommen haben: von einem Paper über ein Repository zu einem Knoten in der Oberfläche, die Leute bereits verwenden.

Was die beiden Ansätze gemeinsam haben

Stellt man die Veröffentlichungen nebeneinander, ist die Richtung klar. Beide versuchen, die Zwischenmaschinerie zu entfernen, die seit den frühen Tagen des Feldes zwischen Pixeln und Modellen sitzt. PixelUMM fragt, ob der Encoder überhaupt notwendig ist. Sana fragt, wie viel der Compute-Kette komprimiert werden kann, bevor die Qualität einbricht.

Der Trade-off ist in beiden Fällen derselbe, und keines der Labore verheimlicht ihn. Einen Encoder zu entfernen bedeutet, dass das Modell lernen muss, was der Encoder früher bereitgestellt hat, was Trainings-Compute kostet und bei Aufgaben, die der Encoder gut bewältigte, Qualität kosten kann. Die Kette aggressiv zu komprimieren bedeutet, dass sich die Qualitätsobergrenze verschiebt, und Sanos eigene Materialien sind sorgfältig in Bezug auf die Hardware- und Messbedingungen hinter diesen Latenzzahlen.

Der Grund, warum beide Labore diese Ebene angreifen, ist, dass die Zwischenkomponenten zum teuren Teil geworden sind. Ein Vision-Encoder und ein VAE werden separat trainiert, separat abgestimmt und separat bereitgestellt. Jede ist eine Komponente, die mit dem Rest der Pipeline aus dem Takt geraten kann, und jede fügt am Anfang jeder Anfrage Latenz hinzu. Sie zu entfernen ist eine architektonische Vereinfachung und kein Forschungstrick, und sie zahlt sich bei jedem Deployment aus.

Warum es für alle wichtig ist, die mit Bildern arbeiten

Für Praktiker ist die praktische Konsequenz eine niedrigere Hardware-Untergrenze. NVIDIAs Sana-Arbeit ist Teil eines breiteren Musters in diesem Jahr: Modelle, die früher eine Rechenzentrumskarte brauchten, werden überarbeitet, um auf Consumer-Hardware zu passen, und die offene Community beginnt, eine 6-GB-VRAM-Untergrenze als Anforderung statt als Bonus zu behandeln.

Es gibt eine zweite Konsequenz, die in Architekturdiagrammen sichtbar wird. Wenn der Encoder und der VAE keine separaten Dienste mehr sind, wird eine Pipeline, die früher drei Modelle zu versionieren, zu überwachen und zu bezahlen hatte, zu einer. Das ist weniger sichtbar als eine Latenzzahl, aber genau das verändert den Wartungsaufwand eines echten Produkts.

Für Teams, die auf diesen Modellen aufbauen, ist die praktische Frage, welche Vereinfachung sie zuerst übernehmen können. Der encoderfreie Ansatz verspricht eine sauberere Architektur, erfordert aber das Vertrauen, dass die eigene Repräsentationsverarbeitung des Modells dem entspricht, was ein zweckgebauter Encoder bot. Der Kettenkompressionsansatz verspricht heute messbare Geschwindigkeits- und Speichergewinne, während die bestehende Architektur intakt bleibt. Eines ist eine Wette auf die Richtung, in die sich das Feld bewegt; das andere ist eine Wette auf die Hardware, die man bereits besitzt.

Beide Wetten sind vernünftig, und die Labore, die sie verfolgen, konkurrieren nicht um dasselbe Deployment. PixelUMMs einheitlicher Rahmen passt zu Teams, die ein Modell für Verstehen und Generieren wollen. Sana passt zu Teams, die hochauflösende Ausgabe auf eingeschränkter Hardware benötigen. Die Überschneidung ist der Teil des Stacks, den beide zu streichen versuchen.

NVIDIA hat nicht gesagt, ob PixelUMM fertig ist. Sanos Code ist veröffentlicht, und das Repo ist um Sprint-Varianten, Videogenerierung, ControlNet, LoRA, Quantisierung, ComfyUI-Unterstützung und einen Onlinedienst gewachsen. Zwei Forschungsteams, zwei Wege, ein Ziel: Die Teile des visuellen Stacks, über die niemand nachdenken wollte, werden wegkonstruiert.

Verwandte Artikel