NVIDIA beschreibt den Python-Pfad zu GPU-Speicherlesungen mit GPUDirect Storage

NVIDIA veröffentlichte einen technischen Leitfaden zu 2026-10-22 , der erklärt, wie Python-Anwendungen Daten direkt in den GPU-Speicher mit Magnum IO GPUDirect Storage lesen können und wie man überprüft, ob ein Lesen den beschleunigten Pfad oder einen CPU-gefassten Fallback verwendet hat. Der Beitrag sagt, dass die Unterscheidung wichtig ist, weil KvikIO und cuFile getrennte Routing-Entscheidungen treffen, bevor eine Anfrage den Speicher erreicht.

Wie der Weg ausgewählt wird

Laut NVIDIA erzeugt GPUDirect Storage einen direkten Datenpfad zwischen unterstütztem Speicher und GPU-Speicher, wodurch unnötiges Staging durch den CPU-Speicher vermieden und die Gesamtauslastung der CPU reduziert wird. Im im Beitrag beschriebenen Python-Stack liegt KvikIO über cuFile: KvikIO entscheidet, ob cuFile überhaupt aufgerufen wird, während cuFile entscheidet, ob die Anfrage den beschleunigten nvidia-fs-Pfad oder einen Kompatibilitätspfad verwendet, der Daten durch den Hostspeicher stündet.

Das Unternehmen sagt, dass allein das Erreichen der cuFile-API nicht beweist, dass der beschleunigte Pfad verwendet wurde. Diese Unterscheidung ist zentral im Tutorial, das zeigt, wie man KvikIO-Standardwerte inspiziert, GDS-Komponenten mit gdscheck.py bestätigt und dann gds_stats verwendet, um festzustellen, ob Operationen unter nvfs oder posix gezählt wurden.

Was das Tutorial verwendet hat

NVIDIA sagt, das Beispiel sei auf einem x86_64 System mit einer H100 GPU, CUDA 13.3 und cuFile 1.18 getestet worden. Das Setup verwendete außerdem ein lokales NVMe-Gerät, das mit ext4 formatiert war, einer PIX-Verbindung zwischen GPU und NVMe-Gerät, IOMMU und ACS deaktiviert sowie dem nvidia-fs-Kernel-Modul, das den beschleunigten Pfad bereitstellte.

Im Python-Beispiel erstellt der Guide eine 1 GiB-Datei, weist ein CuPy-Array im GPU-Speicher zu und liest die Datei mit KvikIO in diesen Puffer. Der Beitrag sagt, dass KvikIO compat_mode als AUTO und einen gds_threshold von 16 KiB im Tutorial-System gemeldet hat. AUTO sagt KvikIO, zuerst cuFile auszuprobieren und auf POSIX zurückzugreifen, falls cuFile nicht verfügbar ist, während Leser unterhalb des Schwellenwerts direkt den POSIX-Pfad verwenden.

Verifikation mit cuFile-Statistiken

Der Artikel sagt, eins Möglichkeit, den tatsächlichen Übertragungspfad zu bestätigen, darin besteht, CUFILE_STATS_LEVEL=3 zu aktivieren und den laufenden Prozess mit gds_stats zu inspizieren. Im Tutorial-Beispiel teilte KvikIOs Standard-4 MiB-Aufgabengröße die 1 GiB-Anfrage in 256 Reads auf, und die Statistiken zeigten n=256, nvfs=256 und posix=0, was darauf hinweist, dass alle Operationen den nvidia-fs-Pfad verwendeten.

Der Beitrag vergleicht die Schichten außerdem durch Einstellungsänderungen. Mit KVIKIO_COMPAT_MODE=off verwendet KvikIO weiterhin cuFile, und cuFile kann mit CUFILE_FORCE_COMPAT_MODE=true, das Operationen unter posix bewegt, in seinen Kompatibilitätsmodus gezwungen werden. Mit KVIKIO_COMPAT_MODE=on umgeht KvikIO cuFile vollständig und führt das Lesen über sein eigenes CPU-gestuftes POSIX-Backend durch.

cuFile-Planung und Anfragegröße

NVIDIA sagt, dass cuFile eigene Ausführungseinstellungen in cufile.json hat, die beeinflussen, wie Anfragen aufgeteilt und geplant werden, einschließlich execution.parallel_io, execution.max_io_threads, execution.min_io_threshold_size_kb, execution.max_request_parallelism und execution.max_io_queue_depth. In der Beispielkonfiguration max_request_parallelism vier cuFile-Worker-Threads auf vier gesetzt, und min_io_threshold_size_kb auf 8192 gesetzt, bedeutete, dass eine 1 GiB-Lesung weiter unterteilt werden konnte, sobald cuFile sie empfangen hatte.

Der Guide merkt an, dass, wenn KVIKIO_TASK_SIZE auf 1 GiB gesetzt ist, KvikIO eins große Anfrage an cuFile sendet, das dann seinen unregistrierten Puffer-Planungspfad verwendet, da der Zielpuffer nicht explizit registriert ist. Der Beitrag besagt, dass cuFile in diesem Fall die Anfrage auf vier Teile beschränkt, jeweils 256 MiB, und dass diese Teile geplante Arbeitseinheiten und keine einzelnen Speicherübertragungen sind. Außerdem heißt es, dass das 8 MiB-Planungsziel für eine 16 MiB-Anfrage wichtig wäre, die cuFile in zwei 8 MiB-Teile aufteilen würde.

Warum NVIDIA den Stack betont

Der Artikel stellt das Tutorial in den Kontext größerer Anforderungen an KI Datenbewegung und zitiert den 2025 Stanford KI Index, der besagt, dass die Rechenleistung für bemerkenswerte KI Modelle etwa alle fünf Monate verdoppelt wurde und die Trainingsdatensätze für große Sprachmodelle etwa alle acht Monate verdoppelt wurden. NVIDIA sagt außerdem, dass Python die Hauptanwendungsschnittstelle für viele KI Projekte war, während cuFile eine C-API bleibt, was KvikIO zu einer Brücke zwischen Python-Code und der Speicherbeschleunigungsschicht macht.

Laut dem Beitrag ist KvikIO Teil von NVIDIA CUDA-X für Data Science und hat seine Wurzeln in früheren cuDF-Arbeiten zur beschleunigten Parquet- und ORC-Aufnahme. Das Unternehmen sagt, dass derselbe Speicherpfad seitdem in cuCIM-digitalen Pathologie-Workflows, cuPhoton xDataReader und GPU-beschleunigtem Presto-Werk verwendet wurde, aber das Tutorial selbst konzentriert sich darauf, wie man bestätigt, ob eine Python-Lesung tatsächlich den beschleunigten Weg gegangen ist.

Der Beitrag weist nicht jeder Konfiguration Leistungssteigerungen zu. Stattdessen betont er, dass der Direct-Path-Betrieb von kompatibler Hardware, Treibern, Dateisystemen, Topologie und Einstellungen abhängt und dass nicht unterstützte Konfigurationen in den Kompatibilitätsmodus zurückfallen können. NVIDIA sagt, Nutzer sollten ihre eigenen Workloads mit gds_stats überprüfen, anstatt von einer Beschleunigung auszugehen.