存算协同：让GPU不再等数据，AI存储性能优化的关键路径

1. GTC 2026 现场观察：GPU 越来越快，存储这头"老黄牛"还好吗

在今年的 NVIDIA GTC 2026 会场，我留出整整一天泡在 AI 基础设施相关的议题里。相比前几年大家围着 GPU 参数看算力翻了多少倍，今年明显多了一个新话题：存储。大会议程里和 AI 数据平台、数据加载、检查点落盘相关的 session 数量翻了不止一倍，展区里做 AI 存储、数据编排、近存储计算的厂商也明显增多。绿算技术就在这个背景下，出现在 GTC 现场，同时在一个小范围的 AI 存储闭门会上分享了存算协同的新进展。

AI 训练任务对存储的需求，早就不只是"够大"那么简单。模型参数动辄千亿万亿，训练集从 TB 级涨到 PB 级，checkpoint 一次写几十 GB 甚至上百 GB，加上多节点并行读取，存储系统如果跟不上，GPU 再便宜也只能干等着。我见过太多客户，训练集群一扩容，瓶颈不出在算力，出在数据搬运上。这背后的核心矛盾，就是计算能力和存储能力的发展节奏严重不匹配。

绿算技术这次讲的东西，没有绕开这个矛盾，而是把重点放在"存算协同"上。所谓存算协同，说得直白点：存储不能只当仓库，要参与到计算任务的数据流动里，和 GPU、CPU 的调度节奏对齐。现场分享的内容，包括分布式存储引擎如何动态分配带宽、如何把数据预取和缓存放到离计算更近的位置、如何通过 RDMA 网络减少 CPU 介入，以及一套面向大模型训练场景的存储观测与调优方法。每个点我都觉得有实际落地价值，不是吹概念的路数。

这篇文章我想把当天听到的内容、看到的技术细节，以及我在现场记录下来的测试过程和一些排障经验整理出来。如果你正在为大模型训练或者科学计算场景选型 AI 存储，或者已经买了存储但在实际业务里跑不出理想性能，这篇文章应该能给你一些直接的参考。内容比较多，我会按思路、技术拆解、实操和问题排查的顺序来讲。

2. 存算协同到底解决什么问题？说人话版本

2.1 GPU 等数据，是当前 AI 训练最大的隐性浪费

先算一笔账。假设一个训练集群有 64 张 GPU，每张 GPU 在 FP8 下的理论算力以千 TFLOPS 计。数据加载阶段，如果存储系统只能提供 2GB/s 的聚合读取带宽，那么即使每张卡每轮训练只需要加载 2GB 数据，也需要 64 秒。而真正的计算可能只需要几秒。这 64 秒里，整卡集群都在空转。一天下来，算力资源的实际利用率可能不到 40%。

很多人会问，多放点内存 cache 不就行了吗？问题在于，模型训练的数据集往往远超单机内存，多机分布式训练中，每个节点的本地缓存只能解决一部分命中问题，而缓存不命中的那一下，恰恰会形成剧烈的 IO 尖峰。一次 checkpoint 落盘如果写入带宽不够，训练进程会直接阻塞。所以存储系统不能只解决容量问题，要解决的是与计算节奏匹配的"流动效率"问题。

建议每一位做训练基础设施的人，都去给自家集群算一笔经济账：GPU 单位时间的成本是多少，因为数据等待而浪费的比例又是多少。一旦把这两个数字量化出来，存储投入的优先级会立刻提升不少。

2.2 存算协同的三个层次

我在现场听到的分享，把存算协同分成了三个层次，这个划分很实用。

第一层是"数据路径的协同"。核心是让数据从存储到 GPU 显存的路径尽量短、尽量直。传统的存储访问路径是：存储节点 -> 网络 -> CPU 内存 -> GPU 显存。中间经过 CPU 拷贝，一方面增加了延迟，另一方面占用了 CPU 资源。采用 NVIDIA GPUDirect Storage（GDS）之后，数据可以绕过 CPU 内存，直接从存储设备经过 RDMA 网络进入 GPU 显存。这个改动对训练加速非常明显，尤其是数据加载密集的场景，CPU 参与率下降，内存带宽压力也随之减轻。

第二层是"调度策略的协同"。存储系统不能只是被动地等计算节点来读，而要主动感知训练任务的阶段。比如在数据加载阶段，预取模块提前把下一轮训练需要的数据推到缓存；在 checkpoint 阶段，存储系统要预留足够的写带宽，避免和其他读请求争抢。绿算技术用了一个很形象的词，叫"按任务阶段做 IO 整形"，就是把无序的 IO 请求梳理成和训练节奏匹配的流量模式。

第三层是"存储内计算的协同"。也就是把一部分重复性高、计算量小的操作下沉到存储节点完成，比如数据解压、格式转换、去重、切片。听起来不大，但在大数据集场景里，每减少一次全量拷贝，都能节省分钟级的时间。尤其现在很多数据集用 WebDataset、TFRecord 这类大文件格式存储，训练前都要做 shuffle、decode、resize，这些操作如果全部塞给训练进程，CPU 负担很重。把其中一部分下沉到存储侧，整体训练吞吐会有可观提升。

这三个层次，不是替代关系，而是叠加关系。做得越完整的方案，越能榨干每一层硬件的性能。

2.3 为什么 GPU 厂商开始重视存储生态

NVIDIA 这几年在存储生态上动作很多，从 Magnum IO 到 GPUDirect Storage，再到 DOCA 框架，其实都在做同一件事：把以 GPU 为中心的加速能力延伸到存储和网络。GTC 2026 现场，存储相关的技术分享明显在往"协同"这个主题上靠，这说明生态已经意识到，单点算力再强，也需要一套能与之匹配的数据基础设施。

从整个 AI 基础设施的演进来看，算力性能每年都在翻倍，但网络带宽和存储带宽的提升幅度远没有这么夸张。这种剪刀差会越来越大。绿算技术在这个节点拿出存算协同的深化方案，方向是对的。AI 存储市场不缺容量型产品，缺的是能让 GPU 集群跑得更满、让用户不再把时间浪费在数据搬运上的协同型产品。这也是我判断这套方案值得写成文章的原因。

3. 绿算技术 AI 存储方案的四个设计要点

3.1 分布式存储引擎：先解决单路径瓶颈

很多存储方案性能上不去，问题出在单客户端数据路径太窄。绿算技术这次分享的分布式存储引擎，核心思路是把一个训练集群的多台计算节点视为一个整体，让每个计算节点的 IO 请求都被虚拟成一条"高吞吐数据管道"，再通过全局元数据服务和数据分布策略，把不同的数据块分散到多个存储节点上并行读写。

听起来很常规，但他们在细节上做了一个我认为很关键的设计：智能数据分片。传统方案按文件切块，容易出现热点文件。绿算的做法是按训练语义来分片，比如一个 TFRecord 大文件，不是简单平均切成 N 块，而是根据每个块的实际访问频率和 GPU 消费速度动态调整分片粒度。这个优化的逻辑是：热门样本被更均匀地分散到更多存储节点上，避免某个节点成为"堵点"。

现场讲到的一个数据我记得比较清楚：在 8 个存储节点、双 100GbE 网络、100Gbps RoCE 的环境下，聚合读带宽能跑到接近 7.6GB/s。这个数字不算极端夸张，但在多客户端并发的真实训练场景里，已经是比较健康的水平。背后的关键是数据分布是否均匀、网络是否无拥塞，这在第四章会展开。

3.2 数据亲和性调度：让数据尽量在"隔壁"

存算协同的核心思想，其实就一句话：数据在哪用，就尽量把相关计算调度到哪。反过来，存储也必须知道哪些计算节点在用哪些数据。

绿算技术在这块做了一个"数据亲和性调度器"，它维护了一张全局的数据分布映射表，训练框架每次下发任务时，调度器会优先把任务分给离数据副本最近的 GPU 节点。同时在存储侧，如果发现某个数据集将被某个节点的高优先级任务读取，它会提前把数据副本迁移到该节点所在机柜的存储节点上。

这个设计最直接的收益是减少了跨机柜流量。大模型训练集群动辄几十个机柜，跨机柜带宽往往只有机柜内带宽的一半甚至更低。把数据流量尽量收敛在机柜内部，能明显降低整个集群的拥塞概率，实测中端到端训练吞吐能提高 15% 到 30%，具体收益取决于任务对数据的访问模式。

这里也需要提醒一句：数据亲和性调度依赖全局元数据服务的稳定，如果元数据服务变成单点，整个集群的调度可能都要停摆。好在绿算的架构里元数据服务本身做了多副本，这部分工程成熟度是过关的。

3.3 缓存与预取：用"空间换时间"要讲究策略

缓存是存储系统中最容易被忽略但也最容易翻车的部分。很多方案一上来就是全局 LRU，结果热点数据反复被挤掉，冷数据又占着空间。绿算的做法是分两层：一层是计算节点上的用户态缓存，负责吸收短时间内的重复访问；另一层是存储节点上的共享缓存，负责存储全局热数据。两层之间通过 RDMA 做高速同步，避免出现缓存不一致。

预取策略也很有意思。它不是简单的"读 A 时顺便读 A+1"，而是会结合数据集里的样本顺序和训练框架的 epoch 循环模式，动态算出下一步最可能被读取的数据块。比如模型在一个 epoch 内会按顺序扫过整个数据集，预取模块就能精确知道下一批要读哪个范围内的样本，提前把数据从冷存储层拉到热缓存层。这个功能在断点续训场景下特别有用，恢复训练时需要重新加载海量数据，如果预取逻辑够聪明，恢复时间能从小时级压到分钟级。

我自己的经验是，缓存和预取策略的调参，是上线后最需要耐心的一步。命中率不是越高越好，因为缓存空间有限，过度追求命中率可能导致预取行为过于激进，反倒把关键数据的带宽挤掉。建议以训练任务实际耗时为基准，小步调整，观察至少两到三个完整的 epoch 再下结论。

3.4 全局视角的观测与调优：看不到就无法优化

这次闭门会我最喜欢的部分，是绿算讲的"存储观测"——如何把存储性能指标和训练任务指标关联起来看。他们做了一个轻量的监控面板，可以直接展示 GPU 利用率、存储带宽、IO 延迟、队列深度这几个指标在时间轴上的对应关系。

不要小看这个功能。过去排查训练性能问题，经常是训练团队说是存储慢，存储团队说是计算卡住，两边扯皮。有了统一的观测面板，一眼就能看出到底是 GPU 在等待数据，还是存储系统在等待计算侧释放连接。这类可观测性建设，应该成为任何 AI 存储方案的标配。

另外，他们还在面板上设计了一个"IO 延迟分布直方图"，不是只给平均值，而是把 p50、p99、p99.9 的延迟都画出来。平均值好看没意义，p99 拉胯才要命。这一点我在第五章的问题排查里还会详细讲。如果你自己做可观测系统，强烈建议也加上这类分位数视图，不要只关注平均时延。

3.5 选型决策里容易被低估的三个维度

在闭门会的问答环节，有人问了一个很实际的问题：如果我现在只有一套传统 NAS，该怎么向这种协同型存储迁移？绿算技术的回答我总结下来有三点坐标。

第一是"API 兼容性"。新存储能不能无缝接入现有训练框架。如果可以兼容 POSIX 语义，同时提供 S3 兼容接口，迁移成本就低很多。绿算方案里同时支持这两类接口，训练侧通常只需要改挂载路径，不需要改代码。

第二是"性能隔离"。多租户共享一套存储时，一个任务满载是否会拖垮另一个任务的延迟。这一点相当考验存储底层 QoS 能力，而很多产品宣传里都不会写。建议测试时专门开两个任务，一个打满带宽，另一个压时延，看相互影响程度。

第三是"运维友好度"。存储集群升级、节点故障替换、坏盘处理，这些日常运维动作是否足够简单。现场有人问热替换一块 NVMe SSD 需要什么操作，回答是"拔盘后系统自动重建数据，默认 30 分钟内完成重平衡"，这个响应速度在训练集群里能避免很多尴尬的空窗期。

4. 闭门会实操环节还原：从测试环境到性能压测

4.1 测试环境的搭建思路

闭门会现场，绿算技术搭了一套 4 节点的测试环境。配置大概是：每个存储节点 2 块 NVMe SSD，单节点 64GB 内存，网卡是双口 100Gbps RoCE，搭配一台支持 RoCE 的交换机。训练侧是两台 GPU 服务器，每台 4 张 A100，通过同一条 RoCE 网络连接。

搭建的时候有一个细节值得提：RoCE 网络必须开启 PFC（优先级流控）和 ECN（显式拥塞通知），否则高并发场景下丢包率会上升，RDMA 性能直接崩掉。这里我现场问了一下他们的配置，用的是 DCQCN 拥塞控制算法，能有效缓解多流并发时的撞车。如果你是自己搭测试环境，建议优先确认交换机端是否开启无损以太网配置。

我整理了一份适用于大多数 AI 存储测试的网络配置检查项：

• 交换机端口开启 PFC，并为 RoCE 流量设置独立优先级队列
• 开启 ECN，并设置合理的阈值，避免缓冲区堆积
• 服务器网卡支持 RoCEv2，并安装相应驱动和固件
• 确认 MTU 是否为 9000 字节，巨型帧对吞吐影响非常明显
• 多网卡时，确认路由和 ARP 配置是否会把流量均匀分散到多张网卡

4.2 性能压测过程还原

再说回现场测试。测试分成三组：第一组是纯带宽测试，用 fio 模拟大块顺序读；第二组是模拟训练数据加载，用一个小工具并发读 TFRecord 文件集合；第三组是端到端测试，直接跑一个公开的图像分类训练脚本，对比存储方案优化前和优化后的 GPU 利用率。

先说 fio 的结果。单客户端随机读 4K 块，IOPS 大概在 18 万左右，时延 p99 在 420 微秒上下。这个数据单看不算惊艳，但重要的是 4 个客户端并发时，聚合 IOPS 能接近 65 万，扩展性方面做得比较线性，没有出现并发一上来就互相挤兑的情况。

第二组测试更贴近真实训练。他们用一个 200GB 的 TFRecord 数据集模拟多节点并发读取，结果聚合带宽大约 6.8GB/s，训练脚本里的平均数据加载时间是 22 秒。同样的硬件和网络，如果走传统 NFS 方案，同样数据量加载时间要 47 秒左右。这个差距就是 RDMA 直通和智能预取带来的。

第三组端到端训练测试更有说服力。一个常规 ResNet-50 训练任务，在优化前 GPU 的平均利用率大约 62%，优化后提高到 87%。现场他们把时间轴拉平展示，能看到优化前 GPU 利用率曲线有大量波谷，优化后曲线明显平稳。这个波谷出现的位置，往往就是数据加载和 checkpoint 落盘的时刻。这个对比非常直观，也是我拿回来给团队做内部培训最好的素材。

4.3 现场记录的两条关键心得

第一，测试结果要在"多客户端并发"下看。单客户端性能漂亮不代表整个集群能跑满，很多存储方案单机数据路径做得好，但网络层打不平。绿算这次演示的并发扩展性，让我印象比较深。

第二，性能压测一定要模拟 checkpoint。相当多训练任务不是死在数据加载，而是死在 checkpoint 落盘那一刻。存储方案如果没有为写放大做好缓冲，一次同步写就能把 IO 延迟拉到毫秒级，训练任务直接卡住。绿算这次演示中专门模拟了每 5 分钟一次、每次 40GB 的 checkpoint 写入场景，整个训练流程没有出现明显阻塞。这个场景设计，我觉得是所有 AI 存储选型测试里都应该加上的。

如果你也想复现类似测试，现场有一个很实用的命令模板：用 fio 做多客户端读取时，建议使用 --group_reporting 聚合统计，而不是分别看每个客户端输出。另外，--ramp_time 要留够，通常 60 秒以上，让系统充分预热后再记录数据，否则前几秒的冷启动数据会拉低平均值，误导判断。

5. 我在现场记下的排障与避坑清单

5.1 为什么训练任务总是卡在"数据加载 99%"

这是现场提问环节问得最多的问题。原因通常是：存储聚合带宽和训练节点的消费速度不匹配，或者数据文件碎片化严重，导致 IOPS 不够。解决方法分几步走：

先看存储侧是否有热点。如果所有训练节点都在读同一份数据集，存储节点的负载会很不均衡。解决办法是把数据集复制多份，分散到不同存储节点，再通过数据亲和性调度让节点就近读取。

再看网络侧是否有拥塞。RoCE 网络最怕丢包，丢包率超过 0.1%，RDMA 吞吐可能掉一半以上。可以在交换机和网卡上看 PFC 暂停帧计数，如果暂停帧数量异常高，说明存在拥塞，需要调整缓存分配或启用 ECN。

最后看缓存命中率。如果预取逻辑没生效，每个 epoch 都会有大量冷读。按绿算现场的排查经验，正常训练场景下热数据命中率应该维持在 80% 以上，低于这个值就说明预取参数或者数据集分片方式有问题。

5.2 GPU 利用率上不去，先别怪代码

很多团队一看到 GPU 利用率低，就想着优化训练代码，其实大概率是数据管道的问题。我整理了一个简单的排查表格，按优先级排：

这个表格我建议直接贴到工位边上，每次遇到"GPU 利用率诡异"的问题，按这个顺序查，通常能在十分钟内定位问题，而不是在代码里瞎调一天。

5.3 并发读写冲突与一致性开销

训练场景里最常见的存储一致性问题是 checkpoint 写入和数据读取同时发生。存储系统为了保证一致性，会加锁，加锁就会增加延迟。很多方案在低并发时正常，一旦多节点同时写 checkpoint，锁竞争能直接把性能打崩。

绿算在闭门会上分享了一个做法：把 checkpoint 写入和训练数据读取走不同的存储路径，写操作走独立的元数据服务和日志，读操作走数据缓存层。这样即使写操作短暂卡顿，也不会影响读路径的带宽。听起来像是架构层面的小改动，但实际工程里能把并发冲突概率降低很多。

另外，如果要用对象存储协议挂载数据集，建议把小文件先合并成大文件。比如把几万张小图打包成几个大的 WebDataset 分片，访问效率会提升一个量级。原因很简单，对象存储对小对象操作的额外开销很高，一次 GET 请求从建立连接到返回数据，可能有几毫秒的固定成本，训练时几万个样本就会带来几万次请求，这就是肉眼可见的等待时间。

5.4 断点续训恢复特别慢怎么办

这个问题在现场也被反复问到。大模型训练中断后重启，往往要重新加载几十 TB 的数据，如果存储侧没有预取和恢复优化，这个过程可能长达一两个小时。

绿算的解法是把断点续训涉及的数据访问模式单独记录下来，做成一份"恢复清单"。下次训练启动时，直接按清单优先级预取数据，而不是等训练框架按照普通 epoch 顺序重新扫描一遍。实际效果是，他们在演示环境里，断点恢复时间从最初的 37 分钟压到了 6 分钟左右。这个优化思路，也适合其他存储产品参考：凡是涉及重复性、可预测的数据访问，都可以通过预取来大幅缩短恢复时间。

6. 关于这场活动，我想单独说说的几个信号

整场闭门会大概两个小时，还有一个问答环节。我看下来，最深的感受是：存储技术正在从"后台基础设施"走向"训练效率的关键变量"，而存算协同也从概念，逐渐有了可以量化、可以复现的落地方式。

绿算技术这次分享的内容不算花哨，没有讲什么颠覆性的大词，重点落在数据路径优化、任务感知调度、可观测性建设这些工程层的事情上。这些恰恰是现阶段 AI 基础设施最需要补的课。我在会后和几个同行交流，大家一致的看法是：GPU 集群要真正体现投入产出，存储和网络的协同优化是绕不开的一环。

如果让我给正在做 AI 基础设施选型的朋友提一个具体建议：不要把"存储性能"当成一个静态指标来买，要当成一个动态的协同能力来测。测的时候，一定要覆盖多客户端并发、checkpoint 落盘、任务断点恢复这几个真实场景。只要这几个场景能扛住，你买的这套存储大概率能陪你顺利跑完多个训练周期。

我在现场还注意到一个小细节：绿算技术把整套方案的观测面板开源演示了，闭门会结束后很多人围过去问接口文档。这种把可观测性和存储引擎打通的做法，未来大概率会成为行业标配。我自己的项目里也准备在下一轮存储优化中，优先把"性能-任务关联分析"这块补上，毕竟数据都看不清楚，优化就无从谈起。

这次 GTC 2026 的存储议题方向，确实比往年更实。希望接下来能看到更多厂商在"协同"这个维度上做出真东西，而不是继续在容量和单点性能上打转。