DiffusionGemma: geração de texto 4x mais rápida

• DiffusionGemma é um modelo aberto experimental de 26B MoE, sob licença Apache 2.0, que gera blocos inteiros de texto de uma só vez com difusão de texto
• Em vez da geração sequencial de tokens típica dos LLMs autorregressivos, usa geração paralela de 256 tokens para oferecer geração de texto até 4x mais rápida em GPUs dedicadas
• Durante a inferência, ativa apenas 3,8B de parâmetros do total de 26B e, com quantização, roda dentro do limite de 18GB de VRAM em GPUs dedicadas avançadas para consumidores
• Com atenção bidirecional e autoajuste iterativo, traz vantagens para tarefas com estruturas não lineares como edição inline, preenchimento de código, sequências de aminoácidos e grafos matemáticos
• Como é um modelo experimental voltado para velocidade e geração paralela de layout, a qualidade geral da saída é inferior à do Gemma 4 padrão, e para aplicações que exigem a melhor qualidade é recomendada a implantação do Gemma 4 padrão

---

Novo valor para desenvolvedores

• DiffusionGemma é um modelo aberto experimental que explora difusão em texto e vai além do processamento sequencial token a token dos LLMs autorregressivos tradicionais, gerando blocos inteiros de texto simultaneamente
• O modelo é um Mixture of Experts (MoE) de 26B disponibilizado sob licença Apache 2.0 e oferece geração de texto até 4x mais rápida em GPU
• Baseia-se na inteligência por parâmetro da família Gemma 4 e na pesquisa Gemini Diffusion, integrando uma nova cabeça de difusão para maximizar a velocidade de geração
• Os modelos Gemma 4 autorregressivos continuam sendo o padrão para saídas de produção de alta qualidade, enquanto o DiffusionGemma foi projetado para pesquisadores e desenvolvedores que exploram fluxos de trabalho locais interativos em que velocidade é crucial

• Trade-offs principais

  • A inferência rápida desloca o gargalo de decodificação da largura de banda de memória para computação, oferecendo saída de tokens até 4x mais rápida em GPUs dedicadas
  • Gera mais de 1000 tokens por segundo em uma única NVIDIA H100 e mais de 700 tokens por segundo em uma NVIDIA GeForce RTX 5090
  • A acessibilidade de hardware vem da arquitetura que ativa apenas 3,8B de parâmetros durante a inferência, de um total de 26B MoE
  • Com quantização, cabe dentro do limite de 18GB de VRAM de GPUs dedicadas avançadas para consumidores
  • A atenção bidirecional gera 256 tokens em paralelo a cada passo direto, permitindo que todos os tokens se referenciem mutuamente
  • Há vantagens em domínios não lineares como edição inline, preenchimento de código, sequências de aminoácidos e grafos matemáticos
  • O autoajuste refina iterativamente a saída para que o modelo corrija erros em tempo real ao avaliar o bloco inteiro de texto de uma só vez
  • O status experimental e a recomendação para produção são claros: como prioriza velocidade e geração paralela de layout, a qualidade geral da saída é inferior à do Gemma 4 padrão

• Exemplo de fine-tuning

  • O desempenho em tarefas específicas pode ser melhorado com fine-tuning
  • A Unsloth fez fine-tuning do DiffusionGemma para resolver Sudoku, uma tarefa difícil para modelos autorregressivos porque cada token depende de tokens futuros
  • A atenção bidirecional do DiffusionGemma torna tarefas como Sudoku muito mais fáceis

Por que usar difusão em texto

• A comunidade de pesquisa em IA explora há anos a geração de texto baseada em difusão, mas aplicá-la a modelos grandes continuava sendo um desafio
• O DiffusionGemma enfrenta esse problema mudando a forma como o modelo usa o hardware

• Trade-offs em relação aos modelos existentes

  • A maioria dos modelos de linguagem gera um token por vez, da esquerda para a direita, como uma máquina de escrever
  • Na nuvem, esse método é eficiente porque o servidor pode agrupar solicitações de milhares de usuários e compartilhar a carga do hardware
  • Quando um único usuário roda localmente, a geração palavra por palavra não aproveita totalmente uma GPU ou TPU dedicada, e o hardware passa muito tempo esperando a próxima “tecla”
  • O DiffusionGemma rascunha ao mesmo tempo um parágrafo inteiro de 256 tokens, entregando blocos de trabalho maiores ao processador do computador de uma vez
  • Essa estrutura transforma a inferência do modelo de uma máquina de escrever sequencial em uma grande prensa que imprime blocos inteiros de texto de uma só vez

• Ganho de velocidade voltado para inferência local e de baixa concorrência

  • O ganho de velocidade do DiffusionGemma foi projetado para inferência local e inferência com baixa concorrência
  • Em serving em nuvem com QPS alto, modelos autorregressivos também podem ser implantados de forma a saturar a computação com eficiência
  • Em ambientes de QPS alto, a vantagem da decodificação paralela do DiffusionGemma diminui, e o custo de serving pode ser maior
  • A vantagem de throughput é mais forte em tamanhos de batch baixos a médios em um único acelerador

Como a difusão em texto funciona

• Difusão em texto aplica ao texto um processo semelhante ao da geração de imagens por IA, que começa com ruído visual e o melhora iterativamente até formar uma imagem nítida
• Na primeira etapa, a tela, o modelo começa com uma tela composta por tokens placeholder aleatórios
• Na etapa de refinamento iterativo, o modelo faz várias passadas, fixa os tokens corretos e usa isso como pista de contexto para refinar o restante
• Na etapa final de refinamento, o texto converge para uma saída de alta qualidade
• Como o modelo consegue processar um parágrafo inteiro durante a geração, torna-se possível fechar corretamente formatação complexa em Markdown ou gerar e renderizar código quase em tempo real

Como começar

• Os pesos do modelo experimental são disponibilizados sob a licença permissiva Apache 2.0 e podem ser acessados no Hugging Face
• É possível ver como integrar no guia para desenvolvedores do DiffusionGemma, e entender melhor seus mecanismos internos em A Visual Guide to DiffusionGemma
• O serving do modelo pode ser feito com MLX, vLLM, Hugging Face Transformers
• A integração com vLLM conta com apoio da Red Hat
• Para experimentação rápida, há um tutorial de fine-tuning baseado no Hackable Diffusion, um toolkit modular em JAX projetado para composabilidade
• O fine-tuning também pode ser explorado com Unsloth e NVIDIA NeMo
• O suporte oficial ao llama.cpp será disponibilizado em breve

Otimização e ambiente de execução

• Em colaboração com a NVIDIA, houve otimização em toda a pilha de hardware, oferecendo compatibilidade e desempenho tanto em ambientes de consumo quanto em sistemas corporativos
• O ambiente de consumo oferece suporte a quantização para GPUs GeForce RTX 5090 e 4090
• O ambiente corporativo oferece alto desempenho em Hopper e Blackwell com kernels avançados NVFP4
• NVIDIA DGX Spark e DGX Station para implantações locais em desktop, além da RTX PRO para profissionais de IA, também estão entre os alvos
• O suporte nativo a ponto flutuante de 4 bits NVFP4 acelera o throughput computacional, permitindo que o modelo rode mais rápido e com precisão quase sem perdas
• É possível escolher entre executar em GPU dedicada de desktop, Gemini Enterprise Agent Platform Model Garden, ou NVIDIA NIM

[GN⁺]

Comentários do Hacker News

• Mudei recentemente para o OpenCode e passei a usar bastante modelos que não são dos principais laboratórios de fronteira dos EUA; inesperadamente, o modelo de que mais gostei foi o Mercury
  Não porque fosse “inteligente”, mas porque era absurdamente rápido. Em vez da experiência moderna, estilo agente, de mandar um prompt e esperar, era mais próximo de programação em par, e isso trouxe de volta um pouco da sensação de codar da era pré-AI, mantendo as vantagens da AI, então ficou mais divertido. Não parecia uma caça-níquel em que você manda o prompt, espera e torce para a direção estar certa; também acabei usando com mais frequência modelos pequenos como Gemini Flash Lite e GPT Mini/Nano. Estou animado para ver um modelo de pesos abertos saindo e pretendo testar assim que possível

  • Se você consegue rodar testes de forma rápida e barata, e também criar rapidamente métricas de baixo custo para identificar código ruim ou mal feito, então, quando tempo importa, um modelo mais rápido e um pouco inferior pode ser melhor do que um modelo muito melhor, porém lento
    Usei métricas que medem complexidade real, e não complexidade ciclomática, e configurei reversão automática até que a complexidade adicional introduzida ficasse dentro de uma faixa razoável em relação à funcionalidade; os resultados com LLM foram bem bons
  • Mercury-2 é excelente. Tenho usado bastante como árbitro no llm-consortium
    A janela de contexto é relativamente pequena, então, para usá-lo em consórcios maiores, dá para montar algo parecido com um meta-consórcio recursivo:
    llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
    Agora, ao enviar um prompt para cns-meta-glm-kimi, ele escolhe o melhor entre 5 do kimi e 5 do glm, e depois sintetiza as duas respostas vencedoras
  • Fico curioso sobre o impacto disso em modelos locais para programação. Se você usar um modelo de difusão várias vezes mais rápido que Qwen ou Gemma 4, vou precisar me preparar mais, como era antes da AI, mas isso talvez seja até melhor, e parece que daria para trabalhar com um modelo local muito rápido e barato
    Se ele não fizer computação pesada por muito tempo, imagino que o custo de rodar em hardware local também não ficaria mais barato?
  • Entendo exatamente o que você quer dizer. Em projetos pessoais, fiquei frustrado com a lentidão do Claude e troquei para Google Antigravity e modelos Flash; a diferença de velocidade é enorme
    Entro melhor no fluxo e consigo me concentrar mais no trabalho. Não imaginava que velocidade faria tanta diferença. Em codebases muito grandes e complexas, o tempo de resposta lento do Claude pode valer a troca pela capacidade de lidar com tarefas mais complexas, mas Antigravity e outros modelos rápidos se encaixam muito melhor quando você quer iterar escrevendo, executando e depurando código pequeno e leve
  • Sim, velocidade é a chave. É ótimo gerar POJOs boilerplate ou data classes a uns insanos 300+ tok/s, e, nesse tipo de cenário, Flash-Lite é mais útil que GPT-5.5
    Se for lento demais, você fica preso naquele maldito loop assíncrono de espera

• O Google continua mostrando força. Surpreende que o Gemini não seja mais competitivo que Claude ou os modelos da OpenAI para código ou uso com agentes, mas está claro que o Google ainda tem talentos de AI de nível de elite
  Ao mesmo tempo, parece que o Google está mais focado em casos de uso para rodar no celular ou quase em tempo real do que em LLMs gigantes de raciocínio. Esse tipo de ganho de eficiência tem grande chance de ser muito importante para a AI daqui para frente. A época em que davam tokens baratos quase como subsídio para te prender a um ecossistema está acabando, e o momento de pagar o custo real está chegando. Vai ganhar a empresa que descobrir como rodar modelos realmente inteligentes com eficiência de custo. O DeepSeek custa mais de uma ordem de magnitude a menos que GPT 5.5 ou Opus 4.8 e, embora seja pior que os dois, não é desastrosamente pior. Se o melhor modelo de código realmente economizar bastante tempo humano, eu pagaria 10x sem problema, mas uma diferença de 100x é difícil de aceitar, como em benchmarks recentes em que o GPT 5.5 Pro saiu mais de 200x mais caro que o DeepSeek e cerca de 30x mais caro que o Opus 4.8

  • Fable custa o dobro do Opus e parece até bem competitivo com o GPT-Pro, então, se os mecanismos de segurança excessivamente sensíveis não forem um grande problema, pode ser uma opção razoável
    O Google também tem sua própria opção de “Deep Research” nessa área, e aparentemente funciona bem. O lado bom do DeepSeek é que dá para rodá-lo em hardware local sem custo de API. Se isso for importante para você, ele ser um pouco pior que Opus ou GPT não é um grande problema
  • No fim, acho que o Google vai vencer. Está focando nas partes que importam: desempenho por watt e desempenho por dólar
    Está construindo seu próprio hardware de inferência e indo para edge computing para reduzir latência e overhead computacional. Os LLMs grandes ainda não são eficientes em custo, e o Google está deixando os concorrentes queimarem capital para “vender” ao consumidor abaixo do custo. Mesmo depois de a bolha da AI estourar, empresas como o Google continuarão firmes, e essa bolha parece estar tentando arrancar a casca de alguns gigantes

• Algumas reações estão deixando passar as vantagens da abordagem por difusão. Isso pode ter um grande impacto em dispositivos de borda como celulares ou GPUs de computador
  O decodificador de um LLM precisa considerar todos os tokens anteriores, então calcula um token de cada vez. Decodificadores de LLM tradicionais escalam bem quando a carga é suficiente para agrupar várias inferências em batch, e nesse ambiente as vantagens da difusão são limitadas. Na borda, o problema é diferente. O acelerador de inferência fica faminto, movendo continuamente pesos na casa dos GB da RAM. RAM de consumo como LPDDRx/GDDRx tem menos largura de banda que HBM, e como as requisições são seriais, não dá para agrupar em batch o cálculo dos pesos compartilhados. A difusão pode calcular tokens em paralelo, aliviando o gargalo de largura de banda de memória

  • Dispositivos de borda não sofrem só com falta de largura de banda de memória, mas também têm desempenho computacional muito limitado. Na prática, mesmo sem muito batch, o volume de operações possível satura rapidamente e bate em limites claros de calor e energia
    Também não é verdade que, em inferência na borda, “as requisições são intrinsecamente seriais”. Há vários pedidos ao mesmo tempo, ou seja, vários chats em andamento, e se houver memória suficiente para manter o cache KV, o processamento em batch pode ser aplicado. Se um modelo de difusão entrega qualidade inferior com mais computação e a economia de largura de banda de memória também é duvidosa, não vejo bem como isso ajuda
  • Em geral está certo, mas está misturando atenção com a estrutura autorregressiva/causal. O verdadeiro problema que impede usar mais computação é a estrutura autorregressiva/causal
    Difusão também pode usar atenção, e este modelo de fato usa atenção

• A NVIDIA está oferecendo um endpoint gratuito para esse modelo. Mais detalhes em https://build.nvidia.com/google/diffusiongemma-26b-a4b-it, e é preciso criar uma conta e provavelmente também fazer verificação por telefone
  Também tentei fazer ele desenhar um pelicano: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

  • Se for um modelo realmente rápido, talvez dê até para pedir quadros de animação. Por exemplo, no quadro 1 o pé direito às 12 horas e o esquerdo às 6, no quadro 2 o pé direito às 3 e o esquerdo às 9
    Aí, em vez de tokens por segundo, o correto seria reportar quadros de pelicano por segundo
  • Eu me registrei há algumas semanas, mas mesmo seguindo o processo minha conta ainda não foi verificada. Sem a conta verificada, não dá para usar a API

• Uma boa explicação visual de como modelos de difusão de texto como o DiffusionGemma funcionam: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

• Até poucos dias atrás eu achava que o Google simplesmente não falava nada sobre o modelo de geração de texto por difusão que mostrou na I/O um ano atrás
  Havia rumores de que era caro demais para rodar, mas se compararem DiffusionGemma e Gemma normal no mesmo hardware 1x H100, como no gráfico fornecido, não parece ser o caso. Fico me perguntando qual é a desvantagem dessa velocidade, além de ele ser um pouco pior que o Gemma

  • Acho que a resposta para “Fico me perguntando qual é a desvantagem dessa velocidade” é esta parte:
    “O ganho de velocidade do DiffusionGemma foi projetado para inferência local e de baixa simultaneidade. Em serving em nuvem com alto QPS, modelos autorregressivos podem ser agrupados em batch com eficiência para saturar a computação, então a vantagem de decodificação paralela do DiffusionGemma diminui e o custo de serving pode ser maior”
  • Num modelo autorregressivo padrão, se houver 256 usuários, é possível gerar por exemplo 256 tokens de uma vez. Este método consegue gerar 256 tokens para um único usuário, mas exige várias etapas de forward pass
    Então o processo de difusão usa mais GFLOPs e, se houver usuários suficientes, já dá para equilibrar memória e computação

• “O DiffusionGemma inverte essa ineficiência. Em vez de prever palavras sequencialmente, ele cria ao mesmo tempo um rascunho do parágrafo inteiro de 256 tokens. Ao dar blocos de trabalho maiores de uma vez para o processador do computador, ele aproveita o hardware ao máximo. É como atualizar a inferência do modelo de uma máquina de escrever digitando caractere por caractere para uma enorme impressora que produz blocos inteiros de texto de uma só vez”
  “Ele opera como um modelo mixture-of-experts (MoE) de 26B no total, com apenas 3.8B parâmetros ativados durante a inferência, e quantizado cabe com folga dentro do limite de 18GB de VRAM de uma GPU dedicada de consumo avançada”
  Então o Gemma 4 26B é um modelo MoE que roda muito rápido na minha GPU de 24GB com ollama. Isso soa como speculative decoding, mas eu achava que isso não funcionava em modelos MoE. Para quem não trabalha acompanhando isso, está difícil seguir tantas mudanças

  • Este é um modelo diferente que, de forma confusa, tem quase a mesma contagem de parâmetros do gemma4 MoE existente. Numa leitura rápida, não ficou claro de que maneira um dos dois foi treinado a partir do outro, se é que foi
    O mecanismo não é o mesmo de speculative decoding. Speculative decoding é sequencial, normalmente alguns tokens por vez. Difusão não é assim: ela lida com o bloco de texto inteiro de uma vez. Ainda não li o material, mas suponho que eles tenham treinado para manter certos especialistas estáveis ao longo de todo o bloco de difusão

• Na minha 3090 Ti ele não chega nem perto da velocidade anunciada, mas é divertido ver a resposta sendo “preenchida”
  Testei o caso do “pelicano em SVG numa bicicleta” do Simon, e o resultado ficou bem minimalista, mas atendeu aos requisitos: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- foi rodado com quantização Q4 em um llama.cpp com patch. Também fiquei curioso se o resultado do Simon é muito diferente

• Como seria um modelo de raciocínio por difusão? Seria algo como difundir por bastante tempo um bloco [thinking] de comprimento pré-definido, e então usar o conteúdo desse bloco de thinking como parte da entrada para o bloco de saída final?
  E, para começo de conversa, como um modelo de difusão define o comprimento da saída? É um parâmetro definido de antemão, ou ele difunde um token [end] em algum ponto no meio? Fiquei curioso

  • Lendo o restante dos comentários, consegui pelo menos uma resposta. Faz sentido que o próprio processo de difusão seja, em essência, um processo parecido com raciocínio: https://www.inceptionlabs.ai/blog/introducing-mercury-2

• É legal, mas mesmo quando os modelos locais já são razoáveis, na prática eles ainda parecem claramente inferiores até à API mais barata, então não me anima muito a ideia de sacrificar nem que seja um pouco da qualidade por velocidade
  Com certeza deve ter valor para alguns casos de uso, mas queria ver exemplos concretos de casos em que isso seria realmente colocado em produção

  • Pode ser bom para escrever testes unitários ou para bootstrap
    Mesmo sem ser nível Opus, já dá para escrever e também é fácil iterar