阿里集团基于 Fluid+JindoCache 加速大模型训练的实践

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

一、背景

时间步入了 2024 年，新的技术趋势，如大模型/AIGC/多模态等技术，已经开始与实际业务相结合，并开始生产落地。这些新的技术趋势不仅提高了算力的需求，也给底层基础设施带来了更大的挑战。

在计算方面，以 GPU 和 FPGA 等异构硬件为例，他们通过短周期的迭代和演进来适应不断变化的需求。阿里集团通过统一调度、统一资源池以及全面弹性等调度手段满足了复杂的计算需求。

在存储方面，经典的微服务应用通过云原生化的方式，兼顾了性能和效率。但对于计算量增量最大的分布式 AI 训练、大数据等计算密集型应用，data locality 直接影响了计算作业的运行效率与吞吐，网络 I/O 的消耗还间接拉高了带宽成本，且在可预见的场景中，数据集规模的还会以较高的速率保持增长，如何通过合理的数据缓存亲和性技术加速数据访问，将是提升计算任务运行效率的同时降成本的关键。

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

综上，阿里巴巴集团内部多个 AI 平台业务面临的现状中，天然适合用分布式缓存/文件系统的形式进行 I/O 层面的加速。

二、面临的挑战

• 计算存储分离架构提升了数据访问与计算水平扩展的灵活度，但导致了数据访问高延时，对于训练等对数据缓存亲和性有显著诉求的场景延迟不友好：业务团队使用的机器学习任务在训练过程中要实时频繁访问 OSS 上的数据（以样本数据集与 checkpoint 为主），在 OSS 带宽受限或者压力较大时，访问 OSS 上数据速度比访问本地文件速度要慢 1~2 个数量级，且占据了用户大量的带宽成本；

• Kubernetes 调度器数据缓存无感知，同一数据源多次运行访问依旧慢: 在现实应用中深度学习任务运行会不断重复访问同一数据，包括相同模型不同超参的任务、微调模型相同输入的任务、以及 AutoML 任务等。这种深度学习任务的重复数据访问就产生了可以复用的数据缓存。然而，由于原生 Kubernetes 调度器无法感知缓存，导致应用调度的结果不佳，缓存无法重用，性能难以提升；

• OSS 成为数据并发访问的瓶颈点，稳定性挑战大: 大量机器学习任务在同时训练时都会并发访问后端 OSS 存储。这种并发机器学习训练造成的 IO 压力比较大，OSS 服务成为了性能单点，一旦 OSS 带宽出现瓶颈则会影响所有机器学习任务；

• 训练文件分散，元数据压力: 机器学习任务的训练数据文件通常会分散在不同路径下，读取文件需要耗费大量的时间在 list 操作上。对象存储的 list 操作性能较差，在进行大规模 list 时对 OSS 元数据压力很大，经常出现超时或者 list 失败的情况；

• IO 稳定性对业务运行有直接影响：导致业务表现不稳定，甚至造成任务失败。基于 FUSE 的存储客户端更容易发生这样的问题，一旦这些问题无法自动修复，则可能中断集群训练任务。时刻保持 IO 的稳定性是保证业务顺利运行的关键途径之一。

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

三、面向深度学习任务的高效缓存调度加速系统

3.1 架构组件介绍

Flu