Escolher o chip errado pode sair muito mais caro do que escolher o modelo de IA errado. Um modelo intermediário, executado em um hardware bem dimensionado, pode entregar excelentes resultados. Por outro lado, até o modelo mais avançado pode se tornar um problema quando executado em uma infraestrutura inadequada, gerando custos elevados de nuvem, desperdício de recursos e atrasos que comprometem todo o projeto.

Quando falamos de IA, a conversa quase sempre gira em torno dos modelos: quantos parâmetros, qual arquitetura, qual posição no benchmark da semana. O hardware fica em segundo plano, como se fosse um detalhe de infraestrutura que alguém resolve depois. Na prática, é o contrário. A arquitetura do chip define o que é viável treinar, quanto custa servir cada requisição e qual latência o usuário final vai sentir na tela.

Hoje, quatro famílias de processadores disputam esse espaço. A CPU, que está em todo computador. A GPU, que virou sinônimo de IA na última década. A TPU, que o Google construiu sob medida para seus próprios modelos. E a LPU, a aposta da Groq em inferência de linguagem com latência mínima. Cada uma nasceu para resolver um problema diferente, e é justamente por isso que nenhuma delas é “a melhor” em termos absolutos.

Neste post, vamos entender como cada chip funciona por dentro, onde brilha, onde tropeça e, principalmente, como se comporta nas duas fases que definem o ciclo de vida de um modelo de IA: o treinamento e a inferência.

Treinamento e Inferência: Duas Cargas de Trabalho Bem Diferentes

Treinar um modelo e usar um modelo são problemas de engenharia distintos, e um chip bom em um deles não é automaticamente bom no outro. Entender essa diferença é o que permite comparar as quatro famílias de forma justa.

O treinamento é um problema de vazão (throughput). A cada passo, o modelo processa um lote grande de exemplos, calcula o erro, propaga esse erro de volta por todas as camadas (o backpropagation) e atualiza bilhões de parâmetros. Lembre-se: IA se resume a Matemática, programação e computação.

Isso significa três coisas na prática:

• A conta é dominada por multiplicações de matrizes gigantescas, executadas milhões de vezes.
• A memória precisa guardar não só os pesos, mas também gradientes, estados do otimizador e ativações intermediárias. Para um modelo treinado em precisão mista com o otimizador Adam, a regra prática é algo em torno de 16 bytes por parâmetro, antes mesmo de contar as ativações. O otimizador Adam é estudado em detalhes no curso de Deep Learning aqui mesmo na DSA.
• Nenhum chip isolado dá conta. O trabalho é dividido entre milhares de aceleradores e a velocidade da rede que os conecta vira tão importante quanto a velocidade de cada chip.

Um treinamento de modelo de fronteira roda por semanas, de forma contínua, com o hardware perto de 100% de ocupação. O que importa é quanto trabalho útil sai por hora e por dólar.

A inferência é um problema de latência e de largura de banda de memória. Aqui só existe o passo para frente (forward pass), sem gradientes. Parece mais simples, e de fato exige menos conta, mas tem uma armadilha. Para modelos de linguagem, a inferência acontece em duas fases com perfis opostos:

1. Prefill. O modelo lê o prompt inteiro de uma vez. Essa fase é intensa em cálculo, parecida com o treinamento.
2. Decode. O modelo gera um token por vez e cada token novo depende de todos os anteriores. Para produzir cada token, o chip precisa ler todos os pesos do modelo da memória. Gerar 500 tokens significa varrer os pesos 500 vezes.

Na fase de decode, o gargalo raramente é a capacidade de cálculo. É a velocidade com que os pesos saem da memória e chegam às unidades de processamento. Um chip com muito poder de cálculo e pouca largura de banda fica ocioso esperando dados, como um chef rápido preso a uma despensa longe da cozinha.

Soma-se a isso o fato de que inferência acontece em tempo real, com um usuário esperando do outro lado. Um treinamento pode levar 30 dias ou 31 dias sem que ninguém perceba. Uma resposta de chatbot que demora 3 segundos em vez de 1 segundo muda a percepção de qualidade do produto inteiro.

O treinamento quer o máximo de cálculo e de interconexão para fazer tudo de uma vez. A inferência quer memória rápida, latência baixa e custo baixo por token. Com tudo isso em mente, vamos aos chips.

CPU: O Generalista Que Ninguém Deveria Subestimar

A CPU não treina modelos grandes, mas ainda é o chip que mais faz inferência de IA no mundo, simplesmente porque está em todo lugar. Vale entender por que ela é ruim em uma tarefa e surpreendentemente competente na outra.

Como funciona. Uma CPU moderna de servidor tem algumas dezenas de núcleos (os AMD EPYC 9005 chegam a 192), e cada núcleo é uma pequena obra de engenharia: previsão de desvios, execução fora de ordem, caches enormes. Tudo foi desenhado para executar uma sequência de instruções complexas o mais rápido possível. É o processador certo para lógica de negócio, bancos de dados, sistemas operacionais e para a maior parte do código que escrevemos no dia a dia.

O problema é que redes neurais não precisam de inteligência por instrução. Precisam de força bruta: a mesma multiplicação, repetida bilhões de vezes, sobre dados diferentes. Uma CPU com 64 núcleos consegue fazer 64 coisas ao mesmo tempo (um pouco mais com instruções vetoriais como AVX-512). Uma GPU faz dezenas de milhares. A diferença de vazão em multiplicação de matrizes é de uma a duas ordens de grandeza.

No treinamento. Para Deep Learning em escala, a CPU está fora do jogo. Treinar um modelo de linguagem de 7 bilhões de parâmetros em CPU levaria meses onde uma GPU leva dias. Ela continua perfeitamente adequada para o que a gente chama de Machine Learning clássico: XGBoost, LightGBM, regressões, árvores de decisão, scikit-learn. Boa parte dos modelos que geram dinheiro em empresas brasileiras hoje são exatamente esses e rodam em CPU sem drama.

Na inferência. Aqui a história muda. Três coisas tornaram a CPU uma opção séria para servir modelos pequenos e médios:

• Instruções de matriz dedicadas. Os Intel Xeon 6 trazem o AMX (Advanced Matrix Extensions), uma unidade que processa blocos de INT8 e BF16 em hardware. Em testes com llama.cpp, um Llama 3.2 de 3B quantizado saiu de 28 para 57 tokens por segundo só com o AMX ligado, e chegou a 80 tokens por segundo com quantização de 4 bits.
• Quantização agressiva. Com pesos em 4 ou 8 bits, um modelo de 8B cabe em poucos gigabytes de RAM comum, e RAM de servidor é barata e abundante: terabytes, não gigabytes.
• Ferramental maduro. llama.cpp, OpenVINO, ONNX Runtime e o backend de CPU do vLLM já são opções de produção, não experimentos.

O limite continua sendo a largura de banda de memória. Um servidor com 12 canais de DDR5 entrega algo entre 400 e 850 GB/s, enquanto uma GPU de datacenter passa de 8 TB/s. Como vimos, a fase de decode é limitada justamente por isso. A CPU serve bem um chatbot interno com poucas dezenas de usuários simultâneos usando um modelo de 8B. Não serve bem um modelo de 70B para mil usuários.

Onde a CPU brilha de verdade. Em cargas intermitentes, onde uma GPU ficaria ociosa a maior parte do tempo. Em ambientes com restrição de dados, onde o modelo precisa rodar no servidor que a empresa já tem. Em embeddings e busca vetorial para RAG. E no papel de anfitriã de qualquer cluster de GPUs: tokenização, pré-processamento, carregamento de dados e orquestração passam todos pela CPU, e um cluster com CPU fraca deixa GPUs caras esperando.

GPU: O Paralelismo Que Mudou a História da IA

A GPU se tornou o padrão do mercado para treinamento e uma das principais escolhas para inferência de modelos grandes. Isso se deve ao seu paralelismo massivo, aliado a um ecossistema de software maduro e acessível.

Como funciona. A GPU nasceu para renderizar gráficos, executando a mesma operação sobre milhões de pixels simultaneamente. Em vez de poucos núcleos complexos, utiliza milhares de núcleos mais simples trabalhando em paralelo. Em 2012, a AlexNet demonstrou que essa arquitetura também era ideal para treinar redes neurais profundas. CUDA, lançado em 2007, já permitia programar GPUs para aplicações além dos gráficos.

Desde a geração Volta (2017), as GPUs NVIDIA incorporam Tensor Cores, unidades especializadas em operações matriciais com precisão reduzida (FP16, BF16, FP8 e FP4). Ao redor do processador fica a HBM (High Bandwidth Memory), memória de altíssima largura de banda. O Blackwell Ultra B300 oferece 288 GB de HBM3e a 8 TB/s, enquanto o Rubin mantém essa capacidade com HBM4 a 22 TB/s.

Outro componente essencial é o NVLink, que interliga dezenas de GPUs. O rack Vera Rubin NVL72 reúne 72 GPUs Rubin e 36 CPUs Vera, com 3,6 TB/s de NVLink por GPU. Segundo a NVIDIA, entrega 2,5 exaflops de treinamento e 3,6 exaflops de inferência em NVFP4. Centenas desses racks, conectados por redes de alta velocidade, formam as chamadas fábricas de IA em datacenters sendo construídos neste momento em várias partes do planeta.

No treinamento. A GPU domina por três razões: enorme capacidade de processamento em precisão mista, escalabilidade com ferramentas como PyTorch e NCCL e, principalmente, um ecossistema consolidado. Bibliotecas, kernels otimizados e frameworks foram desenvolvidos durante anos com CUDA como referência. A AMD, com a linha Instinct e o ROCm, avança em hardware, mas o software ainda diferencia a NVIDIA.

Na inferência. A HBM favorece especialmente a fase de decode, limitada pela largura de banda da memória. Ferramentas como vLLM, TensorRT-LLM e SGLang agrupam requisições em lotes, aumentando a eficiência e a geração de tokens por segundo para muitos usuários simultâneos. A NVIDIA afirma que a plataforma Vera Rubin pode reduzir o custo por token em até dez vezes em relação ao Blackwell.

A principal limitação aparece na latência individual. GPUs otimizadas para grandes lotes nem sempre são as mais rápidas para gerar tokens sequencialmente para um único usuário. Consumo e preço também pesam: um B300 utiliza cerca de 1.400 W, enquanto um rack NVL72 ultrapassa 130 kW.

Por isso, a própria NVIDIA passou a combinar arquiteturas especializadas. O Rubin CPX, com memória GDDR7, acelera o prefill de contextos longos, enquanto o Groq 3 LPU, apresentado adiante, prioriza o decode de altíssima velocidade. A GPU permanece no centro, mas compartilha tarefas.

Disponibilidade em 2026. O Blackwell Ultra B300 já está em produção, enquanto o Vera Rubin entrou em produção plena em junho, com disponibilidade para parceiros no segundo semestre. A demanda dos hyperscalers pode prolongar as filas de alocação até 2027. Para muitas aplicações com modelos de até 70B, o Blackwell já oferece capacidade mais do que suficiente.

TPU: O Chip Que o Google Desenhou Para Multiplicar Matrizes

A TPU demonstra que um chip projetado para uma operação específica pode alcançar uma eficiência superior à de processadores generalistas. Criada pelo Google em 2015 para busca e tradução, tornou-se a base do treinamento e da inferência dos modelos Gemini.

Como funciona. TPU significa Tensor Processing Unit e pertence à categoria dos ASICs, circuitos integrados de aplicação específica. Diferentemente da GPU, que preserva flexibilidade para diversos cálculos, a TPU prioriza operações matriciais. Seu componente central é o arranjo sistólico (systolic array), uma grade de milhares de unidades de multiplicação e soma pelas quais os dados circulam continuamente, como em uma linha de montagem.

A eficiência vem da redução do movimento de dados. Em vez de enviar resultados intermediários repetidamente à memória, o arranjo sistólico os transfere diretamente entre células, economizando energia. A contrapartida é menor flexibilidade: o compilador XLA precisa planejar a execução e códigos com condicionais e acessos irregulares tendem a apresentar desempenho inferior.

O chip utiliza HBM e uma interconexão proprietária chamada ICI (Inter-Chip Interconnect), capaz de conectar milhares de TPUs em topologias de toro, com switches ópticos para reconfigurar os clusters. Um pod Ironwood, da sétima geração, reúne 9.216 chips.

O que mudou em 2026. Em abril, no Google Cloud Next, o Google apresentou duas versões da oitava geração, reconhecendo que treinamento e inferência passaram a exigir otimizações distintas.

A TPU 8t (training) foi desenvolvida para pré-treinamento massivo, com topologia de toro 3D conectando 9.600 chips, SparseCore para operações irregulares com embeddings e suporte nativo a FP4. Segundo o Google, oferece até 2,7 vezes mais desempenho por dólar que a Ironwood em treinamento de larga escala.

Já a TPU 8i (inference) prioriza raciocínio e baixa latência. Possui três vezes mais SRAM para ampliar o KV cache, um motor dedicado à sincronização do decode e a topologia Boardfly, que conecta até 1.152 chips, reduzindo a comunicação necessária para modelos MoE. A promessa é aproximadamente 80% mais desempenho por dólar que a Ironwood em cenários de baixa latência.

Segundo o Google, ambas dobram o desempenho por watt da geração anterior. A Ironwood já está em disponibilidade geral e integra o acordo pelo qual a Anthropic pretende utilizar até um milhão de TPUs para treinar e executar modelos Claude.

No treinamento. A TPU é a principal alternativa à GPU com histórico comprovado em modelos de fronteira. O Gemini utiliza essa arquitetura, cuja combinação de arranjo sistólico, ICI e compilador XLA proporciona elevada eficiência em clusters grandes e cargas regulares. O desafio está no ecossistema: JAX é o caminho natural, PyTorch depende do PyTorch/XLA, e a otimização exige conhecimentos ainda pouco difundidos fora do Google.

Na inferência. Desde a Ironwood, o Google passou a enfatizar essa aplicação, aprofundada pela TPU 8i. Para atender muitos usuários com modelos grandes e custo por token reduzido, a arquitetura está entre as alternativas mais eficientes. As melhorias de SRAM e comunicação também favorecem a latência individual, embora esse não seja seu principal diferencial.

A ressalva. Diferentemente de uma GPU, a TPU não é comercializada como equipamento independente. Seu acesso ocorre essencialmente pelo Google Cloud. Adotar TPUs significa também escolher um fornecedor de nuvem, decisão que precisa considerar custos, flexibilidade e dependência tecnológica.

LPU: A Aposta da Groq em Inferência Determinística

A LPU não foi criada para treinamento. Seu objetivo é gerar tokens com velocidade extrema e latência previsível, especialmente para usuários individuais. Em 2026, essa arquitetura deixou de ser uma aposta isolada da Groq e passou a integrar a estratégia de inferência da NVIDIA.

De onde veio. Fundada em 2016 por Jonathan Ross, um dos criadores da primeira TPU do Google, a Groq desenvolveu uma arquitetura apresentada em 2020 como Tensor Streaming Processor. A ideia era levar a especialização do hardware ainda mais longe. LPU significa Language Processing Unit, refletindo seu foco no processamento de modelos de linguagem.

Como funciona. Três características explicam suas diferenças em relação às GPUs.

A primeira é utilizar SRAM dentro do chip, em vez de depender de HBM externa. A SRAM oferece largura de banda extremamente elevada, mas ocupa muito espaço físico. A LPU original possuía aproximadamente 230 MB, enquanto o Groq 3 LPU chega a 500 MB e 150 TB/s. Para comparação, uma GPU Rubin oferece 288 GB de HBM. A solução da Groq é distribuir os pesos do modelo entre centenas de chips, mantendo-os residentes na SRAM.

A segunda característica é a execução determinística. O compilador define antecipadamente o trabalho de cada unidade e o momento em que os dados devem chegar. Sem escalonamento dinâmico ou mecanismos complexos de controle, o hardware executa um plano previamente organizado, permitindo latências mais previsíveis.

A terceira é uma organização interna baseada em colunas especializadas. Unidades de memória, multiplicação matricial e operações vetoriais são distribuídas de forma que os dados atravessem o chip continuamente, como em uma esteira. Isso reduz a complexidade do controle e favorece o fluxo de processamento.

O resultado ganhou notoriedade em 2024, quando a GroqCloud começou a executar o Llama 2 de 70B a centenas de tokens por segundo para um único usuário, superando amplamente a velocidade de muitas GPUs da época.

No treinamento. A LPU não foi projetada para essa finalidade. Sua arquitetura não oferece o ferramental necessário para backpropagation, enquanto a memória limitada por chip dificulta o armazenamento de gradientes e estados dos otimizadores. É um processador dedicado à inferência.

Na inferência. Seu principal diferencial é acelerar o decode de fluxos individuais, algo especialmente relevante para Agentes de IA. Esses sistemas realizam diversas chamadas sequenciais aos modelos e cada etapa depende da anterior. Assim, pequenas reduções na latência por token podem representar ganhos expressivos no tempo total de execução. O mesmo benefício se aplica a interfaces conversacionais e sistemas de voz em tempo real.

As limitações decorrem das próprias escolhas arquiteturais. O prefill de contextos longos, que exige muito cálculo, não é seu ponto forte. A pequena capacidade de memória por chip também exige interligar centenas de LPUs para modelos grandes, aumentando a complexidade e o investimento. Para atender milhares de usuários simultaneamente em grandes lotes, as GPUs ainda podem oferecer melhor economia.

O que aconteceu em 2026. Em 24 de dezembro de 2025, a NVIDIA fechou um acordo de licenciamento não exclusivo da tecnologia Groq, estimado em US$ 20 bilhões, incorporando Jonathan Ross e parte da equipe de engenharia. A Groq continuou operando a GroqCloud, oferecendo modelos abertos como Llama, DeepSeek, Qwen e GPT-OSS, além de captar US$ 650 milhões em junho de 2026. Ensinamos aos alunos como usar a plataforma Groq em diversos cursos aqui na Data Science Academy onde precisamos de acesso rápido à inferência de LLMs.

Na GTC de março, Jensen Huang apresentou o NVIDIA Groq 3 LPU, fabricado pela Samsung, e o rack Groq 3 LPX, equipado com 256 LPUs e 128 GB de SRAM agregada. A proposta é instalá-lo ao lado dos racks Vera Rubin NVL72, criando uma infraestrutura de inferência especializada.

A divisão de tarefas é clara: GPUs executam treinamento, inferência em lote e prefill, enquanto LPUs aceleram o decode, com a proposta de ultrapassar 1.000 tokens por segundo por usuário. O software Dynamo coordena a comunicação entre as arquiteturas. Segundo a NVIDIA, essa combinação pode oferecer até 35 vezes mais tokens por watt nesse regime, em comparação com um rack Blackwell NVL72 isolado. As entregas começaram no segundo semestre de 2026.

A conclusão: até a maior fabricante de GPUs do mundo reconheceu que a próxima geração de inferência exige arquiteturas complementares.

Como Escolher na Prática: Cenários Comuns

A pergunta certa nunca é “qual chip é melhor” e sim “qual é o gargalo da minha carga de trabalho”. Abaixo, os cenários que mais aparecem no dia a dia de quem trabalha com dados e IA, com a escolha que costuma fazer sentido em cada um.

Você treina modelos clássicos (XGBoost, regressão, árvores) sobre dados tabulares. CPU, sem hesitar. Uma GPU aqui é dinheiro parado. Só vale reconsiderar se os datasets passarem de dezenas de milhões de linhas e bibliotecas como cuML ou XGBoost com suporte a GPU começarem a fazer diferença de horas.

Você faz fine-tuning de um modelo aberto de 7B a 70B para um caso de uso específico. GPU. Uma única placa com 80 a 96 GB (H100, RTX PRO 6000 Blackwell) resolve LoRA e QLoRA em modelos de 70B. Para fine-tuning completo, um servidor com 4 a 8 GPUs. O ecossistema CUDA garante que qualquer tutorial, biblioteca ou receita vai funcionar.

Você pré-treina um modelo do zero em escala de bilhões de parâmetros. GPU ou TPU, e a decisão é mais contratual do que técnica. Se sua equipe já vive em JAX e você aceita ficar no Google Cloud, a TPU tende a entregar mais exaflops por dólar. Se você precisa de portabilidade entre nuvens e da amplitude do ecossistema, GPU. Nos dois casos, a interconexão e a infraestrutura de rede pesam tanto quanto o chip.

Você serve um modelo pequeno (até 8B) para um time interno, com uso intermitente. CPU com AMX ou mesmo uma GPU modesta. Um Xeon 6 servindo um modelo quantizado em 4 bits via llama.cpp ou vLLM entrega dezenas de tokens por segundo, no servidor que a empresa já tem, sem fila de alocação nem fatura de nuvem.

Você serve um modelo de 70B ou maior para milhares de usuários simultâneos. GPU (ou TPU, no Google Cloud). O que importa aqui é vazão agregada com custo por token baixo, e isso se consegue com batching contínuo, quantização em FP8 ou FP4 e muita largura de banda de HBM. Blackwell já é suficiente para a maior parte das cargas de produção em 2026.

Você constrói um agente que encadeia dezenas de chamadas ao modelo, ou uma interface de voz em tempo real. LPU, via GroqCloud ou, quando disponível, via racks LPX. A latência de cada chamada se acumula, e a diferença entre 100 e 800 tokens por segundo muda o produto. Se o agente usa modelos que a GroqCloud não oferece, a alternativa é uma GPU com configuração orientada a latência (lotes pequenos, decodificação especulativa).

Você está em um ambiente regulado e os dados não podem sair do seu datacenter. CPU ou GPU on-premises. TPU e LPU, hoje, são essencialmente serviços de nuvem, embora os racks LPX da NVIDIA comecem a mudar isso para quem tem orçamento de hyperscaler.

Você ainda não sabe qual vai ser a carga. Comece na GPU em nuvem, com cobrança por hora. É a opção mais flexível, com o ecossistema mais amplo e a menor chance de descobrir, três meses depois, que a arquitetura escolhida não suporta o que você precisa. Migre para CPU, TPU ou LPU quando o perfil da carga ficar claro e o custo justificar a especialização.

Uma regra prática para fechar: flexibilidade custa caro em escala, e especialização custa caro em mudança. A GPU é o meio-termo que serve quase tudo razoavelmente bem. As outras três ganham quando você sabe exatamente o que precisa.

Conclusão: O Que Levar Deste Post?

A era do chip único acabou e os próprios fabricantes estão dizendo isso. O Google dividiu a oitava geração de TPUs em uma versão para treinar e outra para servir. A NVIDIA colocou um chip de prefill e um chip de decode ao lado da GPU no rack Vera Rubin. Nenhuma dessas empresas faria isso se uma arquitetura só desse conta de tudo com eficiência.

Por trás de toda essa diversidade existe uma única ideia que vale a pena memorizar. O treinamento é limitado por cálculo e interconexão: ele quer o máximo de operações por segundo e a rede mais rápida possível entre milhares de chips. A inferência é limitada por memória e latência: ela quer os pesos perto das unidades de processamento e cada token entregue sem espera. CPU, GPU, TPU e LPU são respostas diferentes para onde colocar a memória, quanta flexibilidade sacrificar e quanto controle entregar ao compilador.

Para quem trabalha com dados e IA, a implicação prática é que entender hardware deixou de ser assunto de engenheiro de infraestrutura. A escolha do chip define o custo por token do seu produto, a latência que seu usuário sente e a viabilidade do seu cronograma de treinamento. Quem domina essa camada toma decisões melhores sobre modelos, arquiteturas e orçamentos.

E o cenário vai continuar mudando. Rubin Ultra em 2027, uma nova geração de TPUs, mais chips de inferência dedicados de startups e hyperscalers. Os nomes vão mudar; os princípios deste post, não. Treinamento e inferência continuarão sendo problemas diferentes, e o chip certo continuará sendo o que resolve o gargalo que você realmente tem.

Equipe DSA

Referências:

Two new TPUs to power the next wave of AI training and inference at Google

Google presents TPU 8t and TPU 8i chips; splits training and inference

Google Cloud Details Ironwood TPUs and Axion CPUs for AI Inference

NVIDIA GPU Roadmap 2026-2030: Rubin, Rubin Ultra, Feynman

Should I Wait for NVIDIA Rubin or Buy Blackwell?

Groq AI: LPU Chips, GroqCloud, and Pricing