聂瓦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 存储，或者已经买了存储但在实际业务里跑不出理想性能，这篇文章应该能给你一些直接的参考。内容比较多，我会按思路、技术拆解、实操和问题排查的顺序来讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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 阶段，存储系统要预留足够的写带宽，避免和其他读