O Google Cloud publicou um benchmark comparando workloads de classificação e geração no TPU v6e às 15:36 UTC de 4 de setembro. Sua principal conclusão: "Para tarefas de geração intensivas em decode, o modelo Gemma 3 27B atinge um limite rígido de desempenho além de 64 usuários concorrentes, estabilizando em um multiplicador de throughput normalizado de 4,12x em 128 usuários. Em contraste, o modelo 12B escala até um multiplicador de 8,19x."
A ressalva mais abaixo
"Em níveis extremos de concorrência (por exemplo, 128 usuários), você pode notar picos matematicamente anômalos no throughput médio. … Sob severas restrições de recursos, --max-num-seqs ou --max-model-len mal configurados podem levar a abandono silencioso de requisições, timeouts de conexão no cliente ou OOMs em nós de trabalho do GKE. Quando essas requisições com falha terminam imediatamente, elas encurtam falsamente a duração da sessão e inflam artificialmente as métricas de throughput. Os pontos de dados de 128 usuários nestes benchmarks representam o limite absoluto da estabilidade do cluster e devem ser tratados como um teto, e não como uma métrica sustentável de produção."
O que as linhas com respaldo dizem
A tabela de geração, em 16, 32, 64 e 128 usuários, mostra 1,00x / 1,98x / 2,96x / 8,19x para o Gemma 3 12B, e 1,05x / 1,97x / 4,00x / 4,12x para o 27B. Em 64 usuários concorrentes — a última linha da qual o post não se retrata — o modelo maior é o mais rápido, o oposto do que sugere o título. Toda a narrativa de "limite de desempenho" é uma comparação entre dois números da linha desautorizada.
Nada aqui é uma medição absoluta
Cada célula é um múltiplo do Gemma 3 12B em 16 usuários, em uma tabela cujo cabeçalho de coluna diz "Throughput (req/s)". Não há nenhum valor absoluto de requisições por segundo e nenhum custo — em um post cuja primeira frase é sobre economia unitária. A configuração é um pool de nós TPU v6e de host único em topologia de chip 2x2 no GKE Autopilot, servido por vLLM via tpu-inference, com max-model-len=128000, max-num-batched-tokens=8192, max-num-seqs=512.
O que a moldura recebida erra
Isso será citado como "TPU v6e entrega 8x". Trata-se de um múltiplo normalizado, em um único nó, em uma única pilha de serving, em um nível de concorrência que o publicador classifica como instável e possivelmente corrompido por requisições descartadas. O post é incomumente honesto — a ressalva está ali, sem rodeios — e essa honestidade está no parágrafo que ninguém chega a ler. A tabela de classificação, cujos picos de 6,04x a 6,37x vêm da mesma linha de 128 usuários, carrega o mesmo problema.