O DiffusionGemma do Google gera 256 tokens em paralelo e se autocorrige à medida que avança

Os geradores de imagem GenAI, como o Steady Diffusion, não desenham uma imagem pixel por pixel da esquerda para a direita. Eles começam com ruído e refinam iterativamente toda a imagem em paralelo até convergir, em um processo conhecido como difusão. Durante anos, a aplicação desse mesmo princípio à geração de texto permaneceu fora de alcance em grande escala.

Os modelos de linguagem padrão funcionam como uma máquina de escrever: um token por vez, da esquerda para a direita, sem capacidade de revisar uma saída confirmada. Esse padrão funciona na nuvem, onde os tamanhos dos lotes mantêm as GPUs saturadas. Para inferência native ou implantações de baixa simultaneidade, a GPU fica ociosa na maior parte do tempo.

O DiffusionGemma do Google, lançado esta semana, é um modelo experimental de código aberto que aplica difusão à geração de texto em escala de produção. Construído no spine Gemma 4 e lançado sob a licença Apache 2.0, é o primeiro modelo de linguagem de difusão com suporte nativo na plataforma de inferência vLLM de código aberto. Ele gera um bloco de 256 tokens em paralelo, em vez de sequencialmente, com cada posição de token atendendo uma à outra. O Google afirma que o DiffusionGemma gera texto até 4x mais rápido do que os modelos padrão em GPUs. No tamanho de lote 1 em uma única Nvidia H100, a versão FP8 atinge 1.008 tokens por segundo. No H200, atinge 1.288 – cerca de seis vezes a linha de base autoregressiva padrão, de acordo com os resultados do benchmark vLLM publicados hoje.

Apesar dos ganhos de velocidade, o Google não exagerou no lançamento. A empresa postagem de lançamento reconheceu diretamente que a qualidade geral de saída do DiffusionGemma é inferior ao Gemma 4 padrão, acrescentando “Para aplicações que exigem qualidade máxima, recomendamos a implantação do Gemma 4 padrão.”

O que DiffusionGemma faz

DiffusionGemma não gera tokens em ordem. Ele começa com um bloco de 256 tokens de espaço reservado aleatórios, efetivamente uma tela em branco, e executa várias passagens de refinamento em todo o bloco de uma só vez. A cada passagem, ele avalia todas as posições e fixa aquelas nas quais tem mais confiança. Posições incertas são aleatórias e reconsideradas na próxima passagem, com o modelo usando o que foi resolvido na rodada anterior para informar a próxima tentativa. O bloco converge progressivamente até que se estabilizem posições suficientes para ancorar o resto.

Duas coisas decorrem dessa arquitetura.

• Autocorreção. Um modelo autorregressivo que se compromete com um token errado fica preso nele, porque os tokens subsequentes já estão condicionados ao erro. DiffusionGemma pode identificar posições de baixa confiança e reavaliá-las na próxima passagem.

• Contexto bidirecional. Cada posição atende a todas as outras posições do bloco simultaneamente, incluindo tokens que aparecem posteriormente na sequência. Isso torna o modelo estruturalmente mais adequado para tarefas de geração restritas onde a geração da esquerda para a direita falha.

O Google demonstrou ambas as propriedades com um solucionador de Sudoku aprimorado. O modelo básico não resolveu nenhum quebra-cabeça. Após o ajuste fino em um conjunto de dados Sudoku, ele atingiu uma taxa de sucesso de 80% e convergiu em 12 etapas de eliminação de ruído em vez de 48. O ganho de eficiência veio diretamente da capacidade do modelo de autocorreção e parada antecipada.

Como foi construído

DiffusionGemma é executado como um modelo Combination of Consultants de 26B que ativa apenas parâmetros de 3,8B durante a inferência. Quantizado, ele cabe em 18 GB de VRAM em {hardware} de consumidor, incluindo Nvidia RTX 4090 e 5090. Google e NVIDIA também otimizaram para servidores corporativos Hopper e Blackwell usando kernels NVFP4.

A integração do vLLM exigiu novo trabalho porque o DiffusionGemma não se enquadra no modelo de serviço padrão. Um lote típico de vLLM aplica o mesmo tipo de atenção a cada solicitação. As solicitações DiffusionGemma alternam entre atenção causal e bidirecional à medida que passam pela leitura imediata, refinamento da tela e confirmação de bloco. A equipe construiu comutação de atenção por solicitação nos back-ends Triton e FlashAttention 4 e reutilizou o caminho de decodificação especulativa existente para o loop de refinamento.

A nova interface ModelState que a equipe construiu para esta integração foi projetada para oferecer suporte a modelos de difusão adicionais no vLLM à medida que surgem.

Onde a velocidade vence e onde não

A vantagem de velocidade do DiffusionGemma é actual, mas condicional. Onde se aplica depende inteiramente do contexto de implantação.

Os números. No tamanho de lote 1 em um único H100, os benchmarks publicados do vLLM colocam o modelo FP8 em aproximadamente cinco vezes a linha de base autoregressiva padrão. No H200, cerca de seis vezes. Esses números de pico refletem condições ideais: usuário único, {hardware} dedicado, quantização FP8.

Onde vence. Inferência native, aplicativos de usuário único e serviço de baixa simultaneidade. Nessas condições, a GPU tem computação sobressalente e a largura de banda da memória é o gargalo. A geração de blocos paralelos do DiffusionGemma preenche essa lacuna.

Onde isso não acontece. Serviço em nuvem de alto rendimento. Quando um servidor agrupa centenas de solicitações simultâneas, os modelos autorregressivos já saturam a computação disponível e a decodificação paralela do DiffusionGemma fornece retornos decrescentes.

O teto de qualidade. Guilherme O’Tina, pesquisador de IA, coloque um ponto mais preciso no X. “Artefatos locais versus alucinações são problemas diferentes e isso resolve onde isso realmente vence”, escreveu O’Tina.

Como se compara

Os modelos de linguagem de difusão não são novos. Os pesquisadores os construíram em escalas menores por vários anos, e Codificador de Mercúrio da Inception Labs aplicou a abordagem comercialmente para tarefas de codificação em 2025. O que DiffusionGemma adiciona é escala – um spine MoE de 26B, serviço vLLM nativo e um modelo ajustado para instruções de uso geral, em vez de um modelo específico de domínio.

A comparação mais útil para os engenheiros que avaliam isso em relação às ferramentas de inferência existentes é a decodificação especulativa, e a distinção é importante. A decodificação especulativa mantém um modelo de destino autoregressivo padrão e usa um modelo de rascunho menor para adivinhar vários tokens à frente. O modelo de destino os verifica em uma única passagem. Se a amostragem estiver correta, a distribuição da produção permanece idêntica à meta. A arquitetura permanece inalterada.

André Kuncevichum pesquisador de ML e IA focado em sistemas de IA de produção, colocou-o diretamente em X. “DiffusionGemma é diferente. Ele não apenas adivinha tokens futuros. Ele cria uma tela barulhenta de 256 tokens e elimina repetidamente o ruído de todo o bloco em paralelo. Portanto, não é apenas um truque de decodificação – é um paradigma de geração diferente”, escreveu Kuncevich.

Em comparação com o Gemma 4 padrão, a troca é velocidade por qualidade. Os dados de benchmark do Google mostram o DiffusionGemma abaixo do padrão Gemma 4 nas métricas gerais de qualidade de produção, com a lacuna variando de acordo com a tarefa.

Em tarefas estruturadas e restritas, incluindo preenchimento de código, geração de modelos e problemas que exigem propagação de restrições bidirecionais, a arquitetura tem uma vantagem estrutural que o ajuste fino pode revelar, como demonstra o resultado do Sudoku. Na geração aberta, o Gemma 4 padrão continua sendo a opção mais forte.

O que isso significa para as empresas

DiffusionGemma atende por meio de um endpoint vLLM compatível com OpenAI padrão, sem necessidade de alterações de pipeline específicas de difusão.

Esta não é uma atualização de modelo de uso geral.

Para equipes que executam inferência native ou de baixa simultaneidade, a escolha da arquitetura acabou de se expandir. Até agora, reduzir a latência de geração em {hardware} GPU dedicado significava usar um modelo menor e aceitar a compensação de qualidade. DiffusionGemma oferece um terceiro caminho com o mesmo parâmetro, em {hardware} de consumidor, com suporte vLLM no mesmo dia.

Para cargas de trabalho de geração restritas, vale a pena avaliar a atenção bidirecional. Preenchimento de código, geração de dados estruturados e tarefas onde a saída correta depende do contexto ainda não gerado são onde esta arquitetura tem uma vantagem estrutural.

A interface ModelState construída para esta integração foi projetada para generalizar à medida que surgem modelos de difusão adicionais.

A compensação pela qualidade é actual e o Google reconhece isso. Para equipes que executam inferência native em {hardware} de GPU dedicado, vale a pena testar isso.