O TPU 8i do Google coloca a latência de inferência no silício para interfaces guiadas por agentes

Dividindo o chip pela linha treinamento/inferência

A oitava geração de TPU do Google chega não como uma peça única, mas como duas: o TPU 8t, voltado ao treinamento de modelos massivos, e o TPU 8i, voltado à inferência. O Google diz que ambos os chips conseguem rodar cargas de trabalho variadas, mas é dessa especialização que vêm os ganhos.

A empresa descreve ter antecipado essa divisão há alguns anos — apostando que, à medida que modelos de fronteira fossem para produção, a demanda por inferência justificaria uma peça dedicada. Os dois chips têm equilíbrios de recursos diferentes: o 8t pende para throughput de computação e banda de scale-up, enquanto o 8i pende para banda de memória voltada a serviços sensíveis à latência.

Essa divisão importa para quem constrói a camada que o usuário realmente toca. A economia de treinamento e a economia de serving sempre puxaram o hardware em direções opostas; agora o Google torna essa tensão explícita no nível do silício, em vez de pedir que um único chip faça concessões entre os dois lados.

Por que o 8i parece um orçamento de latência

O Google enquadra a era agêntica em termos que são, no fundo, sobre responsividade:

Nesta era dos agentes de IA, os modelos precisam raciocinar sobre problemas, executar fluxos de trabalho de múltiplas etapas e aprender com as próprias ações em loops contínuos.Montana Labs

É nesses loops contínuos que a latência se acumula. O Google é claro ao dizer que "interações entre agentes em escala amplificam até pequenas ineficiências" — um enxame de agentes especializados significa muitas idas e voltas, e cada milissegundo se multiplica. O design do 8i ataca isso diretamente: ele combina 288 GB de memória de alta largura de banda com 384 MB de SRAM on-chip (3x a geração anterior) para manter o conjunto de trabalho de um modelo no próprio chip, além de adicionar um novo Collectives Acceleration Engine on-chip que, segundo o Google, corta a latência interna em até 5x.

O Google chama o objetivo de eliminar o efeito "sala de espera" — processadores ociosos enquanto os dados se movem. Para engenheiros de frontend, esse tempo ocioso é exatamente o que aparece como um spinner na tela. A folha de especificações do chip é, na prática, uma resposta em nível de hardware à latência que define a experiência de uso dos agentes.

KV cache dimensionado direto no hardware

O detalhe mais revelador é a afirmação de co-design do Google: a capacidade de SRAM do 8i foi "dimensionada para a pegada de KV cache de modelos de raciocínio em escala de produção". Isso é uma equipe de hardware projetando em torno de uma estrutura de dados de tempo de serving que determina quanto contexto conversacional e de raciocínio um modelo consegue manter sem precisar recorrer a memória mais lenta.

O Google também lista suporte a frameworks que nomeia diretamente a stack de serving — JAX nativo, MaxText, PyTorch e, notavelmente, SGLang e vLLM, os motores de inferência que os times já usam no dia a dia. Acesso bare-metal é oferecido para pular a sobrecarga de virtualização. O fio condutor é que o Google está otimizando para o caminho específico entre um modelo e uma requisição em tempo real, não apenas para throughput bruto.

A promessa econômica associada é de 80% mais performance por dólar em relação à geração anterior, o que o Google traduz como atender quase o dobro do volume de clientes pelo mesmo custo. Para uma empresa que roda agentes voltados ao usuário, essa proporção é a diferença entre um recurso que se paga e um que não se paga.

O que isso define para times que constroem frontends agênticos

Os dois chips estão previstos para disponibilidade geral ainda este ano via AI Hypercomputer do Google, então nada disso é algo que se possa construir hoje. Mas o anúncio sinaliza para onde está indo o piso de latência dos agentes hospedados, e vale a pena entender isso antes de se comprometer com uma arquitetura.

Se a experiência do seu agente depende de loops rápidos com múltiplas etapas, as escolhas de design do 8i — conjuntos de trabalho on-chip, um motor de collectives focado em latência, banda de interconexão dobrada para modelos Mixture-of-Experts — descrevem as condições sob as quais o Google espera que esses loops rodem. O ponto prático para times de frontend e de aplicação é que a latência que você consegue prometer aos usuários será cada vez mais definida por decisões de hardware na camada de inferência, tomadas abaixo da sua stack — e as metas de design que o Google publicou aqui são uma prévia do que "rápido o suficiente" vai significar ao servir essas cargas de trabalho em escala.