Como usar o Gemini 4 Argon para acelerar a inferência de modelos em GPU (o caso do Gemma 4 E2B no vLLM)

Fala aí, beleza? O Google afirma que usou o Gemini 4 Argon pra acelerar de ponta a ponta a inferência do Gemma 4 E2B no vLLM, numa GPU A100, e o resultado foi um speedup de 2,85x 😀

Sim, quase três vezes mais tokens por segundo na mesma GPU

Este post usa esse caso como roteiro de engenharia de performance: qual contexto entregar ao modelo, o que medir antes e depois e como validar que o ganho é real (e não um número bonito que esconde saída quebrada)

O que o Google relatou no caso do Gemma 4 E2B no vLLM?

Primeiro, quem é quem nessa história

O Gemini 4 Argon é o modelo de fronteira do Google pra trabalho complexo e de raciocínio longo em programação, finanças, jurídico, cibersegurança e ciência

Ele foi anunciado em 30/09/2026

Já o Gemma 4 E2B é o "paciente" da otimização: um modelo aberto com 2 bilhões de parâmetros efetivos, pensado pra celulares e notebooks, com entrada multimodal (texto, imagem e áudio) e saída em texto

E o vLLM? É o motor de inferência que serve o modelo, ou seja, quem recebe as requisições e devolve os tokens

Se liga nos números que o Google divulgou no post de disponibilidade geral do Gemini 4 Argon:

Sobre o que mudou, a descrição é de alto nível: as mudanças foram de ajuste de attention até speculative decoding

Nada de linha a linha, nada de flags, nada de PR publicado

E tem o prazo: segundo o Google, a otimização foi feita em poucos dias, num processo que normalmente levaria meses

Isso é afirmação do Google, beleza? Não tem como a gente checar de fora quanto tempo esse mesmo trabalho levaria pra um time comum

O que você precisa antes de começar:

São duas pontas: o modelo que vai te ajudar a otimizar e o stack de inferência que vai ser otimizado

Como acessar o Gemini 4 Argon?

Pra quem é dev, o caminho principal é o tier pago da Gemini API, usando o ID gemini-4-argon na Interactions API, com suporte desde o primeiro dia nos SDKs google-genai

Se tu é assinante Google AI Ultra, dá pra testar no Google AI Studio e no Google Antigravity

Ele também está disponível no Google Cloud, pela Gemini Enterprise Agent Platform, que tem guia de desenvolvedor próprio

E no app Gemini ele está em liberação gradual pra assinantes Google AI Pro e AI Ultra

Quanto custa usar o Gemini 4 Argon na API?

O preço introdutório é US$ 2 por 1 milhão de tokens de entrada e US$ 10 por 1 milhão de tokens de saída

Esse preço vai até 30/11/2026

Depois disso passa pra US$ 4 por 1M de tokens de entrada e US$ 20 por 1M de tokens de saída

Entrada em cache tem 95% de desconto sobre o preço de entrada, o que ajuda MUITO quando você reenvia o mesmo contexto várias vezes durante a otimização

O limite é unificado: 1M de tokens de entrada e saída via Gemini API

E do lado da inferência?

Aqui o que você precisa é do vLLM com as dependências extras de benchmark e de uma GPU sua pra rodar o modelo

As dependências de benchmark são um extra do próprio pacote do vLLM, instalado via pip (o extra se chama bench)

Passo a passo: como usar o Gemini 4 Argon para otimizar sua inferência no vLLM

A lógica é a mesma de qualquer trabalho de performance: sem número antes, não existe "ficou mais rápido"

É como ir ao médico pra ver se o remédio funcionou sem nunca ter medido a pressão antes haha

Passo 1: medir o baseline

O CLI do vLLM tem três comandos de benchmark: vllm bench latency, vllm bench serve (throughput online) e vllm bench throughput (throughput offline), todos descritos na documentação de benchmarking do vLLM

Começa pelo throughput offline usando o exemplo oficial, trocando <modelo> pelo modelo que você serve:

vllm bench throughput --model <modelo> --dataset-name random --random-input-len 500 --random-output-len 150 --num-prompts 10

Depois roda o vllm bench serve pra ver o comportamento online, que é mais próximo do que seu usuário sente

Os parâmetros do serve dependem do seu cenário, então ajusta conforme a documentação e anota tudo

Erro comum deste passo: medir sem fixar os parâmetros (tamanho de entrada, tamanho de saída, número de prompts) e depois comparar números que não têm nada a ver um com o outro

Já me ferrei com isso em outro contexto: comparar benchmark com carga diferente é a forma mais rápida de comemorar um ganho que não existe xD

Passo 2: registrar as métricas certas

O vllm bench serve reporta várias métricas, e cada uma conta uma parte da história:

• TTFT: tempo até o primeiro token
• TPOT: tempo por token de saída, sem contar o primeiro
• ITL: latência entre tokens
• e2el: latência de ponta a ponta
• Output token throughput e peak output token throughput, em tokens por segundo

Pra modelos generativos, o padrão é reportar ttft,tpot,itl

Guarda essas métricas numa planilha ou num arquivo do repo, junto com o comando exato que gerou cada uma

Erro comum deste passo: olhar só throughput e ignorar latência

Throughput alto com TTFT horrível pode ser ótimo pra processamento em lote e péssimo pra um chat, então depende do seu use case

Passo 3: montar o contexto para o Argon

Agora sim entra o Gemini 4 Argon

Um bom contexto tem, no mínimo:

• Os resultados do baseline (as métricas do passo 2)
• A configuração usada no vLLM e os comandos de benchmark
• O modelo alvo (no caso do Google, o Gemma 4 E2B)
• A meta, com a restrição de qualidade explícita: manter paridade de tokens

Pensa assim: é como contratar um consultor de performance fodão, só que ele chega sem acesso ao seu servidor

Tudo que ele sabe é o que tu entrega pra ele

Erro comum deste passo: pedir "deixa mais rápido" sem números e sem restrição de qualidade

Sem a restrição, qualquer mudança que acelere e estrague a saída parece vitória 🙂

Passo 4: explorar as frentes citadas no caso

O Google citou duas frentes: ajuste de attention e speculative decoding

E o que é speculative decoding?

É a técnica em que um modelo menor ou um mecanismo auxiliar "chuta" alguns tokens à frente e o modelo principal confirma, em vez de gerar um por um

Pro Gemma 4, o vLLM tem suporte a speculative decoding MTP com os modelos assistentes do Gemma 4 (E2B, E4B, 26B-A4B e 31B), e o assistente compartilha o KV cache com o modelo alvo, conforme o PR de suporte no repositório do vLLM

Usa o Argon pra discutir essas frentes com base nos seus números, pedir hipóteses e entender o porquê de cada mudança antes de aplicar

Erro comum deste passo: aplicar várias mudanças de uma vez

Aí o throughput sobe (ou cai) e tu não faz ideia de qual mudança causou o quê

Passo 5: medir de novo com os mesmos comandos

Roda exatamente os mesmos comandos do passo 1, com os mesmos parâmetros, na mesma GPU

Compara métrica por métrica com o baseline

Erro comum deste passo: rodar o "depois" com carga diferente

Mudou o número de prompts ou o tamanho da saída? Então o comparativo virou ficção…

Como validar o ganho sem perder qualidade?

O critério do Google no caso do Gemma 4 E2B foi 100% de paridade de tokens e nenhuma queda de qualidade

Ou seja: mais rápido, mas a saída tem que continuar a mesma

Se liga nos sintomas que valem acompanhar:

Sintoma: o throughput subiu, mas a saída mudou

Causa provável: alguma mudança alterou o comportamento do modelo, e não só a velocidade

Solução: comparar as saídas do antes e do depois com os mesmos prompts e as mesmas configurações de geração

Se os tokens não batem, o ganho não conta, por mais bonito que seja o número

Sintoma: o throughput agregado melhorou, mas TTFT ou ITL pioraram

Causa provável: a otimização favoreceu volume total em troca da experiência de cada requisição

Solução: olhar as métricas separadas do vllm bench serve e decidir com base no seu use case se essa troca faz sentido

Sintoma: o ganho aparece no bench offline e some no serve

Causa provável: o cenário offline e o online exercitam o sistema de formas diferentes

Solução: validar nos dois e considerar o serve como referência quando o modelo atende usuário em tempo real

Como prevenir esses problemas?

• Uma mudança por vez
• Mesmo dataset e mesmos parâmetros no antes e no depois
• Registrar tudo: comando, configuração, métricas e saídas

Nada de fórmula mágica aqui, é disciplina de medição mesmo haha

Quando faz sentido usar o Argon nesse tipo de trabalho?

O caso do Google se encaixa bem em alguns cenários:

• Times servindo modelos abertos no vLLM que querem mais tokens por segundo na mesma GPU
• Modelos pequenos como o Gemma 4 E2B, onde o overhead do motor de inferência pesa bastante
• Quem quer explorar speculative decoding com os assistentes do Gemma 4 e entender as escolhas antes de mexer

Agora o veredito honesto

O 2,85x é número do Google, num cenário específico: A100, Gemma 4 E2B e vLLM

Seu resultado depende do seu stack, do seu modelo e da sua carga, e só vale o que você medir

Tem também a conta de custo: a API cobra por token, e uma sessão longa de otimização com métricas, configurações e iterações consome contexto

Pesa isso contra o tempo de engenharia que você economizaria (o cache de entrada com desconto ajuda nessa conta)

E se o seu trabalho pesado não é performance e sim reescrever um sistema inteiro, o raciocínio de planejar antes também vale pra migração de código em larga escala

Próximo passo: rode o baseline hoje

Recapitulando o método:

1. Medir o baseline com os comandos de benchmark do vLLM
2. Entregar ao Gemini 4 Argon o contexto com números, configuração e restrição de qualidade
3. Aplicar uma mudança por vez
4. Medir de novo com os mesmos comandos e parâmetros
5. Checar paridade de tokens antes de comemorar

O próximo passo concreto é simples: instala o extra bench do vLLM e roda o vllm bench throughput do exemplo oficial no seu modelo

Com esse número na mão, aí sim vale abrir a conversa com o Argon

Sem baseline, qualquer ganho é palpite, e palpite não sobe pra produção 😀

Até o próximo post!