Por trás de cada token do ChatGPT, de cada frame do Sora e de cada LLM que você roda no Ollama, tem um acelerador fazendo a mesma conta trilhões de vezes: multiplicação de matrizes. Os dois jeitos de fazer isso em silício — GPU (NVIDIA) e TPU (Google) — partem de filosofias opostas. Este texto parte do vídeo GPU vs TPU: How AI Chips Actually Work, do Pouria Taj.
O vídeo usa a H100 e a TPU v5e como peças de ensino. Em 2026 o chão de fábrica já é Blackwell de um lado e Trillium/Ironwood do outro — a lição de arquitetura não mudou.
Por que IA é MatMul
Um LLM não vomita o parágrafo de uma vez. A geração é autoregressiva: o prompt vira embeddings, o Transformer produz uma distribuição sobre o próximo token, o token escolhido volta para a entrada, e o ciclo se repete.
Nos diagramas, neurônios e setinhas. No silício, matrizes de pesos. O GPT-3 (175 B, 96 camadas) já empilha dezenas de milhares delas; Claude Opus e GPT-4 sobem para centenas de bilhões a trilhões de parâmetros. Quase todo o custo é o mesmo MAC: linha × coluna, soma, grava a célula da saída.
A sorte do hardware: cada célula da matriz resultante é independente. Não precisa esperar a [0,0] para calcular a [500,200]. Por isso CPU de poucos núcleos rápidos perde feio — e por isso GPU e TPU existem.
Por dentro da GPU: H100
O die GH100 (Hopper) da H100 SXM: 80 bilhões de transistores, 8 GPCs, 132 SMs, 80 GB de HBM3 a 3,35 TB/s, TDP até 700 W.
GH100 (H100 SXM)
80 B transistores | 8 GPC | 132 SM | 80 GB HBM3
SM × 132
4 warp schedulers
128 CUDA cores (FP32/INT32)
4 Tensor Cores (MatMul 4×4, FP8/FP16/BF16)
256 KB registradores | até 228 KB shared/L1
- 16.896 CUDA cores: ALU de uso geral. A ~1,98 GHz isso dá ~67 TFLOPS FP32 (um FMA por ciclo).
- 528 Tensor Cores (4 por SM): hardware de álgebra densa. Bloco de matriz por instrução, FP16/BF16/FP8. Pico de marketing: ~2 PFLOPS FP8 denso, ~4 PFLOPS com esparsidade 2:4.
O host despacha um kernel. Uma MatMul 4096×4096 tem 16,7 milhões de células → milhões de threads, empacotadas em blocos (até 1024). O GigaThread Engine espalha os blocos pelos 132 SMs. Dentro do SM, as threads andam em warps de 32, mesma instrução no mesmo ciclo (SIMT).
O gargalo: memory wall
Um MAC nos registradores: ~4 ciclos. Trazer o número da HBM3 até o core: centenas de ciclos. Gravar o resultado: outra viagem. E milhares de núcleos vizinhos buscam, ao mesmo tempo, a mesma linha e a mesma coluna que o colega do lado acabou de carregar.
Boa parte da energia da GPU não é matemática — é mover dado. É o mesmo muro que a indústria de DRAM tenta furar com HBM e LPDDR (veja a CXMT no LPDDR6).
A aposta da TPU: arranjo sistólico
A pergunta do Google: e se o núcleo passasse o número que acabou de usar direto para o vizinho, sem devolver para a memória?
A TPU é um ASIC só de tensor. Na v5e, cada TensorCore tem quatro MXU de 128×128 MACs — 16.384 unidades por array, quase o total de CUDA cores da H100, mas soldadas umas nas outras. Sem registrador no meio. O nome vem da sístole: o dado pulsa no ritmo do clock.
X0 X1 X2
| | |
v v v
Y0→ MAC → MAC → MAC →
| | |
v v v
Y1→ MAC → MAC → MAC →
| | |
v v v
S0 S1 S2
- Pesos param: saem da HBM, entram na VMEM (SRAM) e ficam fixos em cada célula do array.
- Entradas fluem: o prompt entra pela esquerda e anda um passo por ciclo.
- Acúmulo desce: cada célula multiplica o que passa pelo peso local, soma o que veio de cima, manda para baixo.
- Resultado sai na borda — coluna a coluna, sem round-trip.
A HBM é tocada duas vezes: carregar peso, ler o resultado. Quase 100% da energia vira conta, não trânsito. v5e: ~197 TFLOPS BF16, 16 GB HBM, 819 GB/s — menos pico que a H100, mais joule por MAC em MatMul densa. Em 2026 o mesmo desenho cresceu: Trillium (v6e) foi a 256×256; Ironwood (TPU7x) chega a ~4,6 PFLOPS FP8 e 192 GB de HBM3e por chip, ainda só no GCP.
GPU vs TPU, lado a lado
| NVIDIA H100 (GPU) | Google TPU v5e | |
|---|---|---|
| Tipo | SIMT programável | ASIC de tensor |
| MatMul | CUDA + Tensor Cores, via registrador/cache | MXU sistólico 128×128 |
| Memória | HBM o tempo todo | dado flui célula a célula |
| Pico | ~2 PFLOPS FP8 denso / 700 W | ~197 TFLOPS BF16 |
| Onde roda | AWS, Azure, GCP, on-prem, PC | só Google (GCP / pods) |
| Software | CUDA, PyTorch, Triton, TensorRT | JAX, TensorFlow, XLA, PyTorch-XLA |
Por que o mundo ainda compra GPU
Se a TPU gasta menos joule na mesma conta, por que a fila da NVIDIA não acaba?
- Rigidez do ASIC. A TPU é rápida porque o silício é a matemática dos Transformers de agora. Um modelo novo que não viva de MatMul densa deixa um data center de ASIC no vácuo.
- A GPU não fez essa aposta. Qualquer kernel — física, molécula, híbrido, o próximo paper — cabe em software.
- O fosso do CUDA. Duas décadas de bibliotecas e gente que já sabe. Código novo sobe no driver da NVIDIA no mesmo dia. Risco de adoção, para empresa, é o que decide a compra — não o TDP da MXU.
Referências
- Vídeo: Pouria Taj — GPU vs TPU: How AI Chips Actually Work
- NVIDIA — Hopper architecture in-depth
- Google Cloud — TPU v5e
- How to Scale Your Model — How to think about TPUs
- llama-model: GGUF no Linux sem o daemon do Ollama
Especialização extrema versus generalidade: a TPU mostra o teto de eficiência quando a conta é conhecida; a GPU vende o seguro de que a conta de amanhã ainda cabe no mesmo rack. No Linux do dia a dia, o que você tem na mesa continua sendo a GPU — e o CUDA que veio junto.