NVIDIA 详细介绍了通过 GPU 存储读取 Python 的 GPU 内存路径

NVIDIA 发布了一份技术指南 2026-10-22 ，解释了 Python 应用如何通过 Magnum IO GPUDirect 存储直接将数据读入 GPU 内存，以及如何验证读取是使用加速路径还是 CPU 分级的备回。帖子说这种区别很重要，因为 KvikIO 和 cuFile 在请求到达存储之前会做出不同的路由决策。

路径的选择方式

据NVIDIA称，GPUDirect存储在支持的存储与GPU内存之间创建了直接的数据路径，避免了不必要的CPU存储分级，降低了整体CPU利用率。在帖子中描述的Python协议栈中，KvikIO位于cuFile之上：KvikIO决定是否调用cuFile，而cuFile则决定请求是使用加速的nvidia-fs路径，还是通过主机内存分阶段的数据。

公司表示，仅仅获得 cuFile API 并不能证明加速路径被使用。这一区别是教程的核心，教程展示了如何检查 KvikIO 默认值，用 gdscheck.py 确认 GDS 组件，然后用gds_stats判断操作是被计入 nvfs 还是 posix。

教程用了什么

NVIDIA表示，该示例是在一台配备H100 GPU、CUDA 13.3和cuFile 1.18的x86_64系统上测试的。该设置还使用了本地NVMe设备，格式化为ext4，GPU与NVMe设备之间的PIX连接，IOMMU和ACS被禁用，并加载了nvidia-fs内核模块以提供加速路径。

在 Python 示例中，指南创建了一个 1 GiB 文件，在 GPU 内存中分配一个 CuPy 数组，并用 KvikIO 将文件读入缓冲区。帖子说 KvikIO 在教程系统中报告compat_mode为 AUTO 和 gds_threshold 16 KiB 的 KiB。AUTO 告诉 KvikIO 先尝试 cuFile，如果 cuFile 不可用则回退到 POSIX，而低于阈值的读取则直接使用 POSIX 路径。

用cuFile统计验证

文章说确认实际传输路径一方法是启用 CUFILE_STATS_LEVEL=3，并用 gds_stats 检查正在运行的进程。在教程示例中，KvikIO 默认的 4 MiB 任务将 1 GiB 请求拆分为 256 次读取，统计数据显示 n=256，nvfs=256，posix=0，表明所有操作都使用 nvidia-fs 路径。

帖子还通过更改设置来比较各层。关闭KVIKIO_COMPAT_MODE=时，KvikIO 仍然使用 cuFile，且 cuFile 可以被强制进入与 CUFILE_FORCE_COMPAT_MODE=true 的兼容模式，从而将操作转移到 posix 下。在 KVIKIO_COMPAT_MODE=on 时，KvikIO 完全绕过 cuFile，通过自身 CPU 分级的 POSIX 后端完成读取。

cuFile 调度与请求大小

NVIDIA 表示 cuFile 在 cufile.json 中有自己的执行设置，影响请求的拆分和调度方式，包括 execution.parallel_io、execution.max_io_threads、execution.min_io_threshold_size_kb、execution.max_request_parallelism 和 execution.max_io_queue_depth。在示例配置中，四 cuFile 工作线程，max_request_parallelism 设置为 四，min_io_threshold_size_kb 设置为 8192，意味着 cuFile 接收到 1 GiB 读取后可以进一步细分。

指南指出，如果KVIKIO_TASK_SIZE设置为1 GiB，KvikIO会向cuFile发送一大请求，cuFile随后使用其未注册的缓冲区调度路径，因为目的缓冲区未被显式注册。帖子中提到，在这种情况下cuFile限制请求为四个部分，每个部分256 MiB，且这些部分是调度工作单元，而非单个存储传输。它还说，8 MiB调度目标对于16 MiB请求很重要，cuFile会将其拆分为二 8 MiB部分。

为什么NVIDIA强调技术栈

文章将教程置于更大规模人工智能数据流动需求的背景下，引用2025斯坦福人工智能指数称，著名人工智能模型的计算量大约每五个月翻一番，大型语言模型的训练数据集大约每八个月翻一番。NVIDIA还表示，Python是许多人工智能项目的主要应用接口，而cuFile仍是C API，使KvikIO成为Python代码与存储加速层之间的桥梁。

据文章介绍，KvikIO 是 NVIDIA CUDA-X 数据科学的一部分，其根源可追溯到早期 cuDF 关于加速 Parquet 和 ORC 摄取的工作。公司表示，相同的存储路径后来被用于 cuCIM 数字病理工作流程、cuPhoton xDataReader 和 GPU 加速的 Presto 工作，但教程本身侧重于如何确认 Python 读取是否真的走了加速路线。

文章并未为所有配置分配性能提升。相反，它强调直接路径操作依赖于兼容的硬件、驱动程序、文件系统、拓扑和设置，且不支持的配置可能会退回到兼容模式。NVIDIA 表示用户应自行验证工作负载，而非假设速度提升gds_stats。