GPUDirect Storage 已经能让 NVMe 和 GPU Memory 直接 DMA，为什么 NVIDIA 还要再做一套 SCADA？答案藏在“谁在运行时才知道下一块数据在哪里”这个问题里。

cuFile 适合由 CPU 或上层运行时提交已经成形的文件 I/O；图遍历、GNN 采样和磁盘型向量索引却可能让数十万个 GPU 线程各自发现下一个 offset。SCADA（SCaled Accelerated Data Access）试图把这些细粒度、数据依赖型请求留在 GPU 内核中：先经过 HBM 软件缓存与请求合并，再交给可信服务器访问本地或远端 NVMe。

一句话判断：SCADA 改变的首先是存储控制路径，其次才是数据路径。 它不是 GDS 的新名字，也还不是一个可直接下载部署的通用产品。公开论文已经证明 GPU-initiated storage 的基本机制，2024—2026 年的演讲和硬件演示展示了 SCADA 的扩展方向；但 API、部署要求和端到端生产数据仍处于有限公开阶段。

把 SSD 数据送进 GPU，最直观的优化似乎是“绕过 CPU”。但这句话混合了两个不同问题：数据是否经过 CPU 内存，以及 I/O 请求究竟由 CPU 还是 GPU 发起。NVIDIA GDS 解决前者，BaM 进一步改变后者；代价是原本由 CPU 承担的队列管理、并发和缓存压力转移到了 GPU。

本文整理 DaMoN 2025 论文 Path to GPU-Initiated I/O for Data-Intensive Systems：先沿 Figure 1 比较五条 GPU-centric Storage 路径，再还原 BaM、GDS 与 SPDK 的实验边界。核心结论不是“GPU 发起一定更快”，而是系统应根据 CPU、GPU、PCIe、SSD 与数据复用状态，选择由谁支付 I/O 控制成本。