Interconexões (NVLink/InfiniBand)

Por que as interconunicações importam para o escalonamento de IA

O treinamento e a inferência de IA modernos raramente acontecem em um único processador. Mesmo um único “servidor de GPU” geralmente contém de 4 a 8 aceleradores, e grandes execuções de treinamento podem abranger de dezenas a milhares de GPUs. Assim que você distribui o trabalho entre dispositivos, mover dados entre dispositivos se torna um gargalo de desempenho de primeira ordem — muitas vezes rivalizando ou excedendo a computação.

Interconunicações são os enlaces de hardware (e suas pilhas de software) que transportam esses dados. Duas das mais importantes em clusters baseados em NVIDIA são:

  • NVLink / NVSwitch: enlaces de alta largura de banda e baixa latência dentro de um nó (GPU-para-GPU e, às vezes, CPU-para-GPU em projetos mais novos).
  • InfiniBand: rede de baixa latência com capacidade de RDMA (Remote Direct Memory Access) entre nós (servidor-para-servidor), amplamente usada para treinamento multi-nó com GPUs.

Este artigo fornece um modelo de alto nível para largura de banda vs. latência, explica como elas afetam o escalonamento de treinamento distribuído, e conecta a teoria a decisões práticas (estratégia de paralelismo, topologia do cluster e ajustes).

Contexto relacionado: Panorama de Hardware, Memória e Largura de Banda, Fundamentos de CUDA

Largura de banda vs. latência: o modelo mental central

Duas quantidades simples explicam a maior parte do comportamento das interconunicações:

  • Latência: o “tempo de inicialização” para começar uma transferência (frequentemente microssegundos no nível de rede).
  • Largura de banda: a taxa em regime permanente quando a transferência está em andamento (GB/s).

Uma aproximação útil para o tempo de transferência:

time(message_size) ≈ latency + message_size / bandwidth

Implicações:

  • Mensagens pequenas são dominadas pela latência.
  • Mensagens grandes são dominadas pela largura de banda.
  • Muitas operações de treinamento distribuído (especialmente coletivas) envolvem muitas mensagens, então ambos os termos importam.

Por que isso aparece no tempo de cada passo de treinamento

Um passo de treinamento normalmente alterna entre:

  1. Computação (matmuls, atenção, convoluções)
  2. Comunicação (sincronização de gradientes, ativações, parâmetros, estados do otimizador)

Se a comunicação não puder ser sobreposta com a computação (ou se for grande demais), ela aumenta diretamente o tempo do passo e reduz a eficiência de escalonamento.

Essa é a versão distribuída da lição de Memória e Largura de Banda: mover dados frequentemente domina.

NVLink é a interconexão de alta velocidade da NVIDIA projetada para superar o PCIe em tráfego GPU-para-GPU. Ela permite:

  • Maior largura de banda GPU-para-GPU do que PCIe (dependente da geração)
  • Menor latência do que PCIe para transferências ponto a ponto
  • Comunicação coletiva mais eficiente dentro de um nó (frequentemente via NCCL)

Em muitos servidores, conexões NVLink formam uma topologia (por exemplo, malha parcial). Para sistemas com 8 GPUs, NVSwitch é comumente usado para fornecer uma “malha de comutação” de alta largura de banda, de modo que cada GPU possa se comunicar com todas as outras em alta velocidade.

Impacto prático: “escalonamento em um único nó”

Muitas cargas de trabalho escalam bem de 1→8 GPUs dentro de um nó, em grande parte porque NVLink/NVSwitch torna a comunicação intra-nó rápida o suficiente para que:

  • A sincronização de gradientes do paralelismo de dados seja mais barata
  • Trocas de ativações/gradientes do paralelismo de tensor sejam viáveis
  • Transferências entre estágios do paralelismo de pipeline sejam menos dolorosas

Como regra geral:

  • Se sua configuração de treinamento depende fortemente de paralelismo de tensor, você geralmente quer que o grupo de paralelismo de tensor permaneça dentro de NVLink/NVSwitch sempre que possível.

Mesmo quando os números de largura de banda de PCIe parecem “grandes”, padrões de treinamento distribuído são implacáveis:

  • PCIe tende a ter menor largura de banda efetiva GPU-para-GPU e maiores sobrecargas para coletivas ponto a ponto.
  • NVLink frequentemente permite maior largura de banda sustentada para coletivas entre GPUs (especialmente all-reduce / all-gather) e reduz contenção.

Essa diferença é uma das razões pelas quais nós “8×GPU com NVSwitch” frequentemente entregam um escalonamento muito melhor do que nós “8×GPU apenas em PCIe” para treinamento pesado em comunicação.

InfiniBand: malha inter-nó para treinamento distribuído

O que é InfiniBand (conceitualmente)

InfiniBand (IB) é uma tecnologia de rede de alto desempenho projetada para baixa latência e alta vazão, com recursos extremamente relevantes para clusters de IA:

  • RDMA (Remote Direct Memory Access): move dados entre máquinas sem grande envolvimento da CPU.
  • RDMA GPUDirect (GPUDirect RDMA): permite que adaptadores de rede leiam/escrevam diretamente na memória da GPU (reduzindo cópias e sobrecarga da CPU).
  • Suporte a topologias avançadas (fat-tree, variantes de dragonfly) com forte largura de banda de bissecção quando bem construídas.

Na prática, a maior parte do treinamento multi-nó com GPUs depende de:

  • NCCL para coletivas de GPU
  • InfiniBand como transporte entre nós (frequentemente via RDMA)

Ethernet também pode ser usada (por exemplo, RoCE), mas InfiniBand ainda é o “padrão” comum para clusters de treinamento orientados a desempenho.

Impacto prático: “escalonamento multi-nó”

Quando você vai além de um nó, a comunicação frequentemente se torna o limitador porque:

  • A largura de banda inter-nó é tipicamente menor do que a largura de banda intra-nó de NVLink/NVSwitch.
  • A latência inter-nó é maior, e algoritmos coletivos amplificam os custos de latência.
  • A topologia de rede e a sobrescrição podem fazer a largura de banda efetiva variar amplamente.

Por isso muitos sistemas de treinamento usam coletivas hierárquicas: redução rápida dentro do nó e, depois, um número menor de transferências pela rede.

Comunicação coletiva: onde interconunicações encontram algoritmos de treinamento

A maior parte da comunicação em treinamento distribuído é expressa em um pequeno conjunto de operações coletivas:

  • All-reduce: soma gradientes entre workers (paralelismo de dados).
  • All-gather: reúne fragmentos de parâmetros/ativações (comum em paralelismo de tensor, otimizadores fragmentados, MoE).
  • Reduce-scatter: como all-reduce, mas deixa resultados fragmentados (comum por eficiência).
  • Broadcast: envia parâmetros de um rank para todos os outros.

Essas coletivas geralmente são implementadas por bibliotecas como NCCL e dependem fortemente do desempenho das interconunicações.

Uma intuição simples de desempenho de all-reduce

Para muitos sistemas, o custo de all-reduce é aproximadamente proporcional a:

  • a quantidade de dados a sincronizar (por exemplo, tamanho dos gradientes)
  • dividida pela menor largura de banda relevante (frequentemente inter-nó)
  • mais termos de latência que crescem com o número de participantes e etapas do algoritmo

Um algoritmo comum é ring all-reduce, com um termo de largura de banda aproximado como:

time ≈ (2 * (p - 1) / p) * (N / bandwidth) + (p - 1) * latency

Onde:

  • p = número de ranks (GPUs)
  • N = total de bytes a reduzir por rank (por exemplo, gradientes)
  • bandwidth = largura de banda efetiva do enlace (não a especificação de pico)
  • latency = sobrecarga de inicialização por etapa

Principal conclusão:

  • À medida que p cresce, termos de latência e efeitos de topologia se tornam mais importantes.
  • Se bandwidth é limitada pela malha inter-nó, escalar além de um nó pode travar.

Como as interconunicações afetam estratégias de paralelismo

Treinar modelos grandes frequentemente combina múltiplos tipos de paralelismo. Cada um pressiona as interconunicações de forma diferente.

Paralelismo de dados (DP): pesado em largura de banda, previsível

No treinamento clássico com paralelismo de dados (por exemplo, PyTorch DDP), cada GPU calcula gradientes no seu fragmento de batch e então os gradientes são sincronizados (frequentemente all-reduce).

  • O volume de comunicação por passo é aproximadamente proporcional ao tamanho dos parâmetros do modelo (ou ao tamanho dos gradientes).
  • DP frequentemente é limitado pela largura de banda de all-reduce quando a computação se torna rápida (por exemplo, com tensor cores FP8/FP16).

Nota prática: DP frequentemente funciona bem dentro de um nó e escala para múltiplos nós se a rede for rápida e não estiver sobrescrita.

Paralelismo de tensor (TP): sensível à latência e à topologia

O paralelismo de tensor divide camadas individuais entre GPUs. Isso exige comunicação frequente de ativações e gradientes entre GPUs durante forward/backward.

  • Frequentemente mais sensível à latência do que DP.
  • Tem melhor desempenho quando GPUs estão conectadas por NVLink/NVSwitch e posicionadas de forma consciente da topologia.

Nota prática: um design comum é TP dentro do nó (NVLink) e DP entre nós (InfiniBand).

Paralelismo de pipeline (PP): tolerante, mas pode amplificar travamentos

O paralelismo de pipeline envia ativações entre estágios.

  • O volume de comunicação depende dos tamanhos das ativações e do microbatching.
  • A latência pode ser escondida com microbatches suficientes, mas “bolhas” do pipeline e stragglers podem causar travamentos.

PP pode funcionar entre nós, mas em geral você quer:

  • enlaces estáveis, com baixo jitter
  • posicionamento cuidadoso para evitar gargalos entre racks

Mistura de Especialistas (MoE): pode ser intensivo em rede

MoE frequentemente exige roteamento de tokens para especialistas em GPUs diferentes (padrões all-to-all).

  • All-to-all é implacável para redes e topologias.
  • O desempenho real depende da largura de banda de bissecção efetiva e do controle de congestionamento.

Este é um caso em que “largura de banda de pico do enlace” importa menos do que o projeto da malha de rede e o posicionamento do job.

Topologia e largura de banda de bissecção: por que o “formato” da rede importa

Dois clusters podem ter a mesma largura de banda por enlace, mas resultados de escalonamento muito diferentes.

Dentro de um nó: topologia de GPUs

Dentro de um servidor, as GPUs podem estar conectadas:

  • via NVSwitch (conectividade quase uniforme)
  • via malhas NVLink parciais (alguns pares de GPUs mais próximos do que outros)
  • ou apenas via PCIe

Coletivas terão desempenhos diferentes dependendo de se a comunicação consegue evitar “caminhos lentos”.

Entre nós: fat-tree vs designs sobrescritos

Malhas inter-nó frequentemente são organizadas como fat-trees (ou redes Clos) com diferentes graus de sobrescrição.

  • Malhas não sobrescritas fornecem alta largura de banda de bissecção: muitos nós podem se comunicar simultaneamente sem contenção.
  • Malhas sobrescritas são mais baratas, mas podem estrangular jobs distribuídos grandes, especialmente com all-to-all ou muitos all-reduces simultâneos.

Por isso dois clusters “InfiniBand de 200 Gb/s” podem se comportar de forma muito diferente: a malha determina que largura de banda você realmente obtém em escala.

Exemplo prático: quando a comunicação domina

Considere um caso simplificado de paralelismo de dados:

  • Gradientes do modelo por passo: 2 GB por GPU (não é incomum em modelos grandes)
  • Você roda em 64 GPUs (8 nós × 8 GPUs)
  • A redução intra-nó usa NVLink/NVSwitch, a inter-nó usa InfiniBand

Mesmo que intra-nó seja extremamente rápido, você ainda precisa mover dados substanciais entre nós. Se sua largura de banda efetiva de all-reduce inter-nó por GPU for, digamos, dezenas de GB/s (após sobrecarga de protocolo, contenção de topologia e compartilhamento), então a sincronização pode levar na ordem de:

seconds_per_step_comm ≈ gradient_bytes / effective_bandwidth

Se seu tempo de computação por passo for comparável, a eficiência de escalonamento cai drasticamente. Por isso o treinamento em grande escala frequentemente usa:

  • acumulação de gradientes (menos all-reduces)
  • otimizadores fragmentados (reduzem alguns tipos de comunicação)
  • compressão/quantização de tensores comunicados (com cuidado)
  • sobreposição de comunicação com computação (all-reduce em buckets)

Essas técnicas mudam a forma da comunicação, mas a interconunicação ainda define o teto.

NCCL e coletivas hierárquicas

A Biblioteca de Comunicações Coletivas da NVIDIA (NCCL) é o backend padrão para coletivas em GPU. Ela tipicamente:

  • Usa NVLink/NVSwitch para transferências intra-nó
  • Usa InfiniBand (RDMA) para transferências inter-nó quando disponível
  • Constrói algoritmos hierárquicos (reduz dentro do nó e depois entre nós)

Em muitos sistemas reais, o desempenho se resume a se a NCCL consegue:

  • escolher o algoritmo certo consciente da topologia
  • saturar enlaces sem congestionamento
  • sobrepor comunicação com computação

RDMA GPUDirect: evitando cópias extras

Com RDMA GPUDirect, o adaptador de rede pode transferir dados diretamente para/de memória da GPU, evitando staging extra via memória da CPU. Isso reduz:

  • sobrecarga de CPU
  • latência
  • tráfego PCIe e contenção

É uma razão importante pela qual clusters InfiniBand podem escalar melhor do que redes “genéricas” para coletivas multi-nó de GPUs.

Medindo e diagnosticando gargalos de interconunicação

Quando o escalonamento é ruim, é fácil culpar “a rede” de forma vaga. Uma abordagem mais acionável é medir:

  • Largura de banda alcançada para coletivas (GB/s), não apenas especificações do enlace
  • Decomposição do tempo do passo (computação vs comunicação)
  • Latência de cauda / jitter (especialmente em clusters compartilhados)
  • Posicionamento pela topologia (os ranks estão mapeados de forma sensata?)

Ferramentas e sinais práticos rápidos

  • nccl-tests (por exemplo, all_reduce_perf) para medir a largura de banda alcançada em coletivas.
  • nvidia-smi topo -m para inspecionar conectividade intra-nó de GPUs (presença/topologia de NVLink).
  • Contadores/ferramentas InfiniBand (específicos do fornecedor) para identificar congestionamento, retransmissões ou redução de velocidade de enlace.
  • Profilers do framework (PyTorch profiler) para ver tempo em all_reduce ou all_gather.

Em ambientes compartilhados, considere também efeitos de agendamento/posicionamento discutidos em Agendamento de GPU e Filas de Cluster.

Padrões comuns de otimização (e o que eles sacrificam)

1) Manter a comunicação nos enlaces mais rápidos

Estratégia típica de posicionamento:

  • Grupos de paralelismo de tensor dentro de um nó (NVLink/NVSwitch)
  • Paralelismo de dados entre nós (InfiniBand)

Isso minimiza tráfego sensível à latência sobre a malha mais lenta.

2) Aumentar computação por comunicação (elevar a intensidade aritmética)

Se você consegue fazer mais computação por sincronização, o escalonamento melhora. Exemplos:

  • acumulação de gradientes (sincronizar a cada k passos)
  • batches maiores (dentro dos limites de otimização)
  • kernels fundidos / melhor compilação para aumentar a utilização de computação (Compiladores e Runtimes)

3) Sobrepor comunicação com computação

Muitos frameworks agrupam (bucket) gradientes para que all-reduce comece antes do backprop terminar.

No PyTorch DDP, por exemplo, o tamanho do bucket influencia o comportamento de sobreposição (conceitualmente):

# Conceptual: larger buckets can improve bandwidth efficiency,
# smaller buckets can start earlier for better overlap.
# Actual knobs vary by version and stack.
ddp_model = DistributedDataParallel(
    model,
    bucket_cap_mb=25,
)

Trade-off:

  • Muito pequeno → sobrecarga de latência domina
  • Muito grande → menos sobreposição, mais travamento no fim do passo

4) Reduzir o volume comunicado

  • Usar otimizadores fragmentados (comunicar fragmentos em vez de estados completos)
  • Considerar checkpointing de ativações (muda o balanço computação/comunicação/memória)
  • Em alguns cenários, comprimir tensores comunicados (com cuidado; pode prejudicar a convergência)

5) Evitar contenção da malha

Mesmo código perfeito pode escalar mal se:

  • a rede estiver sobrescrita
  • múltiplos jobs grandes compartilharem os mesmos uplinks
  • o posicionamento espalhar ranks entre racks de forma imprevisível

Isso vira um problema de sistemas envolvendo orquestração de cluster (frequentemente via Kubernetes; veja Kubernetes para ML (Visão de Alto Nível)) e políticas de agendamento.

Como raciocinar sobre “meu job vai escalar?”

Um checklist prático:

  1. Estime a comunicação por passo
    • DP: aproximadamente o tamanho dos gradientes
    • TP/MoE: ativações e roteamento podem dominar
  2. Identifique o enlace mais lento no caminho
    • NVLink intra-nó vs InfiniBand inter-nó
  3. Compare tempo de computação com tempo de comunicação
    • Se comunicação já é uma grande fração em 1 nó, escalar para fora provavelmente será ruim sem mudanças
  4. Considere topologia e sobrescrição
    • Especificações de pico do enlace não são o mesmo que largura de banda alcançada em coletivas em escala
  5. Planeje o layout de paralelismo em torno da malha
    • Mantenha padrões sensíveis à latência localmente (NVLink), empurre sincronização em massa para a rede

Onde isso se encaixa no panorama mais amplo de sistemas

O desempenho das interconunicações interage com:

A ideia unificadora é que escalonamento é um problema de movimentação de dados. NVLink/NVSwitch e InfiniBand são as principais rodovias para esse movimento — dentro de um nó e entre nós — e sua largura de banda, latência e topologia frequentemente determinam se adicionar GPUs gera acelerações lineares ou retornos decrescentes.