NVIDIA PixelUMM foi lançado sem anúncio — Os pesos acabaram de chegar

A maneira mais fácil de descobrir que a NVIDIA criou um novo modelo multimodal unificado é perceber que ninguém te contou. O repositório nvidia/PixelUMM apareceu no Hugging Face às 21:40 UTC de 1º de outubro de 2026, carregando um checkpoint de 15,2 bilhões de parâmetros cuja pilha aprendida inteira fica sobre um backbone Qwen3-8B — e não havia post de blog, comunicado de imprensa, slide de keynote nem thread de lançamento para acompanhá-lo. Buscas pelo nome não retornam nada no próprio blog da NVIDIA. O que existe, em vez disso, é um repositório no GitHub, uma página de projeto cuja própria URL ainda diz "preview", um preprint do arXiv numerado 2609.38597 e um checkpoint dividido em 128 arquivos com um índice oculto sem o qual o loader se recusa a rodar. O PixelUMM é real e pode ser baixado hoje. Se a NVIDIA o considera lançado é uma pergunta que a empresa não respondeu.

Essa lacuna — entre um artefato que existe e um fornecedor que não disse nada — é a história toda aqui, e vale a pena ser preciso sobre de que lado dela cada fato se encontra. Tudo abaixo vem do repositório, da ficha do modelo e do artigo que os próprios autores publicaram. Nada vem de um anúncio, porque não houve nenhum.

O que apareceu, e quando

A série dura cerca de quatro semanas, e cada peça chegou em silêncio.

• 4 de setembro de 2026 — nv-tlabs/PixelUMM é criado no GitHub sob uma licença de repositório Apache-2.0, descrito simplesmente como "Compreensão e Geração Unificadas de Imagem e Vídeo sem Encoder". Ele permanece com um único commit inicial até o final de setembro.

• 28–29 de setembro de 2026 — o commit inicial do repositório é publicado, e o arXiv atribui ao preprint o identificador arXiv:2609.38597, datado de 29 de setembro, listando autores da NVIDIA e da University of Waterloo: Cong Wei, Xuanchi Ren, Bryan Chu, Weiming Ren, Huan Ling, Jiahui Huang, Laura Leal-Taixé, Sanja Fidler, Wenhu Chen, Zian Wang e Jay Zhangjie Wu.

• 1 de outubro de 2026, 21:32 UTC — um commit final no repositório intitulado "docs: add PixelUMM paper citation".

• 1 de outubro de 2026, 21:40 UTC — o repositório de modelos do Hugging Face é criado, oito minutos depois, e é preenchido com os fragmentos de checkpoint.

A página do projeto está hospedada em um caminho que diz literalmente pixelumm-project-page-preview, e o artigo não traz nenhuma linha de veículo — nem CVPR, nem NeurIPS, nem "accepted to". Em conjunto, a sequência soa como uma equipe de pesquisa colocando um artefato de artigo no ar e deixando o upload no HF ser o anúncio. Isso é uma observação sobre as evidências, não uma alegação sobre intenção: a NVIDIA pode muito bem ter um lançamento planejado para depois, e nada aqui descarta isso.

O que o PixelUMM realmente é

A tese de design é declarada na primeira linha do cartão do modelo: sem VAE, sem codificador de visão. Onde um modelo unificado convencional carrega duas interfaces visuais — um transformer de visão que produz características semânticas para compreensão, e um autoencoder variacional que produz latentes de reconstrução para geração — o PixelUMM não carrega nenhuma. As imagens são cortadas em patches de 16×16 pixels; os vídeos são cortados em tubelets espaço-temporais de 4 quadros; ambos chegam ao backbone por nada mais do que projeções lineares de camada única. Pixels brutos entram; pixels brutos saem.

• Arquitetura — Transformer somente decodificador com embeddings de patches de pixels brutos e uma cabeça iterativa de geração de pixels, descrito no artigo como um Mixture-of-Transformers que combina atenção compartilhada com parâmetros específicos da tarefa.

• Estrutura principal — Qwen3-8B, fixado na revisão b968826d9c46dd6066d109eabc6255188de91218. Apenas seus arquivos de configuração e do tokenizador são necessários; o checkpoint carrega seus próprios pesos de linguagem aprendidos.

• Parâmetros — 15.199.672.064 (aproximadamente 15,2B), representado como "8B MoT" nas próprias tabelas de benchmark do artigo, onde a notação de tamanho conta o backbone e o especialista de geração separadamente.

• Objetivos — previsão de texto autorregressiva e flow matching no espaço de pixels treinados conjuntamente, que é o que permite que um único conjunto de pesos tanto responda a uma pergunta sobre uma imagem quanto desenhe uma nova.

• Tarefas — texto para imagem, texto para vídeo em 96 quadros / 24 fps / 4 segundos, texto condicionado por imagem e texto condicionado por vídeo.

A seção empírica do artigo é incomum de uma forma que vale a pena destacar. Oito de suas seções são estudos de escolhas de design, e não de posições em rankings — tamanho do patch de imagem, tamanho do patch de vídeo, artefatos de patch, dinâmica de treinamento em espaço de pixels versus espaço de VAE, tamanho do modelo, escalonamento de computação, condicionamento de contexto multimodal e interfaces de compreensão de vídeo. Esse é um artigo escrito por pessoas tentando responder se a abordagem funciona, não um tentando ganhar uma tabela.

Os números são dos próprios autores.

Cada número abaixo é relatado pelos próprios autores do PixelUMM em seu preprint. Não há reprodução independente, nenhum Elo de arena e nenhuma avaliação de terceiros, porque o modelo tem no máximo seis semanas e antecede qualquer harness externo. Trate esses dados como alegações acompanhadas de um link de download, não como desempenho verificado.

• Compreensão de imagens — 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, no protocolo oficial LMMS-Eval (64.750 gerações em 21 tarefas).

• Compreensão de vídeo — MVBench 70,53, Video-MME 57,33 sem legendas, LongVideoBench 59,61, LVBench 40,41.

• Geração de imagens — GenEval geral 0,83 com um reescritor de prompts por LLM, 0,77 sem ele; DPG-Bench geral 85,74.

• Geração de vídeo — pontuação de qualidade do VBench Parte 1: 84,10, pontuação semântica: 79,80; total do VBench Parte 2: 83,24.

A leitura honesta é que estes são números competitivos dentro da classe, não líderes de categoria, e o próprio artigo afirma isso: observa que, como os dados de treinamento diferem entre os modelos, os resultados "não permitem estabelecer qual arquitetura é superior". Em comparação com o Qwen3-VL-8B, a diferença de compreensão de imagem é grande no MMMU (41,67 contra 69,60) e no MMMU-Pro, onde os autores não relatam nenhum valor comparativo. Em comparação com o Qwen-Image 20B, a diferença no GenEval é de 0,83 a 0,87. O que o PixelUMM não é, segundo seus próprios números, é um modelo de última geração. O que ele é, segundo seus próprios números, é um modelo de 15B com uma arquitetura genuinamente incomum que fica na mesma faixa dos sistemas especializados ao seu redor.

A vantagem mais afiada é a licença, não o benchmark

O repositório é Apache-2.0 e o cartão de modelo anuncia isso claramente. O checkpoint é um artefato diferente, com termos diferentes, e este é o detalhe com maior probabilidade de pegar uma equipe desprevenida. Os pesos são distribuídos sob a NVIDIA One-Way Noncommercial License, cujo uso é limitado a pesquisa ou avaliação não comercial — uma concessão substancialmente mais restrita do que o código que está ao lado. Um arquivo-fonte no repositório, modeling/pixelumm/modeling_utils.py, mantém adicionalmente um aviso CC BY-NC 4.0 derivado do DiT.

Para um grupo de pesquisa, uma equipe de avaliação ou qualquer pessoa que publique um artigo, esta é uma licença perfeitamente utilizável. Para uma equipe de produto criando o protótipo de uma funcionalidade interna, é a primeira coisa a colocar diante do jurídico, e a resposta pode ser não. Um modelo que você não pode lançar é um tipo de ativo diferente de um modelo que você pode, e nenhuma paridade de benchmarks muda isso.

O que é preciso para executá-lo

Isto não é um download de fim de semana. A documentação do ambiente exige Linux x86-64, Python 3.12, um kit de desenvolvimento CUDA 13.0, uma GPU NVIDIA e FlashAttention compilado a partir do código-fonte com esse kit — uma imagem CUDA apenas de runtime não serve. O próprio checkpoint não é um arquivo model.safetensors: são 128 fragmentos .distcp que totalizam cerca de 30 GB, mais um índice .metadata oculto, e o carregador exige que todos os fragmentos referenciados e esse índice estejam presentes.

Mais dois detalhes moldam o que você pode de fato fazer com ele. Primeiro, o text-to-video executa as barreiras de proteção do Cosmos por padrão, e elas precisam de acesso ao repositório restrito nvidia/Cosmos-1.0-Guardrail, além de um segundo ambiente Python com uma versão principal diferente do Transformers — apenas fazer login não desbloqueia os pesos. Segundo, o exemplo de treinamento de brinquedo em quatro etapas, a única receita de treinamento publicada, está documentado como exigindo sete GPUs com pelo menos 48 GiB cada e cerca de 61 GB de disco livre para a saída. O ajuste fino em uma estação de trabalho não é o caminho pretendido; a inferência em uma única placa moderna é.

O repositório inclui quatro checkpoints. S8-F22-R05 é o padrão e o usado na avaliação do artigo, cobrindo todas as quatro tarefas. S8-F18-R01 realizou 10.000 etapas adicionais de fine-tuning em 480p e 720p e geralmente produz resultados de texto para vídeo um pouco melhores, mas não consegue fazer compreensão de vídeo. S8-F19-R03 e S8-F21-R02 são estágios intermediários. Escolher entre eles é uma decisão de verdade, não um detalhe.

O que não está confirmado

Uma lista curta, e ela importa mais do que a longa acima.

• Nenhum anúncio da NVIDIA. Não surgiu nenhum comunicado à imprensa nem publicação no blog da própria empresa sobre este modelo no momento da redação. O lançamento discreto pode ser deliberado — artefatos de pesquisa costumam ser divulgados assim — ou um lançamento pode simplesmente ainda não ter acontecido.

• Nenhuma avaliação independente.Todos os números neste artigo são dos próprios autores. Nada foi reexecutado fora da NVIDIA e de Waterloo.

• Nenhuma rota hospedada em lugar nenhum. Hoje você não pode chamar o PixelUMM por meio de uma API, e isso inclui o OrcaRouter — nós não o roteamos, e não podemos, porque um checkpoint licenciado para uso não comercial não é algo que uma plataforma comercial de serving possa oferecer. Quem lhe disser o contrário está descrevendo uma configuração auto-hospedada.

• Nenhuma posição declarada sobre licenciamento futuro. Os termos não comerciais são os termos conforme entregues. Se serão flexibilizados é desconhecido e, dado o histórico da NVIDIA com checkpoints de pesquisa, não é algo com que se planejar.

O que observar a seguir

Três eventos transformariam o UMM de um artefato de pesquisa em algo que um público mais amplo pode usar. O primeiro é uma mudança de licenciamento no checkpoint — esse único arquivo é toda a diferença entre “interessante” e “utilizável em um produto”. O segundo é um lançamento oficial da NVIDIA, que viria com um enquadramento que o repositório não consegue fornecer: para que serve o modelo e se ele é uma direção de produto ou um artigo. O terceiro é a primeira reprodução independente, provavelmente uma nova execução do GenEval ou do MVBench feita por alguém com um cluster de GPUs de sobra, que é o momento em que os números dos autores deixam de ser os únicos números.

Até então, a postura correta é a que as evidências sustentam. O PixelUMM existe, o código e o artigo são públicos e legíveis, os pesos podem ser baixados, e nenhuma das alegações de desempenho foi verificada por alguém fora da equipe que as fez. Isso não é uma crítica ao trabalho — é com o que se parece um lançamento de pesquisa com seis semanas de idade. É também exatamente a situação em que uma camada de roteamento se paga mais tarde, se a licença algum dia afrouxar: uma única chave para os modelos em que você já confia, preços de tabela repassados com 0% de margem, e failover que permite direcionar uma fração do tráfego para algo não comprovado sem apostar um caminho de produção nele. Por ora, porém, o resumo honesto é mais simples. A NVIDIA construiu algo incomum, publicou tudo minuciosamente e não contou a ninguém. O repositório é o anúncio.