从整个上网应用到基础设施角度看具体的解决方案和一些业内头部的客户的关键实践。从整个大模型的数据的整个链路，业务的需求和产品的响应，客户的收益。

首先大模型谈三个要素，分别是算法、数据和算力。大模型数据在整个流程中是一个核心的要素，类似于数据的质量的高和低决定模型的认知能力，模型的值可以决定模型的上限，如果数据集或训练数据集不太好，反而模型参数很大，它的整个效果也不会一定见优。

其次在整个算法、数据和算力三要素过程中，业界目前都遵守ScalingLaws一定低于原理。第一原理是阐述整个数据和算力面向基础设施过程中，提高整个模型训练或模型生产的效率,第一参数是模型的能力，各家都在发布各种开源的模型，模型的参数量会越来越大。比如大家都以迁移模型做未来标准的大语言模型的门槛，可能会产生更多的泛化的效应，实际数据也是其中的一个核心点，GPT-3数据的训练集只有570GB，一个移动硬盘或一个小的U盘就能装下，GDP-4的数据集有20T左右，但是整个参数量会翻很多倍，所以数据是决定一个核心点。面向多模态的数据集的训练数据集是一个PB或数十PB的量级，这个数据集是值质列的变身，这个数据集是一个PB级或几十PB级的量级，但是需要外部获取全世界或全互联网的公开的知识范畴的原始数据，可能在百PB级以上，对整个基础设施是极大的挑战，把这个数据通过高效的基础设施进行提炼，训练100PB，但真正有用的数据训练是多模态的数据,可能只有1PB。

在概念论中有一个效率的问题，虽然现在都是暴力法则，堆更多的GPU，把参数通过算法把它堆大，但实际上效果、效率其实不一定高。比如千万开源的2.5，签数量其实在75B，但是可以从一些公开的测试集，其实基本上对标现在千亿级别的拉玛3.1，这是一个效果，另一方面数据集是一个关键，虽然参数量更大，但是算法实际上是不能达到一个很好的训练效果，所以数据在里面是非常关键。在大模型管道中，或传统的大语言模型或是现在比较火的多模态的模型整个业务的管道，根据传统的自动驾驶的数据，它的数据采集方式可能是通过车录采方式，多模态更多去买业界好的一些数据集进行训练。

其次面向开源的或特定领域，还需要自己采集，或基于企业自身的一些数据进行进一步的清洗，所以数据采集是第一部分，在数据的处理中需要把数据按照自己定义的标准的数据格式，把它进行成关键数据集进行后续的训练，所以数据采集和数据处理是整个环节的第一部分。

第二部分是数据的模型训练，拿到数据集以后，如何高效的支撑模型的训练，高效是在同等的算力情况下，支撑更多训练的效率，或是更多的训练时长，获得更大的模型参数，在存储基础设施中，该如何做？

第三部分面是推理场景。模型训练好以后，需要面向某些场景下。一个基础的大语言模型不能面向所有的行业和所有的场景都使用，比如去年比较火的应用场景的NPC的扮演,需要拿一些游戏行业的特定领域进行finetrain，或者是调出小的road模型，进行在相应的场景进行适应。所以在模型推理这部分中如何加速，还有通用模型在面向基础大模型处理整个业务的流程，一些通用大模型是没有办法解决的。比如特定领域的数据，比如安全集的安全，或企业内部需要解决大模型幻觉问题，需要通过RAC技术，特别是一些开源搜索的场景，需要通过大模型支撑，响应最新的实时新闻，实际上基础大模型在训练的时候是没有知识的，所以需要实时的面向公开的收据，搜索的场景里面，还需要采集互联网的实时消息进行数据的处理，还有一部分讲ARGC的一个场景，讲在面向存储层看面向数据的处理，数据模型的训练和推理层面,把效率或者数据支撑提高整个训练的效率。

一、数据处理Part实践

首先在数据处理层面，今年大家都在谈多模态、多模态的一些数据处理流程的区别,以及业务的流程对底层基础设施的区别。第一点传统的大语言,使用公开的数据爬文本的数据,文本是半结构化的，或网页数据，业界把这些数据做清洗，文本的数据清洗是非常成熟的框架和理念,对数据做排序关键字提取，再把数据和文本做隐私保护，这些东西是非常成熟的东西，它的数据集几十个T，采用原始的数据量也不大。但面向公开大收场景，这种实时的每天采集互联网上的数据，这些数据量可能会有PB量级。

如果把整个公开互联网每天的新的信息采集回来，这个量也是比较大的，或这些文本的数据其实已经很成熟，这种通过传统的Hadoop框架处理，把这些数据清洗，做全文索引，做一个库，做倒排，再支撑后续的索引，这块是非常成熟的技术架构，挑战比较小，下面是多模态。

第一点数据量是非常大，一个起步的多模态数据采集量都在一个百DB数据，原始数据百DB以上，如何把百DB的数据进行高效的清洗，分为两类，面向人群和面向的产品其实是不一样的，因为现在很多算法或者数据不像传统面向半级化的数据,现在对数据多模态数处理其实面向更多是Python，业界前些年已经有raydata的框架，现在主流都在用这个框架进行多模态的数据的处理，把原始数据做质量筛选，统一格式转码，做关键帧的提取和切片操作，不止有传统的CPU的操作，还有GPU的操作，包括可能未来打标的时候引入GPU的小卡的算力进行推理，把它进行标签化，现在这个GPU时代下，需要追求更高的效率，过程中可以看到每天数据集可能多模态数据是百P，一天采PB级数据，这个数据量是非常大的，整个过程中的中间过程的数据量逐渐逐渐减小，它是对比传统的大语言,对存储层的带宽和性能要求更高。

其次在整个过程中，中间过程数据是不需要持久化的，它其实是一个临时化的，最终只需要把原始数据和结果数据存下来，包括一些标签类的数据保存好，在面向存储基础设施的时候，或者选一个对应算力加存储的时候，如何让它更高效，更便宜或者更弹性,这里面大致分为两部分,面向传统的大语言基于read框架进大原则数据,因为有统一框架，但实际上绝大部分客户通过Spark文本的非结构化半结构化数据进行数据的信息，针对阿里云面向hadoop生态有非常成熟的一个解决方案，不管是针对于学习完以后存到hbase做相关索引库，或者HDFS生态，包括上面的各种各种性能，各种接口是在前些年的整个数据库，这部分是没有任何一些挑战的，这部分也会关系到性能上的问题，性能上的问题面向HDFS，在云上语义通过一种数据库的清洗，提供更高效的、更兼容生态的解决方案。

由于整个数据信息过程中的原始数据的过程，以及数据的爬行数据，还有未来RAY，抽取数据信息做对应的排除和解锁,业务层面要相互影响,业务层面是希望在线业务，不希望把离线业务做带宽或性能上的侵蚀，面向客户做了一些实践，即可以基于统级别组，比如把用户设成一个组，这个组里面共享最高的带宽，但是每个桶里面不是一个平均概念，可以针对高优先级的桶或账号,给他提供更多的一些带宽保证在实时检索场景让它能及时响应，不受离线业务影响，这是面向原来数据库生态以外，面向数据库场景提供的一种功能保证，生产的数据不受性能上的一些影响。

第二点是RAY面向多模态的数据处理，这种数据的处理量很大，性能要求很高，因为每天1PB中间清洗多次，中间过程数据保证性能达到刚性的交付，或更高效的交付，这一点其实有别于其他的框架，跟客户做一些实践,可以在整个流程中里面把相应的高带宽的算子把它绑在一台机器上面。这台机器是一个高内存的机器，因为它的数据量非常大，但是如果需要一个高弹性，或者这个机器里面需要一个本地的临时的数据数存储，如果传统方法的选择可能是本盘，如果面向弹性或者性能场景里面，可能这个本盘可能容量性能不够或者容量多，对成本不太合适的，可以在这台机器上挂一个弹性临时盘，它类似本盘，非常灵活的面向冲突性的或者临时性数据提供一种更高的带宽。得到的结论是面向申请云资源的时候，成本肯定资源没有浪费，不用为申请更大更高性能盘和更高配的机型，浪费CPU或者GPU达到更好的效果。

接下来分享一个案例，这个案例是以整个MiniMax业界开源startup中，或语言模型中startup公司头部的企业，如何在阿里云上进行相应的数据处理，首先要上云，数据的采集和数据的处理中间的资源，包括各种的Ip是否有非常大的弹性，包括资源的差异，库存的量。如果在线下做是不太实际的，成本或各种网络的资源没办法满足，所以要把这个东西放在云上，在云上进行一个高效的处理，处理的过程中是性能，效率还有成本，另外一点，这些业务既有数据的采集，又有数据的处理，还有微些模型的数据，面向用户给他极高的一个TB级的带宽,可以运用OSS技术,即一个主OSS可以基于RUN角色，或基于桶限制业务，而对应角色是交叉的概念,保证它把客户最高的性能发挥出来，而且还不受影响，OSS作为数据湖的底座，同时支撑它的Spark和RAY两层,即大语言和多模态的数据处理，提高整个的满足。首先满足性能的需求，其次是性价比的需求。这个案例对整个业务的价值有一定的借鉴意义。

二、模型训练Part实践

接下来是第二部分数据模型的训练。对比于传统的大语言。多模态对训练场景有挑战或者提高客户本身对训练资源的效率，以下是对存储层面需要的诉求,第一是数据集到50PB的增长,第二是把CheckPoint快速的写进去，但在CheckPoint多模态参数情况下，因为模型和优化态优化器,当CheckPoint已经变成20T，希望把频率变高。因为其在整个算力层面非常贵，而且都是万卡，把CheckPoint的频率压的越低,损失的算力就会越少，比如重新做拉回集训的时候，算力核实就会越少，对存储的挑战量会更大。有些客户在做拉起的时候，一次训练的失败再重新再跑一次。

如何让拉起的效率更快，以及数据集的拉起效率更快，大家以为传统中的大语言或模型中数据集量小，不会重复读。在面向多模态场景里，框架会提前阅读一些数据，但面向图片数据集的场景，它还是有重复读的，如何把同步读通过存储层，让它效率和性能上去，进一步释放它的算力，特别是GPU的算力，这些图可以囊括一个传统大语言和多模态训练场景下做整个方案的实践。面向最关键的或最及时刻的场景，或影响整个训练时长的场景是第一波拉起数据集的时候要拉的快，提前要去读两到三个iteration数据集，这个数据集可能在几十DB级别，多模态查起来可能会有几十DB的量级，在数据集可能很大的情况，短时间内,存储成本在一个高性价比的存储类，如何把数据快速拉上去,第二点是在训练过程中，要写CheckPoint，CheckPoint是对延迟非常高的，或在CheckPoint写的过程中有其他的训练日志也不能影响。

训练日志和CheckPoint有区别。虽然Check，Point写下去，但是由于CheckPoint基本上是一些大文件,对存储是非常友好的，如果一套存储系统设计不太好，它会互相影响，间接的影响训练效率。因为写小文件的时候被写大文件不同的IO模型所影响，这个时候的效率会下降,还有一点是在CheckPoint写完后，要把这个数据进一步的沉降，因为现在业界客户把ChecPoint做成一个几分钟或十分钟的量级，但不一定要把所有的十分钟的切后都存下来,只要挑选先存到比较热的高性能低延迟的存储里，在后台把它挑选或者筛选一些关键的切破点，把它搬到后面更成本更低的一些OSS或者量存储里面保证性价比。做一个高存储和高性能存储和低大容量加高性价高性价比存储的协调，需要方案的设计,主要分为两大类，一个是大容量，非延迟敏感里小延迟敏感型的场景里面,可以看到这个坐标图里面，在CheckPoint的训练日志里面，它的延迟和带宽要求是不一样的，把这一部分放到一个高性能层里面，多模态数据量很大，不一定要把它放在高性能层，只需要保证第一次拉起来的时候把它快速拉上去，而且这里面数据还是有重复读的。

面向多模态的一些场景里面，特别是图片的处理场景，可以通过加速器的场景，让这种存储层把数据的一些同步读，把性能发挥出来提高效率。其次在高性能和低性能这一层之间，通过一些数据流保证性价比和性能的均衡。接下来可以看阿里云上进行的实践，强调面向多模态场景里面，不是把所有的数据都放在比较高性能的CPFC里，面向多模态场景里面，可以把它数据集放在OSS，或者是稍微廉价的数据存储里面，只要保证高的带宽，或者在模型训练数据快速拉起，压缩拉起的时间，比如可以看到在月站面临客户里面，通过开加速器，在图片训练场景里面，至少可以把整个业务拉起的时间，从存储层面其他参数不变加缩到原来的2/5，至少存储层面不会成为相应的瓶颈，间接提高效率。

三、模型推理Part实践

最后是模型推理，从业务形态来看，把一个大模型推上去都可以跑。但面向很多的业务场景都是需要经过小的模型和大的模型,如何保证大的模型，每台机器都需要加载,小的模型中部分机器需要加载，比如做一个深图的场景，生成一个卡通型，只需要其他卡通型roller，模型加载上进行推理，可以分为两边来看，下面的一些细节是通用的，面向基础模型时,把模型加载上去，所有的机器都需要加载,所有的Pod都需要加载，在存储不成为瓶颈的情况，如何把进行P2P的分布式的加载达到高效性。

比如做检索或者是生成一个图，在排除后面的排队情况，希望客户的体验是两分钟就能出来,如果加载基础模型的时候，尽量把Pod拉起来效率压缩到一分钟，模型加载通过P2P的方式把它加载起来，这个效率是达到更高的，面向小模型用下面的场景举例，这个客户是国内的做aI生图的客户，有12000多种小的模型让客户选择，包括可以上传自己的开源或自己训练的模型，生成自己想要的结果，它的商业模式第一是付费，第二可以选择上传自己的KDIY，生成各种各样的小模型,比如一个小模型是10G，有一万多个也是几十TB、上百TB的数据，包括客户自己上传的,小模型是根据客户的特征按需加载,在存储这层，如何做到加载效率,它是有冷热之分的，肯定是有一些风格类或者偏向于实际需求类的场景，可以把这些放到一个加速器中，不仅提升单流的加载效率，并且把解决服务端自身的瓶颈，间接提高整个小模型的加载效率。

最后在面向数据采集的处理模型，处理分为自然语言类和多模态数据处理,模型的训练和推理。做一个全景的面向产品层面的基础架构图,目的在面向基础模型的迭代，特别是一些多模态技术模型的迭代，阿里云面向生态、成本、计算，把它整个效率和成本发挥到最优，这是我们所需要做的价值。总结为买最贵的GPU，但是要用最合适的存储。