Acelerando o Gemma 4: inferência mais rápida com o drafter de predição de múltiplos tokens

 (blog.google)
3 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Google informou que, poucas semanas após o lançamento do Gemma 4, o modelo ultrapassou 60 milhões de downloads e apresentou um drafter de predição de múltiplos tokens (MTP) para a família Gemma 4
  • O drafter MTP usa uma arquitetura especializada de decodificação especulativa (speculative decoding) para aumentar a velocidade de inferência em até 3x sem degradar a qualidade de saída nem a lógica de raciocínio, tendo sido testado em hardware com LiteRT-LM, MLX, Hugging Face Transformers e vLLM
  • Na inferência padrão de LLMs, a necessidade de mover bilhões de parâmetros da VRAM para as unidades de computação para gerar um único token cria um forte gargalo de largura de banda de memória; com MTP, um drafter leve propõe vários tokens futuros e o modelo-alvo os valida em paralelo
  • Se o modelo-alvo concordar com os tokens do rascunho, ele aceita toda a sequência em uma única passagem direta e ainda gera um token extra, permitindo que a aplicação normalmente produza a sequência rascunhada e um token adicional no tempo de um único token
  • O drafter MTP compartilha ativações do modelo-alvo e o cache KV, aplica clustering eficiente do embedder nos modelos de borda E2B e E4B, e seus pesos estão disponíveis no Hugging Face e no Kaggle sob licença Apache 2.0

Por que a decodificação especulativa é necessária

  • A inferência padrão de LLMs é limitada pela largura de banda de memória, o que amplia o gargalo de latência
  • Os processadores acabam gastando a maior parte do tempo movendo bilhões de parâmetros da VRAM para as unidades de computação para gerar um único token
  • Essa estrutura faz com que, especialmente em hardware de consumo, os recursos de computação não sejam plenamente aproveitados e a latência aumente
  • A decodificação especulativa separa a geração de tokens da validação
  • Um modelo-alvo pesado, como o Gemma 4 31B, é emparelhado com um drafter leve, o modelo MTP, para prever vários tokens futuros de uma vez usando recursos de computação ociosos
  • O drafter propõe vários tokens em menos tempo do que o modelo-alvo leva para processar um token, e o modelo-alvo valida os tokens propostos em paralelo

Como o MTP funciona

  • Modelos de linguagem de grande porte padrão geram texto de forma autorregressiva, produzindo exatamente um token por vez
  • Esse método aplica a mesma quantidade de computação tanto a uma continuação fácil, como prever “words” após “Actions speak louder than…”, quanto à resolução de um quebra-cabeça lógico complexo
  • O MTP reduz essa ineficiência com a decodificação especulativa introduzida por pesquisadores do Google em Fast Inference from Transformers via Speculative Decoding
  • Se o modelo-alvo concordar com os tokens do rascunho, ele aceita toda a sequência em uma única passagem direta, e o próprio modelo-alvo também gera simultaneamente um token adicional
  • A aplicação normalmente consegue emitir toda a sequência rascunhada e mais um token adicional no tempo necessário para gerar um único token

Efeitos de desempenho para desenvolvedores

  • Para desenvolvedores, a velocidade de inferência muitas vezes se torna um dos principais gargalos em implantações de produção
  • Em agentes autônomos que exigem planejamento rápido em várias etapas, assistentes de programação e aplicações móveis responsivas executadas totalmente on-device, até latências de milissegundos importam
  • Ao usar modelos Gemma 4 com esse drafter, é possível obter os seguintes efeitos

  • Melhor resposta

    • É possível reduzir significativamente a latência em chats quase em tempo real, aplicações de voz imersivas e fluxos de trabalho agênticos

  • Aceleração do desenvolvimento local

    • Executa mais rapidamente os modelos 26B MoE e 31B Dense em computadores pessoais e GPUs de consumo, dando suporte a programação offline complexa e fluxos de trabalho agênticos

  • Melhor desempenho on-device

    • Faz com que os modelos E2B e E4B gerem saídas mais rapidamente em dispositivos de borda, ajudando a reduzir o consumo de bateria

  • Sem perda de qualidade

    • Como o modelo base Gemma 4 mantém a validação final, ele entrega o mesmo nível de raciocínio e precisão com muito mais velocidade
    • Um exemplo com o Gemma 4 26B rodando em uma NVIDIA RTX PRO 6000 compara os tokens por segundo da inferência padrão com os do drafter MTP e mostra latência reduzida pela metade com a mesma qualidade de saída
    • O vídeo de comparação pode ser baixado

Otimizações internas do drafter MTP

  • Várias melhorias arquiteturais foram aplicadas para tornar o drafter MTP rápido e preciso
  • O modelo de rascunho aproveita naturalmente as ativações do modelo-alvo e compartilha o cache KV do modelo-alvo
  • Graças ao compartilhamento do cache KV, ele não desperdiça tempo recalculando o contexto que o modelo grande já processou
  • Nos modelos de borda E2B e E4B, como o cálculo final dos logits se torna um grande gargalo, foi implementada uma técnica eficiente de clustering no embedder para acelerar ainda mais a geração
  • Também foram analisadas otimizações específicas por hardware
  • No Apple Silicon, o modelo mixture-of-experts 26B tem desafios próprios de roteamento com batch size 1, mas ao processar vários pedidos simultaneamente é possível obter ganho de velocidade local de até cerca de 2,2x
  • Os tamanhos de batch de exemplo ficam entre 4 e 8, e melhorias semelhantes aparecem na NVIDIA A100 quando o batch size aumenta
  • O funcionamento da arquitetura visual, do compartilhamento do cache KV e do embedder eficiente pode ser visto na explicação técnica aprofundada

Como usar e onde está disponível

  • O drafter MTP para a família Gemma 4 é oferecido sob a mesma licença open source Apache 2.0 do Gemma 4
  • A forma de usar o MTP com o Gemma 4 pode ser consultada na documentação
  • Os pesos do modelo podem ser baixados no Hugging Face e no Kaggle
  • A inferência mais rápida pode ser testada com transformers, MLX, vLLM, SGLang e Ollama
  • Também é possível experimentar diretamente no Google AI Edge Gallery para Android ou iOS
  • O Google espera que esse ganho de velocidade acelere o desenvolvimento no Gemmaverse, o ecossistema do Gemma

Leituras relacionadas

1 comentários

 
GN⁺ 1 시간 전
Comentários do Hacker News

  • Gemma e Gemini usam muito menos tokens de saída do que outros modelos, mas ainda chegam bem perto do desempenho de ponta nos benchmarks
    Comparando Gemma com Qwen, o Qwen se sai um pouco melhor, mas gasta 22 minutos na tarefa, enquanto o Gemma frequentemente termina o mesmo prompt em 4 minutos, mesmo errando o alinhamento de botões
    Na prática, o Gemma parece ter um desempenho 5–10% inferior ao dos principais modelos abertos, mas usando apenas 1/10 do tempo

    • Pela minha experiência, mesmo codando o dia inteiro com o plano básico do Gemini de US$ 15 por mês, não chego no limite
      Nem sinto necessidade de fazer upgrade como outras pessoas que postam sobre planos de US$ 100 por mês no Claude ou Codex
      Dito isso, o Gemini perdeu desempenho algumas vezes ao longo do último ano e os limites de taxa também ficaram mais rígidos, então não sei se vai continuar tão bom assim
    • No podcast do Dwarkesh, Dylan Patel, da SemiAnalysis, disse que o Google consegue sustentar modelos maiores do que os concorrentes graças a muito mais recursos de computação e acesso a TPUs
      Como modelos maiores normalmente usam menos tokens para o mesmo nível de inteligência, isso parece explicar a diferença no uso de tokens
    • Como o Gemma é rápido, dá para rodar até em GPUs que originalmente ficariam pequenas demais
      Testei numa 4070, e embora a saída não seja absurdamente rápida, foi utilizável
      Ainda não experimentei em tarefas complexas, então talvez aí seja diferente
    • Hoje o Claude está muito em alta, mas nunca tive problemas usando Gemini nem senti necessidade de trocar
      Depois do Google I/O, talvez mais gente perceba o quão bom o Gemini é
    • Isso faz sentido, mas para ser justo seria preciso somar o volume acumulado de tokens gerados
      Se surgir um problema de alinhamento, você precisa gastar tokens de entrada e saída mais uma vez para corrigir

  • O suporte a MTP está sendo adicionado ao llama.cpp e, pelo menos para os modelos Qwen, o trabalho está em andamento (https://github.com/ggml-org/llama.cpp/pull/20533)
    O Gemma 4 provavelmente vem logo em seguida
    A melhora de qualidade e velocidade dos modelos locais/autohospedados nos últimos meses tem sido impressionante

    • Há um PR mais recente e parece que deve ser integrado em breve: https://github.com/ggml-org/llama.cpp/pull/22673
    • Há alguns dias voltei do Qwen3.6 para o Gemma 4 para uso pessoal, e a versão 26B do segundo mostrou desempenho melhor, em média, do que o 27B do primeiro
      Para quem roda modelos locais há bastante tempo, é uma fase realmente interessante
    • Também há bastante interesse na integração do DFlash: https://github.com/ggml-org/llama.cpp/issues/21978
      Quero muito ver como isso vai se comparar ao MTP
    • Também queria ver isso no oMLX
      Era uma ferramenta bem decente
    • Não sei exatamente em que parte da pilha de inferência o MTP entra, mas fico curioso se alguém sabe se isso seria implementável no ecossistema MLX

  • O Google está praticamente carregando sozinho os modelos open source do Ocidente
    O Gemma 4 31B é excelente
    Mas encaixar a melhor versão, incluindo visão e o drafter que está para sair, em 24 GB de VRAM é bem sofrido
    Minha máquina não permite adicionar mais GPUs, e para tirar o máximo de desempenho eu provavelmente teria que comprar outra 4090, o que é caro demais, ou então trocar tudo de vez

    • No llama.cpp, se você usar --no-mmproj-offload, pode deixar o projetor multimodal — isto é, a parte de entendimento de áudio, imagem e PDF — na RAM do sistema
      Claro, aí você perde a aceleração por GPU, mas economiza VRAM
    • Ainda assim, acho que o Qwen é melhor que o Gemma
      Também dá para ajustá-lo mais por tarefa, então você pode escolher entre priorizar raciocínio e precisão ou velocidade de inferência

  • Ver o computador escrevendo texto me lembra os tempos de acessar BBS com modem
    Isso parece uma grande melhoria, como passar de 300 baud para 1200 baud, mas ainda é bem lento, e um dia provavelmente vamos achar estranho como conseguimos tolerar isso

    • O estado atual realmente parece a era da internet discada, e eu fico pensando como seria a futura era da “banda larga”
      Ver os tokens saindo lembra ver um JPEG carregando em algumas linhas de pixels por vez, e também faz lembrar todas aquelas animações de carregamento e conexão que os aplicativos implementavam antes de a velocidade ficar boa o bastante
      O trabalho da Cerebras e da Taalas é uma pista interessante do que pode ser possível nessa direção
      Também é divertido imaginar o que seria possível se até os modelos de ponta de hoje pudessem usar um milhão de tokens por segundo a um custo muito baixo
    • Concordo que lembra a era discada, mas parece mais 4800 baud do que 300 para 1200
      A comparação modem vs. Claude calculada pelo Claude ficou assim: para 2368 caracteres, 300 leva 1min19s, 1200 leva 19,7s, 2400 leva 9,9s, 14.4K leva 1,6s, 33.6K leva 705ms, 56K leva 447ms, e o Claude leva 7,9s
    • Teve uma startup postada aqui que fez hardware personalizado para permitir resposta imediata de IA
      Ficava na casa de milhares de tokens por segundo

  • A estratégia do Google parece um pouco diferente da dos outros provedores de fronteira
    Parece focar mais em eficiência de desempenho por computação do que em desempenho bruto, e talvez por isso o Gemini pareça ficar para trás à primeira vista
    Outros provedores estão batendo no limite de capacidade e também no limite de quanto conseguem subsidiar o custo de inferência
    A estratégia do Google parece ser escalar e distribuir esses modelos para seus bilhões de usuários existentes

    • Não vejo o Gemini como estando atrás
      Na verdade, ele parece um tipo diferente de inteligência em relação ao GPT-5 mais recente e à família Claude
      Estes últimos estão cada vez mais focados em produtividade e automação de trabalho, otimizados para longos loops de raciocínio autocorretivo e agêntico
      O Gemini parece muito mais um modelo-base inteligente e, especialmente no modo Deep Think, a intuição parece bem mais profunda, mas ele não vai tão bem em loops agênticos de autocorreção de longo alcance
      Nos últimos meses, meu fluxo de trabalho tem sido usar Gemini para saltos criativos e insights, e preferir Codex, Claude e GPT-5.5 Pro para tarefas repetitivas ou de alta precisão
    • Acho que a estratégia de todo mundo está mudando nessa direção

  • Fiquei um tempo sem usar modelos locais, mas recentemente configurei o modelo 26B A4B em uma RTX 3090 com vLLM em 4 bits, e fiquei completamente surpreso com a velocidade e a qualidade que dá para conseguir com um investimento abaixo de US$ 1000
    No começo tentei com Qwen, mas ele era instável e deixava rastros de raciocínio absurdamente longos

    • Algumas das quantizações iniciais do qwen3.6 estavam quebradas
      Ele ainda é meio temperamental, mas com alguns ajustes fica realmente impressionante
      Modelos locais são o futuro, o que é muito legal
    • Com turboquant / Q4, cabe até numa 3060, e entrega cerca de 40T/s, uma velocidade decente para uma placa de uns US$ 200
    • O modelo A4B é extremamente rápido e muito bom para consultas gerais
      Em tarefas de programação, ele claramente fica atrás do Qwen 3.6, mas isso diz mais sobre como os modelos Qwen são bons do que qualquer outra coisa
    • O 31B também é surpreendentemente rápido para um modelo denso
      Na minha máquina, o tg é pelo menos duas vezes mais rápido do que eu esperaria em comparação com outros modelos 30B, provavelmente por causa da atenção híbrida
      Por outro lado, o processamento de entrada é um pouco mais lento

  • Queria saber se alguém conseguiu fazer isso funcionar no LM Studio
    Tem a opção na interface, mas não parece ativar de verdade

    • Ainda não foi implementado no mlx[1] nem no llama.cpp[2], então pode demorar um pouco
      [1] https://github.com/ml-explore/mlx-lm/pull/990
      [2] https://github.com/ggml-org/llama.cpp/pull/22673
    • Funciona
      Como não há modelo pequeno, você precisa conferir se não está usando um modelo esparso do Gemma
      E eu removi todos os modelos de imagem do workspace
    • Normalmente, o LM Studio não gosta quando há um arquivo mmproj dentro da pasta
      Às vezes, apagar esses arquivos faz a opção aparecer
      Eles parecem estar ligados de alguma forma aos recursos visuais e bloquear a decodificação especulativa, mas não me pergunte por quê
      No Gemma, a rota com llama-server funcionou melhor para mim do que usar a decodificação especulativa no LM Studio
    • Já consegui fazer funcionar com outros modelos
      Em geral, provedor, quantização etc. precisam combinar perfeitamente entre si
      Pode levar algum tempo até encontrar um conjunto compatível

  • Nos meus testes, o modelo Gemma 4 31B mostrou o maior ganho de velocidade em tarefas de programação ao usar o runner MLX do Ollama, cerca de 2x
    Mas é preciso um Mac bem potente, porque a quantização reduz bastante a taxa de aceitação
    Os outros três modelos menores não foram tão bons, porque o tempo de validação do modelo de draft consumia quase todo o ganho de desempenho
    Ainda estou ajustando para ver se dá para tirar mais desempenho
    Dá para testar executando ollama run gemma4:31b-coding-mtp-bf16 no Ollama 0.23.1

  • Quando isso for integrado ao llama.cpp, quero testar o quanto antes
    No meu ambiente, o Gemma 4 26B-A4B é cerca de 3x mais rápido que o Qwen3.6-35B-A3B, então só de pensar em somar mais 1,5x de aceleração já dá vontade
    Também tentei modelos de draft, mas os resultados foram limitados, e até um modelo de draft menor de 3B e o modelo denso 14B Ministral já criavam overhead demais

    • Com uma 5090 no vLLM, dá para obter 120–180 TPS com quantização awq 4 bits e decodificação especulativa MTP
      O Gemma4 26B passa de 200 TPS com a mesma quantização
      Também é importante notar que o Qwen tem eficiência de inferência extremamente baixa
      A cadeia de raciocínio dele é, em média, cerca de 3x mais longa que a do Gemma

  • Fico pensando se isso é algo como a predição de desvio de um sistema operacional
    Só que, como a probabilidade já está embutida no próprio modelo, parece uma forma bem mais confiável

    • A ideia é parecida, mas o modo de falha é melhor
      Uma falha na predição de desvio desperdiça ciclos, mas aqui um palpite ruim normalmente só significa que você não ganha tokens bônus
      https://arxiv.org/abs/2211.17192