存储容量规划：确保 GPU 不因等待数据而闲置

训练集群的存储配置常被简化为一个容量数字：需要存放多少 PB 的训练数据。这只是问题中容易的一半，而且并非决定集群性能表现的那一半。

真正关键的指标

关键在于针对训练任务实际访问模式的持续读取吞吐，并以加速器消耗数据的速度作为衡量基准。八卡节点组成的集群消耗数据的速度，可能超过多数企业级存储层的供给能力；一旦如此，昂贵的硬件便处于等待状态。

其表现形式是 GPU 利用率偏低，却查不到明显故障。一切都在运行，一切都显示正常，而集群实际交付的性能远低于其成本对应的水平。

分层设计的真实考量

热数据层采用 NVMe-oF，容量按当前任务的工作集规模配置，吞吐能力与节点数量匹配。容量层采用机械硬盘，用于存放无需闪存承载的原始语料与检查点归档。

当多个节点并发读取同一数据集时，并行文件系统所带来的运维开销是值得的；若不存在此类访问模式，它就只是没有收益的额外负担，采用更简单的设计同样可以达到相当的性能。

检查点是最常被低估的环节

检查点写入具有突发性、数据量大，且往往发生在任务本身已处于内存压力之下的最不利时刻。写入路径应按检查点突发流量而非平均值进行容量规划，并确认网络路径能够承载该流量而不与训练通信相互争用。

一个可操作的起点

在单个节点上实测一个具有代表性的训练任务的读取吞吐，乘以节点数量，再加上检查点突发余量，以此作为选型依据。这个数字远比一个 PB 级容量目标有用，且只需半天即可测得。