【NVIDIA cuFile技术解析】开源GPU直连存储与Storage-Next如何重构AI数据路径-平芜编程栈

文章目录

NVIDIA cuFile技术解析：开源GPU直连存储与Storage-Next如何重构AI数据路径
- 一、引言
- 二、传统数据路径为什么跟不上GPU
- - 2.1 两条路径
  - 2.2 AI工作负载为何特别需要它
- 三、cuFile开源了什么
- - 3.1 API与底层栈
  - 3.2 微秒级不是固定SLA
- 四、Vera CPU：数据服务不能只靠直通
- 五、Storage-Next与SCADA
- - 5.1 40多家厂商共同定义GPU驱动存储
  - 5.2 SCADA只拉应用需要的数据
- 六、工程落地与横向对比
- - 6.1 采用cuFile前先做四类基准
  - 6.2 与其他I/O路线对比
- 七、总结

NVIDIA cuFile技术解析：开源GPU直连存储与Storage-Next如何重构AI数据路径

一、引言

亲爱的朋友们，创作不容易，若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力，谢谢大家！有问题请私信或联系邮箱：jasonai.fn@gmail.com

AI 系统讨论性能时常盯着 GPU 算力和显存带宽，但训练、检索和 Agent 推理都要不断把数据从存储送到 GPU。传统路径通常由 CPU 发起 I/O，把数据读入主机内存，再复制到 GPU；当成千上万个 GPU 线程同时请求小块数据，CPU 搬运、内存复制、压缩、加密和校验会成为新的瓶颈。

2026 年 8 月 4 日，NVIDIA 在 Future of Memory and Storage（FMS）大会宣布开源 cuFile API 及其下层垂直存储软件栈。cuFile 是 GPUDirect Storage 的组成部分，让 GPU 能直接发起对存储的读写，并将访问延迟压到微秒级。NVIDIA 同时联合 40 多家存储和闪存厂商推出 Storage-Next 计划，试图把 GPU 驱动存储从单一厂商优化扩展为开放、互操作的行业规范。

这次开源的目标不是简单“再快一点读文件”，而是让存储从被动容量层变成 AI 计算数据路径的一部分。

二、传统数据路径为什么跟不上GPU

2.1 两条路径

传统I/O： Storage → NIC/NVMe → CPU内核/驱动 → 主机内存 → CPU发起复制 → GPU显存 GPUDirect Storage / cuFile： Storage → NIC/NVMe ───────────────→ GPU显存 受控DMA与存储软件栈

减少中间复制能降低 CPU 占用和主机内存带宽压力，也缩短尾延迟。但“直连”不是物理上完全绕过 CPU：控制面、权限配置、文件系统、错误处理和安全策略仍有 CPU 与内核参与；优化的是数据面的大块搬运路径。

2.2 AI工作负载为何特别需要它

场景	I/O特征	传统瓶颈
大模型训练	大规模分片、检查点和数据集流入	CPU拷贝占用、GPU等待数据
向量检索/RAG	大量并发随机读取	小I/O与尾延迟放大
长上下文推理	KV/上下文层级溢出到外部存储	内存容量不足、换入延迟
多Agent系统	数千并发工具和数据请求	CPU编排、压缩与加密拥塞
科学计算	GPU直接处理大型文件块	主机内存形成中转瓶颈

当 GPU 可以自己发出数千个并发存储操作，存储系统就需要像并行加速器的上游组件一样设计，而不是只优化单个 CPU 线程顺序读写。

三、cuFile开源了什么

3.1 API与底层栈

cuFile 为应用提供 GPU Buffer 与文件之间的读写接口，属于 NVIDIA GPUDirect Storage。开源 API 及其下层软件栈意味着存储厂商和开发者可以查看、贡献并适配实现，而不只在封闭二进制接口外做插件。

// 概念示例，具体参数与错误处理以官方API为准CUfileHandle_t handle;void*gpu_buffer;cudaMalloc(&gpu_buffer,bytes);cuFileHandleRegister(&handle,&handle_desc);cuFileBufRegister(gpu_buffer,bytes,0);ssize_tn=cuFileRead(handle,gpu_buffer,bytes,file_offset,0);cuFileBufDeregister(gpu_buffer);cuFileHandleDeregister(handle);cudaFree(gpu_buffer);

应用仍需注册文件句柄与 GPU 缓冲区，检查对齐、返回值和兼容路径。硬件或文件系统不支持直通时，生产程序必须有回退和可观测性，避免性能悄悄退化却无人发现。

3.2 微秒级不是固定SLA

NVIDIA 表示 cuFile 利用大量 GPU 线程、高带宽显存等方法，使存储访问达到微秒级。这个表述描述技术路径与典型能力，不代表任意网络存储、任意文件大小或拥塞状态都能保证同一延迟。介质、拓扑、文件系统、队列深度、I/O 大小和加密都会影响结果。

四、Vera CPU：数据服务不能只靠直通

GPU 直读存储之前或之后，数据仍可能需要压缩、解压、加密、校验和重构。NVIDIA 博客披露，Vera CPU 在两阶段压缩与加密流水线中，吞吐最高达到 x86 CPU 的 3.21 倍。该数字来自 NVIDIA 展示的特定基准，应按“最高、特定流水线”理解，不应外推到所有 CPU 工作负载。

GPU请求 │ ▼ 存储数据 ─► 压缩/解压 ─► 加密/解密 ─► 校验/重构 ─► GPU显存 Vera CPU / BlueField / 存储处理器协同

cuFile 缩短数据搬运，Vera/BlueField 处理数据服务，Spectrum-X 承担网络，SCADA 管理规模化加速数据访问。NVIDIA 的策略是全路径协同，而非让某一个 API 独自解决所有存储瓶颈。

五、Storage-Next与SCADA

5.1 40多家厂商共同定义GPU驱动存储

Storage-Next 汇集存储厂商、控制器供应商、散热与冷却、编排方和标准组织，目标是让 GPU 驱动存储行为形成互操作、开放标准。NVIDIA 博客列举 DDN、KIOXIA、Micron 等参与者，整体超过 40 家。

参与方	需要共同解决的问题
存储/闪存厂商	并发队列、介质延迟、故障语义
控制器厂商	DMA、隔离、数据服务卸载
网络厂商	大规模东西向流量与拥塞控制
编排平台	资源发现、拓扑感知和QoS
安全/标准组织	权限、审计、接口与互操作规范

5.2 SCADA只拉应用需要的数据

NVIDIA 提出的 SCADA（Scaled, Accelerated Data Access）框架让大规模并行 GPU 从存储中只读取应用所需数据，直接进入高速显存。它把控制面与高速用户路径分离：特权组件在初始化时配置受保护访问，应用的数据面保持高吞吐，但不因此获得任意读写其他进程内存的能力。

这点很重要。直通若缺少隔离，会把性能特性变成安全漏洞。开放 API 的成熟度最终取决于权限、地址验证、租户隔离、审计和撤销是否与速度一样可靠。

六、工程落地与横向对比

6.1 采用cuFile前先做四类基准

测试	至少记录
吞吐	顺序/随机、不同块大小、队列深度
延迟	P50/P95/P99，不只看平均值
资源	GPU利用率、CPU占用、主机内存带宽
可靠性	回退路径、短读写、设备错误、重试与数据校验

对照组A：pread → pinned host memory → cudaMemcpyAsync 实验组B：cuFileRead → GPU buffer 保持文件、块大小、队列深度、缓存状态和校验方式一致， 同时比较端到端任务时间，而不只比较裸I/O带宽。

6.2 与其他I/O路线对比

路线	优势	适用场景	局限
POSIX I/O+主机拷贝	兼容性最好、调试成熟	通用应用与中小吞吐	CPU和内存中转开销
mmap/页缓存	编程简单、复用系统缓存	CPU访问和混合工作负载	GPU仍需迁移，行为受页缓存影响
io_uring+异步拷贝	高效CPU异步I/O	需要广泛Linux兼容	数据仍经主机路径
cuFile/GPUDirect Storage	GPU直达、降低CPU搬运、并发高	AI训练、检索、科学计算	对硬件、驱动、文件系统和拓扑有要求

cuFile 不会让所有工作负载都更快。小文件元数据密集、预处理严重依赖 CPU、数据能完全缓存于内存，或 GPU 计算本身已是瓶颈时，传统路径可能更简单。

七、总结

维度	核心结论
开源内容	NVIDIA开源cuFile API及底层存储软件栈，扩展GPUDirect Storage互操作性
数据路径	GPU可直接向存储读写，减少CPU和主机内存的数据搬运
性能口径	官方称访问可达微秒级；Vera CPU特定两阶段流水线最高为x86的3.21倍
行业协作	Storage-Next联合40多家厂商，推动GPU驱动存储的开放标准
安全边界	直通数据面仍需特权控制面、隔离、审计和可靠回退，不能绕过权限