关于阿里云:基于-FluidJindoCache-加速大模型训练的实践

作者：王涛 (扬礼)、陈裘凯 (求索)、徐之浩 (东伝)

背景

工夫步入了 2024 年，新的技术趋势，如大模型 /AIGC/ 多模态等技术，曾经开始与理论业务相结合，并开始生产落地。这些新的技术趋势不仅进步了算力的需要，也给底层基础设施带来了更大的挑战。

在计算方面，以 GPU 和 FPGA 等异构硬件为例，他们通过短周期的迭代和演进来适应一直变动的需要。阿里团体通过对立调度、对立资源池以及全面弹性等调度伎俩满足了简单的计算需要。

在存储方面，经典的微服务利用通过云原生化的形式，兼顾了性能和效率。但对于计算量增量最大的分布式 AI 训练、大数据等计算密集型利用，data locality 间接影响了计算作业的运行效率与吞吐，网络 I/O 的耗费还间接拉高了带宽老本，且在可预感的场景中，数据集规模还会以较高的速率放弃增长，如何通过正当的数据缓存亲和性技术减速数据拜访，将是晋升计算工作运行效率的同时降老本的要害。

大模型训练 / 多媒体等场景的数据集以图片和音频文件为主，人造适宜将数据托管在 OSS 对象存储上，也是目前线上大多数计算作业的存储选型，以训练场景为例，具备以下读数据的特色：1）数据集程序的随机化解决造成传统的单机缓存策略生效；2) 多个 epoch 会对数据集进行多轮读取；3) 作业间可能复用同个数据集；

综上，阿里巴巴团体外部多个 AI 平台业务面临的现状中，人造适宜用分布式缓存 / 文件系统的模式进行 I/O 层面的减速。

面临的挑战

1. 计算存储拆散架构晋升了数据拜访与计算程度扩大的灵便度，但导致了数据拜访高延时，对于训练等对数据缓存亲和性有显著诉求的场景提早不敌对：业务团队应用的机器学习工作在训练过程中要实时频繁拜访 OSS 上的数据（以样本数据集与 checkpoint 为主），在 OSS 带宽受限或者压力较大时，拜访 OSS 上数据速度比拜访本地文件速度要慢 1~2 个数量级，且占据了用户大量的带宽老本；
2. Kubernetes 调度器数据缓存无感知，同一数据源屡次运行拜访仍旧慢：在事实利用中深度学习工作运行会一直反复拜访同一数据，包含雷同模型不同超参的工作、微调模型雷同输出的工作、以及 AutoML 工作等。这种深度学习工作的反复数据拜访就产生了能够复用的数据缓存。然而，因为原生 Kubernetes 调度器无奈感知缓存，导致利用调度的后果不佳，缓存无奈重用，性能难以晋升；
3. OSS 成为数据并发拜访的瓶颈点，稳定性挑战大：大量机器学习工作在同时训练时都会并发拜访后端 OSS 存储。这种并发机器学习训练造成的 IO 压力比拟大，OSS 服务成为了性能单点，一旦 OSS 带宽呈现瓶颈则会影响所有机器学习工作；
4. 训练文件扩散，元数据压力：机器学习工作的训练数据文件通常会扩散在不同门路下，读取文件须要消耗大量的工夫在 list 操作上。对象存储的 list 操作性能较差，在进行大规模 list 时对 OSS 元数据压力很大，经常出现超时或者 list 失败的状况。
5. IO 稳定性对业务运行有间接影响：导致业务体现不稳固，甚至造成工作失败。基于 FUSE 的存储客户端更容易产生这样的问题，一旦这些问题无奈主动修复，则可能中断集群训练任务。时刻放弃 IO 的稳定性是保障业务顺利运行的要害路径之一。

在事实利用中，通过对于以上典型数据拜访 pattern 的剖析，咱们发现 IO 性能问题会导致 GPU 等低廉计算资源不能被充分利用。机器学习本身训练的特点导致了数据文件拜访较扩散，元数据压力较大。如果可能精细化地缓存元数据和文件数据，那么一方面能够进步缓存效率和磁盘利用率，另一方面也能够解决文件查找操作带来的元数据损耗。

面向深度学习工作的高效缓存调度减速零碎

为了能更好地满足团体大规模机器学习模型训练的高效性需要，模型训练过程中须要对数据拜访获得更好的数据本地化成果。因而，咱们心愿达到以下指标：

• 计算可能充分利用本地化数据拜访

  防止通过网络重复读取，尽量减少 I/O 在计算流水线中的耗时，从而减速机器学习模型的训练速度，并晋升集群的 GPU 使用率。

• 升高 OSS 负载压力

  通过利用对于局部数据的本地读取，减小数据拜访延时和升高对底层 OSS 的带宽压力。

• 充分发挥热点数据集的缓存节点劣势

  在对用户无感知的前提下，智能地将任务调度到数据缓存节点上，从而使得罕用模型训练程序越来越快。

• 元数据缓存和数据缓存拆散

  可独自对文件进行元数据缓存，缓存策略定制化。

• 通过 POSIX 接口读取数据

  这样无需在模型开发和训练阶段应用不同的数据拜访接口，升高开发机器学习模型程序的老本。

3.1 架构组件介绍

Fluid

Fluid [ 1] 是一个开源可扩大的分布式数据编排和减速零碎，以 Kubernetes 规范和对用户通明的形式为 AI 和大数据等数据密集型利用提供数据拜访能力，其指标为构建云原生环境下数据密集型利用的高效撑持平台。

Fluid 通过 Kubernetes 服务提供的数据层形象，能够让数据像流体一样在诸如 HDFS、OSS、Ceph 等存储源和 Kubernetes 下层云原生利用计算之间灵便高效地挪动、复制、驱赶、转换和治理。而具体数据操作对用户通明，用户不用再放心拜访远端数据的效率、治理数据源的便捷性，以及如何帮忙 Kuberntes 做出运维调度决策等问题。用户只需以最天然的 Kubernetes 原生数据卷形式（PV/PVC）间接拜访形象进去的数据，残余工作和底层细节全副交给 Fluid 解决。

Fluid 反对多种 Runtime，包含 Jindo，Alluxio，JuiceFS 和 GooseFS；其中能力、性能和稳定性比较突出的是 JindoRuntime，有比拟多的实在落地场景。JindoRuntime [ 2] 是 Fluid 一种分布式缓存 Runtime 的实现，基于 JindoCache 分布式缓存减速引擎。

JindoCache

JindoCache（前身为 JindoFSx）是阿里云数据湖治理提供的云原生数据湖减速产品，反对数据缓存、元数据缓存等减速性能。JindoCache 可能为不同文件门路应用不同的 CacheSet 从而提供不同的读写策略，满足数据湖的不同应用场景对拜访减速的需要。

JindoCache 能够用于如下场景：

• OLAP（Presto 查问），进步查问性能，缩小查问工夫。
• DataServing（HBase），显著升高 P99 提早，缩小 request 费用。
• 大数据分析（Hive/Spark 报表），缩小报表产出工夫，优化计算集群老本。
• 湖仓一体，缩小 request 费用，优化 catalog 提早。
• AI，减速训练等场景，缩小 AI 集群应用老本，提供更全面的能力反对。

KubeDL

一套基于 K8S（ASI）的 AI 工作负载编排零碎，负责管理分布式 AI 工作负载的生命周期、与一层调度的交互、容错与故障复原、数据集、运行时减速等，高效撑持了团体对立资源池中不同平台的 AI 训练任务，包含但不限于淘系、阿里妈妈、达摩院等业务域，日均撑持 1w+ 训练任务的稳固运行；KubeDL 开源版本 [ 3]。

我的项目整体架构图

3.2 应用基于 JindoCache 的 Fluid 的起因

1. Fluid 能够将数据集编排在 Kubernetes 集群中，实现数据和计算的同置，并且提供基于 Persistent Volume Claim 接口，实现 Kubernetes 上利用的无缝对接。同时 JindoRuntime 提供对 OSS 上数据的拜访和缓存减速能力，并且能够利用 FUSE 的 POSIX 文件系统接口实现能够像本地磁盘一样轻松应用 OSS 上的海量文件，pytorch 等深度学习训练工具可利用 POSIX 文件接口读取训练数据。
2. 提供元数据和数据分布式缓存，可独自进行元数据缓存预热。
3. 提供元数据缓存预热，防止训练文件在 OSS 上大量元数据操作、提供数据预热机制，防止在训练时刻拉取数据造成的数据拜访竞争。
4. 通过 KubeDL 调用 Fluid 数据亲和性调度能力，用户无需感知缓存寄存的节点地位，以及弹性场景中一直随时可能迁徙的节点环境，将有数据依赖的工作和已缓存的节点进行感知调度，实现尽可能的短路 short-circuit 读，最大化性能劣势；
5. JindoCache 提供多种分布式缓存能力，能够依据业务须要抉择适合的缓存策略。在以后场景中咱们抉择 Cache-Aside (Lazy Loading) 的读缓存策略：当应用程序须要读取数据时，它首先查看缓存以确定数据是否可用。如果数据可用（缓存命中），则返回缓存的数据。如果数据不可用（缓存未命中），则会在底层存储查问数据，而后用从底层读取的数据填充缓存，并将数据返回给调用者。写缓存策略抉择 Write-Through 即写时落缓存策略，应用程序向底层文件系统写入的文件，同时也会被写入缓存零碎中，益处是下一次读取这部分数据的时候就能够间接从缓存零碎中读取，大大晋升了读取效率。
6. Fluid 反对 FUSE 挂载点自愈能力，能够主动查看并复原因 OOM 等异样起因导致的 FUSE 挂载点断裂问题，防止数据拜访异样，保障 AI 平台在线业务稳固运行。

3.3 落地实际

在团体场景的实际中，咱们基于 KubeDL 的作业编排能力，联合 Fluid+JindoRuntime 的缓存引擎能力，同时充分利用了团体宏大异构计算资源池中闲置的内存 / 高性能磁盘等本地资源，端到端地为 AI 平台提供了数据 I/O 的减速能力。

1. 团体宏大的对立异构资源池提供了差异化 SLO 的资源售卖等级，运行着高保障、Spot Instance、潮汐离线、一般离线 等多种不同等级的资源，以及搭配了多种代系的机型、SSD、高性能网卡等硬件，通过正当搭配 JindoCache 的多级缓存介质，咱们能充分利用好对立资源池的闲置资源；
2. 联合 JindoCache 缓存集群的组成特点，咱们应用高保障的计算资源运行元数据服务，利用弹性的离线资源来运行 Cache 缓存节点服务（IO  Bound 类型），在充沛联合了团体资源池调度特点的同时最小化了用户老本；
3. 联合 KubeDL 的分布式训练任务治理与 Fluid 数据集治理能力，咱们针对不同用户的雷同数据源主动进行数据集的跨作业复用，甚至不同平台的雷同数据源也能够在对立资源池中主动复用，并且基于作业的援用计数，KubeDL 能够主动回收闲置的数据集以帮忙用户被动节约老本。

3.4 教训分享

依据实际，咱们总结了以下五个方面的教训供大家参考。

1. 抉择适合的缓存节点

应用 JindoRuntime 能够取得更好的数据本地性能，在理论生产中咱们发现不是所有节点都来做缓存性能就比拟好。起因是有些节点的磁盘和网络 IO 性能不是很好，这个时候须要咱们可能把缓存节点尽量抉择到一些大容量磁盘和网络较好的节点上。Fluid 反对 dataset 的可调度性，换言之，就是缓存节点的可调度性，咱们通过指定 dataset 的 nodeAffinity 来进行数据集缓存节点的调度，从而保障缓存节点可高效的提供缓存服务。

2. 配置缓存容量与门路

通过 dataset 的 Mounts 和 JindoRuntime 的 tieredstore 能够设定数据的挂载目录。同时，为防止数据量过多而导致缓存量过于宏大，可手动配置 JindoRuntime 的 tieredstore 来束缚缓存的最大容量与水位线（超过水位线的数据会被主动抛弃），tieredstore 也蕴含对缓存寄存门路的设定与存储层（SSD/MEM/HDD）的设定，以满足各种场景的须要。对于多节点的场景，应用 dataset 的 replacement 能够反对在同一集群上部署多个 dataset。

3. 设定缓存安全策略

在 Fluid 中创立 Dataset 时，有时候咱们须要在 mounts 中配置一些敏感信息，如 OSS 账号的 accessKeyId、accessKeySecret。为了保障平安，Fluid 提供应用 Secret 来配置这些敏感信息的能力。通过创立 Secret，dataset 以 EncryptOptions 字段指定 Secret 的 name，实现对敏感信息的绑定。

4. 数据预加载

对于曾经创立实现的 dataset 和 jindoruntime，第一次拜访挂载的数据会经验一次下载数据目录下全副文件的过程，这就产生了一个问题：若数据所在的目录存在无需应用的其余数据，会造成无意义的空间资源与网络资源节约。为防止这种问题，Fluid 既反对对数据的预加载，同时也反对元数据缓存。通过创立 dataload 读取所要预加载数据门路信息，能够动静将数据注入。dataload 反对缓存元数据与屏蔽非预加载数据的拜访，这样就大大降低的数据拜访效率。

5. 启用 Fluid FUSE 挂载点自愈能力

在线业务运行过程中，FUSE 过程可能因为内存资源有余以及其余起因解体重启，造成业务容器内 FUSE 挂载点断联，呈现数据拜访异样并影响在线业务可用性。通过启用 Fluid FUSE 挂载点自愈能力，Fluid 自动检测并修复此类断联挂载点，继续保障在线业务稳固运行。

3.5 实际后果

读样本减速

以生产环境中的实在用户作业为根底，咱们对 JindoCache 的成果进行了一次端到端的验证。

• 指标工作： LLAMA 13B 的预训练任务
• 试验环境：
• 集群 & 机型：高性能网络集群 A800 服务器，搭载 RDMA 网卡与 Nvme 高速硬盘；
• JindoCache 规格：默认值为 24*32Gi Cache Worker，以 Nvme 盘为存储介质（绝对内存的性价比更高）。

试验论断：

LLaMa 13B 预训练模型

监控数据 - 无缓存直连

监控数据 - 开启缓存

整机的均匀 GPU 利用率同样靠近 100%，然而各卡的负载较为平均，都靠近 100%。

Checkpoint 减速

训练 / 离线推理场景

分布式训练任务在每次重启工作时都会 load checkpoint 模型文件以持续训练，模型大小从几百 MB 到几十 GB 不等；除此之外还有大量的离线推理工作，大量应用了对立资源池中的 Spot Instance 弹性 GPU 资源，每个推理工作都会随时被抢占，并在 FailOver 之后从新加载模型做离线推理，因而会有大量 Job 在“生生灭灭”中加载同一个 Checkpoint 文件。

通过 JindoCache 的分布式缓存减速，咱们将“屡次远端读”变成了“单次本地读”，极大减速了 Job FailOver 速度的同时还为用户节约了屡次重复读的带宽老本，在典型的大模型场景中，7b 参数量搭配 fp16 精度，模型文件的体积约 20Gb，通过 JindoCache 减速咱们将用户每次加载模型的耗时从 10min 缩短到了约 30s。

训练 Spot 场景（写时落缓存）

分布式训练的 Spot 场景中，同步训练任务通常会在被抢占之后 FailOver 从新全局重启并续跑，KubeDL 会与一层调度配合，以交互式抢占的形式告诉到训练任务的 Rank 0 节点做一次 on-demand checkpoint 以保留最新的训练进度，并可能在重启后 reload 最新的 checkpoint 及时续跑，享受 Spot 弹性低成本的同时最小化训练中断的代价。

通过最新版本的 JindoCache 写时落缓存能力，原先从新后从远端从新被动 load 最新的模型文件，变成了重启后即时从本地缓存集群 load 最新的模型文件，端到端 FailOver 的停止工夫从均匀 10min 缩短到了均匀 2min， 节约了 80% 的闲置贵重算力损失。

总结与瞻望

综上，应用基于 JindoRuntime 的 Fluid 在团体大规模机器学习模型训练中施展了重要作用。在读样本减速场景中，通过应用 JindoCacheEngine，咱们大大晋升了零碎的吞吐，使得 GPU 负载利用更加平衡。同时，JindoRuntime 的形象层屏蔽了不同 JindoCache 版本之间的差别，从而实现了无缝的降级。在 CheckPoint 减速环节，端到端模型加载速度显著晋升，咱们以较低成本实现了性能的大幅晋升。

将来，咱们将持续通过 Fluid 进行更多场景的尝试，以及对现有性能的拓展，例如：

1. 基于援用计数，主动回收闲置数据集（DataSet），实现多数据集的智能治理。
2. 智能数据预热，基于工作拜访数据模式的主动预热，按目录优先级预热 / 驱赶，并进行并行预热（按目录拆解预热工作 )。
3. 启用 RDMA 技术来减速集群内的 worker 传输吞吐，从而充分利用集群的高性能网络基础设施。

最初，在充分利用 JindoCache 缓存减速能力和 Fluid 的多 JindoCache 编排能力的根底上，咱们将对应用形式和下层零碎的接入进行优化，推动硬件和软件协同，进一步晋升性能并反对新硬件。

相干链接：

[1] Fluid

https://github.com/fluid-cloudnative/fluid

[2] JindoCache

https://github.com/aliyun/alibabacloud-jindodata/blob/master/docs/user/6.x/6.2.0/jindo_fluid/jindo_fluid_overview.md

[3] KubeDL 开源版本

https://github.com/kubedl-io/kubedl

如果你对 Fluid 我的项目感兴趣，欢送点击此处理解更多。