文章目录NVIDIA cuFile技术解析开源GPU直连存储与Storage-Next如何重构AI数据路径一、引言二、传统数据路径为什么跟不上GPU2.1 两条路径2.2 AI工作负载为何特别需要它三、cuFile开源了什么3.1 API与底层栈3.2 微秒级不是固定SLA四、Vera CPU数据服务不能只靠直通五、Storage-Next与SCADA5.1 40多家厂商共同定义GPU驱动存储5.2 SCADA只拉应用需要的数据六、工程落地与横向对比6.1 采用cuFile前先做四类基准6.2 与其他I/O路线对比七、总结NVIDIA cuFile技术解析开源GPU直连存储与Storage-Next如何重构AI数据路径一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.comAI 系统讨论性能时常盯着 GPU 算力和显存带宽但训练、检索和 Agent 推理都要不断把数据从存储送到 GPU。传统路径通常由 CPU 发起 I/O把数据读入主机内存再复制到 GPU当成千上万个 GPU 线程同时请求小块数据CPU 搬运、内存复制、压缩、加密和校验会成为新的瓶颈。2026 年 8 月 4 日NVIDIA 在 Future of Memory and StorageFMS大会宣布开源 cuFile API 及其下层垂直存储软件栈。cuFile 是 GPUDirect Storage 的组成部分让 GPU 能直接发起对存储的读写并将访问延迟压到微秒级。NVIDIA 同时联合 40 多家存储和闪存厂商推出 Storage-Next 计划试图把 GPU 驱动存储从单一厂商优化扩展为开放、互操作的行业规范。这次开源的目标不是简单“再快一点读文件”而是让存储从被动容量层变成 AI 计算数据路径的一部分。二、传统数据路径为什么跟不上GPU2.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_tncuFileRead(handle,gpu_buffer,bytes,file_offset,0);cuFileBufDeregister(gpu_buffer);cuFileHandleDeregister(handle);cudaFree(gpu_buffer);应用仍需注册文件句柄与 GPU 缓冲区检查对齐、返回值和兼容路径。硬件或文件系统不支持直通时生产程序必须有回退和可观测性避免性能悄悄退化却无人发现。3.2 微秒级不是固定SLANVIDIA 表示 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与SCADA5.1 40多家厂商共同定义GPU驱动存储Storage-Next 汇集存储厂商、控制器供应商、散热与冷却、编排方和标准组织目标是让 GPU 驱动存储行为形成互操作、开放标准。NVIDIA 博客列举 DDN、KIOXIA、Micron 等参与者整体超过 40 家。参与方需要共同解决的问题存储/闪存厂商并发队列、介质延迟、故障语义控制器厂商DMA、隔离、数据服务卸载网络厂商大规模东西向流量与拥塞控制编排平台资源发现、拓扑感知和QoS安全/标准组织权限、审计、接口与互操作规范5.2 SCADA只拉应用需要的数据NVIDIA 提出的 SCADAScaled, Accelerated Data Access框架让大规模并行 GPU 从存储中只读取应用所需数据直接进入高速显存。它把控制面与高速用户路径分离特权组件在初始化时配置受保护访问应用的数据面保持高吞吐但不因此获得任意读写其他进程内存的能力。这点很重要。直通若缺少隔离会把性能特性变成安全漏洞。开放 API 的成熟度最终取决于权限、地址验证、租户隔离、审计和撤销是否与速度一样可靠。六、工程落地与横向对比6.1 采用cuFile前先做四类基准测试至少记录吞吐顺序/随机、不同块大小、队列深度延迟P50/P95/P99不只看平均值资源GPU利用率、CPU占用、主机内存带宽可靠性回退路径、短读写、设备错误、重试与数据校验对照组Apread → pinned host memory → cudaMemcpyAsync 实验组BcuFileRead → GPU buffer 保持文件、块大小、队列深度、缓存状态和校验方式一致 同时比较端到端任务时间而不只比较裸I/O带宽。6.2 与其他I/O路线对比路线优势适用场景局限POSIX I/O主机拷贝兼容性最好、调试成熟通用应用与中小吞吐CPU和内存中转开销mmap/页缓存编程简单、复用系统缓存CPU访问和混合工作负载GPU仍需迁移行为受页缓存影响io_uring异步拷贝高效CPU异步I/O需要广泛Linux兼容数据仍经主机路径cuFile/GPUDirect StorageGPU直达、降低CPU搬运、并发高AI训练、检索、科学计算对硬件、驱动、文件系统和拓扑有要求cuFile 不会让所有工作负载都更快。小文件元数据密集、预处理严重依赖 CPU、数据能完全缓存于内存或 GPU 计算本身已是瓶颈时传统路径可能更简单。七、总结维度核心结论开源内容NVIDIA开源cuFile API及底层存储软件栈扩展GPUDirect Storage互操作性数据路径GPU可直接向存储读写减少CPU和主机内存的数据搬运性能口径官方称访问可达微秒级Vera CPU特定两阶段流水线最高为x86的3.21倍行业协作Storage-Next联合40多家厂商推动GPU驱动存储的开放标准安全边界直通数据面仍需特权控制面、隔离、审计和可靠回退不能绕过权限cuFile 开源意味着 GPU 直连存储从 NVIDIA 的性能特性向行业公共接口迈进。随着训练数据、Agent 上下文和检索索引远超显存容量未来 AI 系统的性能上限会越来越取决于整条数据路径存储能否及时、并行且安全地把正确数据送到 GPU而不只是 GPU 每秒能做多少次矩阵乘法。参考资料As AI Increases Demands on Memory, Storage Steps Up — NVIDIA BlogNVIDIA GPUDirect Storage文档NVIDIA cuFile API Reference