Comunidade desmascara ocultação do MTP no Gemma 4, e Google passa a oferecer suporte indireto só depois

(reddit.com)

5 pontos por darjeeling 1 시간 전 | 2 comentários | Compartilhar no WhatsApp

O Google removeu da distribuição pública do Gemma 4 o recurso MTP com o qual o modelo havia sido treinado, e só começou a oferecer suporte depois que isso foi exposto por meio de engenharia reversa feita pela comunidade, na forma de um modelo assistente externo.

Enquanto analisavam arquivos .litertlm (baseados em TFLite), formato distribuído pelo Google para dispositivos móveis e de borda, desenvolvedores open source encontraram uma descoberta surpreendente. A arquitetura MTP (Multi-Token Prediction, previsão de múltiplos tokens), ausente nos pesos padrão do modelo publicados no HuggingFace, estava incluída apenas nos arquivos compilados para edge.

Depois que a questão foi levantada publicamente, o Google admitiu o fato e respondeu o seguinte:

"Os prediction heads relacionados a MTP foram intencionalmente excluídos do modelo público para manter compatibilidade com a API do HuggingFace Transformers. Eles foram preservados no runtime LiteRT para melhorar o desempenho on-device."

O que é MTP

LLMs comuns geram tokens um por um, de forma sequencial. MTP é uma técnica que prevê vários tokens ao mesmo tempo em um único forward pass e, quando combinada com speculative decoding, pode aumentar bastante a velocidade de inferência sem alterar a qualidade da saída. Em teoria, é uma otimização sem perdas.

A tentativa de engenharia reversa da comunidade

O autor da descoberta inicial conseguiu extrair vários arquivos .tflite de um arquivo .litertlm, publicou no HuggingFace os arquivos extraídos e o processo de reprodução, e pediu ajuda de pessoas com experiência em C++. Depois disso, contribuidores da comunidade iniciaram uma engenharia reversa mais profunda.

Dificuldade técnica: a estrutura dos kernels TFLite era extremamente complicada. Um vetor de atenção de largura 1024 era quantizado para INT8 → multiplicado por pesos INT8 → o resultado era requantizado → e então dequantizado novamente.

Resultado: após vários dias de trabalho intenso, foi possível reconstruir o seguinte:

estrutura GQA (Grouped-Query Attention) e mapeamento do cache KV externo
funcionamento da janela local deslizante
caminho de quantização de pre_project / q_proj / MLP / o_proj / post_project
funcionamento parcial do RoPE
paridade end-to-end com TFLite, alcançando 20/20 de correspondência top-1

A licença é Apache 2.0, então não há problema legal.

Desempenho real: quão rápido é

Medições da comunidade (base Strix Halo):

Tarefa	Antes	Após aplicar MTP
Geração de código	8 tps	25 tps (cerca de 3x)
Escrita geral	7~8 tps	11~14 tps

Em comparação com o speculative decoding nas famílias LLaMA/Qwen3, que normalmente fica em torno de 1,5~1,7x e no máximo 2x, atingir 3x em geração de código é um número incomum. A análise é que, por causa da natureza da geração de código, há muito boilerplate repetitivo, o que eleva a taxa de aceitação dos draft tokens.

Reação da comunidade e suspeitas

As críticas seguiram principalmente em duas direções.

① Crítica por falta de documentação (Undocumented): o modelo foi treinado com MTP, mas o recurso foi removido intencionalmente da distribuição pública sem qualquer menção a isso.

② Suspeita de motivação comercial: a alegação de que "se um modelo open source 31B rodando localmente ficar rápido demais, isso ameaça a competitividade das APIs comerciais da própria empresa (como Flash Lite), então ele teria sido capado de propósito". O modelo 122B que vazou e depois foi removido também foi citado nesse contexto.

A escolha estrutural do Google

Canal de distribuição	MTP incluído?
Pesos públicos no HuggingFace	❌ remoção intencional
LiteRT (edge/mobile)	✅ embutido
`gemma4_assistant` (novo em 5/5)	✅ suporte indireto por modelo assistente externo

Resposta oficial tardia do Google (5 a 6 de maio)

Com a pressão da comunidade aumentando, o Google lançou em 5 de maio o modelo assistente gemma4_assistant separadamente no HuggingFace e anunciou no blog oficial o drafter MTP do Gemma 4. Em vez de manter o recurso dentro do próprio modelo, a empresa passou a oferecê-lo de forma indireta, separado em um modelo externo.

Velocidade: até 3x mais velocidade de inferência sem perda de qualidade
Modelo assistente: drafter leve de cerca de 500M parâmetros
Uso: basta passar no argumento assistant_model= da função generate() para funcionar. Não é necessária uma implementação MTP customizada
Ambientes compatíveis: HuggingFace Transformers, vLLM, MLX (Apple Silicon), LiteRT-LM

💡 Resumo em uma linha: o Google removeu da distribuição pública do Gemma 4 o recurso MTP com o qual o modelo foi treinado, e só passou a oferecer suporte indireto por meio de um modelo assistente externo depois que a comunidade expôs isso com engenharia reversa.