AIGC 训练场景下的存储特性研究

云布道师

弁言：在传统块存储大行其道的期间，必要针对很多行业的工作负载（Workload）进行调研，包含块巨细、随机读、读写比例等等。知道行业的 Workload 对于预估业务的 I/OPS、时延、吞吐等性能有很好的指导意义，其次，也便于订定针对行业的存储配置最佳实践。
在本日这样以 AIGC 为代表的 AI 期间下，相识训练场景对于存储的具体诉求同样是至关重要的。本文将实验解读 WEKA 的一个干系陈诉，来看看 AIGC 对于存储有哪些具体的性能要求。
一、LLM&AIGC 期间的计算架构特性

存储的变化都是基于计算和存储介质造就的。在最早的大型机期间是提供大型机适配的大硬盘。随着介质的变化，小型的硬盘和内存技术鼓起，而商务报价的大幅降落，催生了阵列存储的产生，并且快速地替代了大硬盘。其后，随着关系型数据库这个上一个期间最值钱的数据库不断地发展，产生了各种的高端存储，架构也随着一些硬件技术的进步做了很多的演进，从 scale-up 到 scale-out，但是价格依然高昂。

高端存储宣传的重要方向是高性能、高可靠、高扩展，以及各种名词堆上去的企业级存储平台。在企业存储的赛道之外，其实一直都有另一个赛道存在，那就是HPC(High performance computing) 存储，HPC 存储最初重要面向的是科研机构。

回到 20 年前，HPC 体系已经在处置惩罚几个 PB 的数据了，而在这个期间，产生的大数据技术或多或少也从这里得到了灵感。个人以为，Google 的三驾马车就是一个HPC+DBMS 的结合体，取了 HPC 架构的英华，构造了傻瓜式调用的并行处置惩罚框架MapReduce，然后将 DBMS 放弃了 ACID 的部门功能，构造出了 Bigtable 来适配互联网的业务。
当年的存储架构计划思绪是为计算提供最快的存储层即HDD（当时还没有SSD加入到存储中，EMC主存储加SSD也到了08年左右）。由于HDD的限制，作业通常巨细为尽可能多地加载到内存中，克制换出，并且必要检查点（checkpoint）以确保如果在加载或将作业写入HDD会发生什么样的问题，毕竟由于一个中间错误就去重新加载数据并重新开始任务所花费的计算时长太长了。
但是众所周知，HDD 是数据中央中最慢的部件，或者说存储是数据中央中最慢的部件。厥后出现了 SSD，但是性能和成本是永恒的抵牾，于是分层存储就出现了。

首先，从传感器或者其他领域获取到数据，存储到一个高性能的存储装备。这个存储装备首先必须是一个共享存储，毕竟HPC是采用多个计算节点并行的方式执行任务，因此一般都是文件存储或者对象存储（早期重要是文件存储，对象存储是这几年云期间的到来，很多数据上云的第一站必要超过互联网，因此以对象存储来承载）。
其次，数据颠末预处置惩罚之后加载到计算节点的本地 NVMe SSD 或者 Cache 中，上面这个图画得不一定精准，其实很多时间数据预处置惩罚之后写入到了并行文件体系中，好比说典型的 HPC 高性能存储并行文件体系（GPFS、BeeGFS、Lustre）。
最后，将数据进行干系的备份或者随着生命周期转冷。
在 AI 的领域，可以说 AI 的训练其实是另一个基于 GPU 的 HPC。整个过程的数据流处置惩罚如下（这里面会有几个批次的 copy 工作）。从原始数据预处置惩罚到并行文件体系，从并行文件体系到 GPU 本地的 NVme SSD，从本地 NVMe 到显存。这几个过程不可克制，并且成为制约 AI 最大的性能瓶颈之一（另一个则是内存墙）。NVIDIA GPUDirect Storage 协议是一个可能的解题思绪，可以跳过本地 NVMe SSD，但是存储体系本身的性能可能更是一个关键，毕竟通过网络的时延可能高于本地 NVMe SSD 的访问。

二、AIGC期间的存储重要挑衅

从微软的研究 Analyzing and Mitigating Data Stalls in DNN Training 中可以显着看出，dataset 在 SSD 情况下是否缓存住对于每个 epoch 的时间冲击并没有想象的那么大，但是如果存储性能太差，那么 epoch 的时间冲击将极大。固然这个是DNN 场景，在 LLM 大模子的 transformer 模子是否也会类似并不清晰。理论上，如果网络效果好，加之全闪存是可以逼近本土地的效率（假设dataset cache率没有那么高）。

如果使用对象存储共同本土地来做训练，也有一组测试数据，除了第一个 epoch 性能较差，其他的根本底盘差异并不大。（这里其实有点偷换概念，本质上反面的测试都是 cache 了）

存储性能做到足够好，可以让大模子训练对存储不敏感，但是如果存储性能不好，则可能带来训练时长成倍地增长这个已经是个共识。针对 AI 训练尤其是大模子的训练，在存储上省钱将会大量浪费 GPU 算力。以是，在 GPU 算力紧张的期间，使用最高性能的存储是 AI 训练的基本原则。

很多时间沿用了大数据提出的数据湖的概念，大数据领域的湖仓一体。在 AI 领域也是遵照这个概念，在数仓期间的干系数据流在 AI 期间其实一样存在。

固然当前的底子办法每年都在飞速地发生着变化，AI 模子也是日新月异，但是，整个数据流的架构并没有什么大的变化，还是大致遵照上面这个流程。而当下大模子公司的领先上风并不是算法上的精妙，而是工程上的架构计划以及先发上风，以是，一旦其他厂商加入，护城河将很快被填平。
三、LLM&AIGC 期间的元数据挑衅

图片回到存储角度，大规模的训练带来的第一个挑衅是混合 I/O 特性的需求，这个需求在会合存储、假造化存储、私有云存储期间都在不断地出现和完满。
其次是针对元数据的管理，这个才是这个期间的难题。从前用树形的分布式文件体系，一般可以处置惩罚十亿百亿级的文件，之后在互联网期间为了处置惩罚海量的文件，使用了对象存储的KV架构，不再追求文件树形架构因此也没有目录、文件夹这个概念。很多云厂商的对象存储已经可以做到几千到上万的 QPS。
而在 AI 处置惩罚场景下，不管是当前的大语言模子、图片类模子，训练的语料经常是大量的小文件，小文件下的元数据处置惩罚经常会被忽略，其实很多时间元数据的 QPS 大于数据的 QPS。
在预处置惩罚期间，ingest 数据被处置惩罚到模子训练期望能够使用的状态。这可能涉及表明/标记、图像缩放、对比度平滑、索引等。当您有多个研究职员/科学家处置惩罚雷同的数据时，每个人可能必要以差别的方式预处置惩罚数据，这取决于他们计划训练或重新调整模子的内容。即使使用雷同的数据集，每个研究职员执行的预处置惩罚步调之间也存在巨大差异。其结果是一个用于预处置惩罚的混合 I/O 环境，最多可占用 epoch 训练时间的50%。（这是一个很可怕的结果）

I/O 的影响是巨大的。当访问大量小文件（LOSF）时，不仅会遇到 I/O Blender 问题，而且现在还会有数百万个文件操作，读取和写入，其中 I/O巨细和操作各不雷同。
以一个使用 TensorFlow 在 ImageNet 上进行深度学习的客户为例（训练数据库包含 1400 万张图片）：
阶段1：预处置惩罚函数在读取、修改和写回数据时，会对与之关联的小文件进行大量写入。当这种预处置惩罚与体系中的所有其他 I/O 混合在一起时，将再次遇到 I/O 混合器问题，但有一点差别：可能会耗尽体系中的写缓存，并陷入必须执行额外 I/O 来刷缓存到持久化层的恶性循环，从而导致体系速率降低，并延伸完成这些元数据密集型流水线阶段所需的时间。
阶段2：对元数据产生巨大影响的第二个阶段是深度学习训练阶段。这通常是较少的写密集型，但有很多随机读取小文件。数据处置惩罚通常遵照以下一些变化：
●整个数据集的随机子集上的 mini-batch 和重复
●对每个 mini-batch 进行训练
●整个数据集的完整历元处置惩罚，通常以随机顺序进行（就是一个典型 shuffle）
●设置某种形式的超参数来控制过程（例如，所需的精度，epochs的数量等）
在这个过程会导致大量文件打开、文件统计信息以及更多不显示为传统 I/O 的信息。在下面的图表中，可以看到 WEKA 客户在 ImageNet 上使用 TensorFlow 进行训练的示例，训练数据库包含 1400 万张图像。在此训练期间，30% 的读取是文件打开（open）。这种开销表示深度学习训练和 ResNet-50 类型的迁徙学习负载，读取比例一般在 25-75% 之间，具体取决于部署的训练类型和文件巨细。这种“隐藏 I/O”会在数据平台上产生开销，随着工作负载的增加，开销会变得更大。设想一个1000 万次读取的 I/O 环境，在此底子上您必要额外处置惩罚 500 万次元数据 I/O。（这个就是典型的元数据隐藏）

文件的巨细也很重要。在同一个 TensorFlow 管道中，WEKA 发现数据巨细要么非常小（小于100字节），要么是 10 KB-1 MB 的中等巨细。由于文件巨细的差异，数据平台必要能够同时处置惩罚非常小的随机 I/O 温和序 I/O，以加速训练的epoch时间。其实当前看到大多数大模子训练都是以小 I/O 为主。

四、LLM&AIGC 期间的 I/O 特性分析

首先看一个自然语言处置惩罚（NLP）例子。这家 GenAI 客户正在构建人工智能模子，以支持语音转文本（voice-to-text）和语音转操作（voice-to-action）功能。

在此环境中，可以看到这是一个完全混合的混合 I/O 管道，由相对一致的读取数量和写入时的 I/O 峰值构成（读写是同时发生的）。这些信息可以映射到后端服务器的负载情况。

深紫色和浅紫色表示最大利用率平静均利用率。这显示了该客户的AI管道的猛烈突发性。如果只看均匀值，会以为体系未充实利用率约为 5%。实际情况是，它每隔几分钟就会出现剧烈的颠簸，导致其利用率经常到达 80-100%。（这在自动驾驶和AI场景非常的常见，对于共享的云存储集群来说，如何来处置惩罚这种场景的性能突发以及资源争用，并且最大化地利用资源是个比力复杂的问题。集群的QoS管理是云存储厂商必要不断下功夫的地方）。

对于这个 NLP 业务来说，读/写比例是 47/53，但值得注意的是 I/O 巨细：读 I/O 大（300-500K)，写 I/O 小(100-200K)。在本例中，客户获取了通常小于100 k的小样本，将它们 append 到一个较大的文件中，并对该文件进行阅读，就似乎它是一个流一样。但为什么写的都是小 I/O 呢？这不仅是 GenAI 和 AI 工作负载的共同主题，也是很多 HPC 工作负载的共同主题：Checkpoint。
Checkpointing
当运行长时间的培训或操作作业时，检查点是确保在发生故障时有一个“checkpoint”的方法。故障可能是任何硬件，其中运行作业的服务器出现硬件故障，也可能是 GenAI 工作流中的错误，其中功能嵌入到层中但未完成。检查点答应您规复作业的状态，但也可以用于制止模子训练，评估，然后重新启动，而无需重新开始。检查点涉及将作业或内存状态写入存储器。在内存转储的情况下，这可以是大量的数据，或者在 AI 嵌入/训练检查点的情况下，这可以是较小的增量步调。在这两种情况下，延迟都是一个重要的关键指标，由于写操作所花费的时间越长，作业必须等待的时间就越长。
上面这个图里面的小 I/O 写重要发生在层的 checkpoint。
接下来，看看 AI/ML 模子开发环境。在这个用例中，客户正在构建 NLP 和 ML 函数的组合，以实现 text-text and text-action 功能。这种数据管道更加隔离，重叠较少，由于它们还没有满负载运行。在这里可以看到，混合 I/O，读/写比例大概为48%/52%。此外，读取的 I/O 巨细通常大于写入。

这里最重要的是所有预处置惩罚对 I/O 模式的影响。由于获取数据在构建到H5文件之进步行了大量的预处置惩罚以规范化数据，因此读取的 I/O 范围要窄得多，并且更可预测。这是在做大量的前期预处置惩罚工作使训练 I/O 更容易，或者做更少的工作并使训练 I/O 变得更加可变和难以处置惩罚之间的衡量。
最后，如果看一个图像辨认训练的例子，其中已经完成了自动图像预处置惩罚，（注意这与之前描述的元数据例子差别，客户没有说明这是TensorFlow还是PyTorch），看到客户正在做一个经典的隔离环境，只是为了在图像训练中读取。但在他们现在的运营规模下，他们决定将训练与所有其他工作流程隔脱离来，而不是天天将图像批量传输到存储集群进行训练。

正如预期的那样，总体吞吐量由巨细非常一致的读取控制。然而，写入差异很大。这些写操作大多是对文件的元数据更新、历程数据的回写和 checkpoint 操作。正如之前所指出的，监测的数据展示出了实际的数据传输，固然这些写入的所有元数据操作都不会显示为数据传输，但它们可能会对训练模子的性能产生重大影响。
五、阿里云存储的典型 AI 训练解决方案

结合上文的分析，可以清晰地看到：
首先，在 AI 训练场景中必要一个低时延，高 QPS 和高吞吐的并行共享文件体系。

阿里云文件存储 CPFS 有几个关键的上风：
高性能元数据操作：客户端创新的lease机制和元数据缓存，元数据查询操作无需超过网络，提升操作速率 10 倍，媲美本地 EXT4 性能
大规模训练稳定性：EFC 客户端支持链接层高可用，链路问题秒级别切换；客户端元数据和数据流分离，克制数据大压力下元数据操作卡顿。
其次，在传统的 HPC 架构里，高性能存储和大容量存储分离部署和维护，所有训练数据在高性能存储中清洗、训练、试用；数据转冷后流转到冷存储（手动&工具）。

而云原生期间的AI训练数据路径出现了显着的差异：分散的存储转化到数据湖，数据入口从训练高性能存储转化为对象存储底座。数据入湖后第一时间进入对象存储（数据湖存储底座）；训练数据必要从对象存储进行自动化加载（部门厂商推荐客户使用跳板机映射或者开源主机缓存软件进行手动加载）。
因此，并行文件体系或分布式 Cache 自动加载数据湖对象存储是云原生AI底子办法的关键能力需求。

阿里云存储提供完整的数据管理解决方案，提供全面的数据活动能力：
高效数据活动：数据块粒度活动，多并发技术可实现百 Gbps 活动性能；
极速同步：事件驱动的高效元数据同步，OSS 数据变动在 CPFS 中分钟级可见；
多种模式：支持共同任务调治预加载或随 I/O 读取 Lazyload；
结束语

AI 训练过程中，随着流程的复杂以及并行度的加剧，I/O 的特性是一个非常稠浊的场景，读写以及 I/O 巨细都是弹性多变的，并且除了数据 I/O 还有大量的隐藏的元数据 I/O，很多时间会被忽略，但是它对于性能影响更大。AI 过程对于 I/O 最敏感的是时延而不是吞吐。低延迟是体系团体性能的重要指标，由于它会影响每个操作。团体延迟越低，AI 流程就越快进入模子工作流中的下一个迭代周期。
注：
1、本文干系截图、性能分析等数据出自以下公开陈诉https://www.weka.I/O/wp-content/uploads/files/resources/2023/09/I/O-profiles-gen-ai-pipelines.pdf
2、Analyzing and Mitigating Data Stalls in DNN Training
https://arxiv.org/abs/2007.06775
3、High performance computing (HPC) storage systems vendor market share worldwide in 2021
https://www.statista.com/statistics/802712/worldwide-top-hpc-storage-system-supplier/

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。