Olá, é um prazer inenarrável estar mais uma vez escrevendo este post. A NVIDIA apresentou uma evolução do DOCA GPUNetIO para transformar a comunicação iniciada pela GPU em uma camada compartilhada por diferentes bibliotecas do seu ecossistema. A proposta parece técnica, mas resolve um problema bastante concreto: quando a CPU precisa intermediar cada operação de rede, aplicações distribuídas podem acumular latência e perder capacidade de escala. A questão é entender como o DOCA GPUNetIO pretende evitar esse gargalo sem obrigar cada projeto a manter sua própria implementação.
Tempo de leitura: 6 minutos
Por que o DOCA GPUNetIO importa para a comunicação entre GPUs
Em aplicações de alto desempenho, a GPU pode produzir ou consumir dados em uma velocidade que torna a intermediação constante da CPU um obstáculo. O DOCA GPUNetIO organiza uma arquitetura em que a CPU continua responsável pela configuração inicial, mas os kernels CUDA passam a controlar operações no caminho de dados.
Na prática, o host configura dispositivos, memória e objetos de transporte. Depois, funções do GPUNetIO exportam descritores para a memória da GPU. Com essa preparação concluída, kernels CUDA podem enviar ou receber dados usando Ethernet, RDMA, Verbs e DMA, sem colocar a CPU no caminho crítico de cada transação.
Esse modelo combina recursos como GPUDirect RDMA, GPUDirect Async Kernel-Initiated e GDRCopy. A diferença mais importante não está apenas em remover uma etapa, mas em aproximar a decisão sobre comunicação do código que já está executando na GPU.
Como o DOCA GPUNetIO cria uma base unificada
Antes dessa abordagem compartilhada, bibliotecas como NCCL e NVSHMEM mantinham implementações próprias de comunicação iniciada pela GPU. Cada projeto precisava cuidar de detalhes semelhantes, como preparação de operações, notificações à placa de rede e acompanhamento de conclusões.
O DOCA GPUNetIO propõe concentrar essa infraestrutura em uma base comum. Assim, melhorias de desempenho, correções e suporte a novos recursos podem ser desenvolvidos em um ponto compartilhado, em vez de serem repetidos em várias bibliotecas.
Para desenvolvedores, isso pode reduzir a fragmentação do ecossistema. Para quem mantém aplicações, a vantagem potencial é ainda mais direta: bibliotecas de nível mais alto podem se concentrar em coletivas, comunicação entre processos ou movimentação de dados, enquanto o GPUNetIO cuida da camada de interação com os transportes.
DOCA GPUNetIO combina SDK completo e implementação aberta
A NVIDIA disponibiliza o GPUNetIO em duas formas relacionadas. A versão integrada ao DOCA SDK é a mais abrangente e inclui suporte a diferentes componentes da pilha DOCA, como Verbs, Ethernet, DMA e Comm Channel.
Também existe uma implementação de código aberto com foco principalmente em RDMA por Verbs. Ela foi pensada para projetos que desejam manter uma integração aberta com os transportes de rede. Quando o DOCA SDK está instalado e configurado, essa implementação pode detectar sua presença em tempo de execução e acessar determinadas funções por meio de dlopen. Sem o SDK, continua funcionando com a implementação aberta.
Essa divisão não representa necessariamente duas arquiteturas incompatíveis. A ideia é oferecer uma base comum para comunicação RDMA iniciada pela GPU e, ao mesmo tempo, permitir que aplicações avancem para recursos adicionais quando o SDK completo estiver disponível.
Como funciona o modelo de programação do DOCA GPUNetIO
O fluxo é dividido em duas partes. Na primeira, a CPU executa o caminho de controle: inicializa os dispositivos, reserva memória, cria filas de rede e exporta os objetos necessários para a GPU.
Na segunda, o kernel CUDA executa o caminho de dados. Dependendo do transporte, as threads podem preparar entradas de trabalho, conhecidas como WQEs, notificar a placa de rede e consultar entradas de conclusão, ou CQEs, para confirmar o resultado.
APIs de alto e baixo nível no DOCA GPUNetIO
O SDK oferece APIs de alto nível para operações compostas e APIs de baixo nível para quem precisa controlar cada etapa. Uma função de alto nível pode combinar a preparação de uma operação, a sincronização entre threads e a notificação à placa de rede. Isso reduz a quantidade de código que o desenvolvedor precisa escrever para operações comuns.
Já as primitivas de baixo nível permitem montar fluxos personalizados. Essa flexibilidade é útil quando a aplicação conhece exatamente como suas filas serão distribuídas entre blocos CUDA, mas exige que o próprio código coordene acessos concorrentes e evite condições de corrida.
O que significa tocar a campainha da placa de rede
Depois que as operações são preparadas, a GPU precisa avisar a placa de rede de que há trabalho disponível. A NVIDIA chama essa etapa de “ring the doorbell”, ou tocar a campainha.
O DOCA GPUNetIO suporta uma notificação convencional diretamente nos registradores da placa, o modo BlueFlame, voltado a cenários sensíveis à latência, e uma alternativa assistida pela CPU. Essa última pode ser útil em sistemas sem uma conexão direta entre GPU e placa de rede, embora reintroduza uma etapa intermediária no mecanismo de notificação.
DOCA GPUNetIO chega a NCCL e NVSHMEM
Uma das consequências mais relevantes da camada compartilhada é sua adoção por bibliotecas de comunicação já usadas em clusters de GPUs. No NCCL, a interface GIN oferece primitivas como put, get, signal, wait e flush para kernels CUDA. A partir da versão 2.27, o GIN passou a contar com um backend baseado no caminho Verbs do GPUNetIO de código aberto.
Com isso, algoritmos do NCCL podem iniciar operações RDMA diretamente na GPU, enquanto a camada inferior administra filas, notificações e conclusões. A NVIDIA também relata que, em testes do NCCL, o backend GDA-KI apresentou vantagem sobre o caminho tradicional baseado em comunicação pela CPU, especialmente em mensagens menores.
No NVSHMEM 3.7, a nova opção de transporte baseada no GPUNetIO permite usar a mesma base tanto em cenários de comunicação iniciada pela GPU quanto em configurações em que o caminho de dados continua sendo executado pela CPU. Nos testes apresentados pela NVIDIA, o uso de GDA-KI reduziu o gargalo do proxy da CPU e melhorou a escalabilidade com mais CTAs e filas de pares.
Esses resultados não significam que toda aplicação terá o mesmo ganho. O benefício depende do padrão de comunicação, do tamanho das mensagens, do hardware e da quantidade de filas utilizadas. Ainda assim, o modelo é particularmente interessante para operações pequenas e frequentes, nas quais a latência de uma etapa intermediária pesa mais.
DOCA GPUNetIO também aparece em fluxos de baixa latência
Outro exemplo citado pela NVIDIA é o NVQLink, uma arquitetura para conectar sistemas de controle quântico a recursos de computação acelerada. Nesse cenário, o operador GPU RoCE Transceiver, baseado em DOCA GPUNetIO e DOCA Verbs, mantém um kernel CUDA persistente recebendo e encaminhando pacotes sem intervenção contínua da CPU.
Em uma medição descrita pela empresa com uma plataforma NVIDIA IGX Thor, GPU Blackwell, ConnectX-7 e uma placa FPGA, o encaminhamento apresentou latência mínima aproximada de 2,6 microssegundos e mediana de 2,7 microssegundos. Esses números pertencem ao ambiente específico do teste e devem ser interpretados como uma demonstração de capacidade, não como uma promessa universal de desempenho.
O que o DOCA GPUNetIO muda para desenvolvedores
A principal mudança é arquitetural. Em vez de cada biblioteca construir uma versão própria da comunicação iniciada pela GPU, o GPUNetIO oferece uma infraestrutura que pode ser reutilizada por NCCL, NVSHMEM, UCX, NIXL, Holoscan e outros componentes.
Isso pode diminuir custos de manutenção e acelerar a chegada de otimizações a diferentes projetos. Também cria uma separação mais clara entre a lógica da aplicação e os detalhes de comunicação com a placa de rede. Por outro lado, a adoção exige atenção à compatibilidade entre GPU, NIC, drivers, versão do CUDA, bibliotecas e recursos disponíveis no sistema.
Para começar, o caminho mais seguro é consultar a documentação do DOCA GPUNetIO, examinar os exemplos do repositório de código aberto e comparar o comportamento com o fluxo de comunicação já utilizado pela aplicação.
Conclusão: o DOCA GPUNetIO tenta transformar a GPU em participante da rede
O DOCA GPUNetIO não é apenas uma API para enviar pacotes a partir de kernels CUDA. A proposta mais ampla é criar uma fundação comum para que diferentes bibliotecas de comunicação compartilhem a mesma implementação de GDA-KI, reduzindo duplicação e tornando a pilha mais consistente.
A CPU ainda tem um papel importante na configuração e no controle inicial. A diferença é que, depois dessa preparação, a GPU pode participar diretamente do caminho de dados e acionar operações de rede conforme a execução do aplicativo exige. É como preparar uma linha de produção uma vez e deixar que a própria fábrica coordene o fluxo, em vez de chamar um supervisor para cada peça.
Se a adoção continuar avançando em bibliotecas como NCCL e NVSHMEM, o impacto mais importante pode aparecer menos em uma função isolada e mais na evolução de todo o ecossistema de computação acelerada. O próximo passo para os desenvolvedores é testar a tecnologia no hardware disponível, medir os próprios padrões de comunicação e verificar se a redução da intermediação da CPU realmente se traduz em ganhos para suas aplicações.
