从 MLPerf Storage v2.0 看 AI 训练中的存储性能与扩展能力

8 月 5 日，全球权威 AI 工程联盟 MLCommons 发布了最新的 MLPerf® Storage v2.0 基准测试结果。本次评测吸引了众多厂商参与，包括 Cloud、Shared File、Fabric-Attached Block、Direct-Attached Block 这几大类存储厂商。
由于各厂商在硬件配置、节点规模和应用场景上的差异，直接进行横向比较存在局限性。因此，本文将聚焦于共享文件系统这一类别，分析其在相同测试标准下的表现。
JuiceFS 是支持云上以及机房部署的高性能分布式文件系统。在多个 AI 训练负载下，JuiceFS 均取得了优异的成绩，尤其在带宽利用率、可扩展性等方面均处于领先水平。接下来，本文将结合具体测试结果展开分析，并进一步介绍支撑这些表现的关键特性。
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 中。由于涉及海量小文件的分布式读取，系统不仅要具备足够的整体吞吐能力，还需要在元数据处理和尾延迟控制上表现稳定，否则随着节点规模的增加，延迟波动会显著放大并拖慢整体训练速度。

此外，此次 V2.0 版本中还提供了一类全新的 Checkpointing 负载，用于模拟大模型训练中的 checkpoint 落盘与恢复，主要表现为大文件多并发顺序写负载。在 JuiceFS 架构下，checkpoint 数据通过 JuiceFS 写入到对象存储中，性能瓶颈取决于作为数据持久层的对象存储带宽上限。
02 性能比较：产品类别、弹性扩展能力与资源利用率

在这次 MLPerf Storage v2.0 的测试中，参与的厂商数量众多，涉及块存储和共享文件系统等多种类型，但由于这些类型的存储系统在架构和应用场景上差异大，且各厂商在测试中使用的硬件配置与节点规模差异显著，因此横向对比意义有限。
本文将重点分析共享文件系统这一类别下的结果。在共享文件系统阵营中，还可以进一步细分为两类：
第一类是基于以太网的系统，包括 Alluxio、JuiceFS 和 Oracle，这些云上系统依赖以太网环境提供分布式存储能力，从而实现高性能存储。另有一些厂商，如 Nutanix 和华为，则采用了基于 RoCE 的以太网方案，单机通常配置更高带宽的网卡。
第二类则是基于 IB 网络的存储解决方案，例如 DDN、Hewlett Packard、Ubix 和焱融。这些厂商提供的是完整的存储软硬一体机，通常基于 IB 网络。其硬件配置非常高，整体成本较高，能够提供极高的带宽和性能上限。

在展开结果解读之前，我们先介绍此次比较所依据的标准。
MLPerf Storage 的文档中要求提交的结果满足 GPU 利用率阈值，并尽可能提高 GPU 数量（规模），其中 3D U-Net 与 ResNet-50 的阈值为 90%，Cosmoflow 的阈值为 70%。在满足 GPU 利用率阈值的前提下，真正体现差异的核心指标是存储系统所能支撑的最大 GPU 数量，而这一规模实质上取决于系统能够提供的最大聚合带宽。能够支撑更多 GPU 的存储系统，意味着在大规模训练场景中具备更强的可扩展性与稳定性。尤其是在 Cosmoflow 这样的负载中，由于涉及大量小文件且对延迟高度敏感，对存储系统的扩展性提出了更严苛的考验。
其次，还需要从资源利用率的角度来比较结果。对于软件厂商而言，关键在于存储软件是否能够充分发挥底层硬件的潜力。存储系统的瓶颈通常是网络带宽，为此，我们采用网卡带宽利用率作为参考指标：利用率越高，说明软件的效率越高，也意味着在相同硬件条件下具备更高性能和性价比。
03 JuiceFS 测试结果解读

在 3D-Unet 负载中，JuiceFS 实现了高达 108 GiB/s 的数据读取带宽，支撑了 10 节点共 40 张 H100 GPU的训练规模，网络带宽利用率达到 86.6%， GPU 利用率是 92.7%。
在 CosmoFlow 负载中，JuiceFS 支撑了 10 节点共 100 张 H100 GPU 的训练规模，GPU 利用率为 75%。这一负载对存储延迟的稳定性要求极高，对网络带宽的要求较低，性能瓶颈并不在带宽。由于需要处理海量小文件的并发访问，IO 延迟大小及延迟稳定性直接决定了整体扩展能力，并限制了 GPU 的利用率。
在 ResNet-50 负载中，JuiceFS 的数据读取带宽达到 90 GiB/s，网络带宽利用率为 72%，整体 GPU 利用率为 95%。


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！