A TPU Ironwood da Google reformula a camada de serviço como centro de design

Uma TPU anunciada do lado do serviço, não do lado do treino

Durante uma década, a Google enquadrou as suas TPUs sobretudo em torno do treino. A Ironwood é descrita de forma diferente: é, nas palavras da própria Google, "a primeira concebida especificamente para inferência". Esse enquadramento é a manchete, não a contagem de flops.

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

A leitura prática para quem constrói a camada com que os utilizadores realmente interagem: a Google está a tratar o custo recorrente de servir pedidos — cada consulta, cada passo de agente, cada recuperação de dados — como a carga de trabalho que justifica desenhar silício à medida. O treino é um evento de capital único; a inferência é a despesa operacional que escala com o uso do produto.

Onde os 192 GB por chip se traduzem num produto

A especificação que a Google destaca para o serviço é a memória, não a potência de cálculo em bruto. A Ironwood oferece 192 GB de HBM por chip — seis vezes mais do que a Trillium — e 7,37 TB/s de largura de banda, 4,5 vezes mais do que a antecessora. A Google associa isto diretamente ao "processamento de modelos e conjuntos de dados maiores, reduzindo a necessidade de transferências de dados frequentes".

Isto é relevante ao nível de cada pedido porque a latência de inferência em modelos grandes é muitas vezes limitada pela movimentação de pesos e caches de chave-valor, e não pela aritmética. Mais memória no chip e maior largura de banda são o que evita que um pedido de contexto longo ou de raciocínio fique bloqueado na movimentação de dados — o modo de falha que uma equipa de produto sente como primeiros tokens lentos e streaming irregular.

A Google afirma também que a Ironwood foi "concebida para minimizar a movimentação de dados e a latência no chip ao executar manipulações de tensores em grande escala". A ênfase na latência é, de novo, uma preocupação de serviço, e não de rendimento em treino.

A SparseCore diz que isto é sobre ranking, não só chat

A Ironwood inclui uma SparseCore melhorada, que a Google descreve como "um acelerador especializado para processar embeddings ultra-grandes, comuns em cargas de trabalho avançadas de ranking e recomendação". A empresa acrescenta que o suporte ampliado chega "além do domínio tradicional de AI, a domínios financeiros e científicos".

Isto é um sinal do que "inferência" significa para a Google neste contexto. Não é apenas o chat generativo por detrás de uma caixa de texto; é também a maquinaria de recomendação e ranking com uso intensivo de embeddings que já sustenta produtos à escala do Search e do Gmail. O mesmo chip está a ser direcionado tanto para a resposta do LLM como para a recuperação de dados que a alimenta — o que corresponde à forma do pipeline agêntico que a Google descreve.

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

A Google oferece a Ironwood numa configuração de 256 chips e numa configuração de 9216 chips, esta última atingindo 42,5 Exaflops. A divisão em dois tamanhos é a decisão concreta que um cliente da Cloud enfrenta: um pod menor para serviço limitado, ou um pod completo para treino e serviço de fronteira de modelos LLM densos e MoE.

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

O ganho de eficiência indicado — 2x em desempenho por watt em relação à Trillium, e "quase 30x" em relação à Cloud TPU de 2018 — é enquadrado face a uma restrição específica que a Google nomeia diretamente: "a energia disponível é uma das limitações para disponibilizar capacidades de AI". Um pod que ronda quase 10 MW torna essa restrição literal.

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

O posicionamento da Ironwood indica às equipas de aplicações onde a pressão está a deslocar-se. Se a Google está a construir o seu acelerador mais poderoso em torno da inferência, da largura de banda de memória e da eficiência por watt, então o fator limitante para lançar funcionalidades de AI é cada vez mais o custo e a latência de servir pedidos em escala — e não a existência ou não de um modelo maior.

A Ironwood ainda não está disponível; a Google diz que chega "ainda este ano", e nota que o Gemini 2.5 e o AlphaFold já correm hoje em TPUs. A conclusão prática é tratar o orçamento de serviço — tokens, embeddings, passos de agente por ação do utilizador — como uma variável de design de primeira classe, porque o roteiro de hardware está agora a ser desenhado precisamente em torno desse número.