A TPU Ironwood do Google reformula a camada de serving como centro de design

Uma TPU anunciada pelo lado do serving, não do treinamento

Por uma década, o Google enquadrou suas TPUs principalmente em torno do treinamento. A Ironwood é descrita de forma diferente: é, nas palavras do próprio Google, "a primeira projetada especificamente para inferência". Esse enquadramento é a manchete, não a contagem de FLOPs.

É uma mudança de modelos de IA reativos, que fornecem informações em tempo real para as pessoas interpretarem, para modelos que geram proativamente insights e interpretações. É o que chamamos de "era da inferência", em que agentes de IA vão buscar e gerar dados de forma proativa.Montana Labs

A leitura prática para quem constrói a camada que o usuário realmente toca: o Google está tratando o custo recorrente de atender requisições — cada consulta, cada passo de agente, cada busca — como a carga de trabalho que vale a pena projetar em silício. Treinamento é um evento de capital único; inferência é a despesa operacional que escala com o uso do produto.

Onde os 192 GB por chip entram no produto

A especificação que o Google destaca para serving é memória, não poder de computação bruto. A Ironwood oferece 192 GB de HBM por chip — seis vezes a Trillium — e 7,37 TB/s de largura de banda, 4,5x sua antecessora. O Google liga isso diretamente ao "processamento de modelos e conjuntos de dados maiores, reduzindo a necessidade de transferências frequentes de dados".

Isso importa no nível da requisição porque a latência de inferência em modelos grandes costuma ser limitada pela movimentação de pesos e caches de chave-valor, não pela aritmética em si. Mais memória no chip e maior largura de banda são o que evita que uma requisição de contexto longo ou de raciocínio trave na movimentação de dados — a falha que a equipe de produto sente como primeiros tokens lentos e streaming instável.

O Google também afirma que a Ironwood foi "projetada para minimizar a movimentação de dados e a latência no chip ao realizar manipulações massivas de tensores". A ênfase em latência, de novo, é uma preocupação de serving, não de throughput de treinamento.

O SparseCore mostra que isso é sobre ranking, não só sobre chat

A Ironwood traz um SparseCore aprimorado, que o Google descreve como "um acelerador especializado para processar embeddings ultra grandes, comuns em cargas avançadas de ranking e recomendação". A empresa acrescenta que o suporte expandido vai "além do domínio tradicional de IA, para os domínios financeiro e científico".

Isso é um sinal do que "inferência" significa para o Google aqui. Não é só o chat generativo atrás de uma caixa de texto; é também o maquinário de recomendação e ranking, pesado em embeddings, que já sustenta produtos na escala do Search e do Gmail. O mesmo chip está sendo direcionado tanto para a resposta do LLM quanto para a busca que a alimenta — o formato do pipeline agentivo que o Google descreve.

Dois tamanhos de pod e o Pathways definem a escolha real das equipes

O Google oferece a Ironwood em uma configuração de 256 chips e outra de 9.216 chips, esta última alcançando 42,5 Exaflops. A divisão em dois tamanhos é a decisão concreta que um cliente do Cloud enfrenta: um pod menor para serving limitado, ou um pod completo para treinamento e serving de fronteira de modelos LLM densos e MoE.

Acima de um único pod, o Google aponta para o Pathways, seu runtime construído pela DeepMind, para "compor" centenas de milhares de chips. A narrativa de computação distribuída é vendida como uma camada de abstração de software sobre o hardware, parte da arquitetura mais amplo do AI Hypercomputer.

O ganho de eficiência declarado — 2x em performance por watt em relação à Trillium, e "quase 30x" em relação à Cloud TPU de 2018 — é apresentado contra uma restrição específica que o Google nomeia diretamente: "a energia disponível é uma das restrições para entregar capacidades de IA". Um pod que chega a quase 10 MW torna essa restrição literal.

A implicação: a economia da inferência, não o tamanho do modelo, se torna a restrição de frontend

O posicionamento da Ironwood mostra às equipes de aplicação para onde a pressão está se deslocando. Se o Google está construindo seu acelerador mais poderoso em torno de inferência, largura de banda de memória e eficiência por watt, então o fator limitante para lançar funcionalidades de IA é, cada vez mais, o custo e a latência de atender requisições em escala — não se existe um modelo maior por aí.

A Ironwood ainda não está disponível; o Google diz que ela chega "ainda este ano", e observa que o Gemini 2.5 e o AlphaFold já rodam em TPUs hoje. O aprendizado concreto é tratar o orçamento de serving — tokens, embeddings, passos de agente por ação do usuário — como uma variável de design de primeira classe, porque o roteiro do hardware agora está sendo traçado exatamente em torno desse número.