刚参加完NVIDIA GTC 2026本来想写点会场见闻但看了绿算技术在AI存储闭门会上分享的存算协同方案我觉得这个方向值得单独拆开聊聊。GTC上GPU新品一大把但真正让我觉得有实用价值的反而是这种解决“数据喂不饱算力”的基础设施话题。如果你正在做大模型训练平台的性能调优或者准备给AI集群选型存储方案这篇应该能给你一些可以直接用的思路。先说一下背景过去两年大家猛堆GPU算力规模翻了几番但训练集群的存储系统还普遍停留在“大容量共享盘”的定位上。结果就是GPU空转率居高不下checkpoint写半天数据加载慢得让人抓狂。绿算这次讲的核心思路是把存储从被动提供空间的角色变成主动感知计算节奏的参与者。这中间涉及的不只是存储本身还有网络、驱动、缓存策略、调度机制的一整套联动。我结合自己帮客户调优训练集群的经验把这些技术点拆开讲透。1. 存算协同为什么会成为GTC 2026的显性话题1.1 算力越大存储越拖后腿先说一个很多人忽视的事实大模型训练是典型的I/O密集型超算负载而不是单纯的计算密集型负载。单看GPU的FLOPS很吓人但整个训练流程里GPU真正跑数学运算的时间往往不到一半。其余时间花在哪花在等数据。数据加载阶段每个GPU每步训练要读取一批样本这批样本可能是图片、文本向量、或者多模态特征数据量从几MB到几百MB不等。如果DataLoader来不及供数GPU就空在那等。更麻烦的是checkpoint训练几小时甚至几十小时后为了防止故障丢进度要把模型权重、优化器状态、学习率调度状态全部落盘。一张千卡规模的集群做一次checkpoint数据量轻松上TB级。如果存储写性能跟不上一次checkpoint就要卡住整个集群几分钟甚至更久训练效率的损失是肉眼可见的。还有一个常被忽略的点训练样本集的数据分布是动态变化的。做数据清洗、做难例挖掘、做强化学习的数据采集都会频繁往训练集里灌新数据。传统的存储系统按静态目录管理数据完全没有感知“计算节点现在需要什么”的能力数据放在哪、怎么过去、走哪条路径全凭运气。这些问题叠加在一起就成了算力扩展的隐形天花板。1.2 “存算分离”之后我们又回头谈“协同”前几年行业的主流叙事是“存算分离”因为算力扩缩容和存储扩缩容的节奏不一样拆开才能各自弹性。这个逻辑没错但走了极端之后大家发现新问题数据从存储到GPU的路径变长了而且每一跳都有开销。我做一个不太严谨但很直观的类比存算一体像楼下便利店东西就在手边拿得快但种类有限存算分离像大型仓库什么都有但要叫货车配送路上要花时间和运费。存算协同想做的是在仓库和便利店之间建一套智能调度系统让你常用的东西提前放到寄存柜里不常用的东西走优化路线送过来。所以“协同”不是要否定存算分离而是在分离架构之上解决数据流动效率的问题。核心思路可以概括为三点让存储感知计算的访问模式、让数据走最短路径到显存、让缓存和调度策略随训练阶段动态变化。绿算这次分享的落地路径基本就是围绕这三点展开的。1.3 绿算技术这次方案的核心看点说实话单看存储产品的参数表各家差距已经很小了无非就是带宽多少GB/s、IOPS多少万。绿算这次讲的不是单个指标而是“链路协同”第一数据路径上接入了GPU Direct StorageGDS让数据从远端存储通过RDMA网络直接进GPU显存绕开CPU内存中转和GPU驱动层的多次拷贝。这一步对减少延迟和节省CPU开销非常关键。第二缓存管理从静态分块变成了动态预取。它会分析训练任务当前处于什么阶段是稳定地顺序读样本还是突然要写一个大checkpoint然后动态调整缓存策略。第三存储侧开始理解训练Job的调度语义能根据训练阶段动态调整QoS策略。比如加载阶段提高读带宽的优先级checkpoint阶段集中资源保写带宽训练阶段则把资源释放给正常的数据流。这些放在一起效果就不是单点性能的提升而是端到端训练效率的改善。GTC闭门会上有个数据我印象比较深他们在一套千卡集群的模拟环境中测试启用这套协同优化后端到端训练效率提升了大概20%到30%主要节省在checkpoint时间缩短和数据加载等待减少上。这个幅度在AI基础设施领域已经是质变了。2. 存算协同的关键技术细节拆解2.1 数据路径三关卡从存储到显存要走对路先梳理一下GPU读取远端存储数据要经过哪些环节。传统路径是存储节点通过RDMA把数据发给计算节点的网卡网卡DMA到CPU内存CPU再从内存拷贝到GPU显存。这一路有两次内存拷贝每次都消耗CPU资源而且PCIe带宽被反复占用。GDS做的事情是把网卡收到的数据直接通过PCIe Peer-to-Peer写进GPU显存。省掉了CPU中转延迟能降一个数量级CPU占用也大幅下降。听着很完美但落地有不少坑网卡必须支持RDMA而且是RoCE或者InfiniBand千兆以太网洗洗睡。GPU、网卡、NVMe控制器的PCIe拓扑要能支持P2P传输有些主板上P2P链路带宽受限反而不如传统路径快。驱动版本要匹配。NVIDIA的驱动、CUDA版本、MOFEDNVIDIA网络驱动版本不对GDS根本起不来。访问模式要适合GDS大块顺序读效果最好小IO随机读的提升有限。我见过最典型的翻车案例某团队把GDS打开后性能反而暴跌查了半天发现是PCIe switch的带宽配置问题几块GPU共享一根x8链路P2P数据把链路彻底堵死。所以做GDS优化之前必须先把硬件拓扑摸清楚用nvidia-smi topo -m看每一对GPU和网卡的互联关系再决定数据路径怎么走。从实操角度绿算的做法是把GDS作为默认路径同时保留降级开关。如果检测到P2P链路带宽不足自动切回传统路径避免性能抖动。这个设计思路很值得借鉴别死磕单一技术要留退路。2.2 缓存不是“加一层”那么简单很多存储系统喜欢堆缓存内存池、NVMe缓存池、分层存储一层又一层。但缓存加多了命中率没上来反而增加了数据一致性维护的复杂度。存算协同里的缓存设计核心是“知道接下来会发生什么”。训练样本的读取有很强的规律性。DataLoader通常按顺序遍历数据集或者按固定随机种子做shuffle这意味着存储端可以提前预判下一批数据请求。这时候用预取算法把即将被读取的数据提前从大容量HDD或云端对象存储搬到本地NVMe缓存就能显著降低请求延迟。checkpoint的场景则相反是一大批数据突然涌入需要把写缓冲区和后端下刷节奏做配合。如果写缓存太小checkpoint数据会直接压到后端磁盘速度上不去如果写缓存太大数据滞留在内存里系统一断电就全没了。绿算在缓存这块的思路是“场景感知的缓存分区”。它会根据当前训练阶段动态划分缓存区域数据加载阶段读缓存占比拉高写缓存压缩checkpoint阶段反过来。这个策略本身的逻辑并不复杂但关键在于“感知训练阶段”这一步需要在存储层和应用层之间建立一套轻量的通信机制让存储知道当前任务的推进情况。如果你自己搭类似系统可以用一个比较轻的实现让训练平台在启动任务时打一个标签存储系统按标签关联缓存策略。用Kubernetes的话可以在Pod的annotation里带上任务阶段信息通过CSI或存储插件透传给存储端。具体接口各家存储厂商不一样但大体思路是一致的。2.3 调度语义存储层能不能看懂训练节奏第三个技术点是存储层对训练任务调度语义的感知。传统存储不会去区分“用户是谁”只看到一堆块和文件的读写请求。但在AI训练集群里存储服务面对的是GPU job的潮汐式访问需求是有明显波动规律的。一个训练任务的生命周期大致分四段初始化阶段会从数据集读取初始化配置和权重这部分IO量小但延迟敏感数据加载阶段是持续的顺序大读带宽要求高计算阶段IO压力反而下降但如果开启异步数据加载还是会保持相对稳定的读取checkpoint阶段则是爆发式写入带宽要求是平时的几倍甚至十几倍。如果存储QoS是静态的就必须按峰值需求来配置平时浪费资源不说高峰期还可能照样打不满。绿算这次讲的动态QoS就是把存储资源池按“租户任务阶段”两个维度做动态分配。比如两个训练任务同时跑一个在加载数据、一个在写checkpoint存储调度器会识别出两边的需求差异给checkpoint阶段的任务临时让出更多写带宽等它写完了再收回。这套机制做得好不好关键看两点一是状态感知的实时性能不能在秒级内识别出训练阶段切换二是资源抢占的平顺性切换过程中不能让I/O出现明显毛刺。我自己测试过一些方案的切换过程有的存储系统QoS切换时会出现几秒钟的I/O停滞这在训练场景里是不可接受的——正在跑的GPU全部要等。3. 实操如何评估和落地一套存算协同的AI存储方案如果你正在负责AI集群的存储选型或性能优化我建议按下面的步骤走一遍不要上来就买设备、配参数。我做这类调优项目的基本方法论是先摸清负载再做小规模验证最后才铺开落地。3.1 第一步搞清楚你的负载画像没有数据支撑的优化都是耍流氓。在考虑任何存算协同方案之前先花至少一周时间采集训练集群的真实I/O负载重点看这些指标指标怎么测重点关注什么I/O带宽用DCGM监控GPU侧数据吞吐用存储侧监控看实际读写带宽峰值带宽和平均带宽的比值判断潮汐特性I/O大小分布在客户端用strace或系统tap抓系统调用统计读写块大小大块IO1MB比例高不高小块IO占比多少读写比例存储侧监控统计读写IOPS比例训练和checkpoint阶段的读写比例变化请求延迟存储客户端侧统计P99延迟延迟抖动是否严重是否影响GPU利用率并发请求数观测存储系统连接数或队列深度大量并发请求下是否有排队现象采集工具方面存储侧用Prometheus加node_exporter基本够用客户端侧可以用DCGM配合NVIDIA的Nsight监控GPU利用率。要注意把GPU利用率和I/O数据关联起来看如果GPU利用率低于70%而存储I/O已经打满说明瓶颈基本就指向存储了。我见过不少团队跳过这一步直接上优化方案结果方向全错。有个客户说存储慢测试后发现真正的瓶颈是训练框架的DataLoader配置问题数据按顺序单线程读取根本没有把存储带宽用起来。换了存储也没用纯浪费钱。3.2 第二步搭建小规模对比环境做A/B测试确认存储是瓶颈之后也别急着全量替换。先在测试环境里搭一套小规模集群用两台计算节点加一台存储节点跑一个典型的训练任务做基准对比。建议至少对比三组数据纯存储基准测试用fio或ior测存储的原始带宽、IOPS、延迟了解存储系统的理论上限。传统路径训练测试用当前训练框架的默认配置跑一个固定步数的任务记录端到端时间、GPU平均利用率、每步耗时。协同优化路径测试启用GDS、预取缓存、动态QoS等优化后跑同样的任务记录同样指标。重点对比的指标不是存储的IOPS和带宽而是端到端训练时间和GPU有效利用率。这两个指标才是训练平台的真实收益。理论上协同优化路径的GPU利用率应该比传统路径高出10个百分点以上如果测出来没提升说明你的负载压根没被打到存储瓶颈上。有一个实操细节要提醒测试任务尽量选最能代表你生产负载的模型别为了快随便挑个小模型跑几十步就下结论。数据加载密集型和计算密集型任务的存储需求完全不同选错了样本结论就是错的。3.3 第三步关键参数调整与验证清单协同优化方案接入后需要逐项验证配置是否正确。我整理了一份常用的验证清单照着做基本能把大部分问题排掉网络层确认RoCE的PFC和ECN已开启MTU设为9000巨型帧并检查是否有丢包。可以用ib_write_bw或者perftest工具做网络带宽测试观察发送和接收速率是否对称。驱动层确认CUDA、GPU驱动、MOFED三者的版本兼容矩阵没问题。检查GDS是否成功启用在代码里跑一下cuFileAPI的测试用例看是否走P2P路径。存储层确认缓存策略和预取参数生效观察缓存命中率。如果命中率低于预期调大预取窗口或者调整预取触发阈值。客户端配置DataLoader的num_workers要够prefetch_factor要合理一般设置为2到4太小会让GPU等数据太大会吃爆内存。配置生效后再跑一遍基准测试对比优化前后的数据。记录下来的结果不光是给领导汇报用更是以后出问题时的基线参照。我习惯把每次调优前后的性能数据存一份快照遇到诡异问题就翻之前的记录找变化点这个习惯救过我很多次。4. 常见问题与排查技巧实录4.1 问题速查表真实环境里存算协同不是配好了就能一直稳定跑问题逃不出下面这些典型场景现象可能原因排查方向开启GDS后性能反而下降PCIe拓扑不支持P2P或链路带宽受限检查nvidia-smi topo -m评估是否需要切换回传统路径checkpint期间其他任务卡顿QoS优先级策略没生效或切换不平滑查看存储QoS日志确认策略触发时机检查切换毛刺GPU利用率偶发掉零数据预取不及时或客户端缓冲不足调大prefetch增加缓存命中率监控小文件读取很慢元数据操作瓶颈确认是否走元数据缓存考虑把样本集合并为TFRecord或WebDataset格式多节点带宽不均衡网络哈希不均匀或存储节点热点检查路由和链路负载调整分布策略缓存命中率长时间偏低预取算法不匹配数据访问模式检查访问模式是否规律调整预取窗口大小这些问题的共性是现象在应用侧根源在链路中间层。排查的时候不要只盯着存储设备本身跳出来看整个链路的配合状态。4.2 两个真实排查案例分享两个我实际遇到过的case一个是关于checkpoint一个是关于多节点均衡。第一个case是某训练平台用户反馈模型训练到一半checkpoint经常卡住训练效率损失惨重。排查后发现存储端写带宽其实很充裕但每次checkpoint前排队的读请求和写请求互相干扰读缓存和写缓存之间的资源争抢严重。最后通过把checkpoint数据路径独立挂载到单独的存储池并设置独立的写缓存空间解决了互踩问题。这也验证了绿算在闭门会上强调的“场景感知缓存分区”的必要性。第二个case是多节点训练时每个节点看到的GPU利用率差异很大有的70%有的40%而且位置不固定。排查发现是网络哈希策略问题RoCE网络的ECMP把连接哈希到不同上行链路某些链路过载某些闲置导致数据传递不均匀。调整网络配置并启用更精细的流调度后节点间利用率差距缩小到了5%以内。这个问题的坑在于它不会明确报错只会表现为性能不稳定如果没有仔细看链路利用率的监控很容易被误判成存储问题。4.3 几个配置层的避坑经验最后总结几条我踩过坑后沉淀下来的经验第一缓存不要贪大。缓存越大看起来命中率越高但缓存内容一旦失效或者需要重建重建代价会非常大。而且缓存数据的生命周期要和训练任务对齐任务结束时主动清理避免脏数据残留。第二网络拥塞控制别跳过。RoCE网络没有TCP那么健壮必须依赖PFC和ECN来避免丢包。很多人为了追求极致的低延迟把流控关掉结果拥塞时全网丢包数据传输直接断了。我曾经定位过一个性能问题最后发现是交换机关闭了ECN导致尾延迟飙升重新开启后问题立刻消失。第三小文件场景要想办法合并。训练数据集里有大量小图片或小文本文件时元数据操作会消耗大量资源。推荐把样本集做成WebDataset、TFRecord这种顺序读取友好的格式单个文件大元数据压力小顺序读性能也更好。绿算在闭门会上也提到类似观点大块顺序读才是AI训练的最爱小文件随机读是毒药。说到这我个人的体会是存算协同这个方向本质上不是某个具体产品的功能清单而是让存储架构真正回归到“为计算服务”的定位上。判断一套方案好不好别只看单点性能指标的高与低要看它能不能理解你的训练负载、能不能在数据路径上真正为你省时间。哪怕你现在还没有条件上全套协同方案也建议先把自己的负载画像做好把数据加载、缓存、网络这几个关键环节的基线数据摸清楚。这些基础工作永远不过时也会在你未来选型和调优的时候给你最踏实的判断依据。