作者：欧阳雁（乐忱）阿里云存储产品高级解决方案架构师

存储是历史比较久的一个领域。从大家最早接触的软盘、光盘等那个时代开始，存储就已经出现在大家生活中。分享一个数据，去年，中国的企业级存储市场增长的规模不是很符合预期，但是有一个细分的板块增长比较快。这个板块是高端的企业级存储，是全闪的存储。全闪的存储用在性能比较高的领域，比如AI的场景。去年整个AI大模型的快速发展带动了企业级存储的市场增长。还有个数据是在去年，高端的企业级存储闪存部分在整个企业级存储的占比在中国的市场大概是25%左右。而同一时期，这个比例在欧美这些国家比重需要到50%。

说明我们国家像AI大模型的市场有很大的成长的空间。另外说明了存储跟计算非常紧密结合。作为一个历史比较久的特定领域，我们也在思考在AI大模型时代能不能帮助客户去构建更有竞争力的AI业务。今天分享过去一年对于AI场景的一些探索。

今天的内容分为七个部分，主要从常见的AI业务流程，对应的一些痛点，以及做AI大模型业务过程中涉及到的几个核心的环节中如何提高数据使用，和流转效率以及管理的效能。

大模型AI业务的典型业务流程

先介绍第一部分。在去年有很多的行业专家或者国内外的一些学者对于AI领域提出了自己不同的一些见解。有些专家学者认为五年之内AI可能会渗透到我们的各行各业生活中。甚至可能会让很多的行业产生颠覆性的一些变革。还有一些专家，可能认为AI领域还有很多数据的安全合规或伦理道德等等的一些问题没有解决，未来的AI可能还是一个探索型的场景。在不同的观点中，我们要看到其中一些比较确定性的内容，即第一性原理。

现在整个大模型中有几个趋势。第一是模型的参数越来越大。像1000亿级别的参数规模的模型在行业中不算很大，像1万亿参数以上的模型存在更多的业务场景中。

第二很多做大模型的客户，他的数据量级增长超乎我们想象。很多的大模型的客户，他的数据量在一年之内可能跑到100PB以上，这个数据的增长的量级非常惊人。在未来的几年内，会比我们在移动互联网时产生的数据量更大。

第三要去使用一些大模型的业务，成本比较高。最近在行业中包括云服务商有一些动态，例如阿里云前几天做了一些大模型产品的发布，做了大规模的降价，背后是希望能够降低大模型业务的门槛，让这些技术能力可以以更普惠的方式供大家使用。

这三个比较确定的趋势可以让我们以一个比较乐观的心态面对未来的AI技术。这也是我们存储团队希望在AI领域持续投入的立足点。这个领域还是极具创新，极具想象力和创造力的。

下面介绍常见的AI业务的处理流程。对于一个大模型云服务厂商而言，从左侧看，在数据收集完后，因为数据量很大，可能有很多的脏数据或者是无效的数据。对于这些数据要去做一些预处理，将无效的一些数据做清洗，或者将一些格式去做打标，或者做一些向量化的处理。数据处理完后数据的体量会大幅的缩减。

之后这些数据会进入到下一个环节，去做一些模型化的训练。其中有大量的算法平台会对预处理后的原始数据做相关的一些模型化处理，这个过程是一个反复训练的过程，也是算力存储性能要求非常高的一个流程环节。模型训练完后会有一个初步的模型结果。

大部分模型不是一蹴而就的，会有一个不断调精的过程。所以下面是调优的环节。调优环节一般会根据上一阶段算出来的模型结果做一些测试。例如输入一个问题让大模型回答，看它对语义的理解或者对于文本的支持摘要是否符合我们的预期。不符合预期可能有些参数需要做一些调整，调整后要重新做训练计算。

模型训练完后涉及到模型部署上线，部署到成为平台化服务的一部分。对外我们提供API接口给使用者。使用者去使用模型服务时，可以通过API,或者一些AI的客户端，把数据上传到平台上。因为上传的数据可能有些是违规的，或者有一些不太合理。平台会做一些安全内容的识别处理。处理完后的结果做推理计算，计算完后把结果给最终的消费者，形成了一个完整的数据处理流程。

大模型AI业务存储痛点分析

下面是根据实际服务的客户抽象出的一些情况：

在数据采集阶段，数据的特点是什么呢？举一个例子，像特斯拉目前要推自动驾驶的业务。自动驾驶的模型要经过大量的训练。训练之前的原始数据需要做大量的路采。平均每一天一辆车有几十TB的数据，一天有数百TB以上的数据集。这些数据集大部分可能是一些传感器采集的小文件的数据，但是它的数据体量非常大。在数据采集过程中，可能也有一些第三方送的Checkpoint文件，这些文件也是GB级的文件。

到了数据处理的环节，对于IO的一些特性主要是对一些文件做清洗处理，过程中会有大量比较复杂的一些数据的访问动作。训练环节是一个偏效率的环节，数据在存储系统中存置时，对计算节点访问时尽可能要有低时延高吞吐的访问能力，要提高计算读取的效率，降低GPU等待时间。所以数据训练的环节典型的IO特点是高吞吐、低延时、高并发。

最后到推理，推理最终面向的是消费者，所以对于业务的响应时间比较高。一般结果要秒级形成，所以它的一个特点是要应对海量的客户发过来的高并发请求，能够第一时间响应。上图最下方是一个例子，可以看到在图片生成图片、文字生成图片、文字生成视频这三个场景中对应的训练卡或者推理卡的规模下推理和计算的性能，这还只是一个比较小规模的客户。

综上所述，由此可见整个大模型业务对存储要求三个特点，第一要有稳定的存储，数据存入后不丢、不错是第一个原则。第二对于性能上需要高吞吐高IO，第三因为数据在存储的形态上有冷热的层级，所以要做好生命周期的管理，否则大量的数据放在服务器中存储成本是极其高昂的。

数据预处理场景下的存储解决方案

结合刚才的几个业务的流程，下面介绍预处理环节。数据预处理是一个比较早期的环节，并不是在AI大模型才涌现出来的一个新场景。

之前数据预处理更多是通过hadoop、hive、Spark这些大数据的引擎实现。在AI大模型中，根据业内的一些统计，大概45%的工作时间是在做一些数据的准备。举一个例子，像L4这种自动驾驶平台算法公司，在外面采集了大量数据后，会有上百人的数据预处理的团队去做一些数据的打标，或者是清洗的动作，这是一个重要的业务环节。因为数据预处理环节，数据采集的量一定是越来越大的。未来我们预计前期采集的数据可能有90%以上都会在预处理的环节被清洗掉。随之会引发两个问题。

第一个问题，在预处理环节，要让后面的大模型越精准，意味着前期要采集的数据集体量越大，后面训练出来的模型才可能越精准。现在大量的数据都是从互联网上获取的，互联网获取的数据来自于国内或是全球性的，会引发的问题是数据从国外采集回后需要传到国内，会涉及到全球的网络传输问题。例如是否会有网络的抖动，或者是超时等等问题需要去解决。如果解决不好，即使采集到了数据源也无法传回。

由于数据采集完后，大部分的客户都会放到对象存储中。对象存储是以一个对象协议提供HTTP访问的方式，存储的形态相对比较便宜，比较适合数据体量大的业务形态。放在对象存储后，我们设计了一个全球加速的能力。这种全球加速能力非常简单，使用时把加速能力打开，我们就会提供一个加速的域名，帮助客户通过我们部署在全球的pop点，通过我们自研的网络探测的一个算法，以最优的路径把数据传输到客户的指定的节点。

第二个问题是数据采集回后如何以一个比较高效方式或者高性价比的方式进行清洗。数据清洗的过程伴随了大量随机的参数。到了AI时代由于有很多变量，所以更多偏向于概率性的一个函数。在清洗的过程中，可能有很多随机反复的动作，势必会产生大量的临时过程的一些数据。如果用一个高性能的存储存中间态这些数据，成本很高。如何解决这个问题呢？我们在去年做了大量的探索。在今年年初提出一个产品：弹性临时盘。右侧图可以看到是一个块存储，是一个低延时、高性能、高吞吐的盘。主打弹性和延时，做清洗过程中随时可以把盘挂上去，提供比较低的延时，吞吐比较高，不用时随时卸载掉即可。非常适合在AI的场景中做数据清洗，可以大幅降低清洗过程中临时数据的存储和访问。

如何设计让训练更高效的存储解决方案

第二个环节是训练环节。训练环节，大家在公众号或者文章上看到过很多关于训练场景中的一些架构，或者是一些性能的要求。着重介绍大模型训练中一个很重要的文件Checkpoint文件。

Checkpoint文件可以理解成快照，在训练的过程中训练错了后要做一些数据的重新回滚，会有一定的频率例如多少小时多少分钟记录Checkpoint文件。如果后面发现算错还能再找回原来的文件，继续回滚计算。其中会涉及到一个问题，Checkpoint文件比较大，几个G或者20个T左右。如果有100台计算节点都要去回滚计算，100个计算节点同时都要读Checkpoint文件，要以几秒的时间把数十T的文件读完，加载完。一个T的数据一秒钟要读完，带宽就是一个T的级别。TB级的带宽非常大。所以分布式训练要求数据读写要高效。

GPT4用25000张A100的GPU做90到100天左右的训练时，GPU的训练效率只有32%到36%，很有可能在训练的过程中，有大量Checkpoint反复的读写，浪费了GPU的效率。在训练的环节中，存储的性能跟效率对于GPU整个的性能的综合利用有很大的帮助。

下面是整个存储在AI高性能存储场景中的框架图：

第一因为存储跟计算之间要做通信。在灵骏的环节中用基于RDMA的网络，可以保证是一个高速的通讯网络。其次底层存储介质有全闪和HDD的混闪架构用来满足不同的性能。在Checkpoint文件读写方面通过全闪的方式给上级计算机访问，可以提供一个比较好的性能。

其次有Smart NIC的加速通道，可以提升访问的效能。在每台计算节点上有一个加速的客户端，是定制的一个客户端，可以用来加速数据访问的效率。训练完数据后，不可能把数据长期存放在全闪的介质中，因为它是比较贵的存储。所以后面还有一些设计，如何以快速的形式放到对象存储上，降低整个数据存储的成本。这是整个存储的架构。CPFS在阿里云的官网上有一些小规格的产品可以体验。如果平时公司业务上有需求，可以优先考虑这个规格的存储，也是目前基本上在AI的客户中标配的存储。

推理业务场景下的存储解决方案

下一个环节介绍推理场景。大模型业务不一定所有的公司都会去做，因为大模型要买GPU卡，第一有供应的问题，第二成本比较高。但是推理这个细分领域大部分的客户都会有，不一定是做AI专业的公司。业务场景中做智能推荐或者做人机交互的场景中都会有AI推理。那么推理场景的问题是什么呢？

客户的素材上来后要以非常快的方式把结果反馈给客户，其中要做的事情就是尽可能的减少被推理素材的存储传输的耗时。所以在对象存储层有一个高性能的缓存，如果原始需要推理的数据上传到对象存储后，对象存储会以服务端的形式把数据同步到高性能的缓存上。后面就是在GPU上部署的容器化服务，可以以低延时高吞吐的方式快速的把这些模型文件往容器节点上拖送，减少了底层存储上的时延，而且可以提供比较高的IOPS 存储的能力。

目前整个加速器已经演进到了2.0环节。

2.0阶段的加速器提供了比较丰富的一些能力，例如与弗洛伊德容器的环境兼容比较好。而且使用的成本也比较低。目前能开通一些比较小规格的项目去使用。如果后续大家对于数据加速层面有诉求可以重点考虑一下我们的加速器。

AI Agent场景下的存储解决方案

下一个环节介绍AI agent场景。对于这一方面业内有不同的一些看法。比如一些有专家提过，使用一个ChatGPT3.5，再加上一个AI的agent, 性能可以赶超ChatGPT4。所以AI agent对于构建更高效的一个AI业务是有帮助的。

AI agent在整个业务流程中处于应用层架构。那它与存储底层的关系是怎么样的？

例如一个客户的业务通过AI Agent进入后，会先到中间层智能媒体管理，去做素材的一些处理，包括像一些安全识别或者一些文本的分割和一些托管化的处理，让素材的格式满足训练的一些要求。到了引擎层，有大量的数据存进来必定会产生大量的元数据。这些元数据传统上是通过mysql数据库做一些元数据的存储跟管理。但是在AI大模型阶段这些数据的体量都是亿级，甚至百亿级的量级，用传统的数据库不一定能满足客户的需求。对于数据的检索也会有一些要求。所以在表格存储方面做了向量的一些查询检索能力。表格存储是阿里云nosql数据库的一个存储产品。也是一个Serverless化的产品。早期淘宝的一些订单系统，或者支付宝的一些信息流都是基于table store去构建。最后底层到对象存储，去承载海量的业务。

下面介绍两个比较常见的业务场景。

第一个是RAG场景。左边是一个RAG的业务流程。RAG场景是一个检索增强的业务，训练量很大，因为要尽可能的提高查询检索的效率。传统的RAG可能通过IOP sql方式去做训练，训练工作量很大。所以很多客户早期去构建业务时，去构建和维护的人力很大。另外因为现在大模型业务面向客户的业务场景多样化，有很多的客户的输入是模糊，会涉及到业务场景和索引能力，要支持模糊检索跟精确检索这两种能力。传统的方式通过自己搭ES架构去满足查询检索。但是如果自己搭会有ES的扩容和维护问题，需要自己去做好实时的水位管理，是一个比较大的挑战。

所以今天基于tablestore能力构建了在RAG场景的数据索引存储的底座。第一把标量和向量的索引查询能力聚集到一起，通过一个数据库的产品做了两个事情，避免了传统需要构建两个模块，两个模块分别做两个事情，做完后再做交叉查询。传统涉及到跨模块的通讯和维护，整个效率比较低。最近会在其他的一些客户场景中抽象出该能力，最后以一个PASS化的服务形式供大家使用。

第二个是Feeds数据流场景。用很多大模型服务时会跟大模型做一些对话，对话的过程是一个消息。消息发多了后就是一个Feeds数据流。对于一个客户来说，觉得发的消息不多，一天使用大模型对话十次。但是如果用户基数大就有可能要乘以亿级别，一天就是上百亿条消息需要进行存储。传统的做法是通过mysql数据库去做消息流的存储。但是用户量达到一定量级，mysql数据库运转不过来会被打爆。而且其中会有mysql的扩容和安全等等的风险。所以基于表格存储的能力，打造了在大模型阶段的Feeds流的存储能力。例如钉钉，钉钉每天的消息流的存储也放在我们的表格存储上，每天有千亿以上的一些数据量级。所以在其他场景上已经经历过了考验。

应对海量大数据业务的存储考量

最后介绍大数据业务场景下我们自己的一些考量。大数据场景在早几年就已经出现，但我们今天看到在大模型的客户中还是有大量的大数据处理场景，也会用到像上层的hadoop一些组件，或者是云原生的一些产品。在这个场景下我们一直在持续做一些能力的迭代。

比如最核心的是数据湖存储领域。阿里云的对象存储可以满足海量数据存储的能力，并且以一个比较低成本的方式去满足客户长期存储的诉求。业务过来的协议可能是多种多样的，可能是S3的一个协议，也可能是一个传统的HDFS的语义。所以今天围绕我们的数据库存储的底座，做了HDFS语义的全兼容，也有能力模块OSS与HDFS。上层应用HDFS接口访问数据湖存储没有问题，语义上完全是兼容的。在湖存储上基本是以一套完整的底座对接上层不同的应用。

第二是现在还有很多客户会提需求。因为用户要做大模型训练，他的数据源不一定是自己产生的，有可能是合作伙伴或者一些分支机构产生的，其中会涉及到数据最终如何上云。

闪电立方这个产品在2017年已经上线了，伴随着互联网时代高速在发展。早期互联网时代，我们帮很多客户从IDC把音视频媒体的一些数据上云。到了大数据时代，我们把很多半结构化或者非结构化的一些数据搬到了云上。到了今天大模型时代，我们也把很多客户采集的一些文本，一些视频或者切换的文件上云。这个形态非常直观，就是用闪电立方产品帮助客户把设备送到他指定的地方，然后把数据拷进去后，通过指定的物流和上云服务，帮助客户快速的把数据送到云上。整个的过程有加密等等的一些保证，可以降低客户数据的风险。

第三是大部分的客户数据体量比较大时会想用降本的方案。

在这几年结合我们自身的能力建设，做了很多产品的一些成长。在去年，我们有一款深度冷归档的存储产品供大家使用。这个产品的单价，基本上是一个G的数据在云上放一个月是0.75分。今天在云上基本上能够把我们的红利释放给大家使用，降低使用云计算的成本。

最后再来回顾刚才介绍的这些内容，如图。从前期的数据准备涉及到标注，和前后这些处理中提到的能力，主要就是在大数据场景中构建统一的数据库能力，以及针对AI前期一些能力。同时在中间环节做模型部署训练时，有高性能的并行文件存储CPFS，以及在AI推理，AI清洗环节有加速器的一些能力。同时面向用户端时，有智能媒体的图片处理和元数据管理的一些能力。最后是在RAG智能索引增强和AI客户端的场景中有表格存储、向量数据库的一些能力。整套就构成了当下可以去服务大家的AI存储解决方案。我的分享就到这里，感谢大家！