Gemini Diffusion troca o streaming de tokens da esquerda para a direita por um ciclo de refinamento de todo o output

O que a Google lançou de facto, e o que não lançou

A Google anunciou o Gemini Diffusion como um modelo de investigação experimental, disponível apenas através de uma demonstração com lista de espera. Não se trata de um lançamento geral, e a Google tem o cuidado de o apresentar como uma das várias abordagens que está a testar para reduzir a latência em toda a linha Gemini.

A afirmação concreta é limitada e vale a pena citá-la com precisão em vez de a exagerar. Segundo a Google, a demonstração faz duas coisas em simultâneo.

A demonstração experimental do Gemini Diffusion, lançada hoje, gera conteúdo significativamente mais rápido do que o nosso modelo mais rápido até agora, mantendo o mesmo desempenho na programação.Montana Labs

Nesta frase há duas afirmações mensuráveis: mais rápido do que o modelo mais rápido anterior da Google, e desempenho de programação mantido em paridade em vez de melhorado. A Google não publica, neste artigo, os valores de latência, o modelo de referência ou o benchmark de programação, pelo que a dimensão real de 'significativamente mais rápido' permanece por verificar apenas com base na fonte.

A difusão significa que o output chega de forma diferente, não apenas mais rápido

O método é o verdadeiro tema aqui. A Google descreve o Gemini Diffusion como um modelo que aprende a gerar outputs convertendo ruído aleatório em texto ou código coerente, o mesmo princípio por detrás dos seus modelos de geração de imagem e vídeo. Isto representa um afastamento dos modelos de linguagem autorregressivos, que produzem um token após outro, condicionados por tudo o que veio antes.

Um modelo de difusão refina um output candidato completo através de sucessivos passos de remoção de ruído, em vez de emitir uma sequência da esquerda para a direita. Na prática, isso significa que a forma como o output evolui ao longo do tempo é diferente: em vez de um prefixo que vai crescendo, obtêm-se versões progressivamente mais limpas de um bloco completo.

Porque é que isto afeta primeiro as equipas de frontend

A maioria dos frontends de produtos de AI (mantém-se o acrónimo em inglês) atuais assenta numa premissa: os tokens chegam por ordem, por isso são renderizados à medida que surgem. O efeito de cursor a escrever, a renderização incremental de markdown, os blocos de código parciais que se vão completando linha a linha — tudo isto depende de uma geração autorregressiva que produz um prefixo estável, apenas de acréscimo.

Um modelo de difusão não oferece isso naturalmente. Se os estados intermédios são rascunhos completos que continuam a mudar, o padrão de renderização por acréscimo deixa de corresponder de forma clara ao que o modelo está a fazer. As equipas podem ter de decidir se mostram as passagens de remoção de ruído, se aguardam que o output estabilize, ou se reintroduzem uma camada de streaming sintético por cima.

No caso específico das interfaces de programação, isto tem duas leituras. A afirmação de paridade na programação feita pela Google sugere que a qualidade do código é comparável, mas a forma como esse código é entregue — a chegar como um todo já refinado, em vez de ser escrito progressivamente — altera a forma como uma vista de diferenças, um autocompletar inline ou uma interface de revisão de código devem apresentá-lo. O design de interação que fazia sentido para fluxos de tokens não é automaticamente o design certo para um ciclo de refinamento.

A implicação: a redução de latência está a ser perseguida por dois caminhos incompatíveis em simultâneo

A Google é explícita ao afirmar que o Gemini Diffusion é apenas uma experiência entre várias, e no mesmo artigo aponta para um 2.5 Flash Lite mais rápido, que estará disponível brevemente. Trata-se de um caminho convencional e autorregressivo para reduzir a latência, que mantém intacto o contrato de streaming existente.

Ou seja, a Google está a cobrir várias frentes: modelos autorregressivos progressivamente mais rápidos numa via, e um método de geração fundamentalmente diferente na outra. Para quem constrói sobre o Gemini, isso significa não assumir, a partir de agora, um único contrato de output. Um modelo que faz streaming de tokens e um modelo que remove ruído de rascunhos completos podem ambos ser 'mais rápidos', mas exigem frontends diferentes.

A lista de espera e o rótulo de 'modelo de investigação experimental' são os sinais mais honestos aqui. É ainda demasiado prematuro, e a atitude certa é testar o modelo de interação, não reconstruir um produto em torno de valores de latência que ainda não foram publicados.