大量和高质量的数据集是良好AI模型的基石之一。如何存储和管理这些数据集以及在模型培训期间提高I/O效率一直是AI平台工程师和算法科学家的特别问题。无论是站立培训还是分布式培训，I/O的性能，I/O的性能显着影响整个管道的效率，甚至最终模型质量。
我们还逐渐将容器化的趋势转化为AI培训。容器的使用可以快速灵活地缩回。结合了公共云的资源池，我们可以最大化资源利用的利用，并为企业节省大量成本。因此，像Kubeflow和Volcano这样的开源组件是为了帮助用户在Kubernetes.kubernetes上管理AI任务。从1.15起。社区还根据这个新的调度框架为AI培训场景优化了许多问题。数据需要智能地遵循“流”计算（或依次）。
最后，无论是算法科学家的日常实验还是正式培训模型，POSIX界面仍然是强劲的需求。尽管主流框架或算法库基本上支持存储接口，但POSIX仍然是“第一公民”。某些操作系统（例如页面缓存）的高级特性仅适用于POSIX接口。
以上是一个常见的AI平台体系结构。在目前，使用存储系统更多是对象存储和HDFS。有很多原因原因是此处使用HDFS的原因，例如在没有对象存储的情况下部署在计算机室中的平台，并且训练数据集处理在大数据平台上。计算资源混合了CPU实例和GPU实例。与大数据平台不同，AI平台的资源本质上是异质的。因此，如何合理有效地使用这些异质资源一直是行业中的问题。调度程序是在Kubernetes目前是主流组件之前引入的，并结合了各种工作运营商，火山和调度插头，以最大程度地提高Kubernetes.Pipeline是一个非常重要的部分。AI任务不仅由模型培训的步骤培训组成。它还包括数据预处理，功能工程，模型验证，模型评估，在线模型等。因此，管道管理也非常重要。最后一个是与算法科学家最接触的深度学习框架。这些框架目前有自己的使用组。许多模型优化将基于某个框架（例如TensorFlow的XLA），但与框架（例如TVM [4]）Essence无关
本文的重点在于最低的存储层。如何在保持不变的上部组件时如何优化存储层的I/O效率。本部分包括但不限于诸如数据缓存，预读取，并发读取和调度优化等策略。Juicefs是存储层的增强组件，可以极大地提高I/O效率。以下将详细介绍。
Juicefs是用于云本机环境设计的高性能开源分布式文件系统。它与POSIX，HDFS，S3接口完全兼容。它适用于大数据，AI模型培训，Kubernetes共享存储，大量数据归档管理和其他方案。
当通过JUICEFS客户端获得数据时，这些数据将被智能缓存到应用程序配置的本地缓存路径（可能是内存或磁盘）。同时，元数据也可以缓存到客户端节点的本地内存。对于AI模型培训方案，第一个时期完成后的后续计算可以直接从缓存中获取训练数据，从而极大地改善了训练数据培训效率。
Juicefs还具有阅读和发送数据的能力，以确保每个迷你批次的生成效率，并预先准备数据。
此外，Juicefs还提供标准的Kubernetes CSI驱动程序。应用程序可以将JUICEFS文件系统用作共享持续音量（PV），同时将它们安装到多个容器中。
得益于上述特征的支持，算法科学家可以轻松地管理培训数据，就像访问本地存储一样，无需修改特殊适应的框架，并且也可以保证培训效率。
为了验证使用JUICEFS后模型训练的效果，我们选择了Common Resnet50模型和Imagenet数据集。培训任务使用DLPERF [5]项目提供的脚本。相应的深度学习框架是Pytorch。培训节点配备了8张NVIDIA A100图形卡。
相比之下，我们将对象存储在公共云上作为基准线（通过S3FS方法访问），同时与开源项目Alluxio相比，并测试了1个机器，1张卡，1个机器，4张卡，4卡，，1机器8卡分别不同。配置下的训练效率（即每秒样品数量）。
无论是Juicefs还是Alluxio，训练数据集都会预先预热到内存，并且数据集占据约160G空间。JUICEFS提供热身子命令[6]，以轻松预热数据集的缓存。只需指定需要预热的目录或文件列表即可。
测试方法是在每种配置中进行多轮训练，并且每轮只运行一个时期，以汇总每轮的统计结果。在排除了一些可能的异常数据之后，计算了总体训练效率。
AI模型培训方案的I/O模式是典型的读取模式，即仅读取数据集，并且不会修改数据。因此，为了最大程度地提高I/O效率，某些配置选项（例如与缓存相关的配置）可以详细调整。以下介绍了几个重要的Juicefs配置选项。
可以在内核中缓存三个元数据：属性（属性），文件项（条目）和目录项目（direntry）。他们可以通过以下三个选项来控制缓存时间：
默认元数据只能在内核中缓存1秒钟，并且根据训练时间（例如2小时（7200秒）），可以适当增加缓存时间。
打开文件（即）时，为了确保一致性[7]，Juicefs将请求元数据引擎以获取最新的元信息信息。由于仅读取数据集，您可以适当调整处理策略并设置间隔是时候检查文件了。如果时间未达到设定值，则无需访问元数据引擎，这可以极大地改善开放文件的性能。相关配置选项是：
对于已读取的文件，内核将自动缓存其内容。下次打开时，如果未更新文件（即未更新MTIME），则可以直接读取内核中的缓存（Page Cache）。最佳性能。因此，当第一个epoch运行时，如果计算节点的内存足够，则大多数数据集可能已缓存到页面缓存。这样，时代就无需通过Juicefs读取数据，并且可以大大提高性能。此功能已在Juicefs中打开，默认版本为0.15.2及以上，没有任何配置。
除了内核中的数据缓存外，JUICEFS还支持将数据缓存到本地文件系统，该文件可以是基于硬盘，SSD或内存的任何本地文件系统。可以通过以下选项调整本地缓存：
例如，有两种方法可以将数据缓存到内存，一个是将其设置为，而另一个是将其设置为。Juicefs文件系统，后者仍将保留。性能没有太大不同。以下是缓存数据并限制300GIB内存的一个示例：
Juicefs还支持缓存数据到多个路径。默认情况下，它将通过旋转写入缓存数据中。例如，多个路径将通过结肠分开：
Alluxio的所有组件（例如Master，Worker，Fuse）均在同一节点上部署，并且使用的版本为2.5.0-2。特定的配置如下：
streaming.reader.chunk.size.bytes32mballuxio.worker.network.reader.buffer.size128mb。此外
测试结果包括两种情况，一种使用内核页缓存，另一个不使用。如前所述，测试方法是每种运行多轮训练的配置。在第一轮运行之后，随后的测试可以直接从页面缓存读取数据。因此，我们设计了第二个场景以测试没有页面缓存（例如模型培训的第一个时期）时测试训练效率。该场景可以真正反映基础存储系统的实际性能。
对于第一个场景，Juicefs可以有效地使用内核页缓存而无需其他配置，但是对象存储和Alluxio的默认配置不支持此功能，并且需要单独设置。
应该注意的是，我们尝试了在测试对象存储过程中打开S3F的本地缓存特性，希望达到类似于Juicefs和Alluxio的缓存效应。但是，在实际测试中，即使缓存也可以已经完全热身了，无论使用多少个图形卡，都不能在1天内运行一个时期，甚至比没有缓存时慢。因此，以下测试结果中的“对象存储”不包括打开本地缓存后的数据。
下图是两个场景的测试结果（“ w/o pc”表明没有页面缓存）：
得益于元数据缓存和数据缓存，可以看出，无论哪种情况，与对象存储相比，JUICEFS的平均性能平均达到4倍以上，并且最多可以具有性能差距的7倍同时，由于存储在对象中的访问方法没有有效地使用内核页面缓存，因此在这两个场景中它之间的性能差距并不多。此外，在完整的端 - 到 - 端 - 端 - 端 - 端 - 端模型训练测试中，由于对象存储的训练效率太低，因此要运行到指定的模型准确性花费太长，并且在生产环境中基本上不可用。
与Alluxio相比，它与第一个场景中的Juicefs与Page Cache中没有太大不同。在没有页面缓存的第二个场景中，只有内存缓存，Juicefs的性能平均增加了约20％，尤其是在1 Machine和1 Machine和8张卡，差距进一步增加，达到了约43％的性能差异。与1机器和4张卡片相比，Alluxio在1机器和8张卡片配置下的性能没有改善，并且无法充分利用多卡的计算能力。
GPU资源是一个相对昂贵的资源。因此，I/O效率的差异也可以间接反映在计算资源的成本中。计算资源越有效可用于减少整个TCO。
本文介绍了如何在AI模型培训中充分利用JUICEFS的特征来加快培训。与直接从对象存储中的对象存储读取数据集相比，它可以通过Juicef.的性能提高7倍。它还可以在多卡训练场景中保持一定的线性加速度比率，从而为分布式培训奠定了基础。
将来，Juicefs将在AI场景中探索更多的方向，例如进一步提高I/O效率，大量的小文件存储，数据和计算亲和力，与工作运营商的组合，与Kubernetes计划框架或社区调度框架的结合等等等。欢迎每个人积极参与Juicefs开源社区，共同建立云本地AI场景的存储基石。