Design de Topologia de Rede para Clusters de GPU: Arquiteturas Fat-Tree, Dragonfly e Rail-Optimized

Atualizado em 11 de dezembro de 2025

Atualização de dezembro de 2025: DGX SuperPOD especificando fat-tree de três camadas com switches Quantum-2 InfiniBand (400Gb/s). Estudo da Meta descobrindo que erros de configuração de rede causam 10,7% das falhas significativas em jobs de GPU. Largura de banda de bisseção total é crítica para treinamento distribuído onde os padrões de comunicação mudam dinamicamente. Pods de TPU do Google usando torus 3D; AWS Trainium usando topologias otimizadas para cargas de trabalho.

A arquitetura de referência DGX SuperPOD da NVIDIA especifica uma topologia de rede fat-tree de três camadas conectando até 32 sistemas DGX usando switches Quantum-2 InfiniBand a 400 Gb/s por porta.[^1] A arquitetura oferece largura de banda de bisseção total, significando que a largura de banda agregada entre quaisquer duas metades do cluster é igual à largura de banda total entrando em qualquer uma das metades. Topologias fat-tree dominam as implantações de clusters de GPU porque fornecem desempenho previsível independentemente de quais pares de GPU se comunicam, uma propriedade crítica para treinamento distribuído onde os padrões de comunicação mudam dinamicamente.

As escolhas de topologia de rede afetam diretamente o desempenho do treinamento, custo e complexidade operacional. Um estudo da Meta descobriu que erros de configuração de rede causaram 10,7% das falhas significativas de jobs em seus clusters de GPU, com congestionamento dependente de topologia contribuindo para a variabilidade de desempenho.[^2] Os pods de TPU do Google usam topologias torus 3D permitindo conexões diretas entre aceleradores vizinhos, enquanto os clusters AWS Trainium empregam diferentes topologias otimizadas para seus padrões de carga de trabalho.[^3] Entender os tradeoffs de topologia permite que as organizações selecionem arquiteturas que correspondam aos seus requisitos específicos de carga de trabalho e restrições orçamentárias.

Fundamentos da topologia fat-tree

A topologia fat-tree originou-se do trabalho de Charles Leiserson em 1985, mostrando que estruturas em árvore poderiam alcançar largura de banda de bisseção total se a capacidade do link aumentasse em direção à raiz.[^4] Implementações modernas usam links de capacidade igual em toda a estrutura, alcançando largura de banda total através de múltiplos caminhos paralelos em vez de links mais grossos.

Arquitetura fat-tree de três camadas

Uma fat-tree de três camadas consiste em switches leaf conectando-se a servidores, switches spine agregando tráfego dos leafs e switches core fornecendo conectividade total entre os spines.[^5] Cada switch leaf conecta-se a cada switch spine, e cada spine conecta-se a cada switch core. A malha de conexões cria múltiplos caminhos de custo igual entre quaisquer dois servidores.

A NVIDIA recomenda fat-tree para clusters DGX devido às características previsíveis de latência e largura de banda.[^6] A topologia garante que operações coletivas como all-reduce experimentem desempenho consistente independentemente do posicionamento das GPUs. Jobs de treinamento não precisam considerar a topologia de rede ao agendar, simplificando o gerenciamento do cluster.

Taxas de oversubscription

Largura de banda de bisseção total requer capacidade de switch cara nas camadas superiores. Muitas implantações aceitam oversubscription, onde a largura de banda agregada de uplink das camadas inferiores excede a capacidade disponível nas camadas superiores.[^7] Uma taxa de oversubscription de 2:1 significa que apenas metade do tráfego poderia atravessar simultaneamente as camadas superiores.

Oversubscription é adequado para cargas de trabalho com localidade, onde a maior parte da comunicação ocorre dentro de racks ou pods. No entanto, treinamento distribuído com padrões de comunicação all-to-all satura links com oversubscription, causando congestionamento e degradação de desempenho. Clusters de treinamento de IA tipicamente requerem designs sem oversubscription apesar do custo mais alto.[^8]

Radix e escalabilidade

O radix do switch determina quantas portas cada switch fornece, afetando tanto a escala quanto o custo. Um switch de 64 portas construindo uma fat-tree de três camadas com 32 downlinks e 32 uplinks escala até 32.768 endpoints.[^9] Switches de radix mais alto reduzem o número de switches necessários, mas aumentam o custo por switch.

Os switches Quantum-2 da NVIDIA fornecem 64 portas a 400 Gb/s, permitindo implantações fat-tree de grande escala com contagens razoáveis de switches.[^10] A próxima geração Quantum-X800 aumenta as velocidades de porta para 800 Gb/s, dobrando a largura de banda agregada sem alterar a estrutura da topologia.

Topologia rail-optimized

A topologia rail-optimized surgiu do reconhecimento de que servidores de GPU contêm múltiplas GPUs compartilhando interconexões internas de alta velocidade. Em vez de tratar cada GPU independentemente, designs rail-optimized alinham conexões de rede com o posicionamento das GPUs dentro dos servidores.[^11]

Entendendo os rails de GPU

Um sistema DGX H100 contém oito GPUs conectadas via NVLink, com cada GPU também conectando-se a uma placa de interface de rede (NIC).[^12] As oito NICs correspondem a oito "rails" abrangendo o cluster. O rail 0 conecta a GPU 0 de cada servidor, o rail 1 conecta a GPU 1, e assim por diante. A comunicação dentro de um rail atravessa menos hops de switch do que a comunicação cross-rail.

O NVIDIA NVLink Switch conecta GPUs dentro e entre servidores com largura de banda agregada de 900 GB/s por GPU.[^13] O domínio NVLink lida com a maior parte da comunicação GPU-para-GPU, com a rede InfiniBand lidando com comunicação entre domínios NVLink. A topologia rail-optimized alinha os caminhos InfiniBand com os domínios NVLink para minimizar o tráfego InfiniBand.

Considerações de implementação

Implantações rail-optimized requerem cabeamento cuidadoso para manter o alinhamento dos rails entre racks e pods.[^14] Conexões mal conectadas quebram a localidade do rail, forçando o tráfego através de hops de switch adicionais. Disciplina no gerenciamento de cabos é essencial para realizar os benefícios da otimização por rail.

A topologia reduz os requisitos de switch comparado a fat-tree completa em escala equivalente. As economias vêm da eliminação da capacidade de switching cross-rail que cargas de trabalho rail-optimized raramente usam.[^15] As organizações devem verificar se seus padrões de carga de trabalho realmente exibem localidade de rail antes de se comprometer com designs rail-optimized.

Topologia dragonfly

A topologia dragonfly organiza switches em grupos com conectividade densa intra-grupo e links esparsos inter-grupo.[^16] O design reduz a contagem de switches comparado a fat-tree enquanto mantém comprimentos de caminho razoáveis entre quaisquer dois endpoints.

Estrutura dragonfly

Uma dragonfly consiste em grupos, cada um contendo múltiplos switches totalmente conectados dentro do grupo. Links globais conectam cada switch a switches em outros grupos.[^17] Quaisquer dois endpoints conectam-se através de no máximo três hops: switch local para switch do grupo para switch do grupo remoto para destino.

A contagem reduzida de hops diminui a latência para implantações de grande escala. Menos switches reduzem o custo de capital e o consumo de energia. No entanto, dragonfly fornece menor largura de banda de bisseção do que fat-tree, tornando-a mais suscetível a congestionamento sob certos padrões de tráfego.[^18]

Requisitos de roteamento adaptativo

O desempenho da dragonfly depende fortemente de roteamento adaptativo que distribui o tráfego pelos caminhos disponíveis.[^19] O roteamento estático concentra o tráfego em links específicos, causando congestionamento enquanto outros caminhos permanecem subutilizados. Os switches devem monitorar a utilização dos links e dinamicamente deslocar o tráfego para caminhos menos carregados.

O NVIDIA InfiniBand suporta roteamento adaptativo adequado para implantações dragonfly.[^20] A capacidade requer configuração e testes para garantir que os algoritmos de roteamento respondam apropriadamente aos padrões de tráfego da carga de trabalho. Roteamento adaptativo mal configurado pode ter desempenho pior do que roteamento estático.

Sensibilidade à carga de trabalho

Dragonfly é adequada para cargas de trabalho com padrões de comunicação localizados que mantêm a maior parte do tráfego dentro dos grupos.[^21] Cargas de trabalho gerando tráfego aleatório uniforme entre todos os endpoints estressam os links inter-grupo além de sua capacidade. A topologia funciona bem para serving de inferência com afinidade de requisições, mas pode ter dificuldades com treinamento em grande escala usando coletivos globais.

Organizações avaliando dragonfly devem caracterizar os padrões de comunicação esperados da carga de trabalho antes da implantação. Ferramentas de simulação podem modelar o desempenho esperado sob tráfego realista, identificando potenciais pontos de congestionamento que requerem ajuste de topologia.[^22]

Topologias torus e mesh

Topologias torus conectam nós em padrões de grade regulares com conexões wraparound nas bordas. Os pods de TPU do Google usam topologias torus 3D fornecendo conexões diretas com vizinhos sem switching.[^23]

Redes diretas versus switched

Redes torus conectam cada nó diretamente aos vizinhos, eliminando switches do caminho de comunicação.[^24] A conexão direta reduz a latência para comunicação vizinho-para-vizinho comum em muitos algoritmos paralelos. No entanto, a comunicação entre nós distantes atravessa múltiplos nós intermediários, aumentando a latência e consumindo largura de banda em cada hop.

Redes switched como fat-tree fornecem latência igual entre quaisquer dois endpoints independentemente do posicionamento físico. A uniformidade simplifica a programação e o balanceamento de carga. Redes torus requerem posicionamento consciente da topologia para minimizar distâncias de comunicação.[^25]

Seleção de dimensão

Topologias torus de dimensão mais alta reduzem o diâmetro (contagem máxima de hops) ao custo de aumento na contagem de conexões por nó.[^26] Um torus 3D com N nós por dimensão tem diâmetro 3N/2, enquanto um torus 2D tem diâmetro N. A escolha do Google por torus 3D equilibra contagem de conexões contra diâmetro.

Restrições físicas afetam a seleção de dimensão. Um torus 2D mapeia naturalmente para linhas e colunas em uma sala de máquinas. Um torus 3D requer racks empilhados ou conexões abrangendo distâncias substanciais. Comprimentos de cabo em torus de alta dimensão podem se tornar problemáticos em escala.[^27]

Framework de seleção de topologia

Selecionar a topologia de rede requer avaliar características da carga de trabalho, requisitos de escala, restrições orçamentárias e capacidades operacionais.

Análise de carga de trabalho

Diferentes cargas de trabalho estressam as redes de maneiras diferentes. Treinar grandes modelos de linguagem gera padrões de comunicação all-to-all que requerem alta largura de banda de bisseção.[^28] Serving de inferência com batching exibe comunicação mais localizada dentro de grupos de GPU servindo requisições. Pré-processamento de dados pode gerar padrões de shuffle com comunicação aleatória.

As organizações devem perfilar as cargas de trabalho esperadas para entender os padrões de comunicação. O monitoramento de clusters de produção revela padrões de tráfego reais para cargas de trabalho existentes. Novos tipos de carga de trabalho podem requerer estimativa baseada em análise de algoritmo ou orientação do fornecedor.

Considerações de escala

Clusters pequenos de dezenas de GPUs podem não requerer otimização sofisticada de topologia. Um único switch de alto radix conectando todas as GPUs fornece conectividade total sem complexidade multi-camada.[^29] A seleção de topologia importa mais para clusters abrangendo centenas a milhares de GPUs onde custos de switching e extensões de cabo se tornam significativos.

Crescimento futuro afeta a seleção de topologia. Uma fat-tree escala adicionando switches leaf e servidores enquanto mantém largura de banda de bisseção total. Uma dragonfly escala adicionando grupos, mas pode requerer rebalanceamento de links globais. Planejar para crescimento evita mudanças de topologia que interrompem operações.[^30]

Fatores econômicos

Custos de switch e cabo variam significativamente entre topologias. Fat-tree requer mais switches do que dragonfly em escala equivalente. Designs rail-optimized reduzem switching InfiniBand, mas requerem sistemas NVLink Switch.[^31] Análise de custo total deve incluir switches, cabos, óptica, energia, refrigeração e espaço em rack.

Custos operacionais também variam. Topologias complexas requerem capacidades de monitoramento e troubleshooting mais sofisticadas. Treinar equipe de operações em considerações específicas de topologia adiciona custo. Topologias mais simples podem justificar tradeoffs modestos de desempenho através de carga operacional reduzida.

Implementação e implantação

A implementação de topologia de rede requer planejamento cuidadoso abrangendo infraestrutura física, configuração de switching e testes de validação.

Planejamento de infraestrutura física

Implantações de rede de alta velocidade requerem cabeamento estruturado suportando milhares de conexões a 400 Gb/s ou mais.[^32] O roteamento de cabos deve minimizar violações de raio de curvatura e degradação de sinal. Arranjos de corredor quente/corredor frio devem acomodar caminhos de cabo sem ob

[Conteúdo truncado para tradução]