NVIDIA detalha o caminho Python para leituras de memória GPU com o GPUDirect Storage

A NVIDIA publicou um guia técnico sobre 2026-10-22 explicando como aplicações Python podem ler dados diretamente na memória da GPU com o Magnum IO GPUDirect Storage, e como verificar se uma leitura usou o caminho acelerado ou um plano B em estágio de CPU. O post diz que a distinção importa porque KvikIO e cuFile tomam decisões de roteamento separadas antes que uma requisição chegue ao armazenamento.

Como o caminho é selecionado

De acordo com a NVIDIA, o GPUDirect Storage cria um caminho direto de dados entre o armazenamento suportado e a memória da GPU, evitando stagings desnecessários na memória da CPU e reduzindo a utilização geral da CPU. Na pilha Python descrita no post, o KvikIO fica acima do cuFile: o KvikIO decide se chama o cuFile, enquanto o cuFile decide se a solicitação usa o caminho acelerado nvidia-fs ou um caminho de compatibilidade que passa os dados pela memória do host.

A empresa afirma que alcançar a API cuFile sozinha não prova que o caminho acelerado foi usado. Essa distinção é central no tutorial, que mostra como inspecionar os padrões do KvikIO, confirmar componentes GDS com gdscheck.py e então usar gds_stats para determinar se as operações foram contadas sob nvfs ou posix.

O que o tutorial usou

A NVIDIA diz que o exemplo foi testado em um sistema x86_64 com uma GPU H100 , 13.3 CUDA e 1.18 cuFile. A configuração também usou um dispositivo NVMe local formatado com ext4, uma conexão PIX entre a GPU e o dispositivo NVMe, IOMMU e ACS desativados, e o módulo do kernel nvidia-fs carregado para fornecer o caminho acelerado.

No exemplo de Python, o guia cria um arquivo de 1 GiB, aloca um array CuPy na memória da GPU e lê o arquivo nesse buffer com o KvikIO. O post diz que o KvikIO reportou compat_mode como AUTO e uma gds_threshold de 16 KiB no sistema tutorial. O AUTO orienta o KvikIO a tentar o cuFile primeiro e voltar ao POSIX se o cuFile não estiver disponível, enquanto as leituras abaixo do limiar usam o caminho POSIX diretamente.

Verificação com estatísticas cuFile

O artigo diz que um forma de confirmar o caminho real de transferência é ativar CUFILE_STATS_LEVEL=3 e inspecionar o processo em execução com gds_stats. No exemplo do tutorial, o padrão do KvikIO, 4 tamanho de tarefa MiB, dividiu a requisição de 1 GiB em 256 leituras, e as estatísticas mostraram n=256, nvfs=256 e posix=0, indicando que todas as operações usaram o caminho nvidia-fs.

O post também compara as camadas alterando as configurações. Com KVIKIO_COMPAT_MODE=desligado, o KvikIO ainda usa cuFile, e o cuFile pode ser forçado a entrar em seu modo de compatibilidade com CUFILE_FORCE_COMPAT_MODE=true, que move as operações sob posix. Com KVIKIO_COMPAT_MODE=ligado, o KvikIO ignora completamente o cuFile e realiza a leitura através de seu próprio backend POSIX em estágio de CPU.

Escalonamento e dimensionamento de pedidos no cuFile

A NVIDIA diz que o cuFile tem suas próprias configurações de execução em cufile.json que afetam como as requisições são divididas e agendadas, incluindo execution.parallel_io, execution.max_io_threads, execution.min_io_threshold_size_kb, execution.max_request_parallelism e execution.max_io_queue_depth. Na configuração de exemplo, quatro threads worker cuFile, max_request_parallelism definido para quatro e min_io_threshold_size_kb configurado para 8192 significava que uma leitura de 1 GiB poderia ser subdividida ainda mais quando o cuFile o recebesse.

O guia observa que, se KVIKIO_TASK_SIZE estiver definido para 1 GiB, o KvikIO envia um grande requisição para o cuFile, que então usa seu caminho de agendamento no buffer não registrado porque o buffer de destino não está explicitamente registrado. O post diz que, neste caso, o cuFile limita a requisição a quatro partes, cada uma 256 MiB, e que essas peças são unidades de trabalho agendadas em vez de transferências individuais de armazenamento. Também diz que o destino de escalonamento 8 MiB importaria para uma requisição de 16 MiB, que o cuFile dividiria em dois 8 MiB pedaços.

Por que a NVIDIA está enfatizando a pilha

O artigo coloca o tutorial no contexto de demandas maiores de movimentação de dados IA, citando o 2025 Stanford IA Index como afirmando que a computação para modelos de IA notáveis dobrava a cada cinco meses e os conjuntos de dados de treinamento para grandes modelos de linguagem dobravam a cada oito meses. A NVIDIA também afirma que o Python foi a principal interface de aplicação para muitos projetos IA, enquanto o cuFile permanece uma API C, tornando o KvikIO uma ponte entre o código Python e a camada de aceleração de armazenamento.

De acordo com a publicação, o KvikIO faz parte do NVIDIA CUDA-X para ciência de dados e tem raízes em trabalhos anteriores com cuDF sobre Parquet acelerado e ingestão de ORC. A empresa afirma que o mesmo caminho de armazenamento tem sido usado desde então em fluxos de trabalho de patologia digital cuCIM, cuPhoton xDataReader e trabalhos acelerados com GPU Presto, mas o tutorial em si foca em como confirmar se uma leitura em Python realmente seguiu o caminho acelerado.

O post não atribui ganhos de desempenho a todas as configurações. Em vez disso, enfatiza que a operação por caminho direto depende de hardware compatível, drivers, sistemas de arquivos, topologia e configurações, e que configurações não suportadas podem voltar ao modo de compatibilidade. A NVIDIA diz que os usuários devem verificar suas próprias cargas de trabalho com gds_stats em vez de assumir um aumento de velocidade.