Como entender a GPU

• A GPU desempenha um papel central no machine learning moderno e é estruturada pela combinação de inúmeros Streaming Multiprocessors (SMs), especializados em operações de multiplicação de matrizes em alta velocidade, com HBM (memória de alta largura de banda)
• O SM da GPU é dividido em Tensor Core (multiplicação de matrizes) e CUDA Core (operações vetoriais), oferecendo suporte a computação paralela em larga escala e programação flexível
• GPU e TPU diferem em estrutura interna e configuração de rede; a GPU tem maior versatilidade e escalabilidade, mas alcançar o desempenho ideal exige mais considerações
• Dentro de um nó (Node), é possível realizar comunicação ultrarrápida entre GPUs por meio de NVLink e NVSwitch; entre nós, elas se conectam por redes como InfiniBand, atendendo ao treinamento distribuído em grande escala
• Em GPUs, as operações coletivas (Collectives) (ex.: AllReduce, AllGather etc.) variam muito em desempenho conforme a estrutura de hardware e as camadas de rede, e na prática tendem a ficar abaixo da largura de banda teórica

---

O que é uma GPU?

• As GPUs modernas de ML (ex.: H100, B200) combinam dezenas a centenas de Streaming Multiprocessors (SMs) especializados em multiplicação de matrizes com memória HBM rápida
• Cada SM possui Tensor Core (multiplicação de matrizes), Warp Scheduler (operações vetoriais) e SMEM (cache on-chip)
• Diferentemente da TPU, a GPU permite processamento paralelo mais flexível e em maior escala por meio de mais de 100 SMs

Estrutura detalhada do SM

• O SM é dividido em 4 subpartições, e cada subpartição contém seu próprio Tensor Core, CUDA Core (operações vetoriais), Warp Scheduler, arquivo de registradores etc.
• O CUDA Core é responsável por operações aritméticas vetoriais (SIMD/SIMT), enquanto o Tensor Core é especializado em multiplicação de matrizes
• Os FLOPs de Tensor Core são esmagadoramente maiores, e em operações de menor precisão a velocidade de processamento aumenta ainda mais
• GPUs mais recentes (ex.: B200) adicionam uma grande TMEM para suportar entradas volumosas do Tensor Core

A flexibilidade do CUDA Core

• O CUDA Core da GPU usa o modelo SIMT (Single Instruction Multiple Threads), executando uma instrução em paralelo em múltiplas threads
• Cada thread possui um ponteiro de instrução independente (program counter), oferecendo flexibilidade para desvios condicionais etc.; porém, quando há muita divergência de instruções dentro de um warp, o desempenho cai
• Cada CUDA Core tem estado individual e acesso à memória livremente (a TPU só consegue lidar com memória contígua)

Escalonamento/paralelismo

• O SM agenda vários warps (até 64) para execução simultânea, e cada warp scheduler executa um programa por vez
• Graças a essa estrutura, a GPU consegue oferecer alta simultaneidade mantendo considerável flexibilidade

Estrutura de memória da GPU

• A GPU tem a HBM como memória de maior capacidade e também possui uma hierarquia com L2/L1 (SMEM)/TMEM/registradores

Resumo das especificações das GPUs modernas

• A quantidade de SMs (Streaming Multiprocessors), clock, memória, FLOPs e largura de banda (BW) varia conforme o modelo
• A capacidade de memória (HBM), a largura de banda e os FLOPs (ponto flutuante / inteiro / baixa precisão) aumentam a cada geração
• Principais características na tabela (omitida): a Blackwell (B200) tem HBM de 192GB, HBM BW de 8.0TB/s, FP8 FLOPs de 4.5e15 etc.
• Em cada geração, são evidentes os avanços de hardware como aumento de registradores e cache on-chip (SMEM), além da adição de TMEM

Comparação entre GPU e TPU

• A GPU é de uso geral e modularizada em muitos SMs pequenos (unidades paralelas), com muito controle de hardware, o que dificulta o entendimento/otimização
• A TPU é composta por poucos Tensor Cores grandes e muitos ALUs vetoriais (VPUs), usando um modelo de controle de thread único que simplifica o hardware e reduz custos
• Por isso, na TPU a otimização por compilador é indispensável, enquanto na GPU vários kernels podem ser executados de forma independente, o que facilita o uso
• Em termos de desempenho/preço, recentemente a GPU H200 oferece cerca de 2x os FLOPs/s da TPU v5p, 1,5x a HBM e preço em torno de 2,5x maior
• A TPU tem muita VMEM (cache on-chip) rápida, o que pode gerar grande vantagem em inferência de modelos LLM etc.

Pontos do Q&A sobre hardware de GPU

• O H100 tem ao todo 16.896 núcleos CUDA fp32 (132 SM x 4 x 32), e o B200 tem 18.944
• Os FLOPs de operações vetoriais chegam a no máximo 33,5TFLOPs/s no H100, cerca de 30x menos que os FLOPs de multiplicação de matrizes do Tensor Core (990TFLOPs/s)
• A soma da capacidade de L1/SMEM e registradores do H100 é de 66MB, enquanto a VMEM da TPU é de 120MB
• A relação entre Bandwidth (largura de banda) e FLOPs (intensidade computacional teórica) é de cerca de 280-300 tanto no H100/B200 quanto na TPU

Networking de GPU (estrutura de comunicação)

Estrutura de nó/cluster

• Um nó de GPU geralmente agrupa 8 GPUs, conectadas diretamente em largura de banda total por NVLink (ultrarrápido) e NVSwitch (switch)
• Entre nós, é possível fazer scale-out usando InfiniBand (Ethernet etc.)
• As GPUs mais recentes (Blackwell) têm uma estrutura escalável até 72 nós

Características por camada de rede

• Dentro do nó (domínio NVLink): egress de 450GB/s por GPU (H100), 900GB/s (B200), e até 1.6TB/s por NVSwitch
• Camada superior entre nós (InfiniBand Leaf/Spine): estrutura com Leaf Switch (8) até Spine Switch (16), mantendo teoricamente 400GB/s de largura de banda total entre GPU~GPU
• Em arquiteturas de grande porte como o SuperPod, há 1024 GPUs (128 nós), e o GB200 (nó de 72 GPUs) tem largura de banda ampliada em 9x (3600GB/s)

Pontos sobre desempenho de rede

• Em teoria, a estrutura de rede (Full Fat Tree) é projetada para oferecer largura de banda máxima também entre nó~nó
• Devido a restrições de portas de hardware etc., ao escalar para 1024~4096 GPUs usa-se uma abordagem hierárquica com mais Spine/Core Switches
• A transição de largura de banda dentro do nó (450GB/s) para largura de banda entre nós (400GB/s) gera diferença de desempenho em operações coletivas

Estrutura das operações coletivas (Collectives)

• Há suporte a operações coletivas de alto nível como AllGather, AllReduce (soma), AllToAll (distribuição)
• Dentro do nó, o NVLink permite conexão direta com desempenho ideal possível (largura de banda teórica); entre nó~nó, passa-se pelo InfiniBand
• Utilizam-se as bibliotecas NCCL e NVSHMEM da NVIDIA

Análise de desempenho das operações coletivas

• AllGather/ReduceScatter: implementados em anel (Ring) na B/W (450GB/s no H100), com possibilidade de modo em árvore (Tree) para mensagens pequenas
• AllToAll: cada GPU envia diretamente para a GPU de destino; como a largura de banda é dividida por N, dentro do nó isso é teoricamente 2x mais rápido
• Em medições reais, o AllReduce fica em torno de 370GB/s, não atingindo o máximo do hardware
• Em comparação com a TPU, só em volumes grandes (dezenas de MB ~ GB) é que se aproxima do pico de largura de banda do hardware

Resumo geral e insights

• A GPU tem como pontos fortes a versatilidade e a escalabilidade, mas, dependendo da estrutura de hardware/rede, a dificuldade de otimização e observabilidade de desempenho é maior do que na TPU
• O networking (Intra-Node/NVLink/InfiniBand/Leaf/Spine etc.) é central para o desempenho em treinamento em larga escala, e é preciso atenção à diferença entre largura de banda real e teórica
• Entender as operações coletivas e a estrutura de rede é um elemento essencial em treinamento/serving de modelos distribuídos em escala extrema
• É necessário um processo baseado em benchmarks reais e na compreensão detalhada da estrutura de hardware para identificar gargalos de desempenho e condições ideais de otimização

[GN⁺]

Comentários do Hacker News

• Achei este texto e vários outros documentos meio pouco claros, especialmente porque, ao explicar GPUs, os termos muitas vezes são usados de forma ambígua; por exemplo, na primeira imagem o “Warp Scheduler” é descrito como uma unidade vetorial SIMD parecida com a VPU do TPU, com 32 “CUDA Cores”, mas não fica claro o que exatamente é um “CUDA core”, então a explicação não transmite direito o objeto central da descrição; por causa desse tipo de erro composto, para iniciantes ou para quem está tentando aprender os conceitos o entendimento continua difícil, enquanto para quem já entende um pouco do assunto isso tudo já é conhecido; mesmo que fosse um rascunho, ao publicar é preciso tratar cada termo com precisão cirúrgica, sem confundir nem misturar nomenclaturas; também acho que analogias devem ser usadas com cuidado, e termos como MXU (unidade de multiplicação de matrizes) deveriam ser fáceis de encontrar por meio de explicações adicionais ou hyperlinks; hoje em dia até dá para delegar isso à IA, o que é um pouco triste

  • Respondendo diretamente como autor: concordo em grande parte com a crítica; quanto mais tento garantir precisão na explicação, mais fico equilibrando isso com a “verdade moral”; por exemplo, eu poderia escrever “uma unidade semelhante à VPU do TPU, composta por 32 ALUs de unidade vetorial SIMD (single instruction, multiple data) que a NVIDIA chama de CUDA Cores”, mas aí a frase fica longa e ainda pode faltar a definição de termos como unidade vetorial; tento usar muitas notas de rodapé, mas também é difícil esperar que o leitor clique em cada uma delas, e sidenotes são difíceis de implementar em HTML; termos como MXU já tinham sido definidos em uma seção anterior, mas também acho exagerado presumir que todo leitor vá necessariamente ler todos os capítulos; o próprio termo "Warp Scheduler" também é ambíguo na prática, porque às vezes se refere a vários papéis ao mesmo tempo — escalonador, unidade de dispatch e SIMD ALU — e isso também ocorre porque a NVIDIA não dá nomes separados a essas unidades compostas; vou tentar melhorar mais no futuro, mas é uma sequência de concessões nada fáceis

  • LLMs são ferramentas bem boas para destravar esse tipo de dificuldade de conexão entre termos; quando você pesquisa um termo e aparecem em cadeia vários outros que também não conhece, elas ajudam bastante a orientar por onde começar a estudar

  • Quase tudo está no documento de arquitetura de sistema do Google TPU

  • Pergunta sincera: qual seria um nível adequado de conhecimento prévio sobre arquitetura de computadores? O próprio conceito de SIMD já tem mais de 50 anos; no começo desse material parece haver a expectativa de que o leitor já entenda LLMs e a arquitetura Transformer, mas ao mesmo tempo diz que não é necessário entender como computadores funcionam; ainda assim, fico achando que pelo menos o funcionamento básico de CPUs deveria ser considerado pré-requisito

  • Esse conteúdo é um capítulo de um livro escrito para pessoas que trabalham com machine learning

• Acho muito difícil justificar o tempo investido se não for algo open source ou uma tecnologia interoperável entre vários fornecedores; usar bem chips da Nvidia me parece algo como ser consultor de SAP ABAP antigamente; claro, dá para ganhar muito dinheiro nessa área, mas historicamente esse tipo de especialização nem sempre compensa tanto

  • Eu pensava exatamente assim e até pulei de propósito algumas aulas de CUDA na faculdade, uns 10 anos atrás

  • CUDA tem dois lados: a arquitetura de hardware e a stack de software para ela; a stack de software é fechada, então, se você não pretende fazer otimização low-level diretamente, não precisa se preocupar tanto com ela; mas a estrutura de hardware vale muito a pena estudar; todas as GPUs funcionam basicamente de forma parecida (a filosofia central da arquitetura CUDA é a mesma desde 2007), e essa arquitetura influencia bastante as shader languages e a forma de abstração das GPUs; se você entender bem detalhes como thread scheduling, warps e a estrutura de memória privada/compartilhada, consegue adaptar melhor os algoritmos ao modelo de execução do hardware e aproveitar um enorme poder computacional

  • Quero enfatizar que os princípios da computação paralela e a forma como tudo funciona no nível de hardware e drivers têm bastante generalidade; parte disso é específica de determinadas plataformas, mas muita coisa se aplica de forma ampla; apegar-se demais apenas ao que é genérico também pode ser prejudicial; além disso, open source e generalidade/especificidade são dimensões separadas, então vale explorar isso de forma mais ampla

  • A transição não é tão difícil; para quem já escrevia código com OpenMP ou MPI, começar com CUDA em si foi fácil; aprender a otimizar desempenho em CUDA também acelera código paralelo em CPU, então isso é essencialmente uma evolução dos modelos de computação já existentes

  • Eu também aprendi programação quando era criança em IBM PC/MS-DOS, e nenhum dos dois era open source, mas isso ainda me ajuda bastante hoje

• Acho que o cálculo da seção “Quiz 2: GPU nodes” está incorreto; na prática, cada GPU e cada switch têm número limitado de portas, então aqueles 450GB/s teóricos certamente não são entregues, e é por isso que os principais clouds e sistemas de referência oferecem 3.2TB/s; se 3.6TB/s fosse possível, haveria gargalo em workloads de anel distribuído; aliás, estou procurando emprego

  • Também fui pensar nisso de novo depois de um bom tempo, e o motivo de os provedores de cloud anunciarem só 3.2Tbps é o limite da conectividade de rede IB (InfiniBand) do nó; no DGX, cada H100 tem uma Connect-X 7 NIC que fornece até 400Gbps; 8 GPUs x 400Gbps = 3.2Tbps; o Quiz 2 está escrito de um jeito confuso, mas me parece que ele se refere à conexão entre GPUs dentro do nó, não à rede entre nós

• A série toda ficou realmente muito boa; ela explica os limites teóricos dos workloads modernos de IA e apresenta de forma acessível princípios técnicos como arquitetura e paralelização; embora seja centrada em TPU, a maior parte também pode ser aplicada a outras áreas, então tem bastante utilidade

• A ordem certa é otimizar ao máximo o código numérico intensivo em uma linguagem com tipagem forte e, só se ainda precisar de mais velocidade, considerar a opção de GPU; pela minha experiência, GPU dá algo como 8x de ganho; se você consegue reduzir a resposta web de 4 segundos para 0,5 segundo, isso é uma mudança gigantesca; mas, na prática, muitas vezes é mais fácil usar um websocket para exibir latência (spinner) ou um cache em background; e também é preciso considerar que rodar GPU na cloud custa caro

• Acho interessante como o nvshmem está recebendo tanta atenção na área de ML; em contraste, o MPI com funcionalidade equivalente nunca foi tão satisfatório assim no antigo mundo das simulações científicas; para contexto, eu trabalhava principalmente com tarefas difíceis, como cálculo de forças de longo alcance distribuídas entre vários nós

• Fico me perguntando por que a Nvidia não desenvolveu seu próprio TPU

  • Não há necessidade; ela já ocupa uma posição dominante no mercado de hardware e no modelo de programação, e TPU é, na verdade, mais difícil de programar

  • Na prática, como o próprio artigo explica, 90% do desempenho das GPUs da Nvidia vem de unidades de multiplicação de matrizes, então a estrutura é quase a de um TPU; você sacrifica um pouco de desempenho, mas ganha um ecossistema de compiladores muito mais flexível

• Ainda me surpreende a Nvidia nunca ter disponibilizado oficialmente recursos nesse nível; no fim, terceiros acabam fazendo engenharia reversa do hardware e organizando isso em diagramas conceituais realmente úteis; fico curioso sobre a motivação real da Nvidia; se a ideia fosse apenas marketing, então funcionou, mas isso me deixa com dúvidas sobre a cultura de engenharia deles

  • Do ponto de vista de quem trabalha com renderização em tempo real, sempre foi assim; a NV esconde quase tudo para dificultar que concorrentes percebam as mudanças de uma geração para outra; outros vendors não são muito diferentes; em games, com NDA, eles até fornecem informações arquiteturais mais detalhadas, mas fora disso eu nunca vi divulgação realmente completa, exceto talvez da Intel

  • A Nvidia na verdade publica muita documentação oficial excelente em comparação com outras empresas

  • Fiquei curioso para saber por que você teve essa impressão; na verdade, parece que a maior parte do conteúdo deste artigo foi tirada quase literalmente da documentação oficial da Nvidia; por exemplo, o diagrama do H100 foi basicamente copiado sem atribuição do whitepaper do H100; os números de throughput e bandwidth também já estão todos nos whitepapers oficiais e nos capítulos 5, 6 e 7 do guia CUDA C++; claro, há valor em resumir e acrescentar interpretação externa, mas sem o material oficial da Nvidia esse tipo de artigo mal seria possível, então essa especulação e desconfiança sem base me parecem um pouco exageradas

  • A Nvidia publica apenas um nível mediano de documentação, fazendo com que só bibliotecas fechadas como cuBLAS e cuDNN tenham desempenho realmente alto, o que reforça o vendor lock-in; isso também dificulta que outras empresas consigam alcançá-la via engenharia reversa

  • Pelo conjunto de indícios, a Nvidia parece fornecer materiais sob medida apenas para quem assina NDA e para VIPs, enquanto negligencia de propósito a publicação de manuais oficiais completos para o público; isso provavelmente acontece porque comercialmente lhes favorece; mesmo que a documentação oficial de API crie barreiras para desenvolvedores comuns, eles estão focados em vender o ecossistema inteiro — IA, GPU em si, software e documentação para VIPs — e acabam ligando menos para o desenvolvedor comum

• Ao olhar para diagramas de arquitetura, precisamos ter sempre em mente que eles não refletem necessariamente o hardware real com perfeição; a Nvidia não garante que os blocos ou componentes mostrados no diagrama existam literalmente, e os apresenta apenas como um modelo mental de referência para pensar a estrutura da GPU e dos SMs; por exemplo, oficialmente não dá para saber quantas unidades funcionais existem de fato em um SM, se o “tensor core” é um hardware independente ou o resultado da combinação de várias unidades, nem os detalhes finos do funcionamento abaixo do nível de warp

  • Ponto interessante; mas, na prática, o fato de o SM ficar bloqueado durante operações de tensor core não poderia ser interpretado como evidência de que a mesma FPU também executa todas as operações de tensor?

• Recurso realmente fantástico, aprendi bastante graças a ele