GPU Direct Storage 概述：什么是 GDS、发展背景、与传统 IO 路径的对比
2.1 什么是 GPU Direct Storage（GDS）
GPU Direct Storage（简称 GDS）是 NVIDIA 推出的一种高性能数据访问技术，它允许 GPU 直接与 NVMe 或 NVMe-oF 存储设备交换数据，绕过了 CPU 和系统内存的中间拷贝环节。在传统架构中，存储数据必须先从磁盘读入系统内存（Host Memory），再由 CPU 发起拷贝操作将数据送入 GPU 显存；而 GDS 通过 RDMA 与 PCIe 点对点传输机制，让存储控制器与 GPU 显存之间建立直接数据通道。
从 API 层面看，GDS 并不是一套全新的编程模型，而是对 CUDA 流（Stream）与存储事件（Storage Event）机制的扩展。开发者仍然使用 cudaMemcpyAsync 或 cuFileRead 等接口，但底层数据路径已经发生了根本变化。GDS 的核心组件包括：
- cuFile 库：提供
cuFileRead/cuFileWrite等 API，允许 GPU 直接访问文件系统上的数据。 - GPU 页表与 BAR 映射：GPU 显存物理地址通过 PCIe BAR 空间暴露给存储设备，使 NVMe 控制器可以直接 DMA 写入显存。
- 存储事件（Storage Events）：用于在 CUDA 流中同步存储完成信号，避免 CPU 轮询。
核心要点：GDS 的本质是消除“存储 → 系统内存 → GPU 显存”路径中的 CPU 拷贝与内存中转，让数据以 DMA 方式直达显存。它适用于大块数据、高吞吐场景，而非小 IO 随机访问。
2.2 发展背景：为什么需要 GDS
GDS 的出现并非偶然，而是数据中心算力结构变化与数据规模膨胀共同推动的结果。理解其发展背景，需要从三个维度审视：
（1）数据洪流与存储带宽的跃升
PCIe Gen4/Gen5 NVMe SSD 的单盘顺序读带宽已突破 7 GB/s 甚至 14 GB/s，而 GPU 的显存带宽更是高达 2~3 TB/s。然而，传统 IO 路径中，数据从存储到显存需要经过系统内存，而系统内存带宽（DDR4/DDR5 通常为 50~100 GB/s）成为瓶颈。更关键的是，CPU 参与的每一次拷贝都会消耗内存带宽和 CPU 周期，导致整体吞吐量远低于硬件理论值。
（2）GPU 计算能力过剩而数据供给不足
在深度学习训练、大数据分析等场景中，GPU 的计算吞吐量往往远超数据加载速度。以 NVIDIA A100 为例，其 FP16 算力高达 312 TFLOPS，而传统 IO 路径下数据加载速率可能仅 2~3 GB/s，导致 GPU 大量时间处于等待状态。GDS 的目标就是让数据供给速度匹配 GPU 的计算能力。
（3）CPU 内存墙与功耗约束
数据中心 CPU 的核心数增长趋缓，但数据拷贝任务却随数据量线性增长。将大量数据搬移工作从 CPU 卸载到 DMA 引擎，不仅降低 CPU 占用率，还能减少内存访问能耗。在超大规模集群中，这种卸载带来的 TCO 收益非常可观。
| 时间节点 | 关键事件 | 对 GDS 的推动 |
|---|---|---|
| 2019 年 | NVIDIA 发布 Magnum IO 技术栈 | 首次系统化提出 GPU 直通存储的软件框架 |
| 2020 年 | CUDA 11.0 引入 cuFile API | 提供用户态文件读写接口，无需修改内核驱动 |
| 2021 年 | GPUDirect Storage 正式 GA | 支持 Linux 内核 5.x 与主流 NVMe 控制器 |
| 2022 年起 | NVIDIA 与存储厂商联合优化 | DDN、WEKA、IBM 等存储系统原生支持 GDS |
2.3 传统 IO 路径与 GDS 的深度对比
为了更清晰地理解两者差异，下面从数据路径、CPU 参与度、内存占用、延迟特征和适用场景五个维度进行对比。
| 对比维度 | 传统 IO 路径 | GDS 路径 |
|---|---|---|
| 数据路径 | NVMe → 系统内存（DMA）→ CPU 拷贝 → GPU 显存（PCIe） | NVMe → GPU 显存（PCIe P2P DMA） |
| CPU 参与度 | 全程参与：发起 DMA、中断处理、内存拷贝、地址映射 | 仅初始化阶段参与：设置 DMA 描述符、注册显存 BAR 地址 |
| 内存占用 | 需要 Page Cache 或临时缓冲，额外占用系统内存 | 无需中间缓冲，系统内存占用几乎为零 |
| 延迟特征 | 微秒级额外延迟（拷贝 + 上下文切换） | 接近纯 DMA 延迟，减少 30%~50% 端到端延迟 |
| 适用场景 | 小文件、随机 IO、需要 CPU 预处理的数据 | 大文件、顺序 IO、数据无需 CPU 修改的场景 |
2.4 典型应用场景与误区澄清
典型受益场景
- 深度学习训练数据加载：ImageNet、视频数据集等大文件顺序读取，GDS 可将数据加载时间缩短 40%~60%。
- 科学计算检查点（Checkpoint）：HPC 应用定期保存大体积状态文件，GDS 加速写入与恢复。
- 数据分析与 ETL：GPU 直接读取 Parquet/ORC 列式文件，省去 CPU 解析前的内存拷贝。
- AI 推理中的向量数据库：大规模向量索引加载到显存时，GDS 减少初始化等待。
常见误区与注意事项
误区一：GDS 对所有 IO 场景都有加速效果。实际上，对于小于 1 MB 的随机小 IO，GDS 的 DMA 描述符开销可能超过收益，传统路径反而更快。GDS 最适合大块顺序 IO。
误区二：启用 GDS 后 CPU 完全不参与。CPU 仍需负责文件系统元数据操作、DMA 描述符构建和错误处理，只是数据搬移不再经过 CPU。
误区三：GDS 需要特殊硬件。GDS 需要支持 PCIe P2P 的 NVMe 控制器和 NVIDIA GPU（Volta 架构以上），但无需专用存储网络——只要 PCIe 拓扑允许 P2P 即可。
代码示例：cuFile 基本读取流程
// 使用 cuFile 实现 GPU 直接读取文件
cuFileDriverOpen(); // 初始化驱动
cuFileHandle_t fh;
cuFileHandleRegister(&fh, fd); // 注册文件描述符
CUdeviceptr d_ptr;
cuMemAlloc(&d_ptr, buffer_size); // 分配 GPU 显存
// 核心：GPU 直接读取，无需 CPU 拷贝
cuFileRead(fh, d_ptr, buffer_size, 0, 0);
cuFileHandleDeregister(&fh);
cuFileDriverClose();从上述对比可以看出，GDS 并非颠覆性技术，而是对现有 PCIe DMA 能力的精细化利用。它通过减少数据搬移次数、降低 CPU 负载、缩短端到端延迟，为 GPU 密集型应用提供了更顺畅的数据供给通道。在实际部署中，需要结合存储硬件能力、文件大小分布和 GPU 利用率综合评估收益，才能发挥 GDS 的最大价值。