训练效率提升 40% 丨多云架构下高效存储策略详解

破题大模型算力荒，如何打造高性能存储底盘？

2024 中国生成式 AI 大会于 4 月 18-19 日在北京举行，在大会第二天的主会场 AI Infra 专场上，焱融科技 CTO 张文涛以《多云环境下大模型训练和推理的高效存储》为题发表演讲。

随着大模型训练和推理需要的算力越来越高，单个数据中心已经无法满足大模型训练所需要的算力要求，需要多数据中心进行训练和推理。

多个数据中心存在多份数据拷贝的成本越来越大，如何在保证性能的前提下，让数据按需跟随算力进行流转，成为大模型厂商和存储厂商要解决的难题。从数据加载、模型加载到 Checkpoint 保存等过程中，存在大量的读写请求、元数据访问和内存拷贝等操作。在此背景下，张文涛解读了存储对大模型训练和推理的重要性和一些可行方法。

对于多模态大模型，高性能存储对训练的提升效果更好，效率可提升 20-40%。针对训练推理，焱融科技推出了多云存储解决方案。基于统一的数据湖底座，通过数据编排将数据按需加载到数据中心，并异步将新增的模型数据推到数据湖。数据加载支持对接 OSS、COS、BOS 等各大主流对象存储平台。

【以下为焱融科技 CTO 张文涛的演讲实录】

焱融科技专注于高性能分布式文件存储，是英伟达在中国的合作伙伴之一。在 Gartner 中国软件定义存储竞争格局报告中，我们是唯一一家专注于文件存储的厂商。

我们曾参与过 IO500 测试，全球排名第六，是国内首家进入云原生存储领域的公司。去年，焱融科技入选了赛迪中国式存储挑战者象限，展现了我们在行业中的竞争实力。焱融科技的产品在 AI 和智能汽车行业占有领先地位。

接下来，我们将分享三个主要方面：第一，为什么存储对大模型训练和推理很重要；第二，大模型推理和训练的解决方案；第三，在当前算力短缺的情况下，我们不得不采用多云方式进行训练和推理，在此过程中，将会遇到哪些问题，又该如何去解决？

01.大模型场景六大环节需要存储，优秀方案能平衡性能与成本问题

大模型场景里有哪些环节，这些环节里对存储又有哪些诉求？主要分为六个部分。

第一，数据采集。包括从第三方购买数据、网络爬取以及现场采集。由于采集方式各异，存储访问也需考虑多种协议。采集的原始数据量较大，因此需要高容量、低成本的存储方案。同时，我们希望存储能够支持高并发、高带宽。

第二，数据预处理。包括清洗、筛选、格式转换和集成。这一过程涉及多个环节，对存储而言需要支持多种协议，如 NFS、SMB、S3、HCFS、POSIX 等。在数据预处理中，需要进行大量的数据检索，从各个维度提取数据，满足不同的检索需求。数据在此阶段的特点是混乱的，IO 大小和读写方式也是混合的。

第三，模型训练。在存储方面相对简单，但也具有挑战性。在这一阶段，性能是关键，包括对读取带宽、读取 IOPS 和写入带宽的要求，以及整体低延迟的需求。

第四，模型验证。这也是训练过程的一部分。

第五，推理。推理本身并不需要频繁访问存储，其主要对存储的需求源自模型的部署和更新。在模型部署和更新时，要批量将模型加载到 GPU 中，这可能引发类似启动风暴的问题，需要瞬时加载大量数据，峰值瞬时流量可能达数十 TB。

第六，数据归档。随着数据的不断增加，涵盖了模型数据、数据集以及原始数据，数据治理问题日益显现。在存储方面，我们期望实现全生命周期的数据管理，最好是基于时间维度的方式。随着数据访问热度的降低，我们希望自动将冷数据转移到低成本的存储介质上，但同时保证当需要访问时，数据能够随时可见。

这几个环节对存储的需求很高，特别是在模型的训练和推理阶段，这两个环节尤为挑战性。

为何存储在这两个方面至关重要？主要有两个原因。

首先，存储直接影响了模型训练的效率。在训练过程中，需要从存储加载模型和数据，并定期将 GPU 内存中的数据保存到存储中。在每个环节，存储都必须提供最佳性能。

其次，推理业务上线时通常会同时启动数十甚至上百个业务 pod，需要瞬时提供几十 TB 的流量。例如，一个量化后的模型可能有数十 GB 甚至上百 GB，几十个业务 pod 同时启动，会产生巨大的瞬时流量。由于模型更新频繁，业务上线的延迟应控制在分钟级别，并且希望不受推理业务规模扩大影响，以避免存储带宽峰值对模型下载延迟的影响。优秀的存储解决方案不仅能够解决这些问题，还能平衡性能与成本。

02.高性能存储如何影响训练与推理？缩短多模态训练时间可提升 40% 效率

接下来介绍一下存储对于训练的影响，在训练过程当中，有 4 个地方会对存储有要求：

1、数据的预读和训练。我们进行数据训练时，需要将数据从存储加载到 GPU 进行计算。在这个过程中，可能会采用预读机制或直接读取方式。特别是在 Batch Size 较小时，会产生大量小的 I/O 操作。在多模态大模型中，由于存在许多图文对形式的小文件，因此会出现大量小文件访问带来的大量元数据操作。

2、POSIX 和 GDS 协议。尽管当前许多训练任务都使用对象存储，但在训练阶段，实际上还是通过文件接口进行访问。只有文件接口能够提供高性能，并且具有最佳的兼容性。随着越来越多的训练任务面临内存拷贝性能问题，将数据从 CPU 内存拷贝到 GPU 内存时，性能问题变得突出。目前，许多客户开始尝试使用 GPU Direct 技术来加速性能。

3、模型的加载。当启动新的训练任务，或由于其他原因需要重新启动训练时，需要将模型加载到 GPU 中。在这个过程会产生大量的读取 I/O。英伟达在 2021 年发表了一篇论文，关于千卡规模，当时的存储峰值读取带宽可达到 1TB/秒。

4、Checkpoint 的保存。在训练过程中，Checkpoint 起着重要作用。由于有大量 GPU 同时进行 Checkpoint，且 GPU 的故障率相对较高，因此需要定期保存 Checkpoint。这个过程本身就是保存一个模型，保存过程中，训练状态会暂停，并进行同步等待。保存过程的时长越短，训练的 GPU 利用率就越高。

这个图比较直观，红色表示数据加载，绿色表示训练，黄色表示 Checkpoint 保存。

对于大语言模型而言，由于其训练集较小，存储访问占比并不会很高。但是对于多模态大模型，尤其像 Sora 模型，数据访问占比较大。对于训练任务来说，普通存储和高性能存储之间的差异会非常明显。高性能存储能够大大压缩存储访问时间。对于多模态任务来说，缩短训练时间可以提升 20% 至 40% 的效率。

在英伟达的最佳实践中，对于 NLP 任务，单台 GPU 只需要 4GBps 的读取带宽。但对于多模态任务而言，单节点需要 40GBps 的读取带宽，基本上需要一张 400Gb NDR 的卡来处理。一个 SuperPod 需要 500GBps 的读取带宽，这个要求是相当高的。

存储对推理的影响主要集中在模型加载和更新的过程。在启动推理业务时需要先加载模型文件，模型文件大小在几十 G 到上百 GB 之间，而一次性会启动几十个 pod，因此整个数据量可达几十到上百 TB。

推理业务通常部署在边缘节点，其 GPU 配置不如训练集群那么高。在这样的环境中，存储和计算之间的网络带宽通常也会受限，一般为 25Gb 的以太网络。此时启动整个推理业务时的延迟会很高，在启动和扩容过程中会遇到严重的启动风暴问题。

03.基于四大核心组件，精准部署存储解决方案

我们的大模型训练和推理过程的存储解决方案基于 YRCloudFile 系统，整体架构包含四个核心组件：1）集群管理服务，采用一主多备的高可用架构；2）元数据服务，支持海量小文件场景，我们的元数据集群能够横向水平扩展；3）集群服务，能够水平扩展；4）客户端。相比于基于 FUSE 的用户态私有客户端，它有更高的性能。

在硬件方面，我们能够支持标准 x86 架构，也支持 Arm 架构的鲲鹏服务器、海光服务器和飞腾服务器；在数据冗余方面，支持副本的方式，也可以支持低成本的纠删码的方式；在网络方面，支持 25Gb、100Gb、200Gb 的以太网，以及支持 200Gb、400Gb 的 Infiniband 网络，也支持 RoCE 网络；在协议层面，支持标准的 NFS、SMB、S3、HCFS 以及私有的 POSIX 协议。

针对大模型训练场景，我们提供了一系列功能和特性，以支持和加速模型的训练过程。

其中包括 Multi-Channel 技术，支撑单节点提供超高性能带宽和 IOPS 的核心技术。

其次是 GPU Direct Storage（GDS）技术。随着客户内存的不断增大，传统的缓存技术已经无法满足数据集的存储需求，GDS 技术应运而生。

还有内核私有客户端，能够减少上下文的切换，能够提供高带宽和 IOPS。

第四，能够支持 400Gb NDR 的网络，结合 Multi-Channel 技术，在 x86 架构下，提供单节点 90GBps 的带宽，以及 300 万 IOPS 的性能。

针对多模态的海量小文件场景，我们提供了分布式元数据集群，单个集群能够支撑千亿级的文件数量。我们线上最大的单一集群包含接近 400 亿文件，拥有 100 多个元数据节点，是目前线上最大的单一元数据集群。

在功能层面，我们提供了多种功能。

第一，智能分层。能够有效地将数据下沉到对象存储中，从而极大地降低成本。即便在提供高性能的情况下，也能够实现低成本。

第二，目录级 Quota 和 QoS。为运维人员提供方便的管理工具，同时提供了日审计和回收站功能，使运维同学能更好地应对客户的需求和问题。

第三，协议网络支持。近一年来，对多协议网络支持的需求急剧增加。由于 GPU 卡供应紧张，数据中心构建时出现了异构网络场景，既有 InfiniBand 网络，又有以太网。

在这种情况下，构建多套存储是不现实的，因为存储之间不互通，且会增加成本和管理复杂度。我们提供了多网络协议支持，在同一个集群中可以同时支持 InfiniBand 和以太网访问，方便数据中心存储设施的构建和管理。

GDS 技术的最大优势在于能够有效减少 CPU 和 CPU Memory 的使用，从而极大地降低了 CPU 的利用率。在没有 GDS 技术时，数据的传输路径通常是从网卡拷贝到 CPU Memory，涉及多次内存的拷贝。而使用了 GDS 技术后，数据可以直接从网卡经由 DMI 方式传输到 GPU 的 Memory 里面，减少了内存拷贝的次数，有效降低了 CPU 的利用率。

接下来是一些我们在实验环境和客户现场测得的数据。

我们对比了使用 GDS 和不使用 GDS 的情况，在带宽和延迟方面都取得了显著的性能提升。具体来说，在带宽方面，使用了 GDS 后，整体带宽性能提升了近 40%；而在延迟方面，我们观察到有 50% 至 60% 的性能提升。

当然，在低负载情况下，性能提升不太明显，但在高负载情况下，其效果显著。这与 GDS 的作用相符合。在 CPU 利用率方面，我们可以看到，在高并发量的情况下，CPU 负载显著降低。使用了 GDS 后，CPU 的利用率基本上处于空闲状态。

针对推理环节的解决方案，主要在于存储和计算之间的网络瓶颈。由于推理集群通常采用 25Gb 以太网络，无法像训练集群那样构建 200Gb 或 400Gb 的 IB 网络，因此存储和计算之间的带宽成为一个重要瓶颈。

我们推出了客户端缓存池解决方案，该方案在加载模型时充分利用计算节点的本地 SSD 形成一个大的缓存池。当需要加载模型时，我们首先将模型并发加载到客户端缓存池中，然后再由客户端缓存池将模型加载到 GPU 中。这样一来，我们有效地解决了启动风暴的问题。随着计算节点规模的增加，缓存池的性能也会相应提升，从而有效地应对启动风暴的挑战。

04.训练推理无法在单一数据中心完成，多云方式带来一系列挑战

之前我们讨论了单一数据中心内的解决方案，然而，由于诸多因素的影响，如卡的采购、资源租赁等，训练和推理往往无法在单一数据中心完成。

因此，我们不得不采用多云的方式，但这也带来了一系列挑战。

对于大模型厂商而言，通常会将所有数据存放在一个称为“Source of Truth”的数据中心内，而训练集群和推理集群则分布在多个云上，它们之间通过公网或专网连接。

训练集群通常需要共享数据，而不是为每个集群提供一份全量数据，这样做成本高且管理复杂。推理集群也需要共享模型数据，以便灵活扩展推理业务。由于边缘数据中心的存储容量有限，我们的训练集群和推理集群都需要按需加载数据。

我们面临两个主要特点：共享和按需。在这种情况下，通常会有一个中心的“Source of Truth”数据湖提供对象存储访问。当我们在边缘数据中心进行训练时，需要通过数据编排的方式将数据集按需加载到数据中心。当训练产生模型数据或结束后，我们可以将模型数据导出到数据湖中，而其他推理集群可以根据需要订阅并拉取这些模型数据到各自的集群中。

整个架构的基本思路就是这样，所有边缘数据中心都能与数据湖进行连接，数据的流转通过数据编排的方式按需拉取或导回到数据湖中。

实现数据的灵活流转，需要具备相应的功能支持。其中，数据加载功能可以让数据在各个平台之间灵活地流动；Dataload 功能可以与主流的调度平台对接起来进行数据编排，对接标准的 S3，如公有云的 OSS、COS、BOS 以及开源的对象存储，如 Ceph、Minio 等。Dataload 功能能够关联对象和文件，将对象 bucket 或者 Prefix 与文件路径关联起来，并支持多次导入导出；通过 API 方式，可以按需进行数据流转。

为了方便管理员管理，我们提供了查看导入导出进度和历史记录的功能。这些功能不会影响业务对数据的访问，业务仍然可以通过标准的 NFS、SMB、POSIX、S3 等接口进行访问。

当数据发生变化时，例如 A 集群的数据推送到 Source of Truth 的数据湖中，其他集群可以通过订阅方式实时感知这些数据的变化。这样，我们可以通过 API 制定策略，选择是否要更新本地数据。同时，我们还适配了 Fluid 对数据集进行编排，使用户的访问更加灵活。