NVIDIA技术博客演示如何用KvikIO在Python中经GDS直读GPU显存
NVIDIA发布教程，展示用KvikIO Python API把 1 GiB文件读入GPU显存，并用cuFile统计区分nvidia-fs加速路径与经CPU暂存的兼容路径。教程同时指出，调用到cuFile并不等于已走加速路径。
AI解读：NVIDIA开发者博客发布一篇技术教程，主题是用KvikIO的Python API在GPUDirect Storage（GDS）支持下把文件读入GPU显存，并核验实际走的是否为加速路径。
教程强调，KvikIO和cuFile各自做一次路径选择。KvikIO先决定是否调用cuFile，cuFile再依据系统支持、文件系统和配置决定用GDS加速路径还是经CPU暂存的兼容路径；因此到达cuFile API本身不能证明加速路径已启用。
验证方法是在进程存活时用CUFILE_STATS_LEVEL=3 采集cuFile统计，再用gds_stats查看计数：nvfs对应经nvidia-fs内核模块的加速操作，posix对应兼容路径。在示例中，一次 1 GiB读取被KvikIO默认的 4 MiB任务大小拆成 256 次读操作，统计显示nvfs=256、posix=0。
教程还演示了三个可对照的配置：设KVIKIO_COMPAT_MODE=off强制使用cuFile；再叠加CUFILE_FORCE_COMPAT_MODE=true后，操作记入posix；设KVIKIO_COMPAT_MODE=on则完全绕过cuFile，走KvikIO自己的CPU暂存后端，cuFile不记录该操作。
文章说明KvikIO的compat_mode可为AUTO、ON、OFF，AUTO表示先尝试cuFile、不可用时回退到POSIX后端；gds_threshold在测试系统上为 16 KiB，小于该值的读取直接走KvikIO的POSIX路径。这些设置也可通过KVIKIO_COMPAT_MODE和KVIKIO_GDS_THRESHOLD环境变量控制。
文中关于KvikIO已被cuDF、cuCIM、cuPhoton等工作流使用的说法属于NVIDIA的陈述，教程本身未给出这些场景的性能对比数据；读者可核实的范围限于作者所述测试环境下的路径判定与统计结果。
NVIDIA开发者博客发布教程，介绍如何用KvikIO的Python API在GPUDirect Storage（GDS）支持下把文件读入GPU显存，并判断这次读取实际走了哪条数据路径。作者Tanya Lenz给出的测试环境为：x86_64系统、H100 GPU、CUDA 13.3、cuFile 1.18，数据存放在ext4格式的本地NVMe设备上。
教程的核心提醒是：KvikIO选择调用cuFile，并不等于加速路径已启用。cuFile还会依据系统支持、文件系统和自身配置，决定使用GDS加速路径，还是经CPU暂存的兼容路径。
KvikIO与cuFile的两层路径选择
文章把GDS描述为在受支持的存储与GPU显存之间建立直接数据路径的技术，可避免数据先经CPU内存中转，并降低系统CPU占用。面向文件系统存储时，应用和框架通过cuFile的C库与API访问GDS；KvikIO位于cuFile之上，提供Python和C++高层接口，并对I/O请求的执行方式提供额外控制。
按教程描述的执行流程，应用提供文件路径和GPU缓冲区，KvikIO决定把请求交给cuFile还是走自己的POSIX兼容路径（数据经主机内存暂存）。选择cuFile后，KvikIO注册文件并用目标GPU缓冲区发起I/O，随后由cuFile决定实际传输路径。作者因此写道，调用到cuFile API只能确认KvikIO选了cuFile，不能单独确认加速GDS路径被激活。
用cuFile统计判断实际路径
教程用cuFile的按进程运行时统计来验证路径。设置CUFILE_STATS_LEVEL=3，并在进程保持存活时用gds_stats查看计数：nvfs表示经nvidia-fs内核模块的操作，posix表示由cuFile兼容路径处理的操作。示例以Python交互模式运行，读取完成后进程不退出，便于外部查看累计计数。
示例文件为 1 GiB随机数据，用dd以direct I/O写入并刷盘，读入预先分配的 1 GiB CuPy数组。返回的字节数只证明完整读入，不标识底层路径。由于KvikIO默认任务大小为 4 MiB，1 GiB被拆成 256 次读操作，统计显示n=256、nvfs=256、posix=0，即 256 次操作全部走nvidia-fs路径。
三种配置下的路径对照
教程用同一读取分别改变两层设置。设KVIKIO_COMPAT_MODE=off时，KvikIO必须使用cuFile，在测试系统上gds_stats报告nvfs操作。再叠加CUFILE_FORCE_COMPAT_MODE=true时，KvikIO仍调用cuFile，但操作记入posix而非nvfs。设KVIKIO_COMPAT_MODE=on时，KvikIO完全绕过cuFile，改由自身CPU暂存的POSIX后端执行，cuFile不记录该操作。
默认设置方面，测试系统上KvikIO的compat_mode为AUTO、gds_threshold为 16 KiB。AUTO表示先尝试cuFile，cuFile不可用时回退到KvikIO的POSIX后端；小于阈值的读取直接走KvikIO的POSIX路径。这些值可用KVIKIO_COMPAT_MODE和KVIKIO_GDS_THRESHOLD环境变量，或在Python中通过defaults.set调整。
cuFile侧的执行参数与示例取舍
在KvikIO选定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。教程给出的配置为 4 个cuFile工作线程、max_request_parallelism为 4、min_io_threshold_size_kb为 8192（8 MiB）。
文章对比了任务大小的区别：默认 4 MiB任务下，1 GiB读取产生 256 个cuFile请求；把KVIKIO_TASK_SIZE设为 1 GiB时，KvikIO只向cuFile发送一个大请求。由于CuPy目标缓冲区未显式注册给cuFile，cuFile走未注册缓冲区调度路径，把请求限制为min(4 个工作线程, 4 个最大请求并行度)=4 份，每份 256 MiB。这些份数是调度单位，不是单次存储传输；在示例配置下nvidia-fs路径使用不超过 16 MiB的slab，256 MiB的份再拆成更小的传输。
作者还用 16 MiB请求说明 8 MiB阈值的作用：四等分将是 4 MiB一份，因此cuFile改为调度两个 8 MiB份；要让cuFile完整收到该请求，KvikIO的任务大小至少需为 16 MiB。
前提条件与适用范围
教程列出的前提包括：带NVIDIA GPU和GPUDirect Storage的Linux系统，受GDS支持的存储与文件系统配置，对存储端点创建、读写文件的权限，以及对gdscheck、gds_stats等工具的访问权限。测试系统还要求GPU与NVMe设备之间为PIX连接（最多经过一个PCIe桥）、关闭IOMMU和ACS以保留PCIe点对点传输、加载nvidia-fs内核模块。
文章提到KvikIO属于面向数据科学的NVIDIA CUDA-X库（原RAPIDS），其开发与为cuDF构建的GDS集成密切相关；作者称KvikIO此后被用于cuCIM数字病理和cuPhoton的xDataReader科学图像分析等场景。这些使用情况属于NVIDIA的陈述，教程未提供这些工作流与兼容路径的性能对比。作者引用的 2025 斯坦福AI Index数据（重要模型算力约每五个月翻倍、LLM训练数据集规模约每八个月翻倍）用于说明数据搬运需求，并非对GDS效果的实测。