利用 NVMe、GDS 和 RDMA 探索更快速 GPU 训练的分布式缓存技术

导读 本文将从工程化的角度，介绍 Alluxio 如何通过分布式缓存，同时结合现在常用的 NVMe、GDS 以及 RDMA 技术来加速 GPU 训练。

在第一部分中，将分析当前大语言模型时代中 IO 在整个的 AI 框架中的作用与影响，并探讨当前浪潮下 IO 所面临的挑战与机遇

第二部分将深入介绍当前 AI 平台中主流的三种 IO 访问模式，从中引导出为何需要一个分布式的中间缓存层

第三部分将详细介绍 Alluxio 是如何构建一套具有高性能、高可扩展性的分布式缓存系统，以满足现代 AI 以及数据密集型应用需求的。

第四部分会分享 Alluxio 当前正在探索的实验性课题，包括在硬件层面如何利用 GDS 和 RDMA 等技术来进行深度优化的最新进展。

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

1. 大模型时代下 IO 的重要性

2. 几种主流 IO 方式

3. 如何设计一个高性能、可扩展的 GPU 缓存

4. 使用 NVMe、GDS 和 RDMA 来加速

5. 客户案例

分享嘉宾｜汤文军 Alluxio 解决方案架构师

编辑整理｜胡俊琪

内容校对｜李瑶

出品社区｜DataFun

---

01

大模型时代下 IO 的重要性

首先从工程化的角度来思考一下 scaling law。为什么在大语言模型的场景下， IO 的影响是至关重要的？Scaling law 最早是由 OpenAI 的研究人员在 2020 年提出的，主要描述了大语言模型的性能如何随着模型的规模、数据量的规模和计算力的增加而变化的数学规律。这一理论为 AI 系统的构建者提供了一个优化资源配置和预测模型性能的基础理论依据。

根据 scaling law，如果我们要构建一个更强大的模型，就需要更多的 token，也就是更大规模的数据集，这些海量的数据需要通过 IO 供给 GPU 来进行计算。此外，随着模型的扩大，相应的参数数量也会随之提升，这意味着在训练过程中需要更频繁地保存 checkpoint。随着大模型在算力、数据规模以及模型参数方面的大规模的增长，我们认为 IO 效率瓶颈已经成为制约 AI 训练性能的一个核心问题，提升 IO 效率是优化 AI 平台的关键。

大语言模型规模正在快速扩张，从最初仅有几亿参数的小模型，到如今拥有千亿甚至万亿的超大规模模型。人工智能的能力爆发式增长，对数据集的需求也呈现出指数级的提升，这些庞大的数据集不仅对存储能力提出了严峻挑战，更对 IO 的效率带来了前所未有的挑战。为应对这些挑战，不仅需要硬件性能的不断提升，还涉及到数据存储格式的优化，包括分布式文件系统的高效部署，以及数据预处理流程的全面改进。在这一过程中，我们认为高效 IO 成为释放超大规模模型潜力的关键所在。

随着当前模型的迅速扩张，我们的参数数量也从早期的 7B 增长到了当前的将近一个 T，这也意味着模型文件的体积会变得越来越庞大。在训练过程中，AI 框架要更加频繁地去刷新这些 checkpoint 以保持中间状态，防止训练过程中状态数据的丢失。然而在存储这些 checkpoint 时， GPU 会因为写入操作而进入阻塞的状态，导致无法执行正常的训练任务，显著降低了 GPU 的利用率。因此，我们需要一种能够快速完成 checkpoint 写入的机制，同时还要能够适应 checkpoint 文件体积不断增长的需求。高效的 checkpoint 管理对于 GPU 的利用率和训练效率至关重要。

基于上面的介绍可以看到，第一是如何拉取训练数据，第二是如何管理 checkpoint，这两个问题都对 IO 效率提出更为严苛的要求。

同时我们也注意到，现在新型的硬件技术正在为优化人工智能基础设施注入动力，尤其是在应对大规模模型训练中的 IO 挑战方面，例如 NVMe 存储技术已倍广泛使用，通过更快地访问持久性存储可以大幅降低延迟，提高数据处理效率。另外，利用 RDMA 技术，无需通过 CPU 即可进行内存访问，显著加速了数据传输速率。还有大家正在摸索中的 GDS 这样的 GPUDirect Storage 技术，可以实现 GPU 和存储之间的直接数据传输，绕过系统内存，从而有效地缓解数据传输中的瓶颈问题。这些前沿的技术的应用和普及正在塑造我们对这些大规模型训练中 IO 系统的认知。这也引出了一个关键问题，如何能够充分地把这些技术利用到 AI 平台，构建一个更加高效、可扩展的 IO 系统。在模型和数据规模持续爆发性增长的背景下，确保 IO 不会成为 AI 工作负载的瓶颈，当前显得尤为重要。因此我们希望能够提供一套完整的解决方案。

当前的 AI 平台通常采用上图中的架构模式来处理计算节点和存储之间的训练流量。在这一架构中，后端网络主要负责管理训练数据的流动，而前端网络则承担数据集的 load 和checkpoint 的存储管理。我们将重点关注图中橙色框标注的 Training Dataset Storage 和 Checkpoint Storage 部分，后文中将以 Alluxio 的架构为例，探讨如何设计一个具备高扩展性的分布式存储系统，并且具体说明其中的一些设计理念和实践方法。

02

几种主流 IO 方式

第一种方案，是最直观的方案，也就是直接连接云存储来进行训练。这种方式的主要优点就是管理简单。因为云数据湖可以作为一个唯一的数据源，无需额外的部署，也无需额外的复杂的基础设施。

然而这种方法也存在着一些明显的缺点。首先性能可能会比较慢，并且稳定性得不到保证，例如像 AWS、 S3 这样的云存储服务可能会因为延迟或者限流的原因出现类似于 503 这样的错误。其次，大规模访问云存储也可能会带来一些高昂的成本，包括流量的成本、跨区的成本。这些在与 CMU 以及 Uber 的一些相关案例研究中有充分的体现，可以参考上图中的链接。

总体而言，尽管直接访问云存储的方法操作非常简单，但是在高性能的训练场景中在性能和成本方面都面临着巨大的挑战，并不是大规模训练的理想解决方案。

如果不用云存储，那么第二种解决方案就是在云存储和训练集群之间引入高性能的存储，比如 HPC 的解决方案。这种方法主要优势在于能够显著提升 IO 性能，从而加快训练的访问速度，确保训练工作中的稳定和高效。

但是这种方案也伴随着一些缺点。首先是高成本，当前市场上的高性能存储的解决方案价格是很贵的，尤其是在大规模的部署中，基础设施的成本会显著增加。另外，管理复杂性也会增加，因为要将数据从底层的数据湖迁移到高性能存储，会增加额外的管理负担，包括数据迁移和日常维护都引入了更多的复杂性。第三点就是可扩展性受限，尤其是在多区域和多云的环境中，这种方案的可扩展性非常差，如果我们的集群需要跨区域部署，那么需要在多个区域之间引入 HPC 的 storage，这样就会引入额外的基础设施的成本以及出口流量的费用。同时，整个过程还会受到带宽的限制。

总体而言，我们认为高性能存储虽然带来了比较好的 IO 性能，但是在面对跨区域扩展的需求中，其高成本和复杂性限制了其适用范围，尤其是在当前需要灵活扩展的一些 AI 场景中。

因此，我们提出了方案三，添加高性能缓存层。这种方法的关键优势在于，首先它能够像高性能存储一样提供高效且稳定的 IO 性能，为训练过程加速；其次，与高性能存储方案不同的是，这种缓存层允许我们以数据湖为唯一的数据源，无需进行额外的数据迁移和维护，大大降低了管理的复杂度；同时，因为我们只缓存经常访问的热点数据，按需从数据库中获取其他的数据，所以可以有效降低存储以及带宽的成本；最后，这种架构具有卓越的可扩展性，能够无缝扩展到多区域或者多云的环境中，无论是在美西还是美东，各个区域都可以通过分布式的缓存快速地访问热点数据，并仅从数据湖中提取所需的数据，从而轻松解决高性能存储方案在扩展性上的限制。

总体上看，高性能缓存方案不仅能够提升 IO 的性能，同时能降低整体的复杂性和成本，是一种更加灵活且高效的解决方案。下面就来详细介绍 Alluxio 是如何实现这套高性能、高扩展性的分布式缓存的。

03

如何设计一个高性能、可扩展的 GPU 缓存

上图展示了 Alluxio 存在的位置。Alluxio 是一个面向 AI 和大数据分析的高性能数据访问层，其核心理念是通过一个高性能可扩展的数据访问层，将上层的不同计算引擎和下层的不同存储之间连接起来。此外，由于 Alluxio 位于现有数据库之上，用户无需担心数据副本和管理问题，从而可以降低数据工程的复杂性和成本。

通过这样的架构设计，不仅能够满足 GPU 对 IO 训练的严格需求，同时还能够对不同存储系统的数据进行虚拟化，从而使企业能够以统一访问的方式来管理来自不同数据源的数据。

Alluxio 的主要优势包括：

• 首先，可以加速数据密集型的工作负载，对于 AI 和大数据分析可以提供快速的数据访问，极大地缩短训练时间，尤其是在大规模语言模型以及多模态模型的训练中这一优势尤为突出。

• 第二，可以提供统一的多存储系统的统一命名空间。Alluxio 支持将多种后端存储，包括 S3、Hadoop、HDFS 以及本地存储全部接入，用户可以通过统一的命名空间来管理这些后端存储的数据。这种虚拟化能力能够让企业可以在不同的存储环境中自由切换，无需改动底层的存储架构。

• 第三，Alluxio 只缓存热点数据，从而可以降低存储成本以及网络带宽的消耗。数据按需从数据库中检索，确保始终缓存一直要使用的热门数据。

通过 Alluxio，我们希望能够给 ML 应用或者是 AI 平台带来更快的模型开发与部署效率，并提供更好的数据管理通道，降低数据工程的复杂性和 AI 基础设施的成本。

上图展示了一些正在使用 Alluxio 产品的国内外知名公司。

Alluxio 的前身是 Tachyon，它是 Berkeley 实验室提出的一个分布式虚拟内存存储系统，其设计初衷是为大数据和分布式计算环境提供更高效的存储层。在 2015 年，该项目更名为 Alluxio，并持续发展成为支持多种存储后端的一个高性能分布式缓存系统。

下面详细介绍 Alluxio 是在如何满足 GPU 训练场景下的一些核心问题的。在大规模的 AI 或者 ML 训练中，我们需要一个高性能的数据访问层来解决以下问题。

• 第一个是编程接口。Alluxio 提供了接近 POSIX 的一个编程接口支持常见的文件操作，方便开发者在多种环境中无缝迁移使用。

• 第二是数据格式。Alluxio 支持多种数据格式，既支持 Parquet 这样的结构化数据，也支持各种非结构化数据，例如音频、视频、图片和文本，涵盖了机器学习和多模态训练中的各种需求。

• 第三是元数据扩展能力。对于计算机视觉或者多模态训练，模型可能需要处理数以十亿计的文件。Alluxio 的元数据架构支持大规模的并发扩展，可以轻松应对海量文件的挑战。

• 第四是 IO 并发。在训练过程中，模型需要同时从多个 GPU 中并发读取数据。Alluxio 支持高并发的读取操作，可以确保数据访问不会成为瓶颈嗯。

• 第五是可靠性。大规模的训练通常需要运行数天甚至数周的时间，Alluxio 可以提供高可靠性的架构，确保用户在训练过程中不会因为数据的访问问题而导致训练失败。

• 第六是写入能力。Alluxio 提供了高效的写入能力。模型训练中的检查点操作需要高效的写入性能，Alluxio 对于顺序写进行了深度优化，大幅缩短了检查点 writing 的时间，降低了训练中断的风险。

上述这些需求推动了 Alluxio 核心架构的变动，在 3.0 版本中进行了较大的架构调整。

第一个核心的架构变动是从传统的存储系统架构（标准的元数据服务器加数据服务器的架构），迁移到了全分片，即无主架构。在这种架构中，客户端会通过一致性哈希来自主决策访问的 worker 节点的路径。

通过这种设计，集群将不再依赖于单一的 master 集群管理的数据，从而从根本上消除了在 AI 场景下海量小文件，例如 100 亿 dataset 小文件这种场景下对元数据服务造成的巨大压力，避免了因为过载而导致的集群不可用的问题。这种架构也确保了集群在扩容 worker 节点的时候基本上能够实现性能的线性增长。此外，去中心化的设计消除了单点故障的风险。同时，由于移除了 master 节点对关键路径的依赖，IO 延迟也得到了降低。

我们还得到了一个额外的好处，就是平台可以将 Alluxio 视为一个标准的逻辑文件系统。Alluxio 为上层应用提供了一个统一的接口访问，我们可以在下层对接不同类型的后端存储，屏蔽不同存储厂商带来的运维差异。例如我们可以从 S3 或者是 HDFS 后端存储中拉取所需要的数据。用户可以通过 Alluxio 虚拟出来的逻辑路径来访问数据，比如以 Alluxio 协议开头的路径，或者是直接使用原始的协议，例如 HDFS 或者 S3 这样的协议来直接拉取数据。Alluxio 提供了透明 URL 的能力，使用户能够在使用原始协议的同时能够享受到缓存的优势，避免对现有应用产生侵入性的影响，大大简化了应用迁移到 Alluxio 平台的过程。

下面来探讨一些具体的技术细节。

首先是一致性哈希，Alluxio 利用这一技术将数据和元数据分别缓存到多个节点，避免了传统架构中集中化的瓶颈。这种设计的直接效果就是减少了 IO 请求的 RPC 路径，大幅提升了数据访问的性能。另外，全分片架构摒弃了单点故障的风险，提高了系统的可靠性，即使某个节点发生故障，仍然不会影响数据的访问和整个训练过程。

另外，因为移除了 master 节点的关键路径依赖，master 节点不再是系统中的性能瓶颈。

同时，通过优化资源分配，我们将 master 从 IO 的关键路径中移除，避免了传统架构中集中性能问题。Alluxio 充分利用了零拷贝技术，尽可能地去减少数据传输中的内存复制操作，从而进一步提升性能。这种优化对于高并发、低延迟的 IO 请求是非常重要的，能够显著提高 GPU 训练任务的效率。

通过这些架构的优化， Alluxio 实现了 IO 延迟的显著降低，吞吐量大幅提高，特别适用于大规模并发的 GPU 训练场景，并且通过一致性哈希和去中心化设计，使系统具备极高的容错能力，能够保证训练任务的连续性。

下面来看一下通过上述优化带来的实际的 performance result。

• 首先，在高性能方面，在缓存服务中，每个工作节点可以达到每秒数十 GB 的吞吐，这个数据吞吐量大部分都是受限于整个硬件的处理性能的限制。我们这一能力让 Alluxio 可以高效处理大规模的并发数据请求，非常适合于需要快速数据加载的 GPU 训练任务。Alluxio 可以提供高效的缓存预加载能力，能够充分利用存储网络的带宽。在训练任务开始之前就可以快速将数据加速加载到我们的缓存中。这样可以显著减少训练任务在运行时的数据加载延迟，从而提高整体的训练效率。

• 第二，在低延迟方面，Alluxio 能够实现亚毫秒级甚至个位数毫秒级的低延迟，确保数据能够得到快速的响应。这对大规模语言模型或者需要频繁访问数据的小批量训练任务显得尤为重要，能够有效避免 IO 成为训练瓶颈。

• 第三，在线性扩展方面， Alluxio 的架构支持容量的线性扩展，能够轻松处理数百亿的对象和文件。随着数据规模、数据复杂性的增加，依然能够保持高效的性能表现。通过增加工作节点的数量，能够在吞吐量和数据并发性能上实现类似线性的增长，为企业应对不断扩展的数据需求提供坚实的扩展性保障。

• 最后，Alluxio 的全分布式架构也确保了即使在节点扩缩容或者是故障的时候，数据的访问性能和系统稳定性依然能够得到保证。

除性能之外，Alluxio 从另外一个角度也给用户提供了一个更高效的解决方案。通过 Alluxio 可以无缝地进行数据访问，显著提高AI 模型开发效率。Alluxio 提供了统一的一套接口，可以无缝地访问分布在不同存储系统中的数据，无论是对象存储还是 HDFS 或者是本地存储，开发人员无需关注底层存储的差异，只需要关注模型的开发和优化效率即可。

• 首先，Alluxio 可以帮助用户避免数据迁移或复制。在传统方法中，数据迁移和临时的数据副本的管理不仅费时费力，还增加了存储成本。利用 Alluxio 可以直接从源头访问数据，省去了这些繁琐的迁移过程以及重复制的过程，可以显著提高效率。

• 其次， Alluxio 完全兼容现有的工具和框架。Alluxio 的架构设计与现有的 AI 工具能够和框架能够完全兼容，无需对代码进行任何改动，开发人员可以继续使用熟悉的工具链，同时享受到 Alluxio 带来的性能提升。这种无缝集成可以显著降低技术门槛。

• 最后， Alluxio 也提供了统一的身份验证和安全管理方案。对于底层的分布式存储系统，用户可能使用不同的身份验证机制，增加了数据管理的复杂性。Alluxio 提供统一的身份验证方案，简化了多存储环境下的安全管理，确保数据访问的安全性和合规性。

通过无缝的数据访问和对现有工具的兼容性，可以使企业的 AI 应用开发更加高效、更加便捷，提升企业竞争力。

04

使用 NVMe、GDS 和 RDMA 来加速

1. 应用 NVMe SSDs 架构

我们用 FIO 的客户端来验证 Alluxio 的 worker 节点能够提供的整体 IO 存储率的性能， worker 和相应的压力生成器 client 配置如下。可以看到核心的网络瓶颈是在 100G 带宽时单 worker 顺序读的性能。

其中 x 轴是并发的客户端数， y 轴表示的是每一个 worker 节点的吞吐，可以看到客户端在生成 8 个并发的时候，就可以在 worker 端达到 8GB 每秒的顺序读的性能。这一结果受到了 100G 带宽以及整个 SSD 协议栈的影响。所以我们认为已经基本上达到了硬件瓶颈，并且随着客户端并发数的压力增加，整个 worker 仍可以保持非常稳定的性能输出。这对于海量并发请求场景而言是非常重要的，即使达到了 128 个并发请求，整个 worker 的性能也不会出现明显下降。

这是 worker 的随机读的性能，并发数达到 32 以后，可以达到 worker 的最佳性能基线，也是 7GB 每秒的性能输出。

同样，随着客户端并发数的增加，worker 性能也能保持稳定的性能输出。可以看到 Alluxio 在集群环境下的可扩展性，我们将 worker 节点从 1 个增加到 4 个，可以看到在多客户端并发测试情况下， Alluxio 的总吞吐量基本上可以做到根据 worker 节点数目的大概率的线性增长，尤其是在客户端压力并发数越来越大的时候，线性增长的趋势会越来越明显。这一特性主要得益于无主的全分片架构。

从上面这个角度来看， Alluxio 的 worker 其实已经达到整个存储磁盘存储和网络的硬件瓶颈。

2. 网络传输

下面来看一下 Alluxio 在网络传输层面做了哪些优化。高效的数据传输也是 Alluxio 的一个性能关键点，之前 Alluxio 使用 GRPC 去做整体的底层数据传输。虽然在 Java 的客户端实现中， GRPC 依赖了 Java 里面的 Netty 库，但是我们认为 GRPC 很难做到底层的性能优化，所以在近一两年，我们直接将之前的 GRPC 架构做了优化，直接将数据面切换成了 Netty，但是控制面仍然用 RPC 去做数据面的传输。

Netty 的这个异步框架的 IO 异步非阻塞的 IO 模型可以高效地处理大规模的并发请求，可以大大降低 IO 瓶颈，让系统能够同时处理多个数据。同时，我们利用系统里面的 center file API 大幅提升了磁盘到网络零拷贝的性能。我们还优化了 lighted 的零拷贝技术，避免数据在内存中的多次复制操作，提升了内存的利用率。另外，我们将大文件顺序读取的性能提升了 30% 到 50%。还有一个问题是 high current position read 问题，我们在读放大问题上做了大量优化，来提升高并发性能下的 producer read 的性能。对于非结构化文件的随机读取，我们将读放大问题降低到最小，实现了高达 9 倍的读取性能的提升。对于结构化数据，Alluxio 也实现了 position read 的 2 到 15 倍的提升。以上就是我们在网络层面的一些优化。

这一点是我们的一个 experimental 的一个特性，我们正在实验性地支持 RDMA 的技术，通过 UCX 的框架来实现更快速的一个数据传输。这个技术的话可以直接在计算节点直接传输数据，绕过 GPU 来进一步减少延迟和资源消耗。

3. 试验性的：提升 checkpoint 效率

我们尝试将 GDS 和 RDMA 技术结合，将 GPU 的显存数据直接传入到 worker 来提升模型训练中 checkpoint 的效率。

在大语言模型和深度学习的训练中，我们认为检查点的操作是保证整个训练进度和训练安全的关键环节，但是随着模型规模的不断扩大，检查点操作的频率和数据量都显著增加，传统方法很难满足性能需求，所以我们在探索一种实验性的解决方案，结合 GPUDirect storage 以及 RDMA 技术来优化检查点流程。

GDS 允许 GPU 与存储设备之间直接进行 IO 操作，绕过主机的内存路径，减少一些不必要的数据传输延迟。这种优化使得 GPU 的数据可以快速存储到远程节点，极大提升训练效率。同时利用 RDMA 可以允许节点之间直接传输数据，无需经过 CPU，避免了上下文切换带来的性能损失，并且结合刚才提到的 UCX 框架 RDMA 可以实现更低延迟和更高吞吐的网络传输性能。

在 Alluxio 的实验性架构设计中，我们深度优化传输路径， GPU 显存的数据可以首先通过 GPUDirect 直接传输到远程 Alluxio worker 节点，避免中间步骤带来的性能瓶颈。在 Alluxio worker 节点上，数据从 GPU 内存传入到 CPU 内存，再写入到 NVME 存储中。这样做最大的优点就是可以解决客户端与 Alluxio worker 节点之间的 RDMA 通信问题，从而显著减少检查点的操作时间，提高模型训练的效率和可靠性。但是有利就会有弊，目前如果要支持这种特性的话，需要相应的硬件支持，比如 RDMA 和 GPUDirect 的存储功能。另外，在 worker 节点仍需要将数据从 GPU 的内存复制到 CPU 内存，这其实也增加了额外的开销，我们认为这种加速检查点的操作可以减少检查点的写入延迟，使得模型可以更频繁地保存训练数据，防止数据丢失。

对于大模型的训练，我们认为这种优化是尤为重要的。通过 GPUDirect 和 RDMA 的结合，我们正在探索一些更高效的解决方案。

05

客户案例

最后一个部分将介绍一个典型的客户案例，让大家感受一下真实用户是如何使用 Alluxio 来加速模型训练以及模型部署，同时解决多云的环境下训练集群推理及集群相关复杂性管理问题的。

1. 客户的情况

这里展示了客户的 AI 基础框架，客户在多个云平台上运行着训练集群，同时在自建 IDC 中也部署了多个训练集群，核心的数据湖服务也是位于自建的 IDC 中作为统一的存储解决方案为外部的云上集群提供数据支持。

云端的训练集群需要从数据库中拉取训练数据，而推理集群则会访问数据湖以获取 checkpoint。此外，AI 平台还需要服务于众多的内部客户，需要管理数千张 GPU 卡，并支持上百位数据科学家进行数据训练，每天处理数千个训练任务。这种复杂的布局虽然满足了多场景的需求，但是也带来了诸多的痛点和挑战。

2. 客户的痛点

• 一个挑战就是之前用户在训练集群部署了云端的对象存储服务，为训练集群提供训练数据，同时将 checkpoint 保存到本地存储，以提高云上训练集群的训练效率。自建集群仍然依赖核心的数据服务，负责提供训练数据和存储的 checkpoint。为保证核心数据服务与云端对象存储之间的数据一致性，客户有许多自研工具用于在两者之间进行数据的同步和管理。然而这种架构存在一些核心的问题，第一就是性能的瓶颈，云端的对象存储性能较差，难以满足 GPU 高吞储率的需求，直接影响用户的训练效率。

• 第二是复杂性，由于需要在多个云上维护对象存储服务，且不同云的对象存储产品的特性各有差异，增加了部署和整体流程的管理复杂度，也带来了高成本和低可维护性。为保持多个对象存储和核心数据库之间的数据同步，不仅大幅增加了存储成本，还显著降低了系统的可维护性和稳定性。这种架构的限制使得用户难以在多语言和自建环境中实现高效统一的数据管理，迫切需要一种更优的解决方案。

3. 客户使用 Alluxio 后

引入 Alluxio 为客户带来了以下几个核心收益：

• 首先，显著缩短了生产部署时间，通过 allocation 和 community 的结合，用户可以将生产部署时间从之前的数周缩短到分钟级别。传统流程中，从开发环境到生产环境往往需要数周的时间，而引入 Alluxio 以后，这一过程被压缩到大概 10 分钟左右。此外，数据无需从数据库迁移到对象存储，直接省略了这一繁琐的步骤，使整个流程更加高效和简洁。

• 其次，提升了 GPU 的投资回报率。在引入 Alluxio 之前， GPU 的利用率长期偏低，例如 500 台 GPU 仅有 30% 用于训练大模型语言。大模型语言模型通过 Alluxio 的优化， GPU 利用率得到了显著提升，从 30% 增长到了 90%。同时，其他模型，例如搜广推类的利用率也从 20% 提升到了 40%。更为重要的是这种效率的提升支持客户将集群中的 GPU 规模从 500 台扩展到了 2000 台，大规模提升了整体的计算性能和产出。

• 最后是加速整个训练，借助 Alluxio 的高效缓存，客户的训练时间显著缩短，训练速度整体提升了 2.5 倍。为机器学习工程师带来了更快的迭代速度和更高的开发效率，显著缩短了模型的开发周期。

除了训练阶段， Alluxio 还可以帮助用户提高模型部署阶段的效率。通过提供统一的运行空间，可以显著提升易用性。Alluxio 提供了一个统一的数据访问视图，不管数据是存储在本地还是在云端，还是在对象存储中，用户都可以通过统一的协议来访问。因此在部署模型的阶段，云上的推理集群只需要通过 Alluxio 就可以无缝地访问数据湖中的 checkpoint 数据，无需专门单独拉取，方便使用。

其次，通过 Alluxio，企业可以减少冗余数据副本的创建以及繁琐的迁移过程，从而降低至少 50% 的存储和维护的成本。维护成本大幅地降低是因为统一的管理数据面减少了操作的复杂性。

最后在模型部署阶段，Alluxio 通过优化数据分发的流程将原本需要 10 分钟的模型分发时间缩到了 3 分钟，这意味着企业可以更快地将更新的模型推向生产环境，从而提升整个环境中业务的响应速度和市场的竞争力。

以上就是本次分享的内容，谢谢大家。