AIGC内容分享(六)：AIGC世界的IO特征研究

目录

引言

第一章节 LLM&AIGC时代的计算架构特征  

第二章节 AIGC时代的存储主要挑战 

第三章节 LLM&AIGC时代的元数据挑战  

第四章节 LLM&AIGC时代的IO特征分析  

结论  

---

引言

在以前做传统块存储的时代，我们针对很多的行业做了workload的调研，包含块大小、随机读，读写比例等等，在传统存储场景，知道行业的workload对于预估业务的IOPS性能有很好地指导意义，其次，也可以制作针对行业的存储配置最佳实践。

很多年前获取这些信息是一个比较难的过程，毕竟传统的存储设备是直接销售到了客户的现场，缺乏有效地权利来获取运行信息，一般都是在进行性能调优及其他配置升级的时候进行获取的，这些很大意义上对于很多客户来说也算是机密数据。

针对AIGC的场景，我其实是比较好奇的，大模型的训练和推理对于存储的诉求怎么样？因为我们在太多的PPT里面听到的描述是，大模型训练对于存储有高性能的诉求，到底多高的性能、什么样的特征，从来语焉不详，今天我们解读weka的一个报告，来看看他们所谓的AIGC领域的存储IO特征。

第一章节 LLM&AIGC时代的计算架构特征  

存储的变化都是基于计算和存储介质造就的。在最早的IBM大型机时代是提供大型机适配的大硬盘（那是IBM的专属时代，虽然有少量的兼容机厂商也在做。

随着介质的变化，小型的硬盘和内存技术兴起，更多的是商务的大幅下降，催生了阵列存储的产生，并且快速的替代了大硬盘。其后随着关系型数据库这个上一个时代最值钱的数据不断的发展，产生了各种的高端存储，架构也随着一些硬件技术的进步做了很多的演进，从scale-out到scale-out，但是依然是价格高企，单价居高不下。    

高端存储的PPT里面宣传的主要方向是高性能、高可靠、高扩展，各种名词堆上去的企业级存储平台。心情好的话我们再加点对于业务的描述，比如说business-critical 、mission critical。为什么MKT要构造这么多词，很多做技术的同学也非常不喜欢，说是生造。其本质就是要给自己的存储高溢价找到合理的理由。

 在企业存储的赛道之外，其实一直都有另一个赛道存在，那就是HPC存储，但是这个存储主要面对的是科研机构（上个时代），有些科研机构钱多点有的少点。因此这个市场的存储厂商销售量一直不是很大，在上个时代，这里的代表厂商是IBM、DDN等，dell和HPE和Netapp也有涉猎。    

High performance computing (HPC) storage systems vendor market share worldwide in 2021

回到20年前，HPC系统已经在处理几个PB的数据了，而在这个时代，产生的大数据技术或多或少也从这里得到了灵感。从我个人的角度来看，google的三驾马车就是一个HPC+DBMS的结合体，取了HPC架构的精华，构造了傻瓜式调用的并行处理框架mapreduce，然后讲DBMS放弃了ACID的部分功能，构造出了bigtable来适配互联网的业务。前微软亚洲研究院 (MSRA) 首席研究员张霖涛有个“三十年” 理论：要解决一个难题，就去读三十年前的文章。

比如神经网络，最早就是上世纪 80 年代提出的，2010 年左右重新火了起来。近十年、二十年的创新作者还活跃在科研一线，如果他当年的方法能解决现在的问题，他自己早就解决了。但三十年前的创新作者大多数都已经不在一线了，这时候封存在故纸堆里的老方法可能就有用了。另外，在很多领域，系统架构也是螺旋式发展的，例如瘦客户端和胖客户端、集中式和分布式、统一指令集和异构计算等，当前新的架构在上一个历史周期里可能都是玩剩的。        

当年的存储架构设计都是基于这样的想法，即为计算提供最快的存储层是HDD（当时还没有SSD加入到存储中，EMC主存储加SSD也到了08年左右）。由于HDD的限制，作业通常大小为尽可能多地加载到内存中，避免换出，并且需要检查点（checkpoint）以确保如果在加载或将作业写入HDD会发生什么样的问题，你不可能因为一个中间错误就去重新加载数据并重新开始任务，毕竟计算的时长太长了。

但是众所周知，HDD是数据中心中最慢的部件，或者说存储是数据中心中最慢的部件。后来出现了SSD，但是性能和成本是永恒的矛盾，分层存储就出现了。

 首先，从传感器或者其他领域获取到数据，存储到一个高性能的存储设备（历史上分层存储居多）。这个存储设备首先必须是一个共享存储，毕竟HPC是一个多个计算节点并行执行的任务，因此一般都是文件存储或者对象存储（历史上都是文件存储，对象存储是这几年云时代的到来，很多数据上云的第一站需要跨越互联网到来，因此以对象存储来承载）。    

其次，数据经过预处理之后加载到计算节点的本地NVMe SSD或者cache中，上面这个图画的不一定精准，其实很多时候预处理之后写入到了并行文件系统中，比如说典型的HPC高性能存储并行文件系统（GPFS、BeeGFS、Lustre）。

最后，将数据进行相关的备份或者随着生命周期转冷。

在AI的领域，他非常类似于HPC，或者说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训练的基本原则。以前在HPC时代，由于存储带来的CPU闲置可能是在10-50%，在GPU时代，GPU时间闲置甚至可能达到80-90%，加入使用的性能较差的存储。    

如何完成AI数据链路的整合？

很多时候我们沿用了大数据提出的数据湖的概念，大数据领域的湖仓一体。在AI领域也是遵循这个概念，在数仓时代的相关数据流在AI时代其实一样存在。

虽然当前的基础设施每年都在飞速的发生这变化，AI模型也是按天发生的变化，但是，整个数据流的架构并没有什么大的变化还是遵循这上面这个大概的流程。我们现在每天在讨论这GPT-4以及各种大模型，其实大模型领域各个厂商的护城河并没有想象的那么宽广。

套用semianalysis的一个评论，“OpenAI is keeping the architecture of GPT-4 closed not because of some existential risk to humanity but because what they’ve built is replicable. In fact, we expect Google, Meta, Anthropic, Inflection, Character, Tencent, ByteDance, Baidu, and more to all have models as capable as GPT-4 if not more capable in the near term.”

OPENAI的领先优势并不是他们算法上的精妙，而是他们工程上的架构设计以及先发优势，一旦其他厂商加入，可能很快都能追上，他还点名了Tencent, ByteDance, Baidu，竟然没有点名阿里巴巴，看来整个世界都在看衰阿里吗？

第三章节 LLM&AIGC时代的元数据挑战  

回到存储角度，大规模的训练带来的第一个挑战是混合IO特征的需求，这个需求在前十年的集中存储、虚拟化存储、私有云存储时代都被不断地出现且完善。

其次是针对元数据的管理，这个才是这个时代的难题。以前大家用树形的分布式文件系统，一般可以处理十亿百亿级的文件，之后在互联网时代大家为了处理海量的文件，使用了对象存储的KV架构，不在追求文件树形架构因此也没有目录、文件夹这个概念。对象存储我们可以看到大多数云厂商的承诺在几千到上万的qps，而对于带宽云厂商则更加宽容。

而在AI处理场景下，不管是当前的大语言模型、图片类模型，训练的语料经常是大量的小文件，小文件下的元数据处理经常会被忽略，其实很多时候元数据的qps大于数据的qps。

在预处理期间，ingest数据被处理到到模型训练期望能够使用的状态。这可能涉及注释/标记、图像缩放、对比度平滑、索引等。当您有多个研究人员/科学家处理相同的数据时，每个人可能需要以不同的方式预处理数据，这取决于他们打算训练或重新调整模型的内容。即使使用相同的数据集，每个研究人员执行的预处理步骤之间也存在巨大差异。其结果是一个用于预处理的混合IO环境，最多可占用epoch训练时间的50%。（这是一个很可怕的结果）  

IO的影响是巨大的。当访问大量小文件（LOSF）时，您不仅会遇到IO Blender问题，而且现在还会有数百万个文件操作，读取和写入，其中IO大小和操作各不相同。

以一个使用TensorFlow在ImageNet上进行深度学习的客户为例（训练数据库包含1400万张图片）

阶段1：预处理函数在读取、修改和写回数据时，会对与之关联的小文件进行大量写入。当这种预处理与系统中的所有其他IO混合在一起时，将再次遇到IO混合器问题，但有一点不同：可能会耗尽系统中的写缓存，并陷入必须执行额外IO来刷缓存到持久化层的恶性循环，从而导致系统速度降低，并延长完成这些元数据密集型流水线阶段所需的时间。

阶段2：对元数据产生巨大影响的第二个阶段是深度学习训练阶段。这往往是较少的写密集型，但有很多随机读取小文件。数据处理通常遵循以下一些变化：

l整个数据集的随机子集上的mini-batch和重复

l对每个mini-batch进行训练

l整个数据集的完整历元处理，通常以随机顺序进行（就是一个典型shuffle）    

l设置某种形式的超参数来控制过程（例如，所需的精度，epochs的数量等）

在这个过程会导致大量文件打开、文件统计信息以及更多不显示为传统IO的信息。在下面的图表中，您可以看到WEKA客户在ImageNet上使用TensorFlow进行训练的示例，训练数据库包含1400万张图像。在此训练期间，30%的读取是文件打开（open）。这种开销表示深度学习训练和ResNet-50类型的迁移学习负载，读取比例一般在25-75%之间，具体取决于部署的训练类型和文件大小。这种“隐藏IO”会在数据平台上产生开销，随着工作负载的增加，开销会变得更大。设想一个1000万次读取的IOP环境，在此基础上您需要额外处理500万次元数据IOP。（这个就是典型的元数据隐藏IO）

事实上我在其他的AI场景观测到甚至元数据IO比例超过实际数据IO比例的情况。（如果使用对象存储做训练的数据源，这个将是最大挑战）

文件的大小也很重要。在同一个TensorFlow管道中，WEKA发现数据大小要么非常小（小于100字节），要么是10 KB-1 MB的中等大小。由于文件大小的差异，数据平台需要能够同时处理非常小的随机IO和顺序IO，以加快训练的epoch时间。其实当前看到大多数大模型训练都是小IO为主。    

第四章节 LLM&AIGC时代的IO特征分析  

说明：WEKA正在帮助许多世界领先的GenAI公司加速其GenAI工作负载，这些用例在多个行业和AI/GenAI类型中各不相同。显示的数据和图表直接来自WEKA Home遥测。WEKA Home是一个基于云的电话总部支持和分析工具，客户可以在其中管理他们的WEKA环境。

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

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

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

对于这个NLP业务来说，读/写比例是47/53，但值得注意的是IO大小：读IO大（300-500K)，写IO小(100-200K)。在本例中，客户获取了通常小于100 k的小样本，将它们append到一个较大的文件中，并对该文件进行阅读，就好像它是一个流一样。但为什么写的都是小IO呢？这不仅是GenAI和AI工作负载的共同主题，也是许多HPC工作负载的共同主题：Checkpoint。

Checkpointing 

当运行长时间的培训或操作作业时，检查点是确保在发生故障时有一个“checkpoint”的方法。故障可能是任何硬件，其中运行作业的服务器出现硬件故障，也可能是GenAI工作流中的错误，其中功能嵌入到层中但未完成。检查点允许您恢复作业的状态，但也可以用于停止模型训练，评估，然后重新启动，而无需从头开始。检查点涉及将作业或内存状态写入存储器。在内存转储的情况下，这可以是大量的数据，或者在AI嵌入/训练检查点的情况下，这可以是较小的增量步骤。在这两种情况下，延迟都是一个重要的关键指标，因为写操作所花费的时间越长，作业必须等待的时间就越长。   

接下来，让我们看看AI/ML模型开发环境。在这个用例中，客户正在构建NLP和ML函数的组合，以实现text-text and text-action 功能。这种数据管道更加隔离，重叠较少，因为它们还没有满负载运行。我们在这里看到，混合IO，读/写比例大概为48%/52%。此外，读取的IO大小往往大于写入。

这里最重要的是所有预处理对IO模式的影响。由于获取数据在构建到H5文件之前进行了大量的预处理以规范化数据，因此读取的IO范围要窄得多，并且更可预测。这是在做大量的前期预处理工作使训练IO更容易，或者做更少的工作并使训练IO变得更加可变和难以处理之间的权衡。

最后，如果我们看一个图像识别训练的例子，其中已经完成了自动图像预处理，（注意这与之前描述的元数据例子不同;客户没有告诉我们这是TensorFlow还是PyTorch），我们看到客户正在做一个经典的隔离环境，只是为了在图像训练中读取。但在他们目前的运营规模下，他们决定将训练与所有其他工作流程隔离开来，而不是每天将图像批量传输到存储集群进行训练。    

正如预期的那样，总体吞吐量由大小非常一致的读取控制。然而，写入差异很大。这些写操作大多是对文件的元数据更新、进程数据的回写和checkpoint操作。正如我们之前所指出的，监测的数据说明了实际的数据传输;虽然这些写入的所有元数据操作都不会显示为数据传输，但它们可能会对训练模型的性能产生重大影响。

结论  

1，AI训练过程中，随着流程的复杂以及并行度的加剧，IO的特征是一个非常混杂的场景，读写以及IO大小都是一个弹性多变的，并且出了数据IO还有大量的隐藏的元数据IO，很多时候会被忽略，但是它对于性能影响更大。AI过程对于IO最敏感的是时延而不是吞吐。低延迟是系统整体性能的主要指标，因为它会影响每个操作。整体延迟越低，AI流程就越快进入模型工作流中的下一个迭代/epoch/retune/enrichment/embedding周期。

2，AI存储的主要挑战：

(1)如果期望通过RDMA技术加速传统NFS等协议可能不一定是个好想法，还是要考虑另起炉灶，考虑新的实现方式。比如说自研客户端，做并行文件存储（pnfs也行），GDS适配等。

(2)低时延问题，文件存储本质上复杂度要高于块存储，所以在块存储场景的低时延在大规模小文件场景如何实现。

(3)混合IO,很多时候我们的存储系统内部的条带深度、块大小、缓存算法、qos策略等都是默认设置好的，在AI时代如何精细化的适配?

(4)海量小文件的元数据效率，假设10亿文件场景的海量小文件，如何保障批量元数据操作的效率以及数据随机遍历的性能？

AI时代的存储是不是HPC存储的升级和轮回？并行文件系统是不是一个好的答案？