Google TPU ou NVIDIA H100: como escolher o acelerador de IA certo

A diferença central: especialização contra flexibilidade

TPUs são ASICs especializados em processamento tensorial para machine learning ^[2]. Essa especialização é justamente o que pode torná-las atraentes em cargas grandes e regulares: se o compilador, os formatos dos tensores, o batch e o particionamento do modelo colaboram, é mais fácil manter o hardware trabalhando de forma eficiente.

A H100 segue uma lógica mais flexível. Ela é fortemente otimizada para IA por meio dos Tensor Cores, mas a tabela pública da H100 SXM também inclui desempenho em FP64 e FP32 convencionais, além de vários modos de menor precisão ^[10]. Essa variedade importa quando o mesmo pool de aceleradores precisa atender experimentos diferentes, bibliotecas existentes ou trabalhos que não são todos o mesmo tipo de deep learning.

Especificações públicas ajudam, mas não são benchmark

As tabelas de especificação mostram o formato da disputa, não o vencedor final. TPUs e GPUs costumam publicar números em modos de precisão diferentes, com premissas de sistema diferentes e caminhos de escala diferentes.

O Google Cloud também documenta tipos de máquina A3 com 1, 2, 4 ou 8 GPUs H100 anexadas, cada uma com 80 GB de HBM3 ^[1]. Além disso, o material do AI Hypercomputer do Google Cloud trata TPUs e VMs A3 com GPUs H100 como parte do mesmo portfólio de infraestrutura para IA ^[18]. Ou seja: na prática, a escolha nem sempre é TPU no Google Cloud contra GPU em outro lugar. Às vezes, as duas opções estão no mesmo ambiente de nuvem.

Quando Google TPU faz mais sentido

A TPU tende a ser a candidata mais forte quando a especialização é vantagem, não obstáculo. Ela deve entrar no topo da lista se:

• o trabalho é treino ou inferência de deep learning dominado por grandes operações tensorais ^[2];
• o modelo tem formatos, batches e padrões de particionamento relativamente estáveis;
• a equipe aceita trabalhar com práticas de escala próprias do universo TPU, já que a documentação de JAX usa tamanho de pod, tamanho de host, HBM, largura de banda e throughput BF16/INT8 como dimensões centrais de planejamento ^[11];
• o Google Cloud já é o ambiente previsto para implantação;
• o objetivo de negócio é custo-desempenho medido em poucos modelos importantes, e não portabilidade máxima para muitos tipos de workload.

TPUs podem ser muito competitivas quando a carga mantém os chips ocupados e não exige reescritas caras. Mas isso é resultado de workload, não uma regra universal. O próprio Google já publicou material sobre desempenho por dólar de GPUs e TPUs em inferência de IA, reforçando que a análise econômica precisa olhar para o serviço em execução, e não só para o nome do acelerador ^[16].

Quando NVIDIA H100 faz mais sentido

A H100 costuma ser a escolha mais segura quando flexibilidade vale mais que especialização. Ela é especialmente atraente quando:

• você precisa de modos de maior precisão, como FP64 ou FP32, além de modos Tensor Core de menor precisão; a tabela pública da H100 SXM inclui FP64, FP32, TF32, BF16, FP16, FP8 e INT8 ^[10];
• a base de código já depende de kernels, bibliotecas ou ferramentas operacionais orientadas a GPU;
• o mesmo hardware precisa atender vários tipos de carga, não apenas uma família estreita de modelos;
• você quer usar H100 no Google Cloud, onde os tipos de máquina A3 são documentados com 1, 2, 4 ou 8 GPUs H100 ^[1];
• o risco de migração pesa mais que um possível ganho teórico de eficiência no chip.

O melhor argumento a favor da H100 não é que uma GPU sempre vence uma TPU em qualquer benchmark. É que ela oferece um caminho mais flexível quando os requisitos mudam.

Custo: preço por hora é só o começo

Comparar preços é tentador, mas pode ser enganoso. Um comparativo de terceiros listou a Google Cloud TPU v5e em cerca de US$ 1,20 por chip-hora e um exemplo de Azure ND H100 v5 em cerca de US$ 12,84 por hora de uma H100 de 80 GB ^[4]. Como é uma comparação não oficial e entre nuvens diferentes, ela deve ser vista apenas como sinal direcional, não como prova universal de que TPU sempre sai mais barato.

Uma comparação melhor mede o sistema inteiro:

1. Throughput útil: etapas de treino por segundo, amostras por segundo, tokens por segundo ou latência no batch-alvo.
2. Modo de precisão: FP8, BF16, FP16, TF32, FP32, FP64 e INT8 não são intercambiáveis ^[10][11].
3. Memória e largura de banda: modelos grandes, contextos longos e batch size podem deslocar o gargalo do cálculo para a memória ^[10][11].
4. Comportamento em escala: topologia de pod em TPU e configuração das VMs com H100 afetam o desenho de treino distribuído e serving ^[1][11].
5. Utilização real: acelerador ocioso custa caro, mesmo quando o preço por hora parece bom.
6. Custo de engenharia: portabilidade, compilador, depuração, monitoramento e mudanças de deploy podem anular economias no chip-hora.

A métrica prática é custo por resultado útil: por etapa de treino, por modelo convergido, por token de inferência ou por meta de latência.

Matriz de decisão

Conclusão

Pense na TPU como o acelerador mais especializado para IA e na H100 como a plataforma de aceleração mais flexível. Se o seu modelo é amigável a TPU, depende fortemente de deep learning e já está indo para Google Cloud, uma TPU pode oferecer a melhor relação custo-desempenho. Se você precisa de modos numéricos variados, workloads mistos, continuidade operacional em GPU ou menor risco de migração, a NVIDIA H100 tende a ser o ponto de partida mais seguro ^[10][11].

A resposta final confiável vem de benchmark no workload real: throughput, comportamento de memória, utilização, custo total e esforço de engenharia no modelo exato que você pretende treinar ou servir.