Compreendendo o Tráfego de LLM, GPUs, Clusters e Fabrics para Profissionais de Redes – Parte 2

Tráfego GPU-a-GPU em Clusters de Treinamento de LLM: Padrões e Desafios
tl;dr: Este artigo explora o tráfego GPU-a-GPU em clusters de treinamento de LLM, destacando a necessidade de largura de banda ultra-alta, fluxos de dados sincronizados e intermitentes (bursty), e desafios como latência, elephant flows e baixa entropia, que causam ineficiências na rede. Topologias emergentes, como Rail-Optimized Fabrics, são cruciais para atender a essas demandas em cargas de trabalho de IA escaláveis.
Este é o segundo artigo de uma série que visa capturar os padrões gerais de tráfego de rede em clusters de treinamento de LLM baseados em GPU. A Parte 1 desta série focou em fornecer um breve contexto sobre clusters de treinamento de GPU. Esta segunda parte explicará os padrões de tráfego GPU-a-GPU e as tecnologias/técnicas envolvidas, bem como as características únicas do tráfego de rede impulsionadas por esses padrões. Este contexto abrirá caminho para discussões mais aprofundadas sobre a largura de banda, a latência necessária e os recursos de rede emergentes. Planejamos cobrir esses tópicos em uma ou mais publicações futuras.
As GPUs não são apenas dispositivos densos em capacidade de processamento (compute-dense); elas também são dispositivos intensivos em comunicação e storage (armazenamento). Armazenar e compartilhar dados é fundamental para o uso eficiente dos recursos computacionais fenomenais disponíveis na GPU.
Largura de Banda Ultra-Alta por GPU
Cada GPU é conectada a um bus interno dedicado (NVLink, no caso das GPUs Nvidia). O bus interno dedicado é usado para conectar-se a outras GPUs no mesmo nó (node ou domínio). Na geração Blackwell atual, são utilizados Serdes 4x224G (4 lanes) para um total de 800 Gb/s. Isso totaliza 100 GB/s. Existem 18 desses links em cada GPU B200, resultando em uma conexão total de bus interno (NVlink) de 1,8 TB/s.
Para uma comparação rápida com a rede externa (scale-out fabric), isso é equivalente a 9 conexões unidirecionais de 400 Gbps. Por um lado, isso demonstra o quão intensivas em dados essas GPUs são. Por outro lado, podemos ver claramente o quão rapidamente a rede externa (scale-out) precisa avançar para acompanhar.
Enquanto o desempenho da rede externa não se iguala, este bus interno inter-GPU dentro do mesmo domínio (servidor, nó ou sistemas como NVL72) será sempre preferido. Essa clara preferência traz mudanças significativas nas topologias de rede usadas para conectar GPUs.
Cada GPU se conecta através de um segundo link a um bus diferente (PCIe), onde se conecta à placa de interface de rede (NIC). O caminho PCIe/NIC é capaz de suportar até 400 Gb/s atualmente. É muito necessária e esperada que a largura de banda das NICs aumente nos próximos anos.
Topologia de Collective GPU Fabrics
O surgimento de novas topologias de rede, como rail e rail-optimized fabrics (malhas otimizadas para trilhos), é criticamente importante para suportar bibliotecas de operações coletivas em ambientes centrados em GPU, particularmente aqueles que impulsionam cargas de trabalho de GenAI.
Operações coletivas — como all-reduce, all-gather ou broadcast — exigem caminhos de rede de alta largura de banda, baixa latência e lossless (sem perdas) para sincronizar dados e gradientes de forma eficiente em um grande número de GPUs. Topologias tradicionais, como fat-tree, podem ter dificuldades em escalar ou manter essas propriedades à medida que o tamanho do cluster aumenta. Esses desafios introduzem atrasos ou gargalos que prejudicam o desempenho do treinamento e da inferência de IA.
As topologias Rail e Rail Optimized são projetadas especificamente para atender a esses requisitos exigentes. Estruturar o fabric (malha) de rede para fornecer conectividade previsível e não-bloqueante aumenta o paralelismo e minimiza o congestionamento. Isso permite uma comunicação mais eficiente entre GPUs distribuídas, garantindo não apenas um desempenho robusto para bibliotecas de operações coletivas, mas também operações e gerenciamento otimizados para implantações de IA em larga escala. Isso torna as topologias rail e rail-optimized essenciais para data centers modernos baseados em GPU que lidam com padrões complexos de comunicação coletiva exigidos pelas cargas de trabalho de IA.
Elephant Flows (Fluxos Elefante)
A IA é treinada usando clusters de GPUs, o que ajuda a dividir grandes conjuntos de dados entre servidores de GPU, com cada um lidando com um subconjunto. Assim que um cluster termina de processar um lote de dados, ele envia toda a saída em uma única rajada (burst) para o próximo cluster.
Cada conjunto de dados é grande o suficiente para gerar um “elephant flow” (fluxos elefante são aqueles maiores que 1 GB/10 segundos). Esses fabrics de clusters de GPU se conectam à rede com NICs de altíssima largura de banda, variando de 200 Gbps a 800 Gbps. As NICs das GPUs operam a 100% quando os dados são transmitidos.
Exemplos de elephant flows no treinamento de IA incluem:
- A distribuição de dados de treinamento em múltiplas GPUs frequentemente envolve grandes transferências de dados.
- A sincronização de parâmetros do modelo entre GPUs, especialmente durante o treinamento distribuído, pode resultar em fluxos de dados significativos.
- A troca de gradientes entre GPUs durante a backpropagation é outra fonte de grandes transferências de dados.
Transmissão Sincronizada e Intermitente (Bursty)
Cargas de trabalho assíncronas são comuns em ambientes que não são de IA, como usuários finais fazendo consultas a bancos de dados ou solicitações a um servidor web, que são atendidas sob demanda. As cargas de trabalho de IA, no entanto, são síncronas, o que significa que os clusters de GPUs devem receber todos os dados antes de poderem iniciar seu próprio trabalho. A saída de etapas anteriores, como gradientes, parâmetros do modelo e assim por diante, torna-se uma entrada vital para as fases subsequentes. Em clusters de IA, as bibliotecas de operações coletivas gerenciam a distribuição de dados e cronometram o início da transmissão para as GPUs participantes.
Latência e Tail Latency (Latência de Cauda)
Latência e tail latency são conceitos cruciais em fabrics de rede de GPU, especialmente no contexto de cargas de trabalho de IA. A latência refere-se ao tempo médio que os pacotes de dados levam para viajar da origem ao destino. Essa métrica é essencial para entender a eficiência de linha de base de uma rede, pois ajuda a indicar a velocidade típica de transmissão de dados.
A tail latency (latência de cauda) mede o atraso experimentado pelos últimos ou mais lentos pacotes, ou ambos. As cargas de trabalho de treinamento de IA dependem de Collective Communications Libraries (Bibliotecas de Comunicações Coletivas) para distribuir dados e sincronizar transmissões de conjuntos de dados entre GPUs. Nesses ambientes coletivos, as GPUs não podem começar a processar conjuntos de dados até que todos os conjuntos de dados sejam completamente entregues aos seus destinos.
Isso torna a tail latency particularmente importante no networking de IA, porque ela identifica potenciais gargalos e interrupções que podem afetar o desempenho geral. Em tarefas de IA distribuída, alguns pacotes atrasados por alta tail latency podem prejudicar todo o processo. Manter a tail latency baixa torna-se fundamental para garantir a sincronização oportuna de dados em múltiplas GPUs.
Baixa Entropia
No tráfego GPU-a-GPU, os endereços IP de origem/destino e os números de porta envolvidos nessas grandes transferências de dados tendem a ser relativamente consistentes. Isso leva a um baixo grau de entropia. Essa consistência é particularmente evidente em cargas de trabalho de treinamento distribuído de AI/ML.
As GPUs em um cluster frequentemente sincronizam seus estados usando RDMA sobre Ethernet, encapsulado em pacotes padrão UDP/IP. Ao usar Equa-Cost Multi-Path (ECMP) em tais ambientes, a baixa entropia pode fazer com que múltiplos fluxos de tráfego sejam hashed (distribuídos por hash) para o mesmo link.
Fluxos de alta largura de banda, frequentemente vistos em clusters de GPU, podem resultar em múltiplos fluxos sendo direcionados para o mesmo caminho. Isso leva a um potencial congestionamento de link e utilização ineficiente da rede. Isso acontece porque o algoritmo ECMP não leva em consideração a utilização do link; ele, em vez disso, depende de mecanismos de hashing estáticos. Esse desequilíbrio na carga pode resultar em perda de pacotes (packet drops) e redução do desempenho geral da rede, impactando especificamente o desempenho do treinamento de cargas de trabalho distribuídas de AI/ML.
Sobre o Autor: Sam Hassan
Com mais de duas décadas de experiência na vanguarda do data networking (redes de dados), Sam desempenhou um papel fundamental no design e na arquitetura de pré-vendas de várias soluções em escala empresarial que sustentam as cargas de trabalho mais exigentes da atualidade. Sua carreira abrange a evolução do Ethernet desde a adição de voz como aplicação e computação de alto desempenho. Desde a adoção inicial de clusters HPC (High-Performance Computing) até a ascensão de data centers otimizados para IA — Sam construiu profunda experiência na integração de tecnologias de rede de ponta, orquestrando implantações complexas e aconselhando clientes Fortune 500 em estratégias que maximizam desempenho, segurança e escalabilidade. Ao longo dos anos, ele fez parceria com líderes da indústria para entregar soluções robustas alavancando Ethernet e plataformas avançadas de gerenciamento de cluster, e tem sido fundamental para ajudar organizações a preencher a lacuna entre infraestruturas legadas e ambientes de próxima geração, prontos para IA. Hoje, o foco de Hassan está na intersecção entre fabric GENAI e gerenciamento de tráfego de GPU, projetando e implantando infraestrutura end-to-end (ponta a ponta) que acelera iniciativas de inteligência artificial. Com base em uma vasta experiência em networking de IA e integração de clusters de GPU em larga escala, ele se especializa em otimizar arquiteturas de fabric para IA generativa, garantindo movimento de dados seamless (contínuo) de alta largura de banda e baixa latência através de centenas de GPUs. Seus engajamentos práticos incluem a liderança de avaliações de prontidão de data center, arquitetando redes de servidor aceleradas por GPU, permitindo que os clientes desbloqueiem todo o potencial de cargas de trabalho de IA de próxima geração e deep learning.
Precisa de ajuda com suas soluções de TI?
A VirtuAllIT Solutions oferece consultoria especializada em virtualização, cloud computing e infraestrutura tecnológica.

