NVIDIA detalla el camino de Python hacia las lecturas de memoria GPU con GPUDirect Storage

NVIDIA publicó una guía técnica sobre 2026-10-22 explicando cómo las aplicaciones Python pueden leer datos directamente en la memoria GPU con Magnum IO GPUDirect Storage, y cómo verificar si una lectura utilizó la ruta acelerada o una alternativa en etapas de CPU. La publicación dice que la distinción importa porque KvikIO y cuFile toman decisiones de enrutamiento separadas antes de que una solicitud llegue al almacenamiento.

Cómo se selecciona el camino

Según NVIDIA, GPUDirect Storage crea una ruta directa de datos entre el almacenamiento soportado y la memoria GPU, evitando etapas innecesarias a través de la memoria de la CPU y reduciendo la utilización general de la CPU. En la pila de Python descrita en la publicación, KvikIO se sitúa por encima de cuFile: KvikIO decide si llama a cuFile, mientras que cuFile decide si la solicitud utiliza la ruta acelerada nvidia-fs o una ruta de compatibilidad que almacena los datos a través de la memoria del host.

La empresa afirma que llegar solo a la API cuFile no demuestra que se haya utilizado la ruta acelerada. Esa distinción es central en el tutorial, que muestra cómo inspeccionar los valores predeterminados de KvikIO, confirmar componentes GDS con gdscheck.py y luego usar gds_stats para determinar si las operaciones se contaron bajo nvfs o posix.

Lo que usaba el tutorial

NVIDIA afirma que el ejemplo fue probado en un sistema x86_64 con una GPU H100 , 13.3 CUDA y cuFile 1.18. La configuración también utilizó un dispositivo NVMe local formateado con ext4, una conexión PIX entre la GPU y el dispositivo NVMe, IOMMU y ACS deshabilitados, y el módulo del kernel nvidia-fs cargado para proporcionar la ruta acelerada.

En el ejemplo de Python, la guía crea un archivo de 1 GiB, asigna un array CuPy en la memoria de la GPU y lee el archivo en ese búfer con KvikIO. La publicación dice que KvikIO informó compat_mode como AUTO y una gds_threshold de 16 KiB en el sistema tutorial. AUTO indica a KvikIO que pruebe primero cuFile y vuelva a POSIX si cuFile no está disponible, mientras que las lecturas por debajo del umbral usen directamente la ruta POSIX.

Verificación con estadísticas cuFile

El artículo dice que uno forma de confirmar la ruta real de transferencia es habilitar CUFILE_STATS_LEVEL=3 e inspeccionar el proceso en ejecución con gds_stats. En el ejemplo del tutorial, el tamaño de tarea por defecto de 4 MiB de KvikIO dividió la petición de 1 GiB en 256 lecturas, y las estadísticas mostraron n=256, nvfs=256 y posix=0, indicando que todas las operaciones usaron la ruta nvidia-fs.

La publicación también compara las capas cambiando la configuración. Con KVIKIO_COMPAT_MODE=apagado, KvikIO sigue usando cuFile, y cuFile puede forzarse a su modo de compatibilidad con CUFILE_FORCE_COMPAT_MODE=true, lo que mueve las operaciones bajo posix. Con KVIKIO_COMPAT_MODE=on, KvikIO evita cuFile por completo y realiza la lectura a través de su propio backend POSIX con etapas de CPU.

Programación de cuFiles y tamaño de solicitudes

NVIDIA dice que cuFile tiene sus propios ajustes de ejecución en cufile.json que afectan a cómo se dividen y programan las solicitudes, incluyendo execution.parallel_io, execution.max_io_threads, execution.min_io_threshold_size_kb, execution.max_request_parallelism y execution.max_io_queue_depth. En la configuración de ejemplo, cuatro hilos de trabajo cuFile, max_request_parallelism configurados en cuatro y min_io_threshold_size_kb en 8192 significaban que una lectura de 1 GiB podía subdividirse una vez que cuFile la recibía.

La guía señala que si KVIKIO_TASK_SIZE está configurado a 1 GiB, KvikIO envía uno petición grande a cuFile, que entonces utiliza su ruta de planificación del búfer no registrado porque el búfer de destino no está registrado explícitamente. La publicación dice que en este caso cuFile limita la solicitud a cuatro piezas, cada una 256 MiB, y que esas piezas son unidades de trabajo programadas en lugar de transferencias individuales de almacenamiento. También dice que el objetivo de planificación de 8 MiB importaría para una solicitud de 16 MiB, que cuFile dividiría en dos 8 MiB partes.

Por qué NVIDIA está poniendo énfasis en la pila

El artículo sitúa el tutorial en el contexto de mayores demandas de movimiento de IA datos, citando el 2025 Stanford IA Index que dice que el cálculo para modelos de IA notables se ha duplicado aproximadamente cada cinco meses y que los conjuntos de datos de entrenamiento para grandes modelos de lenguaje se han duplicado aproximadamente cada ocho meses. NVIDIA también afirma que Python fue la interfaz principal de aplicaciones para muchos proyectos IA, mientras que cuFile sigue siendo una API en C, convirtiendo a KvikIO en un puente entre el código Python y la capa de aceleración de almacenamiento.

Según la publicación, KvikIO forma parte de NVIDIA CUDA-X para ciencia de datos y tiene raíces en trabajos anteriores de cuDF sobre la ingestión acelerada de Parquet y ORC. La empresa afirma que la misma ruta de almacenamiento se ha utilizado desde entonces en flujos de trabajo de patología digital cuCIM, cuPhoton xDataReader y trabajos acelerados por GPU Presto, pero el propio tutorial se centra en cómo confirmar si una lectura en Python realmente siguió la ruta acelerada.

La publicación no asigna mejoras de rendimiento a todas las configuraciones. En cambio, enfatiza que la operación de ruta directa depende del hardware, controladores, sistemas de archivos, topología y ajustes compatibles, y que las configuraciones no soportadas pueden volver al modo de compatibilidad. NVIDIA dice que los usuarios deberían verificar sus propias cargas de trabajo con gds_stats en lugar de asumir una aceleración.