如何为 GPU 提供充足存储：AI 训练中的存储性能与扩展性

在 AI 训练中，业界往往将关注点集中在计算资源上，但如果存储性能不足，GPU 无法被充分利用，计算效率将会大幅受限。因此，存储系统的性能对于提升整体训练效率至关重要。本文旨在通过分析最新的 MLPerf Storage v2.0 测试结果，探讨不同存储系统在大规模 AI 训练中的表现，并帮助读者理解如何根据实际需求选择合适的存储方案。

MLPerf Storage 基准测试作为业界权威评测体系，专门用于还原真实 AI 训练负载，以全面检验存储系统在不同场景下的表现。 8 月 5 日，全球 AI 工程联盟 MLCommons 发布了最新的 MLPerf® Storage v2.0 测试结果，本次评测吸引了包括云存储、共享文件系统、Fabric-Attached Block 以及 Direct-Attached Block 在内的众多厂商参与。

由于各厂商在硬件配置、节点规模及应用场景方面存在差异，结果间的横向比较存在一定局限。因此，本文将重点聚焦于共享文件系统这一类别，在统一测试标准下对其表现进行分析。

01 MLPerf Storage v2.0 及其测试负载 

MLPerf 是 MLCommons 推出的通用 AI 基准评测套件，其中的 MLPerf Storage 通过多客户端模拟真实 AI 负载访问存储系统，能够复现大规模分布式训练集群场景存储负载，从而全面评估存储系统在 AI 训练任务中的实际表现。

在最新的 v2.0 版本中，MLPerf Storage 提供了三类训练负载，覆盖了深度学习训练中最具代表性的 I/O 模式。

在 3D U-Net 医疗分割负载中，系统需要处理大体积三维医学图像的顺序和并发读取。每个样本平均大小约为 146 MB，并作为独立文件存储。这类任务主要考察存储系统在大文件连续读取场景下的吞吐性能，以及在多节点同时访问时能否保持稳定的响应能力。

ResNet-50 图像分类负载则完全不同，它是小样本的高并发随机读取压力。每个样本平均大小只有 150 KB，数据通过 TFRecord 格式打包存放在大文件中。这样的数据组织方式使得训练过程中存在大量随机 I/O 和频繁的元数据访问，因此该负载对存储系统的 IOPS 提出了极高要求，是衡量小文件场景下并发性能的重要测试。

CosmoFlow 宇宙学预测负载，强调的是跨节点场景下的小文件并发访问和带宽扩展性。每个样本平均 2 MB，通常以单文件形式存储在 TFRecord 中。由于涉及海量小文件的分布式读取，系统不仅要具备足够的整体吞吐能力，还需要在元数据处理和尾延迟控制上表现稳定，否则随着节点规模的增加，延迟波动会显著放大并拖慢整体训练速度。

MLPerf Storage v2.0 工作负载

此外，此次 V2.0 版本中还提供了一类全新的 Checkpointing 负载，用于模拟大模型训练中的 checkpoint 落盘与恢复，主要表现为大文件多并发顺序写负载。

02 性能比较标准：产品类别、弹性扩展能力与资源利用率

在这次 MLPerf Storage v2.0 的测试中，参与的厂商数量众多，涉及块存储和共享文件系统等多种类型，但由于这些类型的存储系统在架构和应用场景上差异大，且各厂商在测试中使用的硬件配置与节点规模差异显著，因此横向对比意义有限。本文将重点分析共享文件系统这一类别下的结果，为用户在类似场景中的选型提供更具参考价值的结论。

在共享文件系统阵营中，还可以进一步细分为两类：

第一类是基于以太网的系统，包括 Alluxio、JuiceFS 和 Oracle，这些云上系统依赖以太网环境提供分布式存储能力，从而实现高性能存储。另有一些厂商，如 Nutanix 和华为，则采用了基于 RoCE 的以太网方案，单机通常配置更高带宽的网卡。

第二类则是基于 IB 网络的存储解决方案，例如 DDN、Hewlett Packard、Ubix 和焱融。这些厂商提供的是完整的存储软硬一体机，通常基于 IB 网络。其硬件配置非常高，整体成本较高，能够提供极高的带宽和性能上限。

在展开结果解读之前，有必要说明本文采用的比较视角。本文在遵循 MLPerf 官方基本提交要求的基础上，结合对软件产品的理解，总结出一套用于横向分析的参考框架。

MLPerf Storage 的文档中要求提交的结果满足 GPU 利用率阈值，并尽可能提高 GPU 数量，其中 3D U-Net 与 ResNet-50 的阈值为 90%，Cosmoflow 的阈值为 70%。在满足 GPU 利用率阈值的前提下，真正体现差异的核心指标是存储系统所能支撑的最大 GPU 数量，而这一规模实质上取决于系统能够提供的最大聚合带宽。能够支撑更多 GPU 的存储系统，意味着在大规模训练场景中具备更强的可扩展性与稳定性。尤其是在 Cosmoflow 这样的负载中，由于涉及大量小文件且对延迟高度敏感，对存储系统的扩展性提出了更严苛的考验。

其次，还需要从资源利用率的角度来比较结果。对于软件厂商而言，关键在于存储软件是否能够充分发挥底层硬件的潜力。存储系统的瓶颈通常是网络带宽，为此，我们采用网卡带宽利用率作为参考指标：利用率越高，说明软件的效率越高，也意味着在相同硬件条件下具备更高性能和性价比。

03 测试结果解读

3D-Unet：大文件连续读取对存储带宽的挑战

3D-Unet 训练负载是典型的大文件连续读取场景，对存储系统的读带宽提出了较高要求，并要求 GPU 利用率 保持在 90%以上。在本次 MLPerf Storage v2.0 测试中，使用以太网的存储产品在 GPU 支撑数量、总带宽以及带宽利用率等方面的表现如下图所示。Oracle 和 JuiceFS 在这些指标上均表现出色，尤其是 JuiceFS 支撑了最多的 H100 GPU，并维持了较高的带宽利用率 86.6%。这类存储方案的优势在于能够充分发挥网络和硬件资源的潜力，确保高效的性能，并在性能与成本之间实现良好的平衡。

下面这部分是使用 IB 网络和 RoCE 网络（RDMA over Converged Ethernet）的参测厂商结果。这两类厂商的硬件规格整体都非常高，最低的网络总带宽在 400 GiB/s 左右，最高的甚至超过 1500 GiB/s。因此，它们能够为训练业务提供极高的总带宽。不过，从利用率角度来看，随着单卡带宽的提升，采用 IB 网络的产品通常会面临较低的带宽利用率，普遍低于 50%。

Cosmoflow：海量小文件访问的考验

CosmoFlow 训练负载需要读取海量小文件，这对存储系统的元数据性能和读延迟性能提出了极高要求，同时测试规定 GPU 利用率需达到 70% 以上。由于任务对延迟要求非常高，随着 H100 数量的增加，多节点分布式训练的读取延迟方差会显著增加，从而使得 GPU 利用率快速下降，导致水平扩展十分困难。与 3D U-Net 相比，CosmoFlow 的提交结果总数明显更少，这也反映了该负载优化难度较大。

下图横轴表示系统能够支撑的 GPU 总数，即 H100 GPU 的数量，JuiceFS 和 Oracle 的表现继续领先。JuiceFS 通过 10 个客户端同时运行，支撑了 100 张 H100 GPU 的 Cosmoflow 训练任务。

Chart

与此同时，基于 IB 网络的系统在该负载下表现尤为突出（如下图所示）。这得益于 IB 网络系统性提供了全链路的极低且高度稳定的延迟。尽管其成本较高，但在延迟敏感型任务中，IB 网络的性能优势依然是不可忽视的。

Chart

ResNet50： 高并发随机读的存储压力

ResNet-50 训练负载属于大文件高并发随机读负载，对存储系统的 IOPS 提出了极高要求，并要求 GPU 利用率保持在 90% 以上。

在该测试中，JuiceFS 在同类系统中支撑了最多数量的 500 张 H100 GPU，并在所有基于以太网的方案里实现了最高的网络带宽利用率，达到 72%，其余产品在此次测试中的带宽利用率大约在 40% 的水平。

下图汇总了采用 InfiniBand (IB) 等专用高速网络的解决方案的测试结果。可以看出，使用 InfiniBand 网络的厂商凭借更高的总带宽和 IOPS，在支持的 GPU 数量 和 吞吐带宽 上取得了较高的成绩，但很多方案的网络利用率并不突出。

04 小结

本文分析了此次 MLPerf Storage v2.0 测试结果。在评估存储产品的 GPU 利用率之前，用户首先需要了解存储产品的类型，包括其架构、硬件资源及成本等因素。在 GPU 利用率达标的前提下，存储系统的关键差异体现在其能够支撑的最大 GPU 数量，能够支持更多 GPU 的存储系统意味着在大规模训练场景中具备更强的可扩展性与稳定性。此外，还需关注资源利用率，即存储软件是否能够充分发挥底层硬件的潜力。

多个类别的存储系统参与了本次 MLPerf Storage v2.0 测试。与 InfiniBand 系统相比，基于以太网的存储方案通常在灵活性和成本效益方面具有优势，能够在不依赖昂贵专有硬件的前提下，仍然提供出色的性能。以太网方案在大规模 AI 训练中已经得到了广泛应用，成为许多用户选择的经济且可扩展的解决方案之一。

关于作者

莫飞虎， Juicedata 系统工程师