Azure Managed Lustre MLPerf 存储 v3.0 结果

MLPerf 存储 是用于人工智能（AI）工作负载使用的存储系统的 MLCommons 基准套件。 它生成具有代表性的存储 I/O 模式，并度量存储路径是否可以按工作负荷所需的速率提供数据或保存模型状态。

MLPerf 存储 v3.0 包括训练、检查点、矢量数据库和键值缓存工作负载。 Azure Managed Lustre提交包括训练和检查点类别的结果。

基准度量值

MLPerf 存储使用客户端节点为模拟加速器生成 I/O。 它测试存储系统及其数据路径;它不会对 GPU 计算、模型准确性或端到端训练时间进行基准测试。

基准测试旨在从常规用途商用客户端节点生成工作负荷 I/O。 报告的结果是聚合存储系统度量，而不是按客户端性能度量。 客户端计数描述负载生成器配置，不应用于规范化或比较基准数字。

Training

训练基准衡量存储能否持续提供足够快的训练数据，以保持模拟加速器的活跃状态。 Azure提交使用带有模拟 B200 加速器的 UNET3D 工作负荷。

基准报告：

• 模拟加速器的数量和类型。
• GiB/s 中的持续读取带宽。
• 基准运行的模拟加速器利用率。

Azure连续五小时保持了 90 多个% 模拟加速器利用率。 此结果指示测试的存储配置在运行期间持续了工作负荷所需的数据速率。

检查点

检查点基准模型保存分布式模型状态并在恢复期间读取它。 检查点写入发生在训练作业中的同步点，而恢复读取表示在中断后加载已保存的检查点。

基准报告：

• GiB/s 中的检查点写入和恢复读取吞吐量。
• 写入和恢复持续时间（以秒为单位）。
• 数据并行实例数。
• 检查点表示的模型缩放。

封闭式除法

所有Azure Managed Lustre结果都提交到 MLPerf 存储关闭部门。 在此部门中，工作负载代码和基准参数是标准化的。 提交者可以在基准规则中配置和优化存储系统。

Azure提交范围

所有 17 个Azure结果都使用 Azure Managed Lustre 作为通过 POSIX 协议的共享远程文件系统。

带宽单位

MLPerf 存储结果表以每秒兆字节（GiB/s）报告二进制单位的带宽。 一个 GiB/s 等于 1.073741824 GB/秒（GB/秒），一个十进制单位。

训练吞吐量、可伸缩性和检查点图使用 在 MLPerf 存储结果表中报告的 GiB/s。 带宽密度图使用每 TiB MB/秒。 结果表同时提供 GiB/s 和转换后的 GB/s 值。

训练结果

跨服务层级的比较

在具有三个模拟加速器的配置中，测量的读取带宽介于 17.3 和 17.4 GiB/秒之间。 在 16 个模拟加速器中，所有五个Azure Managed Lustre服务层级的测量读取带宽介于 89.0 和 90.6 GiB/秒之间。

每个面板中的虚线显示经过测试的文件系统配置的名义带宽。 每个容量增量提供 2,000 MB/秒。 从容量增量数计算名义带宽，然后转换为 GiB/s 以匹配 MLPerf 存储结果表中的测量值：

Nominal bandwidth (GiB/s) = capacity (TiB) / tier increment (TiB) * 2,000 / 1,073.741824

每个三加速器配置具有 10 个容量增量和 18.6 GiB/秒的名义带宽。 每个 16 加速器配置具有 50 个容量增量和 93.1 GiB/秒的名义带宽。

图 1. 通过Azure Managed Lustre服务层级和 （a） 3 和 （b） 16 个模拟加速器的预配容量来测量和名义训练带宽。

带宽密度效率

Azure Managed Lustre服务层名称标识性能类，但名义带宽和名义带宽密度是根据层容量增量计算的。 每个容量增量提供 2,000 MB/秒。

Nominal bandwidth (MB/s) = capacity (TiB) / tier increment (TiB) * 2,000

Nominal density (MB/s per TiB) = 2,000 / tier increment (TiB)

为了计算演示的带宽密度， MLPerf 存储结果表中 的测量值从 GiB/s 转换为十进制 MB/秒，并除以文件系统容量：

Demonstrated density (MB/s per TiB) = measured bandwidth (GiB/s) * 1,073.741824 / capacity (TiB)

效率被演示为密度除以计算名义密度。 在经过测试的五个层中，表现出的密度介于 95.6% 和 97.3 之间，名义上是 97.3%。

图 2. 计算了 16 加速器配置的名义和演示的带宽密度。

AMLFS 带宽可伸缩性

AMLFS 125 被选为训练可伸缩性的参考层，因为提交包括 3、16、46 和 70 个模拟加速器的结果。 当文件系统调整大小以提供所需的名义带宽时，所有 AMLFS 层都需要类似的缩放行为。

AMLFS 125 配置从 3 个模拟加速器和 17.4 GiB/s（18.6 GB/秒）增加到 70 个模拟加速器和 379.1 GiB/s（407.1 GB/秒）。 文件系统容量随工作负荷规模增加，从 3 个模拟加速器的 160 TiB 增加到 70 个模拟加速器的 4,096 TiB。

虚线表示从三个加速器结果进行理想的线性缩放，其中带宽与模拟加速器的数量直接成比例增加。

图 3. 测量的 AMLFS 125 训练带宽和理想的线性缩放从 3 到 70 个模拟加速器。

最大的训练配置使用了 70 个模拟加速器。 除了 AMLFS 125 结果外，AMLFS 20 配置测量为 378.0 GiB/s。

完成训练结果

检查点结果

检查点结果涵盖四个 Llama 3 模型缩放。 所有四种配置都使用 AMLFS 125，预配容量从 160 TiB 到 4,096 TiB。 最大的结果，表示 1250B 模型，测量了 642.2 GiB/s（689.6 GB/秒）的检查点写入和 489.6 GiB/s（525.7 GB/秒）的恢复读取。

图 4. 检查点写入和恢复读取吞吐量（按模型缩放、AMLFS 层和预配容量）。

如何将数据用作大小调整引用

MLPerf 存储使用标准化工作负载，并练习一个具有代表性的端到端 I/O 链，其中包括工作负载软件、客户端 I/O 堆栈、网络路径、POSIX 文件系统和存储服务。

在估算 AI 基础结构部署的存储要求时，将这些结果用作比较参考点。 但是，它们不是针对生产工作负荷的直接容量建议。 AI 框架行为、缓冲、并发和本地暂存可以更改共享文件系统所需的带宽。 不要从短检查点峰值调整持续训练工作负荷的大小。

定义工作负荷要求

确定工作负荷主要受持续训练读取、检查点写入或恢复读取的约束：

• 对于训练，请估计保持计划加速器处于活动状态所需的持续读取带宽。
• 对于训练关键路径上的同步检查点写入，将检查点大小除以可接受的最大检查点持续时间。
• 对于异步检查点，估计在创建下一个检查点之前刷新缓冲或本地暂存检查点所需的速率。
• 对于恢复，将检查点大小除以可接受的最大恢复持续时间。

例如：

Required checkpoint bandwidth (GiB/s) = checkpoint size (GiB) / target duration (seconds)

将此计算用作初始参考，但考虑到 AI 框架中提供的特定检查点策略（如异步检查点或使用本地缓存策略）可以降低要求。

应用程序 I/O 行为帐户

真正的 AI 工作负载可以从基准生成不同的 I/O 模式，即使加速器和模型缩放类似也是如此。 请注意以下几点：

• 检查点是同步的还是异步的。
• 训练框架如何预提取、缓冲区、缓存和随机数据。
• 本地 NVMe 或其他暂存存储是否用于检查点、缓存或暂存训练数据。
• 无论是在作业之前预处理数据，还是在训练时转换数据。
• 模型和检查点大小。
• 输入文件大小、文件格式、样本大小和存储在每个文件中的记录数。
• 大型顺序 I/O、小型随机 I/O 和文件系统元数据操作的平衡。
• 共享文件系统的并发作业数。

例如，更深入的预提取或有效的本地缓存可以减少共享文件系统中的时间敏感读取。 联机预处理、小型文件、频繁访问元数据或多个并发作业可能会增加或更改存储要求。

将初始带宽估算转换为 AMLFS 容量

如果有初始共享存储带宽目标，则可以将其转换为估计的 AMLFS 容量。 每个 AMLFS 容量增量提供 2,000 MB/秒的名义带宽。

Target bandwidth (MB/s) = target bandwidth (GiB/s) * 1,073.741824

Estimated increments = ceiling(target bandwidth (MB/s) / 2,000)

Estimated performance-driven capacity (TiB) = estimated increments * tier increment (TiB)

此计算提供用于测试的初始配置。 最终部署必须满足数据容量要求和应用程序验证的性能要求，向上舍入为支持的容量增量。

作为算术示例，16 个加速器训练配置使用 50 个容量增量：

50 increments * 2,000 MB/s = 100,000 MB/s = 93.1 GiB/s nominal bandwidth

相应的测试容量为 4,800 TiB，用于 AMLFS 20,2,400 TiB，用于 AMLFS 40,800 TiB，用于 AMLFS 125,400 TiB（适用于 AMLFS 250）和 200 TiB（对于 AMLFS 500）。 这些值说明了名义带宽如何映射到容量;对于每 16 个加速器工作负荷，不建议使用它们的大小。

客户端和网络帐户

尽管基准客户端计数不用于规范化结果，但客户客户端基础结构必须提供足够的聚合网络带宽才能达到存储目标。 规划客户端池时：

• 使用具有足够网络带宽和加速网络的 VM 大小。
• 当区域支持可用性区域时，将客户端置于与Azure Managed Lustre文件系统相同的可用性区域中。
• 在客户端和文件系统之间保持网络路由。
• 规划工作负载的文件大小和访问模式的文件和目录布局。

有关详细信息，请参阅“优化Azure Managed Lustre性能和优化文件和目录布局。

使用应用程序进行验证

在完成生产能力之前运行代表性试点。 使用计划的模型和框架、客户端 VM 类型、网络拓扑、数据格式、文件大小分布、每个文件记录、文件布局、预处理、预提取、本地暂存策略、并发和检查点方法。 将测量的吞吐量和作业级别行为与初始估计进行比较，然后根据需要调整容量或服务层。

相关内容

• 优化Azure Managed Lustre性能
• 用于 AI 训练的分层检查点
• MLPerf 存储GitHub存储库