JuiceFS 企业版在 MLPerf 存储基准测试中表现优异。BERT 模型千卡规模下 GPU 利用率超 98%，Unet3D 模型五百卡规模下保持 97% 以上。通过启用分布式缓存，JuiceFS 有效突破了对象存储带宽瓶颈，利用 SSD 聚合提升读吞吐。相比专有高性能存储，JuiceFS 凭借云原生架构与高性价比，更适合大规模 AI 训练场景。测试显示，开启分布式缓存后，GPU 利用率随规模扩大呈缓慢线性下降，证明了其良好的扩展性。
2023 年 9 月，AI 领域的权威基准评测 MLPerf 推出了 Storage Benchmark。该基准测试通过模拟机器学习 I/O 负载的方法，在不需要 GPU 的情况下就能进行大规模的性能压测，用以评估存储系统在 AI 模型训练场景的适用性。
目前支持两种模型训练：BERT（自然语言模型）和 Unet3D（3D 医学成像）。虽然目前不支持大语言模型如 GPT、LLaMA，但 BERT 与大语言模型同为多层 transformer 结构，大语言模型的用户仍可从 BERT 训练结果获得一定的参考。
高性能存储产品厂商 DDN、Nutanix、Weka 和 Argonne National Laboratory（简称 ANL）发布了 MLPerf 的测试结果作为行业参考，我们也使用 JuiceFS 企业版进行了测试，让用户了解它在模型训练中的表现。
测试中最直观的指标是 GPU 利用率，大于 90% 为测试通过，表示存储系统能够满足训练业务的性能需求。JuiceFS 在 Unet3D 的 500 卡规模测试中，GPU 利用率保持在 97% 以上；在 BERT 的 1000 卡规模测试中，GPU 利用率保持在 98% 以上。
JuiceFS 企业版是基于对象存储的并行文件系统，相比社区版它提供了更强的元数据引擎和缓存管理能力，它的架构图如下：
我们在华为云上搭建了一套企业版 JuiceFS 文件系统，使用华为云 OBS 作为数据持久层，部署了 3 节点的元数据集群和多节点的分布式缓存集群，硬件规格如下：
准备好文件系统后，我们使用 mlperf 的脚本生成后续模拟训练所需要的数据集，所有的测试中 batch size 和 steps 均采用默认设置。目前仅支持模拟 NVIDIA v100 GPU，后文中提到的 GPU 均是模拟 v100。
架构深度解析： JuiceFS 的核心优势在于将元数据与数据分离。元数据操作（如打开文件、列出目录）由元数据服务器处理，而实际的数据读写则直接流向对象存储。这种设计使得元数据服务可以独立扩展，专注于低延迟响应，而数据吞吐量则取决于底层对象存储和缓存层的聚合带宽。在企业版中，元数据引擎经过优化，能够处理更高并发的元数据请求，这对于 AI 训练中频繁的小文件访问至关重要。
MLPerf 为 BERT 模型生成数据集时，会按照每个数据集文件包含 313,532 个样本的规则来生成，每个样本大小为 2.5 KB。训练过程中每个模拟 v100 GPU 每秒能处理 50 个样本，即每个 GPU 的 IO 吞吐需求为 125 KB/s，绝大部分存储系统都能轻松满足它的模型训练需要，JuiceFS 也是一样的，能够满足 1000 卡规模的模型训练需要。
我们汇集了 MLPerf 的主要公开结果，包括 ANL、DDN、Weka 的数据，并新增了本次测试中 JuiceFS 的结果。
Unet3D 模型的训练对带宽的需求高于 BERT 模型。我们首先在没有任何缓存（包括分布式缓存和单机缓存）的条件下测试了训练 Unet3D 模型的情况。在这种设置下，JuiceFS 客户端将直接从对象存储中读取数据。
如下图所示，随着节点数的增加，GPU 利用率（图中的绿色线条）会缓慢下降。当 GPU 增至 98 卡时，它出现了一个明显的拐点，随后 GPU 利用率随节点数的增加而急剧降低。
下图是根据 OBS 监控数据和 MLPerf 的结果绘制出来的曲线图，可以看到 OBS 带宽在 98 卡及更大规模的训练中已经不再增加，成为性能瓶颈。
因此，在没有缓存的情况下，OBS 提供的 300Gb/s 带宽在 98 卡同时训练时就已经满载。根据 MLPerf 90% 的测试通过标准来看，可以满足最多 110 卡同时训练 Unet3D 模型。
在对大型数据集进行多机多卡训练时，单机缓存由于其空间限制仅能缓存数据集的一小部分；同时，由于训练过程中数据访问的随机性，缓存命中率较低。因此，这种情况下，单机缓存对于提升整体 I/O 性能的贡献有限（如上图绿线，能看到单机的内核缓存对读带宽有提升作用，虽然内核缓存空间多达 200GB，但效果有限），因此我们没有进行单机缓存的针对性测试。
相比本地缓存，分布式缓存可以提供更大的缓存容量以支撑更大的训练集和更高的缓存命中率，从而提升整个 JuiceFS 集群的读带宽。
JuiceFS 的分布式缓存架构如下图所示，机器学习训练集群和 JuiceFS 的缓存集群可以是两批独立的机器组成的集群，它们通过高速网络连接。这两个集群都挂载了 JuiceFS 客户端。训练任务通过 JuiceFS 在本地的挂载点访问数据。当本地挂载点需要数据时，它会首先从缓存集群请求数据；如果缓存集群中缺失所需数据，系统则会从对象存储中获取数据并更新到缓存中。如果训练集群中的 GPU 节点自身也配置了充足的 SSD 存储，那么它们可以直接用作 JuiceFS 的缓存盘并组成缓存集群，无需部署独立的缓存集群。这种配置实际上是将训练集群和缓存集群的功能合并在一起。在本次测试中，我们采用了这种。
之前的测试表明，未开启缓存时，110 卡时的 GPU 利用率不足 90%。为了直观展示分布式缓存对性能的影响，我们对 JuiceFS 进行了进一步的测试。我们选择 180 卡 GPU 规模的集群作为测试对象进行新一轮的测试，以评估 JuiceFS 的缓存命中率时跟 GPU 利用率关系。
下图中，横坐标表示缓存空间与数据集大小的比例，纵坐标表示缓存命中率和 GPU 使用率。当完全没有缓存时，GPU 的使用率只有 49%。随着缓存空间比例的增加，缓存命中率（蓝色线条）逐渐提高，进而带动 GPU 利用率（绿色线条）上升，当缓存命中率到 85% 时，GPU 利用率到了 93.1%，已经能够满足 180 卡的训练使用。当缓存命中率达到 100% 时，GPU 利用率达到最高的 98.8%，几乎满载运行。
为了验证 JuiceFS 的缓存系统的扩展能力，我们按照数据集的大小调整了缓存集群的容量，确保了缓存命中率达到 100%。这样，所有训练所需数据均可直接从缓存中读取，而不必从速度较慢的对象存储中读取。在这种配置下，我们测试了最多约 500 卡规模的训练任务，随着测试规模的增大，GPU 利用率的变化如下图所示。
从图中红色线条可以看到，开启分布式缓存的 JuiceFS 突破了带宽瓶颈的限制，GPU 利用率会随着集群规模变大仅缓慢线性下降。按照上图的变化趋势估计，在当期的网络配置 (25Gbps) 下，JuiceFS 可以支撑约 1500 卡训练 Unet3D 时保持 GPU 利用率在 90% 以上。
DDN、Weka 公布的数据中最大规模的模拟 GPU 总数低于 200。
ANL 在 512 卡的规模下依然没有明显衰减，GPU 利用率能够达到 99.5%。ANL 的读写带宽为 650 GBps，理论上最多能支撑 1500 卡训练 Unet3D，它的出色表现与充足的硬件配置密切相关。
JuiceFS 的 GPU 利用率随着集群规模变大，缓慢线性下降，在 500 卡规模时保持 97% 以上。JuiceFS 遇到的性能瓶颈主要来自于缓存节点的网络带宽。由于缓存节点的机型数量和网络带宽有限，本次测试达到的最大规模为 483 卡。在这种规模下，JuiceFS 集群的聚合带宽为 1.7 Tb，而 ANL 集群的带宽是 5.2 Tb。
基于上述测试结果，针对大规模 AI 训练场景，以下是 JuiceFS 的优化建议：
cache-size 参数灵活调整。大规模的 AI 训练场景中，通常都需要专有高性能存储，或是基于全闪架构和内核态的并行文件系统才能满足性能需求。但随着计算负载增加、集群增大，全闪的高昂成本和内核客户端的运维复杂度会成为用户面临的一大挑战。而 JuiceFS，作为一款全用户态的云原生分布式文件系统，借助分布式缓存来大幅提升系统的 IO 吞吐量，使用便宜的对象存储完成数据存储，更适合大规模 AI 业务的整体需要。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online