{"id":432,"date":"2026-09-05T22:33:52","date_gmt":"2026-09-06T01:33:52","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2026\/09\/google-tpus-guia-completo-arquitetura-e-modelos\/"},"modified":"2026-09-08T04:51:50","modified_gmt":"2026-09-08T07:51:50","slug":"google-tpus-guia-completo-arquitetura-e-modelos","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/en\/2026\/09\/google-tpus-guia-completo-arquitetura-e-modelos\/","title":{"rendered":"Google TPUs: arquitetura, gera\u00e7\u00f5es e modelos"},"content":{"rendered":"

\"Mascote<\/p>\n

Por volta de 2013 o Google fez a conta que assustou Mountain View: se cada usu\u00e1rio Android usasse o comando de voz da Busca por tr\u00eas minutos ao dia, em CPU x86, a empresa teria de dobrar os data centers<\/strong> s\u00f3 para infer\u00eancia. GPU de consumo ainda era placa de jogo adaptada. A resposta foi um ASIC s\u00f3 de \u00e1lgebra linear: a TPU (Tensor Processing Unit)<\/strong>. Este texto \u00e9 o mapa do sil\u00edcio \u2014 MXU sist\u00f3lica, bfloat16, OCS \u2014 e das gera\u00e7\u00f5es at\u00e9 o TPU7x Ironwood<\/strong>, em disponibilidade geral desde 31 de mar\u00e7o de 2026. O recorte GPU vs TPU, lado a lado, est\u00e1 no post GPU vs TPU<\/a>.<\/p>\n

<\/p>\n

Por que um ASIC, n\u00e3o uma GPU<\/h2>\n

CPU gasta transistor com preditor de desvio, cache e decodificador. GPU gasta com SIMT gen\u00e9rico. A TPU dedica o die a uma conta: MAC<\/strong> (multiply-accumulate). Quase todo o servi\u00e7o do Google \u2014 Busca, Tradutor, Fotos, YouTube, Cloud \u2014 e o treino de Transformer, BERT, AlphaFold, PaLM e Gemini passou por esse sil\u00edcio.<\/p>\n

HBM  <=>  VMEM (SRAM on-die)\n              \u2502\n     \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n     v                 v\n  MXU sist\u00f3lica     VPU\n  (MatMul pura)     (softmax, GELU, LayerNorm)\n  128\u00d7128 MACs\n  (16.384 c\u00e9lulas)\n<\/code><\/pre>\n
Nas gera\u00e7\u00f5es novas o SparseCore entra para embedding esparso (an\u00fancio, YouTube, Busca). v6e e Ironwood usam MXU 256\u00d7256<\/strong>.<\/p>\n
Arranjo sist\u00f3lico: o dado n\u00e3o volta para a HBM<\/h2>\n
Num processador comum, cada MAC intermedi\u00e1rio l\u00ea e grava registrador\/cache \u2014 o memory wall<\/em> do post das placas de v\u00eddeo<\/a>. Na MXU:<\/p>\n
    \n
  1. Weight-stationary:<\/strong> os pesos da camada saem da HBM uma vez e estacionam na c\u00e9lula.<\/li>\n
  2. S\u00edstole:<\/strong> o vetor de entrada entra pela esquerda e anda uma coluna por ciclo.<\/li>\n
  3. Ac\u00famulo:<\/strong> cada c\u00e9lula multiplica entrada \u00d7 peso local, soma o que veio de cima, empurra para baixo.<\/li>\n
  4. Sa\u00edda:<\/strong> a coluna da matriz resultante escorre pela base.<\/li>\n<\/ol>\n
    O n\u00famero pulsa de vizinho para vizinho. Energia vira conta, n\u00e3o tr\u00e2nsito. \u00c9 o oposto do KV cache gordo que o MLA da DeepSeek<\/a> tenta encolher na GPU.<\/p>\n
    O efeito colateral aparece na conta de efici\u00eancia: numa matriz 128\u00d7128, um dado que entra pela borda participa de 128 multiplica\u00e7\u00f5es antes de sair, sem tocar em mem\u00f3ria nenhuma. Na CPU, cada uma dessas 128 opera\u00e7\u00f5es seria um par load\/store. \u00c9 da\u00ed que sai a diferen\u00e7a de watt por opera\u00e7\u00e3o \u2014 n\u00e3o de clock. A TPU nunca ganhou de GPU em frequ\u00eancia.<\/p>\n
    bfloat16: a faixa do FP32 na metade dos bits<\/h2>\n
    FP32 gasta banda. FP16 IEEE corta o expoente para 5 bits e o treino de rede grande estoura (overflow\/underflow). O Google inventou o bfloat16<\/strong>:<\/p>\n
    FP32      1 sinal | 8 expoente | 23 mantissa\nFP16      1 sinal | 5 expoente | 10 mantissa   (faixa estreita)\nbfloat16  1 sinal | 8 expoente |  7 mantissa   (mesma faixa do FP32)\n<\/code><\/pre>\n
    Metade do tr\u00e1fego, multiplicador menor, treino sem malabarismo de loss scaling. NVIDIA, Intel, AMD e ARM adotaram. Hoje \u00e9 o default de JAX, PyTorch e dos LLMs.<\/p>\n
    A sacada \u00e9 entender o que a rede neural realmente precisa. Gradiente pequeno demais vira zero em FP16 e o treino trava; o que quase nunca importa \u00e9 o terceiro decimal do peso. O bfloat16 joga fora precis\u00e3o (mantissa) e preserva alcance (expoente) \u2014 exatamente na ordem em que a rede tolera a perda. Ironwood leva a l\u00f3gica adiante com FP8<\/strong>, onde a infer\u00eancia aceita ainda menos bits.<\/p>\n
    VPU, SparseCore, ICI e OCS<\/h2>\n
    MatMul densa n\u00e3o \u00e9 o modelo inteiro. A VPU<\/strong> faz GELU, ReLU, softmax, LayerNorm\/RMSNorm. O SparseCore<\/strong> trata embedding esparso largo demais para a MXU \u2014 o suporte a embeddings em hardware apareceu na v4, e a documenta\u00e7\u00e3o do Cloud lista o bloco como SparseCore na v5p, na v6e e no TPU7x.<\/p>\n
    O superpoder n\u00e3o \u00e9 o chip: \u00e9 o Pod<\/strong>.<\/p>\n
    chip <== ICI (Inter-Chip Interconnect) ==> chip\n         malha 2D ou 3D torus\n         OCS: espelhos MEMS desviam o laser\n              topologia reconfigur\u00e1vel em software\n<\/code><\/pre>\n
    ICI<\/strong> liga vizinhos sem TCP\/IP. Torus 3D<\/strong> fecha as bordas. OCS<\/strong> (v4, v5p, Ironwood): em vez de switch el\u00e9trico que converte luz\u2194el\u00e9tron, um microespelho aponta o feixe. Isola chip morto, muda o recorte (data \/ tensor \/ pipeline parallel) em milissegundos.<\/p>\n
    Vale insistir no ponto do OCS porque ele \u00e9 o que n\u00e3o tem equivalente do outro lado: num cluster de GPU, trocar a topologia significa recabear rack. No pod, \u00e9 uma ordem para o espelho. Um chip que falha no meio de um treino de semanas n\u00e3o derruba o job \u2014 o pod se reconfigura em volta do buraco.<\/p>\n
    Gera\u00e7\u00f5es (n\u00fameros oficiais do Cloud TPU, 2026)<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n
    Gera\u00e7\u00e3o<\/th>\nAno<\/th>\nFoco<\/th>\nPico\/chip<\/th>\nHBM<\/th>\nPod<\/th>\n<\/tr>\n<\/thead>\n
    v1<\/td>\n2015<\/td>\ns\u00f3 infer\u00eancia INT8<\/td>\n~92 TOPS<\/td>\n8 GB DDR3<\/td>\nPCIe avulso<\/td>\n<\/tr>\n
    v2<\/td>\n2017<\/td>\ntreino + infer\u00eancia, BF16<\/td>\n45 TFLOPS<\/td>\n16 GB HBM<\/td>\n256 chips (11,5 PFLOPS)<\/td>\n<\/tr>\n
    v3<\/td>\n2018<\/td>\nl\u00edquido, escala<\/td>\n~123 TFLOPS<\/td>\n32 GB HBM2<\/td>\n1.024 chips<\/td>\n<\/tr>\n
    v4<\/td>\n2021<\/td>\nOCS, torus 3D<\/td>\n275 TFLOPS<\/td>\n32 GB HBM2<\/td>\n4.096 (1,1 EFLOPS)<\/td>\n<\/tr>\n
    v5e<\/td>\n2023<\/td>\ncusto\/watt<\/td>\n197 TFLOPS BF16<\/td>\n16 GB HBM2e<\/td>\n256 chips<\/td>\n<\/tr>\n
    v5p<\/td>\n2023<\/td>\nLLM (Gemini)<\/td>\n459 TFLOPS BF16<\/td>\n95 GB HBM3<\/td>\n8.960 chips<\/td>\n<\/tr>\n
    v6e Trillium<\/td>\n2024<\/td>\nMXU 256\u00d7256<\/td>\n918 TFLOPS BF16<\/td>\n32 GB, 1.638 GB\/s<\/td>\n256 chips<\/td>\n<\/tr>\n
    TPU7x Ironwood<\/strong><\/td>\n2025 (GA 2026)<\/td>\ndois chiplets, FP8<\/td>\n2.307 BF16 \/ 4.614 FP8<\/strong><\/td>\n192 GB, 7.380 GB\/s<\/strong><\/td>\n9.216 chips<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Ironwood \u00e9 o primeiro TPU pensado com infer\u00eancia no centro: 2 TensorCores, 4 SparseCores por chip, ICI de 1.200 GB\/s bidirecional. Um superpod de 9.216 chips chega a 42,5 EFLOPS em FP8<\/strong>. Foi anunciado em 9 de abril de 2025<\/strong>, entrou em preview<\/em> no Cloud em 24 de novembro de 2025 e chegou \u00e0 disponibilidade geral em 31 de mar\u00e7o de 2026<\/strong>. No Cloud h\u00e1 um \u00fanico recorte de VM, a tpu7x-standard-4t<\/code>: 4 chips, 768 GiB de HBM, 224 vCPUs e 960 GB de RAM no host. A v6e continua sendo o custo\/benef\u00edcio para Gemma, Llama e difus\u00e3o.<\/p>\n
    A oitava gera\u00e7\u00e3o j\u00e1 foi anunciada<\/h2>\n
    Em 22 de abril de 2026<\/strong>, no Cloud Next \u201926, o Google apresentou a gera\u00e7\u00e3o seguinte \u2014 e, pela primeira vez, dividida em duas pe\u00e7as com prop\u00f3sitos separados:<\/p>\n