NVIDIA PixelUMM wydane bez zapowiedzi — wagi właśnie się pojawiły

Najprostszym sposobem, by dowiedzieć się, że NVIDIA zbudowała nowy ujednolicony model multimodalny, jest zauważenie, że nikt ci nie powiedział. nvidia/PixelUMM pojawiło się na Hugging Face 1 października 2026 o 21:40 UTC, niosąc checkpoint o 15,2 miliarda parametrów, którego cały wyuczony stos opiera się na Qwen3-8B jako szkielecie — i nie było żadnego wpisu na blogu, komunikatu prasowego, slajdu z keynote ani wątku o premierze, który by temu towarzyszył. Wyszukiwania tej nazwy nie dają nic na własnym blogu NVIDIA. Zamiast tego istnieje repozytorium GitHub, strona projektu, której własny adres URL wciąż mówi „preview”, preprint arXiv o numerze 2609.38597 oraz checkpoint podzielony na 128 plików z ukrytym indeksem, bez którego loader nie uruchomi się. PixelUMM jest prawdziwy i można go dziś pobrać. Czy NVIDIA uważa go za wydany, to pytanie, na które firma nie odpowiedziała.

Ta luka — między istniejącym artefaktem a dostawcą, który nic nie powiedział — to cała historia w tym miejscu, a warto zachować precyzję co do tego, po której jej stronie znajduje się każdy fakt. Wszystko poniżej pochodzi z repozytorium, karty modelu i artykułu, który opublikowali sami autorzy. Nic nie pochodzi z ogłoszenia, ponieważ go nie było.

Co się pojawiło i kiedy

Cykl trwa około czterech tygodni, a każdy element wylądował cicho.

• 4 września 2026 — nv-tlabs/PixelUMM zostaje utworzone w serwisie GitHub na licencji repozytorium Apache-2.0, opisane po prostu jako „Encoder-Free Unified Image and Video Understanding and Generation”. Pozostaje z pojedynczym początkowym commitem do końca września.

• 28–29 września 2026 — pojawia się pierwszy commit w repozytorium, a arXiv nadaje preprintowi numer arXiv:2609.38597, datowany na 29 września, wymieniając autorów z NVIDIA i University of Waterloo: Cong Wei, Xuanchi Ren, Bryan Chu, Weiming Ren, Huan Ling, Jiahui Huang, Laura Leal-Taixé, Sanja Fidler, Wenhu Chen, Zian Wang oraz Jay Zhangjie Wu.

• 1 października 2026, 21:32 UTC — końcowy commit do repozytorium zatytułowany "docs: add PixelUMM paper citation".

• 1 października 2026, 21:40 UTC — repozytorium modelu Hugging Face zostaje utworzone, osiem minut później, i zapełnia się shardami punktów kontrolnych.

Strona projektu jest hostowana pod ścieżką, która dosłownie brzmi pixelumm-project-page-preview, a artykuł nie zawiera wiersza o miejscu publikacji — żadnego CVPR, żadnego NeurIPS, żadnego „accepted to”. Wzięte razem, ten ciąg czyta się tak, jakby zespół badawczy wypuszczał na żywo artefakt artykułu i pozwalał, by ogłoszeniem było wgranie na HF. To spostrzeżenie na temat dowodów, a nie twierdzenie o intencjach: NVIDIA może mieć zaplanowaną premierę na później i nic tutaj tego nie wyklucza.

Czym właściwie jest PixelUMM

Teza projektowa jest wyrażona w pierwszej linijce karty modelu: brak VAE, brak enkodera wizyjnego. Tam, gdzie konwencjonalny zunifikowany model ma dwa interfejsy wizualne — transformer wizyjny produkujący cechy semantyczne do rozumienia oraz autoenkoder wariacyjny produkujący latenty rekonstrukcyjne do generowania — PixelUMM nie ma żadnego. Obrazy są dzielone na fragmenty 16×16 pikseli; filmy są dzielone na 4-klatkowe czasoprzestrzenne tubletki; oba trafiają do szkieletu poprzez nic więcej niż jednowarstwowe projekcje liniowe. Surowe piksele wchodzą; surowe piksele wychodzą.

• Architektura — Transformer typu decoder-only z osadzeniami fragmentów surowych pikseli oraz iteracyjną głowicą generowania pikseli, opisany w artykule jako Mixture-of-Transformers, który łączy wspólną uwagę z parametrami charakterystycznymi dla danego zadania.

• Model bazowy — Qwen3-8B, przypięty do wersji b968826d9c46dd6066d109eabc6255188de91218. Potrzebne są tylko jego pliki konfiguracyjne i tokenizatora; punkt kontrolny zawiera własne wyuczone wagi językowe.

• Parametry — 15 199 672 064 (około 15,2 mld), podawane jako „8B MoT” w tabelach wyników samej pracy, gdzie w zapisie rozmiaru szkielet i ekspert generacji liczone są osobno.

• Cele — autoregresyjne przewidywanie tekstu i dopasowywanie przepływu w przestrzeni pikseli trenowane jednocześnie, dzięki czemu jeden zestaw wag potrafi zarówno odpowiedzieć na pytanie dotyczące obrazu, jak i narysować nowy.

• Zadania — tekst na obraz, tekst na wideo przy 96 klatkach / 24 fps / 4 sekundy, tekst warunkowany obrazem i tekst warunkowany wideo.

Sekcja empiryczna tego artykułu jest nietypowa w sposób, który warto podkreślić. Osiem jej sekcji to badania nad decyzjami projektowymi, a nie pozycjami w rankingach — rozmiar patchy obrazu, rozmiar patchy wideo, artefakty patchy, dynamika treningu w przestrzeni pikseli w porównaniu z przestrzenią VAE, rozmiar modelu, skalowanie obliczeń, warunkowanie kontekstem multimodalnym oraz interfejsy rozumienia wideo. To artykuł napisany przez ludzi, którzy próbują odpowiedzieć na pytanie, czy to podejście działa, a nie przez tych, którzy próbują wygrać tabelę.

Liczby są własne autorów.

Każda poniższa liczba jest podawana przez autorów PixelUMM w ich własnym preprintcie. Nie ma niezależnego odtworzenia, Elo areny ani oceny stron trzecich, ponieważ model ma co najwyżej sześć tygodni i powstał przed jakimkolwiek zewnętrznym środowiskiem testowym. Traktuj je jako twierdzenia z linkiem do pobrania, a nie jako zweryfikowaną wydajność.

• Rozumienie obrazu — MMMU 41,67, MMStar 53,99, AI2D 80,12, DocVQA 90,42, ChartQA 82,96, OCRBench 78,00, BLINK 53,46, MMMU-Pro 27,63, zgodnie z oficjalnym protokołem LMMS-Eval (64 750 generacji w 21 zadaniach).

• Rozumienie wideo — MVBench 70,53, Video-MME 57,33 bez napisów, LongVideoBench 59,61, LVBench 40,41.

• Generowanie obrazów — GenEval ogółem 0,83 z przepisywaczem promptów LLM, 0,77 bez niego; DPG-Bench ogółem 85,74.

• Generowanie wideo — VBench część 1: wynik jakości 84.10, wynik semantyczny 79.80; VBench część 2 łącznie 83.24.

Uczciwa interpretacja jest taka, że są to wyniki konkurencyjne w obrębie klasy, a nie wiodące w kategorii, i praca sama to przyznaje: zauważa, że ponieważ dane treningowe różnią się między modelami, wyniki „nie mogą ustalić, która architektura jest lepsza”. W porównaniu z Qwen3-VL-8B luka w rozumieniu obrazów jest duża w MMMU (41,67 wobec 69,60) oraz w MMMU-Pro, gdzie autorzy nie podają żadnego wyniku konkurencyjnego. W porównaniu z Qwen-Image 20B luka w GenEval wynosi 0,83 wobec 0,87. To, czym PixelUMM nie jest – na podstawie jego własnych liczb – to model state-of-the-art. To, czym jest – na podstawie jego własnych liczb – to model 15B o naprawdę nietypowej architekturze, który plasuje się w tym samym przedziale co otaczające go systemy specjalistyczne.

Najostrzejszą krawędzią jest licencja, a nie benchmark.

Repozytorium jest objęte licencją Apache-2.0, a karta modelu wprost o tym informuje. Checkpoint to inny artefakt objęty innymi warunkami i właśnie ten szczegół najczęściej może zaskoczyć zespół. Wagi są udostępniane na podstawie licencji NVIDIA One-Way Noncommercial License, której użycie ogranicza się do niekomercyjnych badań lub oceny — to istotnie węższe uprawnienie niż w przypadku sąsiadującego z nim kodu. Jeden plik źródłowy w repozytorium, modeling/pixelumm/modeling_utils.py, dodatkowo zachowuje adnotację CC BY-NC 4.0 pochodzącą z DiT.

Dla grupy badawczej, zespołu ewaluacyjnego lub każdego, kto publikuje artykuł, to całkowicie użyteczna licencja. Dla zespołu produktowego prototypującego wewnętrzną funkcję to pierwsza rzecz, którą trzeba przedstawić działowi prawnemu, a odpowiedź może brzmieć: nie. Model, którego nie można wypuścić, to inny rodzaj zasobu niż model, który można wypuścić, i żadna równoważność wyników benchmarków tego nie zmieni.

Co jest potrzebne, aby to uruchomić

To nie jest pobieranie na jeden weekend. Dokumentacja środowiska wymaga systemu Linux x86-64, Pythona 3.12, zestawu narzędzi deweloperskich CUDA 13.0, karty GPU NVIDIA oraz FlashAttention zbudowanego ze źródeł względem tego zestawu narzędzi — obraz CUDA zawierający wyłącznie środowisko uruchomieniowe nie wystarczy. Sam checkpoint nie jest plikiem model.safetensors: to 128 fragmentów .distcp o łącznym rozmiarze około 30 GB plus ukryty indeks .metadata, a loader wymaga obecności każdego przywoływanego fragmentu i tego indeksu.

Dwa dalsze szczegóły kształtują to, co można z tym faktycznie zrobić. Po pierwsze, text-to-video domyślnie korzysta z mechanizmów zabezpieczających Cosmos, a te wymagają dostępu do repozytorium z ograniczonym dostępem nvidia/Cosmos-1.0-Guardrail oraz drugiego środowiska Python z inną główną wersją biblioteki Transformers — samo zalogowanie się nie odblokowuje wag. Po drugie, czterokrokowy uproszczony przykład treningowy, jedyny opublikowany przepis na trening, jest udokumentowany jako wymagający siedmiu GPU, z co najmniej 48 GiB pamięci na każdy, oraz około 61 GB wolnego miejsca na dysku na dane wyjściowe. Dostrajanie na stacji roboczej nie jest docelową ścieżką; jest nią wnioskowanie na pojedynczej nowoczesnej karcie.

Repozytorium zawiera cztery checkpointy. S8-F22-R05 jest domyślnym i tym używanym w ewaluacji opisanej w artykule, obejmującym wszystkie cztery zadania. S8-F18-R01 wykonał 10 000 dodatkowych kroków dostrajania przy 480p i 720p i generalnie daje nieco lepsze wyniki konwersji tekstu na wideo, ale nie potrafi rozumieć wideo. S8-F19-R03 i S8-F21-R02 to etapy pośrednie. Wybór między nimi to prawdziwa decyzja, a nie szczegół.

Co nie jest potwierdzone.

Krótka lista, a znaczy więcej niż ta długa powyżej.

• Brak ogłoszenia NVIDIA. W momencie pisania tego tekstu nie pojawiła się żadna informacja prasowa ani wpis na blogu samej firmy dotyczący tego modelu. Cicha premiera może być zamierzona — artefakty badawcze często trafiają do obiegu w ten sposób — albo premiera mogła po prostu jeszcze nie nastąpić.

• Brak niezależnej oceny.Każda liczba w tym artykule pochodzi od samych autorów. Nic nie zostało ponownie uruchomione poza NVIDIA i Waterloo.

• Nigdzie nie ma żadnej hostowanej trasy. Nie można dziś wywołać PixelUMM przez API, i dotyczy to także OrcaRouter — nie routujemy go, i nie możemy, ponieważ checkpoint z licencją niekomercyjną nie jest czymś, co może zaoferować komercyjna platforma udostępniająca modele. Ktokolwiek mówi ci inaczej, opisuje konfigurację self-hosted.

• Brak określonego stanowiska w sprawie przyszłego licencjonowania. Warunki niekomercyjne są takie, jak zostały wydane. Nie wiadomo, czy zostaną złagodzone, a biorąc pod uwagę historię NVIDIA z checkpointami badawczymi, nie jest to coś, na czym można opierać plany.

Na co uważać w dalszej kolejności

Trzy wydarzenia przekształciłyby PixelUMM z artefaktu badawczego w coś, z czego szersza publiczność mogłaby korzystać. Pierwszym jest zmiana licencji na checkpoint — ten pojedynczy plik stanowi całą barierę między „interesującym” a „użytecznym w produkcie”. Drugim jest oficjalna premiera NVIDIA, która wiązałaby się z ramą, jakiej repozytorium nie może dostarczyć: do czego służy model i czy jest to kierunek produktowy, czy artykuł naukowy. Trzecim jest pierwsza niezależna reprodukcja, najprawdopodobniej powtórzenie GenEval lub MVBench przez kogoś z zapasowym klastrem GPU, co jest momentem, w którym liczby autorów przestają być jedynymi liczbami.

Do tego czasu właściwą postawą jest ta, którą popierają dowody. PixelUMM istnieje, kod i artykuł są publiczne i czytelne, wagi można pobrać, a żadnego z twierdzeń o wydajności nie sprawdził nikt spoza zespołu, który je przedstawił. To nie jest krytyka pracy — tak właśnie wygląda sześciotygodniowa publikacja badawcza. To także dokładnie ta sytuacja, w której warstwa routingu zwróci się później, jeśli licencja kiedykolwiek się poluzuje: jeden klucz dla modeli, którym już ufasz, ceny katalogowe przekazywane dalej z 0% narzutu i przełączanie awaryjne, które pozwala skierować część ruchu na coś nieudowodnionego, nie stawiając na tym ścieżki produkcyjnej. Na razie jednak uczciwe podsumowanie jest prostsze. NVIDIA zbudowała coś niezwykłego, opublikowała to szczegółowo i nikomu o tym nie powiedziała. Repozytorium jest ogłoszeniem.