你的GPU正在挨饿。
这不是一个比喻。在一座典型的AI数据中心里，价值数万美元的H100 GPU，有相当比例的时间并没有在计算。它们在等待，等待数据从NVMe SSD穿过CPU、穿过系统内存、穿过PCIe总线，最终抵达显存。这条路径上的每一站都是一道减速带。当模型参数以TB计量、推理上下文窗口膨胀到百万Token级别时，GPU的饥饿感正变得越发严重。
2026年8月4日，在圣克拉拉举办的未来内存与存储大会（FMS）上，英伟达给出了它的解决方案：开源cuFile API及底层存储软件栈，让GPU可以绕过CPU，直接读写NVMe SSD。同时，它还拉来了Google、Intel和Meta作为首批维护者，以及40多家存储厂商站队到一个名为Storage-Next的新倡议之下。
两个动作，一个信号
英伟达在FMS 2026上同时做了两件事。
第一件：将cuFile API及整个底层存储软件栈开源，托管到xio-sig（Accelerated IO Special Interest Group）的GitHub组织下，首批维护者名单包括Google、Intel、Meta和英伟达自己。cuFile是英伟达GPUDirect Storage（GDS）技术的核心组件，最早于2021年7月随CUDA Toolkit 11.4发布。它提供了一条从存储设备到GPU内存的直接DMA通道，数据搬运不再需要经过CPU和系统主内存。根据英伟达官方博客，cuFile可以实现微秒级的数据访问。
第二件：发起Storage-Next倡议，联合超过40家存储与闪存厂商，包括DDN、KIOXIA和美光，共同推动下一代AI存储技术的标准化。同时发布的还有SCADA（Scaled, Accelerated Data Access）框架，让大规模并行GPU能够直接从存储中拉取应用程序所需的数据，而不是被动等待CPU的调度。
AI的成功将不再由组织拥有多少基础设施来定义，而是由它们如何高效地使用这些基础设施。
——DDN首席技术官Sven Oehme
这两件事发生在8月1日至6日于拉斯维加斯举行的黑帽大会同期。一个在圣克拉拉宣布开源，一个在拉斯维加斯讨论安全。GPU直连存储的技术路线和它带来的攻击面，在同一周内被摆上了台面。
同行者比技术更重要
cuFile的开源本身当然重要，但更值得关注的是谁坐在了牌桌上。
Google有TPU，Intel有Gaudi加速器，Meta有自研的MTIA芯片。这三家都是英伟达在AI芯片领域的直接或潜在竞争对手，但他们同时出现在xio-sig的首批维护者名单上。这意味着什么？在AI数据中心里，GPU是英伟达的，这一点短期内无法改变。与其另起炉灶做一个没人用的标准，不如加入英伟达的生态，至少能在标准制定过程中保留发言权。
另一边，Storage-Next的40家参与方覆盖了从闪存颗粒（KIOXIA、美光）到存储系统（DDN），再到控制器、散热、编排和标准组织。整条存储产业链的每个环节都有人坐在谈判桌前。存储厂商正在用脚投票。
GPU饥饿的根源
要理解cuFile开源的意义，先要理解GPU饥饿是怎么发生的。
AI推理和训练的工作流中，GPU需要不断从存储中读取模型权重和数据集。在传统架构下，数据路径漫长而曲折。NVMe SSD首先把数据送到CPU系统内存中的bounce buffer，再拷贝到GPU显存。每一步都涉及一次数据拷贝和一次CPU中断处理。当模型规模达到数百GB、推理并发请求数以千计时，这条路径就成了整个系统的短板。
一组数据可以说明问题。一台8卡H100 SXM服务器，在FP8精度下的理论算力约为32 PFLOPS，但数据从NVMe存储灌入显存的实测带宽仅为7-14 GB/s，取决于PCIe代际和SSD配置。GPU的计算能力与存储的供给能力之间存在数个数量级的差距。
更致命的是在大规模训练场景中。一个70B参数量的BF16检查点大约是140GB。通过传统CPU路径，每保存一次检查点需要4-5分钟。如果一次训练任务需要保存1000次检查点，光等待I/O就浪费67-80小时的GPU时间。按每块H100按需价格4.06美元/小时计算，8卡节点仅在检查点I/O上的浪费就超过2100美元。
cuFile的解决思路极其直接：砍掉路径上的所有中间站。数据路径变成NVMe SSD到PCIe总线再到GPU HBM。CPU不参与，系统内存不参与，内核拷贝不参与。这就是GPUDirect Storage的核心，DMA引擎直接将数据从存储设备搬进GPU显存。英伟达官方博客引用的一项基准测试显示，在两级压缩加密流水线场景下，搭配Vera CPU的存储平台吞吐量可达x86 CPU的3.21倍。
开源是最高明的封闭
在英伟达的商业工具箱里，开源从来不是慈善。CUDA就是最好的例子。英伟达开放了CUDA的编程接口和工具链，但底层硬件牢牢握在自己手里。结果就是，CUDA成了GPU计算的事实标准，开发者被绑定在英伟达的生态里，竞争对手追赶了十几年依然难以撼动。
cuFile的故事几乎如出一辙。
cuFile的技术并不新，它已经存在了5年。但此前它是英伟达的专有API，只有使用了英伟达认证存储方案的客户才能充分利用。现在开源，意味着任何存储厂商甚至英伟达的竞争对手都可以在自己的产品中集成cuFile。但请注意：cuFile的底层依赖nvidia-fs内核模块，这个模块只兼容英伟达的GPU。你可以用cuFile的API来开发存储系统，但底层跑的依然是英伟达的硬件。
这就像开了一家开放餐厅，所有菜谱都是公开的，但所有食材必须从你这里买。
Google、Intel和Meta的加入，从侧面印证了这个逻辑。他们不是被逼的，而是算过账的。在AI数据中心里，GPU绝大多数是英伟达的。与其花几年时间推一个无法撼动CUDA生态的替代标准，不如加入这个标准，在内部影响它的走向。
存储厂商的选边站时刻
Storage-Next的40家厂商，相当于在英伟达的旗帜下完成了一次集体站队。
这对存储行业意味着什么？过去几十年，存储系统的设计逻辑一直是CPU优先。存储控制器、文件系统、I/O调度器都围绕CPU的指令集和中断机制构建。GPU在存储架构中几乎没有存在感，它只是一个被动的数据消费者。
但AI正在改变这个格局。AI工作负载的I/O模式与传统数据库或文件服务器完全不同。它需要大规模并行读取、高带宽流式传输、对延迟极度敏感。传统的存储架构是为OLTP和文件共享设计的，不是为GPU设计的。
英伟达的开源动作加上Storage-Next倡议，本质上是在推动存储行业从CPU存储范式切换到GPU存储范式。存储厂商必须做出选择。要么适配英伟达的标准，在GPU驱动的存储生态中分一杯羹；要么继续做传统存储，在AI数据中心里越来越边缘化。
对于DDN、VAST Data、WEKA这类AI原生存储厂商，这是一个好消息，他们已经在适配GDS和cuFile的路上走了很远。对于传统存储巨头，这是压力信号。如果不尽快兼容cuFile，他们的产品在AI数据中心采购清单上的位置会越来越靠后。
没有银弹
cuFile和GPUDirect Storage并非万能。英伟达官方文档明确指出了几个限制。
cuFile适合粗粒度的流式传输，不适合细粒度的随机访问。这意味着它更适合大模型推理中的权重加载和训练中的检查点读写，但不太适合需要频繁小文件随机读写的场景。
cuFile的DMA直连路径绕过了CPU的权限控制和安全检查。虽然英伟达推出了SCADA框架来应对安全挑战，但让GPU直接操作存储设备的底层数据，确实引入了新的攻击面。在同期举行的黑帽大会上，安全研究人员对GPU直连存储的安全风险有大量讨论。当GPU可以绕过操作系统直接访问存储设备时，传统的安全模型就需要重新设计。
生态迁移需要时间。存储厂商需要重新设计自己的软件栈来适配cuFile，这不是一个周末就能完成的工作。即使标准已经开源，从兼容cuFile到真正优化到微秒级延迟之间，还有很长的路要走。
英伟达的存储拼图
英伟达正在执行一个日益清晰的逻辑闭环。GPU是AI计算的引擎，引擎需要燃料，燃料就是数据。燃料的输送管道不能成为瓶颈，所以英伟达必须控制管道。
从计算（CUDA/GPGPU），到网络（NVLink/Spectrum-X/Mellanox），再到存储（cuFile/Storage-Next），英伟达正在完成AI基础设施的全栈闭环。对于一家市值超过3万亿美元的公司来说，单独卖GPU已经不够了。它需要确保整个AI数据中心的技术栈都基于英伟达的标准运转。
存储行业的CUDA时刻已经到来。就像当年CUDA将GPU从图形卡变成通用计算设备一样，cuFile正在将GPU从被动的计算者变成主动的存储掌控者。而这一次，40家厂商已经签下了名字。
对于AI从业者和企业决策者，接下来的问题不是要不要用cuFile，而是你的存储基础设施，准备好被GPU直接调用了吗？
英伟达卖的不是GPU，而是AI基础设施的语法。cuFile是这本语法书里最新的一章，关于存储应该如何被GPU阅读的规则。
快报