PixelUMM e Sana apontam para a mesma ideia: remover o andaime dos modelos de visão

Dois lançamentos de pesquisa da NVIDIA chegaram com poucos dias de diferença, e compartilham uma mesma tese. O PixelUMM surgiu sem alarde no Hugging Face em 1º de outubro às 21:40 UTC, um checkpoint de 15,2 bilhões de parâmetros sem post de blog, sem press release, sem slide de keynote. O Sana, de pesquisadores da NVIDIA, do MIT e da Tsinghua, está público há mais tempo e adota a abordagem oposta para o mesmo problema de infraestrutura.

PixelUMM: um modelo unificado sem encoder

O nome do repositório diz o que o projeto é: nv-tlabs/PixelUMM, descrito em seu próprio resumo de uma linha como "compreensão e geração unificadas de imagem e vídeo sem encoder". Ele se baseia em um backbone Qwen3-8B com licença de repositório Apache-2.0.

A parte "sem encoder" é a afirmação interessante. A maioria dos sistemas de IA visual hoje encadeia componentes separados: um encoder de visão para transformar uma imagem em tokens que um modelo de linguagem consegue ler, um VAE para comprimir dados de pixels em um espaço latente no qual um modelo de difusão consegue trabalhar, e um transformer visual para lidar com a sequência. O PixelUMM foi construído para operar sem essas etapas intermediárias, e é por isso que sua própria página de projeto ainda exibe "preview" enquanto os pesos estão disponíveis para download.

Essa lacuna entre um artefato que existe e um fornecedor que não disse nada é toda a história do lançamento. Há um repositório no GitHub, um preprint no arXiv numerado 2609.38597, datado de 29 de setembro, com autores da NVIDIA e da Universidade de Waterloo, e um checkpoint dividido em 128 arquivos com um índice oculto sem o qual os loaders se recusam a executar. Se a NVIDIA considera o PixelUMM anunciado é uma pergunta que a empresa não respondeu.

O padrão de lançamento importa para quem acompanha essa área. Pesquisas que antes chegavam com um post de blog, uma página de demonstração e um ciclo de imprensa coordenado agora às vezes chegam como um repositório e um artigo. O artefato é público e citável enquanto a comunicação do próprio fornecedor permanece silenciosa, o que torna possível usar o modelo e impossível citar um benchmark oficial para ele. As equipes que o avaliam estão trabalhando a partir de um artigo e de seus próprios testes.

Sana: comprimir a cadeia de custos em vez de um único módulo

O Sana ataca a mesma camada da pilha pela direção oposta. A geração de imagem a partir de texto em alta resolução fica cara por um motivo que tem pouco a ver com a contagem de pixels: o número de tokens latentes que entram no transformer de difusão cresce rapidamente com a resolução. A autoatenção padrão precisa relacionar cada token a todos os outros, então custo, memória e latência sobem juntos.

Na própria comparação de 1024 pixels da NVIDIA, o FLUX-dev tem 12 bilhões de parâmetros, roda a 0,04 amostras por segundo e leva 23 segundos por imagem. Avançar em direção a 2K ou 4K, encolher o modelo ou cortar etapas de amostragem não resolve o problema de fundo.

O Sana comprime a cadeia inteira em vez de um componente. Um autoencoder de compressão profunda de 32x reduz o número de tokens latentes. A atenção linear diminui o custo de cada camada do transformer. Um solver eficiente e destilação em poucos passos cortam o número de passagens de amostragem. Fatiamento, offloading e quantização de baixa precisão reduzem a memória de implantação. Os modelos publicados incluem versões de 0,6B e 1,6B voltadas para até 4K, com o Sana-1.5 chegando a 4,8B. Na comparação oficial de 1024 pixels, a versão de 0,6B opera com 0,9 segundo de latência.

A abordagem de compressão da cadeia tem uma propriedade atraente que uma correção de módulo único não tem. Como cada etapa contribui, uma equipe pode aplicar as partes que se encaixam em seu hardware e pular o resto. Alguém com uma estação de trabalho e sem experiência em quantização pode adotar o solver eficiente. Alguém que implanta em escala pode empilhar fatiamento, offloading e quantização de baixa precisão para caber em uma placa muito menor. Os trade-offs são documentados por etapa, em vez de agrupados em uma decisão de tudo ou nada.

A linhagem do Sana também mostra o quão rápido um resultado de pesquisa se torna uma superfície de produto. O modelo original visava saída de texto para vídeo em 4K. O repositório desde então cresceu para incluir Sana-Sprint, geração de vídeo, ControlNet, LoRA, quantização, integração com o ComfyUI e um serviço online. É o mesmo arco que as ferramentas de imagem seguiram: de um artigo, para um repositório, para um nó na interface que as pessoas já usam.

O que as duas abordagens têm em comum

Coloque os lançamentos lado a lado e a direção do movimento fica clara. Ambos tentam remover a maquinaria intermediária que se situa entre pixels e modelos desde os primeiros dias da área. O PixelUMM pergunta se o encoder é necessário. O Sana pergunta quanto da cadeia de computação pode ser comprimido antes que a qualidade se degrade.

O trade-off é o mesmo nos dois casos, e nenhum dos laboratórios o esconde. Remover um encoder significa que o modelo precisa aprender o que o encoder costumava fornecer, o que custa computação de treinamento e pode custar qualidade em tarefas que o encoder lidava bem. Comprimir a cadeia de forma agressiva significa que o teto de qualidade se desloca, e os próprios materiais do Sana são cuidadosos quanto ao hardware e às condições de medição por trás daqueles números de latência.

A razão pela qual os dois laboratórios atacam essa camada é que os intermediários se tornaram a parte cara. Um encoder de visão e um VAE são treinados separadamente, ajustados separadamente e servidos separadamente. Cada um é um componente que pode sair de sincronia com o resto do pipeline, e cada um adiciona latência na frente de cada requisição. Removê-los é uma simplificação arquitetural, não um truque de pesquisa, e compensa em toda implantação.

Por que isso importa para quem constrói com imagens

Para os profissionais, a consequência prática é um piso de hardware mais baixo. O trabalho da NVIDIA com o Sana faz parte de um padrão mais amplo neste ano: modelos que antes precisavam de uma placa de data center estão sendo reformulados para caber em hardware de consumidor, e a comunidade aberta passou a tratar um piso de 6 GB de VRAM como requisito, e não como bônus.

Há uma segunda consequência que aparece nos diagramas de arquitetura. Quando o encoder e o VAE deixam de ser serviços separados, um pipeline que antes tinha três modelos para versionar, monitorar e pagar se torna um só. Isso é menos visível do que um número de latência, mas é o que muda a carga de manutenção em um produto real.

Para as equipes que constroem em cima desses modelos, a pergunta prática é qual simplificação elas podem adotar primeiro. A abordagem sem encoder promete uma arquitetura mais limpa, mas exige confiar que o próprio tratamento de representações do modelo equivale ao que um encoder feito sob medida fornecia. A abordagem de compressão da cadeia promete ganhos mensuráveis de velocidade e memória hoje, mantendo a arquitetura existente intacta. Uma é uma aposta na direção para a qual a área caminha; a outra é uma aposta no hardware que você já tem.

Ambas as apostas são razoáveis, e os laboratórios que as perseguem não competem pela mesma implantação. O enquadramento unificado do PixelUMM serve equipes que querem um único modelo para compreensão e geração. O Sana serve equipes que precisam de saída em alta resolução em hardware restrito. A sobreposição é a parte da pilha que ambos tentam eliminar.

A NVIDIA não disse se o PixelUMM está finalizado. O código do Sana está disponível, e o repositório cresceu para incluir variantes sprint, geração de vídeo, ControlNet, LoRA, quantização, suporte ao ComfyUI e um serviço online. Duas equipes de pesquisa, duas rotas, um alvo: as partes da pilha visual com as quais ninguém queria se preocupar estão sendo projetadas para fora.