☰ Menu

07.10.2026 · Signal Titans Editorial

NVIDIA unifica rede iniciada por GPU na pilha CUDA via DOCA GPUNetIO

A NVIDIA padronizou as operações de rede iniciadas por GPU com o DOCA GPUNetIO, eliminando gargalos de CPU em bibliotecas como NCCL e NVSHMEM.

Ilustração conceitual de um chip de processador metálico conectado diretamente a um cabo de rede de cobre sobre uma superfície de vidro.

A NVIDIA detalhou como a sua estrutura DOCA GPUNetIO serve como uma base consolidada para comunicação de rede iniciada diretamente pela GPU em toda a pilha de software CUDA. Ao padronizar as operações de GPUDirect Async Kernel-Initiated (GDA-KI) sob uma arquitetura unificada, a tecnologia substitui implementações isoladas que existiam em frameworks como NCCL, NVSHMEM, UCX/NIXL e o SDK Aerial 5G.

Eliminando gargalos no caminho de controle da CPU

As aplicações distribuídas em GPU tradicionalmente dependem dos processadores principais (CPUs) para gerenciar transações de rede, o que introduz latência em caminhos de dados críticos. O DOCA GPUNetIO combina GPUDirect RDMA, GDRCopy e GDA-KI para permitir que os kernels CUDA gerenciem diretamente operações de Ethernet, RDMA, Verbs e DMA sem a necessidade de rotear essas transações pelo processador hospedeiro.

Distribuição dupla: código aberto e camadas do SDK

A NVIDIA disponibiliza o GPUNetIO em duas configurações complementares. Uma biblioteca leve de código aberto fornece uma implementação focada em Verbs para frameworks que exigem transportes de rede totalmente abertos. Já o SDK DOCA completo funciona como um superconjunto, adicionando suporte a interfaces Ethernet, DMA e canais de comunicação.

A versão de código aberto consegue detectar a presença do SDK DOCA completo em tempo de execução via carregamento dinâmico com dlopen. Caso o SDK seja identificado, a camada open-source invoca funções do SDK proprietário para expor recursos estendidos; se estiver ausente, ela continua operando normalmente com sua implementação Verbs de código aberto.

Configuração do caminho de controle e modelos de execução

A execução requer um modelo de programação em duas fases. Primeiro, a CPU hospedeira executa o caminho de controle inicializando objetos de fila de rede — como filas Verbs ou Ethernet via mlx5dv — e exportando os descritores dessas filas para a memória da GPU. Em seguida, os kernels CUDA assumem o caminho de dados diretamente na GPU, criando entradas na fila de trabalho (WQEs), notificando a placa de rede e, opcionalmente, verificando entradas na fila de conclusão (CQEs).

Para notificar o hardware sobre novas tarefas pendentes, o GPUNetIO suporta múltiplos modos de notificação (doorbell): gravações diretas em MMIO, o modo BlueFlame para cargas de trabalho de baixa latência (em que WQEs completas são gravadas nos registradores da placa) e um modo auxiliado por CPU. Neste último, as atualizações da GPU são direcionadas via memória compartilhada e monitoradas por uma thread da CPU, atendendo a arquiteturas sem conexões diretas entre GPU e placa de rede, como o DGX Spark.

Integração entre bibliotecas de comunicação

A arquitetura permite que bibliotecas de alto nível padronizem suas mecânicas de transporte. Desde a versão 2.27, o NCCL integra o GDA-KI por meio de sua interface de rede iniciada por GPU (GIN), utilizando o backend Verbs open-source do GPUNetIO para isolar algoritmos coletivos do gerenciamento de filas de baixo nível. Integrações semelhantes se estendem a modelos de programação PGAS, como o NVSHMEM, permitindo que melhorias de desempenho unificadas beneficiem todo o ecossistema de GPUs.

Ilustração editorial gerada por IA; não é uma fotografia documental.

Fonte: How DOCA GPUNetIO Unifies GPU-Initiated Networking Across the NVIDIA Software Stack