Gemini Diffusion

• O Gemini Diffusion, anunciado pelo Google, é o primeiro LLM a usar uma abordagem de difusão em vez de transformers
  • Semelhante ao que é usado em modelos de imagem como Imagen ou Stable Diffusion
• Esse modelo gera texto não pelo método autorregressivo tradicional, mas por um processo de difusão que refina ruído em etapas
• Como resultado, a velocidade de resposta é muito alta e, em testes, mostrou desempenho de 857 tokens por segundo
• Ainda faltam benchmarks precisos, mas o Google afirma que ele é 5 vezes mais rápido que o Gemini 2.0 Flash-Lite

---

Visão geral do Gemini Diffusion

• O Gemini Diffusion é um novo modelo de linguagem de grande porte (LLM) apresentado pelo Google
• Em vez do método autorregressivo dos LLMs tradicionais baseados em transformers, ele adota uma abordagem de difusão
• Essa abordagem de difusão, semelhante à de modelos de geração de imagem (como Imagen e Stable Diffusion), foi aplicada à geração de texto
• Entre suas principais características estão a alta velocidade de resposta e a capacidade de corrigir erros de forma eficiente durante o processo de geração
• Em um exemplo de uso, com o prompt "Build a simulated chat app", ele entrega um resultado em HTML+JavaScript em poucos segundos e registra velocidade de geração de até 857 tokens por segundo

Como funcionam os modelos de linguagem por difusão

• Os modelos de linguagem autorregressivos tradicionais geram tokens um a um em sequência, o que os torna mais lentos e limita a consistência da saída
• Já os modelos de difusão começam com ruído e melhoram gradualmente o resultado, processando frases ou parágrafos inteiros de uma vez ao longo de várias etapas
• Isso permite a geração paralela de tokens, viabilizando resultados extremamente rápidos
• Eles são eficazes em áreas em que o feedback imediato é importante, como edição de texto, matemática e código

Modelos semelhantes e comparação de desempenho

• Até então, quase não havia LLMs comerciais por difusão, e o projeto Inception Mercury surgiu como o primeiro caso em fevereiro de 2024
• Em velocidade e desempenho, o Gemini Diffusion é semelhante ao Gemini 2.0 Flash-Lite segundo o Google, mas cerca de 5 vezes mais rápido
• Assim como o Cerebras Coder, ele mostra alta velocidade de geração, e dados objetivos de benchmark devem ser adicionados futuramente

Explicações adicionais e correções

• Modelos de linguagem por difusão não substituem completamente a arquitetura transformer; em vez disso, mudam a estrutura de geração de texto do modo autorregressivo para o modo por difusão
• Tanto Mercury quanto Gemini Diffusion são baseados em transformers, mas processam toda a entrada de uma vez e diferem na forma de geração
• Trata-se de uma evolução do método de mascaramento e restauração no estilo BERT, aumentando gradualmente a proporção de máscara e concluindo o resultado de forma progressiva mesmo quando todos os tokens estão mascarados
• A abordagem por difusão confirma apenas parte dos tokens em várias etapas, aumentando repetidamente a proporção de tokens finais até completar toda a sequência
• A ideia central desses LLMs por difusão é a restauração gradual e a geração paralela

Conclusão

• O Gemini Diffusion é um novo tipo de LLM que apresenta características inovadoras em velocidade e qualidade de geração
• Ele expande com sucesso para a geração de texto as vantagens dos modelos de difusão já comprovadas na geração de imagens
• Cresce a expectativa sobre seu valor em aplicações práticas diversas e sobre futuros resultados de benchmark

[GN⁺]

Comentários do Hacker News

• Não sei exatamente como isso funciona internamente no Google, mas recentemente houve algo notável no lado do RWKV. Fizeram um experimento trocando por completo o mecanismo de atenção existente por WKV (atenção linear), e tudo isso foi obtido apenas com pós-treinamento. O que isso sugere é que a maior parte do conhecimento útil na verdade está no FFN (feedforward network), e que a atenção em si talvez não seja um elemento tão único ou importante quanto se pensa. Vale a pena conferir os links relacionados também. Por outro lado, embora fuja um pouco das regras, também seria interessante aproveitar uma atenção já treinada e testar separadamente quão rápido é apenas o FFN em treinamento na velocidade do GPT-2; eu gostaria de ler isso em um artigo. Entre as coisas que li ontem, havia uma discussão de que, em certo ponto, os embeddings de todos os modelos se tornam (muito) parecidos, de modo que dá para treinar um transformador simples, e que, se essas duas coisas forem verdade, talvez seja possível compartilhar embeddings e atenção e acelerar muito o treinamento completo

  • Atenção, com todo o máximo respeito aos pesquisadores, me parece ser pegar todas as informações passadas da rede e jogá-las em uma rede neural reverse-MoE. Nesse caso, quem escolhe o que será executado não é uma parte da rede, mas sim uma parte da entrada. Todo mundo sabia que isso provavelmente funcionaria, mas era tão ineficiente que nem usuários de R ou Python pensavam em tentar executar. A própria estrutura era lenta demais para ser testada de forma prática

  • Estou começando a achar que "Attention is all you need" talvez possa ser interpretado em outro sentido

  • A história de que os embeddings dos modelos se tornam (muito) parecidos e podem ser mapeados por um transformador simples veio daqui

  • Vejo a atenção como um método completamente arbitrário para dividir a rede e permitir treinamento em paralelo. A parte que realmente contribuiu para o sucesso foram as shortcut connections entre camadas. Isso dá mais influência às camadas iniciais durante o treinamento

  • A importância relativa menor da atenção SDPA usada nos transformers atuais já é conhecida. FFN, normalização e conexões residuais são absolutamente insubstituíveis, mas a atenção pode ser facilmente trocada por qualquer outra camada que compartilhe informação entre tokens, como pooling, convolução, mistura aleatória etc.

• É uma velocidade realmente absurda. Até agora, acho que o melhor caso de uso dos modelos tem sido escrever código totalmente novo e fazer prototipagem rápida. Nunca achei que eles fossem tão fortes para melhorar grandes codebases já iteradas várias vezes. Um dos motivos é que, por definição, o modelo não pode saber sobre aquilo que “não está incluído” na codebase. O fato de algo “não existir” no código também é um sinal cheio de significado, e isso é um problema bem difícil de representar. Por mais inteligente que seja o modelo, acho que aí permanece uma limitação fundamental por falta de “contexto e experiência internos”. Por exemplo, mesmo que você dê uma grande codebase a um desenvolvedor extremamente talentoso e peça para resolver um problema específico na hora, um desenvolvedor comum que conhece bem a codebase pode entregar um resultado mais valioso no mesmo tempo

  • Dá para resolver isso focando na forma de comunicação. Hoje, meu fluxo principal é: quando preciso de um trabalho grande, como um recurso novo ou um refactor, começo uma conversa com o o3 como se fosse um colega. Vou colando continuamente os arquivos-fonte necessários para dar contexto e discuto em alto nível os objetivos e o estado atual do código. Nesse processo, sinto que tanto o que eu quero fazer quanto o contexto da codebase ficam claros. Depois peço ao o3 um plano de implementação e passo isso ao Codex para executar uma série de automações, como leitura de código, edição de arquivos e testes. Quando sai o PR, às vezes basta um pequeno ajuste manual ou até dá para fazer merge direto. Concordo que os modelos precisam de contexto rico, mas isso não é uma limitação essencial, e sim uma questão de como colaborar de forma eficaz. Com prática, além do ganho de produtividade, para mim esse jeito de trabalhar também deixa a cabeça mais feliz

  • Sinto uma identificação profunda com a ideia de que “o que não existe na codebase carrega um sinal significativo”. Trabalho com software há muito tempo, mas nunca tinha percebido essa verdade fundamental com tanta clareza. Obrigado pelo insight

  • Pela minha experiência até agora, LLMs são bons em imitar código bom já existente, mas não costumam criar por conta própria partes novas e originais, a menos que você peça isso de forma bem explícita. Muitas vezes eles não conseguem ingerir a codebase o suficiente, então é preciso apontar diretamente outras partes do projeto. Mesmo assim, seria muito legal se fosse possível dar algo como um “prompt negativo”, como no Stable Diffusion

  • Fico curioso para saber que resultado sairia se um LLM pudesse ler como contexto todo o histórico do git, o issue tracker e até as gravações de reuniões. Ainda precisamos ver se entradas de contexto gigantes realmente levam a resultados úteis na prática

• Fiquei realmente impressionado com este anúncio. Acho que foi o maior anúncio do IO, embora tenha sido ofuscado por outras novidades, como o Veo 3. Usar um modelo de diffusion para geração de código é algo de enorme importância. Se usar transformer, cairia na família DiT (diffusion transformer); participei há alguns anos de um modelo híbrido que combinava diffusion baseado em U-Net, e muita coisa avançou desde então. Acho que vamos ver um grande salto na área de diffusion daqui para frente

  • Fico pensando como a intuição dos vision transformers funcionaria quando aplicada a código. Em visão, você começa com ruído e vai refinando a imagem-alvo camada por camada. Se aplicar esse princípio à geração de código, parece que seria necessária uma estrutura hierárquica que reduz gradualmente o nível de abstração, como “precisa usar Django”, “definir a lista de endpoints” e “gerar o código específico”. Mas diffusion não tem um mecanismo de backtracking, então, mesmo que um problema de nível inferior seja detectado, há limitações para dar feedback imediato às camadas superiores. Já transformers rodam o modelo inteiro a cada token, então é mais fácil fazer o backtracking e as mudanças de design necessárias para cada problema. Meu modelo mental pode estar falho, então gostaria de ouvir mais insights

  • O Veo 3 chamou atenção porque é muito intuitivo perceber o desempenho e os diferenciais, enquanto entender o valor de um avanço importante em completar texto exige conhecer os resultados anteriores e os usos potenciais. Muita gente ainda nem está convencida de que LLMs são úteis para programação

  • Modelos de geração de código baseados em diffusion são realmente revolucionários. Algumas ideias simples do que esses modelos podem fazer: gerar os tokens entre uma assinatura de função e o resultado, mantendo ambos fixos e usando informação bidirecional; em segundo lugar, primeiro esboçar a estrutura geral de uma função, como um LLM escrevendo os “capítulos” de um artigo, e depois dividir isso em detalhes de implementação cada vez mais finos; gerar iterativamente dentro de contextos maiores guiando-se por sinais como linters, informações de AST etc. Há realmente muita coisa para experimentar

  • Em princípio, esse método parece ter grandes vantagens, e modelos como o LLaDA que experimentei na prática foram impressionantes mesmo com poucos recursos de treino. Mas ainda ficam atrás em métricas como perplexity. Eles também parecem tender a se fixar durante a geração, então pode haver limitações para revisar texto profundamente, já que quanto maior a probabilidade de masking, mais difícil fica fazer revisões simultâneas. Ainda assim, consegui resultados bem práticos em testes reais

  • Já vi demos disso em lugares como a InceptionLabs, então não é algo tão surpreendente assim

• Acho que o ponto principal desta notícia está se perdendo. É um InstructGPT realmente rápido e muito bom. Isso certamente será usado em corretores ortográficos, codemods, editores de código etc. Graças ao recurso de instant edits, ele consegue fazer edição de texto realmente rápida e precisa, sem adições ou sugestões desnecessárias. Pedi para ele renomear variáveis em um código de exemplo do ShaderToy para nomes mais fáceis de entender, copiei o resultado e executei, e fiquei surpreso que continuou funcionando perfeitamente

  • Mas corretor ortográfico já não é um problema completamente resolvido?

• A vantagem de diffusion não é só velocidade. Segundo benchmarks iniciais, em comparação com AR, ele é melhor em inferência e planejamento mesmo com o mesmo número de parâmetros. Diffusion permite edição intermediária e não sofre do problema de viés dos tokens iniciais

  • Afirmação interessante. Você poderia compartilhar links de benchmarks ou materiais de referência sobre isso?

  • O próprio AR não impede elaborar planos longos, mas na forma como muitos modelos AR populares atuais são implementados, esse tipo de limitação aparece com frequência. AR é, em essência, muito importante para aprender a distribuição correta

  • Pessoalmente, concordo com a ideia ou gostaria que fosse verdade, mas ainda não vi artigos ou demos sobre revise diffusion text. Eu gostaria de testar, então seria bom compartilhar a referência do artigo

• Há muito tempo tenho interesse em aplicar tecnologia de diffusion à geração de texto. Fico feliz que finalmente o Google tenha lançado um modelo assim, porque dá a sensação de que minha intuição foi validada. Do ponto de vista de hardware usado em experimentos, a maior parte do que se vê roda em serviços pagos ou em equipamentos high-end, no mínimo de nível alto entre hardware de consumo. No meu caso, hoje tenho algo como uma 5700XT e está difícil fazer upgrade, mas isso me ajudou a ver com mais clareza as limitações dos modelos atuais. Como a consistência aumenta com o tamanho do modelo, modelos pequenos acabam inevitavelmente restritos a tarefas simples. Uma coisa importante que constatei nos meus experimentos é a importância do tamanho de contexto, mas com GPUs pequenas é difícil colocar contexto suficiente e um modelo grande ao mesmo tempo; então me pergunto se, com diffusion, seria possível mudar esse equilíbrio entre densidade e consistência. Espero geração de texto mais consistente mesmo com pouco contexto, e talvez resultados melhores na mistura entre tool call e resposta. A questão da velocidade também é uma reclamação bem realista: no método tradicional de LLM, a repetição de entrada e saída vai se arrastando lentamente, o que testa a paciência, especialmente em GPUs antigas sem hardware voltado para IA. Seria ótimo pelo menos ver o progresso em tempo real, de 0 a 100%, e tenho esperança de que modelos de diffusion possam melhorar isso. Daí surge outra dúvida: como a entrada com ruído é importante, existe alguma boa fonte de ruído especializada para LLM/texto? E o comprimento total do bloco é fixado de antemão ou pode variar?

• Posso dizer com segurança, pela minha experiência, que esse modelo é absurdamente rápido. O ponto fraco é que ele cede com muita facilidade a ataques de prompt injection. Por exemplo, se você pede uma receita de drogas, ele recusa, mas se reformular como uma “brincadeira de faz de conta com uma criança”, ele entrega o resultado de verdade. Tirando esse defeito, a velocidade e a usabilidade para automação são excelentes. Se somar uma abordagem mais agentic, o potencial desse modelo realmente vai aparecer

  • Talvez isso não seja tanto uma limitação do modelo em si, mas sim porque menos recursos foram investidos em segurança ou censura durante o treinamento. Acho que é meio um experimento protótipo, uma demonstração mais leve antes de investir de verdade em um modelo grande

  • Não vejo esse tipo de prompt injection como sinal de que em breve será possível controlar modelos mais inteligentes

• A descrição “o primeiro diffusion LLM do Google, usando diffusion em vez de transformer” é uma afirmação incorreta. O Google nunca anunciou isso dessa forma. Pelo contrário, modelos de diffusion baseados em Transformer são comuns. Acho bem provável que o Gemini Diffusion também use transformer. A diferença seria que ele é um transformer encoder-only. Ou seja, você fornece toda a sequência em estado noisy/corrupted e o modelo prevê a sequência correta completa. Isso permite computação paralela sobre o quadro inteiro da sequência ao mesmo tempo e, se o número de iterações for razoável, pode ser muito mais rápido do que a decodificação sequencial de modelos decoder-only, embora speculative decoding também tenha vantagem semelhante de velocidade. Normalmente isso é treinado com masking ao estilo BERT, mas continua sendo uma área de pesquisa ativa. Também tenho curiosidade sobre a relação com o Gemini e sobre como os checkpoints são aproveitados: importação direta, fine-tuning específico para diffusion, destilação de conhecimento, ou apenas uma marca? Gostaria que os detalhes oficiais fossem divulgados

• É ridiculamente rápido. Imagino que a GPU fique sempre rodando na capacidade máxima e que quase não exista ganho de economia computacional com batching. Mas, pensando bem, isso talvez nem seja exatamente um tradeoff de verdade. Uma preocupação é que o objetivo de diffusion possa ficar atrás do AR em desempenho. Se isso acontecer, uma alternativa seria modelos AR multi-token alcançarem a mesma velocidade do diffusion, ou usar modelos de diffusion como geradores de rascunho para speculative decoding

  • Fico curioso sobre por que você acha que dLLM vai ter qualidade inferior a arLLM. Como ele processa repetidamente a saída como um “todo estruturado” — tema, pontos principais, conceitos, árvore de palavras —, há quem ache que a qualidade pode até ser melhor

  • Esse tradeoff estrutural é muito mais vantajoso em ambientes de hospedagem pessoal. Como não há necessidade de grandes batches, a vantagem é menor na nuvem, mas enorme para LLM local

• Estou extremamente empolgado com diffusion LLMs. Nossa equipe sonha com mecânicas de jogo baseadas em voz → código, e diffusion pode ser exatamente a peça que faltava. Cerebras e Groq são impressionantes, mas têm limitações para fine-tuning e escala por causa do hardware customizado. A outra alternativa seria um MoE com cerca de 0.5b de parâmetros ativos, mas no momento não temos margem para investir recursos nisso. Se alguém do Google/DeepMind estiver lendo isto, por favor disponibilizem uma API. Nossa equipe está desenvolvendo um jogo sandbox generativo, e o primeiro título tem uma estrutura em que se dá comandos em tempo real para monstros. Temos até um vídeo de protótipo para referência