模型训练

有效解决数据驱动型人工智能面临的 I/O 挑战

2024 年 9 月 2 日

导读本次分享的主题是如何通过 Alluxio 来解决 AI 训练模型在各种 I/O 上遇到的问题与挑战，通过提高 GPU 利用率来实现训练模型的加速。本次分享的很多挑战是来自于 Alluxio 客户的真实案例，是用户实际遇到的困难与痛点。

文章将介绍 Alluxio 作为计算应用与存储系统之间的纽带，通过集群扩容、高性能 I/O 和成本可控的方案来解决 AI 框架下例如算力不足、GPU 利用率低和数据 I/O 瓶颈等问题。还将介绍 Alluxio 最新版本的功能升级，包括读写性能提升、新增 API 和稳定性易用性的改进，并通过实际案例展示 Alluxio 在模型训练和部署中的应用效果。

主要内容包括以下几个部分：

1. Alluxio 数据编排平台介绍

2. AI 训练面临的挑战 & 解决策略

3. 客户应用案例

4. 在机器学习工作流中部署 Alluxio

5. Alluxio Enterprise AI 3.2

分享嘉宾｜王宇阳 Alluxio 高级工程师

编辑整理｜乔伊

内容校对｜李瑶

出品社区｜DataFun

Alluxio 数据编排平台介绍

Alluxio 是一个数据编排平台，上层服务于常见的数据应用，包括但不限于大数据场景下计算相关的应用，例如 Spark、Presto、Hive，以及 AI 场景下的 TensorFlow 和 PyTorch。下层又承接了不同的存储系统，包括常见的 S3、HDSF、Ceph，以及各种对象存储 OSS、COS，包括火山引擎的 TOS 等等。Alluxio 作为中间层，它是计算应用跟存储系统之间的纽带，能够帮助上层的计算应用更好地处理数据，更好地消费数据，更好地管理数据。然后将底层各种存储系统的数据整合在一起，以一种高效高性能的方式服务于上层计算应用。本次分享的案例更多的是在 AI 框架（TensorFlow、PyTorch）上的使用。

另外，Alluxio 的部署方式也是非常通用的，支持常见的云原生的方式，通过 K8s 以 pod 的方式来部署，假如你有物理机或者公有云的虚拟机都可以轻松部署 Alluxio。

AI 训练面临的挑战 & 解决策略

1. AI/ML 的竞争对企业至关重要

接下来具体介绍 Alluxio 的应用与部署场景。开始之前，我们先聊聊AI的重要性，以及目前 AI 训练面临的挑战。AI 有很长一段发展历史，已经被大家所熟知，但是近几年随着 ChatGPT 的爆火，我们越来越多地关注到 AI，包括各种 AI 应用、大语言的模型，新奇的 AI 应用场景层出不穷，例如 AI 制药、无人驾驶、能源、医疗等。现在各种各样的大模型发展迭代迅猛，从之前的纯文本模型到后来的大语言模型，再到多模态，例如文生图、文生视频、图生视频等等。

大家现在更加关注各种 AI 相关新闻，包括新的模型，基于模型的新应用等。但作为大数据人员，我们看到帮助模型更快迭代训练的 AI 基础设施是非常重要的，所谓“工欲善其事，必先利其器“。但是实际上，目前市场上相关产品架构是早期或者非常原始的，尤其是在数据存储和访问方式上面，更多的是沿用已有方案，例如很多公司沿用离线计算已有的存储集群，包括 HDFS 或者对象存储。在上述情景下，公司在应对大模型发展时会面临很多挑战。

2. 企业搭建/优化 AI 高性能数据访问平台面临的挑战

下面具体介绍企业目前在搭建和优化高性能数据访问平台时面临的挑战。

（1）GPU 的烦恼

首先，GPU 算力价格昂贵，市面上的 GPU 例如 A100、H100 等价格高昂，且现在千卡场景越来越普遍。算力不足会导致计算速度缓慢，导致模型训练周期加长。其次，在实际训练过程中 GPU 的利用率很低，难以达到 50%，研究发现大部分时间花在 data loader 加载数据的 I/O 上面，即我们需要花费很多时间将数据准备到 GPU 服务器上，或者是让 GPU 能够访问到。

（2）业务压力带来的数据增长

随着业务压力越来越大，模型的翻新迭代速度越来越快，要求模型训练周期越来越短，随之带来的数据集呈几何级增长。例如几年前常见的是 1000 万张图，现在则需要几千万上亿张图或者更多，图片的规格从过去两三百 KB 一张，变成 8～10 MB 一张的原图。同时多模态场景下，数据集的类型增多，同时包括纯文字、语音、视频与图片类型。在这种情况下，原本的数据访问方式和存储方式变得低效和困难，最终可能会阻塞训练。

（3）复杂且价格高昂的解决方案

针对上述两个问题，在现有架构下，为了更高效地管理和利用扩大的数据集（从 10 TB 增加到 30-40 TB），我们常常采取以下措施：

①平台化 GPU 管理：统一管理所有 GPU 资源。

②数据拆分：由于单个服务器难以容纳更大的数据集，需要对数据进行拆分处理。

③引入专用存储层：在原始对象存储（如 HDFS）之上添加高性能 NAS 或并行文件系统，以提高数据访问速度。但同时带来了数据迁移与协调问题：

手动迁移：工程师需要手动将所需数据从底层对象存储迁移到专用存储。
重复存储问题：不同工程师可能会独立迁移相同数据，造成存储冗余。
空间管理困难：难以决定何时清除不再使用的数据，这可能导致存储空间迅速耗尽。
运维挑战：需要频繁沟通以确定数据是否还需保留，避免误删正在使用中的数据，减少线上事故风险。
使用并行文件系统时，随着存储需求的增长，成本也会显著上升。

3. Alluxio 如何解决问题

Alluxio 作为 AI 数据平台，希望解决三个维度的问题。第一，Alluxio 通过提供更多的数据管理和缓存管理的方案去支持不断扩容的数据。第二，Alluxio 提供了更高性能的 I/O，使之不会成为计算训练任务的瓶颈。第三就是成本可控，Alluxio 作为数据平台，它所需的存储空间只需要保证足够热数据的存储即可，不需要存储总数据集。通过规划 Alluxio 本身的存储空间能让存储成本更小。

为了解决数据访问和管理的问题，Alluxio 还采用了以下方法：

统一访问接口：

本地文件模拟：通过 FUSE 技术使计算框架如 Paddle 或 TensorFlow 认为是在访问本地文件，但实际上这些文件通过 Alluxio 进行代理访问。

高性能访问：如果数据已缓存在 Alluxio 中，则可以快速响应计算框架的需求；若未缓存，则从底层存储加载数据。

无侵入性：算法工程师无需修改现有脚本，仍可访问相同的文件路径。

冷热数据分层：

Alluxio 内置分布式缓存用于存储最热数据，通常这些数据量远小于原始数据集（例如，从10 PB 压缩到几十 TB）。计算任务只需访问这部分缓存中的热数据，提高读取效率。对于访问频率较低的数据，通过冷存储访问底层的对象存储或 HDFS。

集群运维能力：

与 Kubernetes 集成，通过 Helm Chart 和 Operator 实现一键部署和滚动重启等功能，简化运维工作。

4. Alluxio AI 模型训练场景

在大多数客户的实际场景中我们会采用上图架构，但有些客户是例外的，具体情况会在后面详细讲解。该架构具有如下特性：

去中心化架构

Alluxio 自3.x 版本起，采用了去中心化架构。在 2.x 之前，使用的还是中心化架构，这种架构与许多存储系统类似，需要一个中心节点来管理元数据，例如文件和索引的管理。中心化架构在一致性和效率上有优势，但会出现热点问题。单节点的扩展能力有限，随着集群规模增大，单节点始终有上限。之前的架构中，单节点最多支持接近十亿个文件。而现在，采用去中心化架构后，不会再有热点问题。去中心化架构能避免竞争、阻塞和等待问题，从而支持超过 100 亿个文件。随着数据集和参数的增加，文件数量会不断增长，而去中心化架构不会出现热点问题，可以在大规模集群中保持稳定的 I/O 和吞吐量。

降低了数据工程的复杂性和成本

通过 fuse，我们可以用 helm chart 或 operator 编写固定配置文件，一键部署 Alluxio 集群，同时支持动态扩缩容。当节点故障时，其他节点可继续提供服务，或通过客户端直接访问存储来确保服务不中断。我们有 CSI failover 机制，在 K8s 场景下可保证节点恢复后迅速恢复对应的 Alluxio worker 服务，从而降低运维复杂性。

2-8x 访问速度提升

相比直接访问底层存储或 NAS 场景，通过高性能 I/O，数据访问速度可以提升 2 到 8 倍，甚至超过 10 倍，具体效果取决于存储方案和网络条件。

上图右边部分则是 Alluxio 的实际部署方式。

Alluxio 可以灵活地部署在 GPU 节点、CPU 节点或两者混合节点上，以适应不同客户的需求。通过整合每个节点的存储资源，实现存储资源的集群化管理，并支持自动清理和替换磁盘空间，提升存储空间的利用率。上层客户端支持多种方式访问 Alluxio，包括 FUSE 和 S3 接口，其中 90% 以上的场景使用 FUSE 来访问本地文件系统。Alluxio 提供全局统一命名空间，可以连接不同的存储系统，如 OSS、S3、HDFS 等，实现数据的统一管理和访问。它支持动态扩缩容，并提供运维管理工具来优化数据缓存、生命周期管理和性能表现。在高并发场景下，Alluxio 的数据访问速度可以达到 10 GB/s

客户应用案例

接下来介绍一些客户的实际应用案例，包括训练场景、部署上线场景，涉及 AI 制药和智慧驾驶场景。

1. Alluxio + 模型训练- 随时随地启用 GPU

第一个场景是远程训练集群。见上图，训练集群位于 GPU 集群之上，对象存储在下方，Alluxio 在中间。Alluxio 通过高性能 I/O 将对象存储的数据提供给训练集群用于训练，并执行 checkpoint 持久化。远程训练集群的特点是灵活使用不同的计算中心或公有云的 GPU 服务。这些服务的价格波动较大，因此用户可能会在不同的集群间切换。在这种情况下，集群部署需要尽可能简单，数据读取速度要快。Alluxio 可以通过 Operator 实现一键部署，并将数据加载到 Alluxio 中，通过多副本方式提供给多个 GPU 服务器访问。这样，训练集群可以快速完成部署并开始训练。训练完成后，集群和 Alluxio 都可以被清理，保证数据安全，并为下次的训练任务做好准备。

2. 客户案例- 模型部署

这是一个模型部署上线的场景。客户有多个机房（在线、离线机房），其中模型训练在离线机房完成，并通过机器学习平台进行训练，完成微调后，模型需要迅速推送到在线机房的推理服务器进行上线。通常每 8-12 个小时需要微调一次，每次微调训练时间很短，但是上线所需的时间很长。其中模型需要通过离线 HDFS 推送到在线 HDFS，再供推理服务器使用。这个流程有三个痛点：

每个机房需建立自己的 HDFS 或对象存储，管理多个 HDFS 维护成本高。
每次都要进行数据推送，可能导致数据重复拷贝，并需要在多个 HDFS 集群中清理数据。
HDFS 有 DataNode 热点问题，大量服务器同时访问同一个 checkpoint，会给少数 DataNode 带来极大压力，只能通过增加副本来分担流量。

有了 Alluxio 后，模型部署场景优化如下：在离线和在线机房中建立 Alluxio 集群，各个 Alluxio 集群可以连接同一个对象存储或 HDFS。这样，所有集群看到的都是相同的文件，实现了全局统一的命名空间和共享视图。

Alluxio 的维护和部署更快，比传统 HDFS 集群更容易管理。通过机房专线，Alluxio 可以有效减少流量竞争。例如，模型 checkpoint 只需加载一次，通过多副本放在不同的 worker 上，减少时延。在极端情况下，每个 worker 都可以有一份数据，这样 GPU 服务器可以通过访问本地 worker 来达到极快的读取速度。这种架构将模型部署时间从 30 分钟缩短到 2-3 分钟，实现了近十倍的速度提升。此外，在线 AI 集群不再需要维护本地存储，只需部署一套 Alluxio。高并发下，Alluxio 有效减少了流量竞争，提升了对象存储的 I/O 性能，减轻了专线流量压力。

3. 客户案例- 模型训练

这个模型训练场景中，有多个 GPU 机房，它们的数据集来自同一个离线 HDFS 集群。跨机房直接访问 HDFS 性能差，因此采用了在每个 GPU 机房内建立对象存储，再通过中间自研组件实现数据缓存的方案。

在这种架构下，训练容器通过 S3fs-fuse 读取数据，如果数据在本机房的对象存储中，直接读取；如果不在，则需先从离线 HDFS 加载到对象存储，再提供给训练容器。这种方式导致首次延迟高，初次训练时需长时间等待。此外，维护压力大，每个集群要维护自己的对象存储和自研组件。对象存储方案在性能和一致性上表现有限，且存在高存储成本及人力介入管理问题。多份数据存储增加了管理和清理的复杂性。

在引入 Alluxio 之后，解决了多个 GPU 服务器的模型训练的问题。

高性能数据访问：Alluxio 部署在 GPU 服务器上，模型训练可以通过 Alluxio 高效访问所需的热数据。其高性能能够提升吞吐量，降低延迟，从而支持高效的前卡训练。
自动缓存管理：Alluxio 自带缓存自动淘汰功能，不需要人为干预，从而节省存储空间和人力成本。如果缓存满了，可以自动清理旧数据，为新任务加载新的热数据。不同 GPU 机房只需存储特定任务所需的热数据，而无需存储全部数据集。
提高 GPU 利用率：借助 Alluxio 的高效 I/O，数据加载时间大幅减少，使 GPU 的利用率从 30%-50% 提升到 90% 以上，减少了训练时间并降低了算力成本，相当于节约了 300% 的算力成本。

以上改进显著简化了数据运维的复杂度和成本，提高了整体系统的效率和效能。

4. 客户案例- 智驶模型训练

如上图架构，在智慧驾驶的模型训练中，现存以下问题：

性能瓶颈：虽然使用了高性能 NAS，但在高并发情况下，NAS 性能下降严重，导致数据访问阻塞，多个任务同时进行时系统可能会完全卡死。
数据冗余：不同工程师为训练任务从公有云对象存储中分别拉取相同数据，导致 NAS 中存在大量重复数据，浪费存储空间。
运维复杂：数据清理需要人工介入，工程师需要确认数据是否仍在使用，导致运维成本高且容易误删数据，进而导致训练任务失败。
低 GPU 利用率：由于数据加载耗时长，GPU 利用率低于 50%，浪费计算资源。

引入 Alluxio 后，智慧驾驶的模型训练变得更简单和高效：

多存储集群支持：Alluxio 可以同时接入不同的公有云对象存储，通过逻辑化目录映射，使不同训练任务可以高效访问所需数据，无需重复加载，降低存储成本。
高并发性能：Alluxio 采用去中心架构，能够在高并发读写情况下保持稳定性能，不会像传统 NAS 那样性能下降。
提升 GPU 利用率：通过减少数据加载时间，整体训练时间显著缩短，GPU 利用率从 30-50% 提升到 90% 以上。
降低运维复杂度：Alluxio 具备自动化缓存加载和淘汰功能，防止数据重复和误删，且具备故障恢复机制（failover and fallback），即使缓存数据被淘汰或出错，系统也能自动从底层存储读取数据，避免训练任务中断。

5. 客户案例– AI 制药

在 AI 制药领域，对象存储性能不足及带宽限制导致 GPU 利用率低下。使用高性能 NAS 虽提升了性能，但成本高昂，且处理大量小文件时性能仍不理想。为此，算法工程师需手动合并小文件为大文件以优化读取效率，这增加了开发复杂度和成本。同时，多用户访问相同数据集导致数据冗余，加之全闪存 NAS 的高昂扩容成本和人力管理成本，使得整体解决方案成本较高，且需定期清理无用数据以释放空间。

使用 Alluxio 可以直接利用现有 GPU 服务器上的空闲 SSD，无需购买专有硬件，从而降低成本。Alluxio 集群支持动态扩缩容，确保训练任务在节点损坏时能正常完成。通过自动缓存管理节省存储成本，同时可以直接访问不同集群，简化数据运维并降低运维成本。此外，Alluxio 方案能保证高 GPU 利用率，与昂贵的全闪存 NAS 相比，提供了一种低成本的替代方案，同时仍然使用 NAS 进行 checkpoint 存储。

在机器学习工作流中部署 Alluxio

1. Alluxio 在 AI 模型训练和部署中的应用

上面章节介绍了各类客户真实案例。本章节则重点描述的是 Alluxio 在 AI 模型训练和部署中的应用。

Alluxio 作为一个数据平台解决方案，主要解决的是数据存储与处理的问题，而不是直接关注算力。在 AI 模型训练和智慧驾驶等场景中，使用 Alluxio 可以加速模型的训练过程。传统的，客户尝试了多种方法来提升他们解决问题的能力，包括使用不同的存储解决方案，但仍会遇到各种问题。通过 Alluxio，用户可以高效地管理底层数据存储，并确保训练平台能够有效地读取和消费数据。Alluxio 强调两个重要方面：模型训练和模型部署。在模型训练阶段，它允许使用低成本的存储方案来保存大量原始数据，并且可以高效地访问最热的数据以保持 GPU 的高利用率。此外，Alluxio 简化了数据管理和运维工作，减少了数据副本和维护成本，同时提供了灵活的接口对接 GPU 集群。在模型部署阶段，Alluxio 支持高并发的数据加载，快速将模型推送到推理服务器，并减少网络带宽的竞争和存储访问的负载。

总之，Alluxio 提供了一个降本增效、灵活易用的解决方案，优化了从数据存储到模型训练和部署的整个流程。

2. Alluxio 使用前后效果对比

我们做了性能对比，左图显示未使用 Alluxio，GPU 利用率仅 17%，而 data loader 占用了 82% 的时间，导致 GPU 空闲。使用 Alluxio 后，data loader 时间降至 1%，GPU 利用率提升至 93% 以上。这不仅缩短了训练时间，还大幅提高了 GPU 的使用效率，显著节约了成本。

3. Alluxio VS 直接访问 S3

之前在 S3 训练场景下，我们总训练时间为 85 分钟。现在使用 Alluxio 后，训练时间缩短至 17 分钟，GPU 利用率也从 17% 提升至 93%。但这是相对测试结果，具体效果还需根据用户场景而定。例如，之前提到的案例中，GPU 利用率低可能是由于使用了较多的存储或 NAS，而后续 GPU 利用率提高则可能使用了全闪存，但这也意味着成本增加。因此，我们需要一个既能保证高性能、低成本，又能支持数据不断扩容的解决方案。

Alluxio Enterprise AI 3.2

Alluxio 最新发布的 3.2 版本中新增了多项亮点功能。现在官网提供 14 天免费试用，你可以简单部署并体验性能提升。如果你有类似之前客户案例的场景，欢迎与我们交流，我们可以提供针对性的优化经验和方案。

在 3.2 版本中，我们进行了以下升级：

提升了读写性能，这将直接影响到 data loader 的时间和整体训练时间。无论是顺序读、随机读还是冷读场景，都有明显提升。
新增了一些 API。之前的版本主要支持 FUSE，因为大部分客户场景都在 FUSE 上。但 FUES 存在一些瓶颈，所以我们增加了 Python 的 SDK API 和 S3 的 API。
在稳定性和易用性方面进一步提升。在 3.0 和 3.1 版本中，我们进行了大的架构变化，并提供了技术功能支持。而在 3.2 版本中，我们着重优化了性能和稳定性。

下面进行更详细的介绍。

1. 读写性能提升

速度即时间，时间即金钱！

在基于 FUSE 的 API 上，我们进行了性能优化，特别是在顺序热读、随机热读和顺序冷读的场景下。性能优化主要来自于整体架构的重构和 I/O 路径的优化。与旧版本相比，新版本的性能有了显著提升，提升达到了 20% 至 30%。此外，我们还针对数据热度和冷度进行了优化，通过预取策略提高了顺序冷读的吞吐量，尤其是在高并发情况下。

对于写操作，我们特别关注了 checkpoint 场景。由于 checkpoint 的特殊性，我们采取了不同于一般文件的处理方式。例如，将 checkpoint 直接写入本地磁盘，利用内存或磁盘的高速写入能力，再异步上传到最终存储，这样可以减少 GPU 闲置时间，提高整体的训练或应用性能。

上图中展示了 3.2 版本、3.1 版本和 2.9 版本之间的性能对比。图中最下面的线代表 3.1 版本，最上面的线代表 3.2 版本。3.2 版本在顺序热度上的性能提升显著，无论是在单并发还是高并发的情况下。而 2.9 版本是社区开源版，未进行专门优化，存在一些问题，尤其在高并发情况下性能急剧下降。

在随机读性能上，3.2 版本和 3.1 版本表现优秀，能达到接近 8 GB 每秒的读取速度。相比之下，2.9 版本的随机读几乎没有优化，性能较差。在最新的 3.2 版本中，单节点单 fuse 单 worker 单并发情况下能达到 2 GB 每秒，多并发 32 线程及以上能达到 8 GB 每秒。随着集群规模增加，性能呈线性增长，如五个 worker 可达 40 GB 每秒。

2. 新增 API

3.2 版本主要针对 FUSE 进行了优化，同时并提供了 Python 和 S3 的 API。由于 fuse 是用户态的文件系统，存在性能瓶颈，如传输过程中受 block size 和 kernel 上下文的影响，导致无法达到极致的 I/O 性能。尽管我们已经尽可能优化了 FUSE 在各种场景下的 IO 性能，但仍有天然瓶颈。因此，我们基于 Python 提供了新的 SDK 和 API，可以通过 fsspec 直接访问 Alluxio。对于 S3，我们通过零拷贝方式完成数据传输，并在各个场景下进行了性能测试，发现其性能都优于 fuse 场景。

3. 稳定性和易用性提升