分享人：阿里云智能解决方案专家 川军

大模型的第一性原理| Scaling Laws

大模型场景/AI场景是目前的一个核心热点。大模型的核心三要素是算法、算力和数据，而决定大模型智商水平的核心就是数据。数据如同人类的知识输入一样，输入高质量的知识，产生高质量的认知。整个业界都遵守第一性原理（Scaling Laws），是指随着模型规模的增加，其性能、效率以及对资源的需求方面的规定上变化。

第一是性能，一般来讲，随着模型参数的增加，模型学习的能力和泛化能力也对应增强，大模型能够更好的获取性能。以最近发布的Llama 3.1举例，它的参数量已达到4050亿，实测效果优于ChatGPT4o，可见模型参数的增加，会带来整个性能的提升。现在整个大模型的门槛的基础是千亿级的参数，并且未来会达到万亿级的量级。

第二是数据，大模型通常需要更多的数据来进行训练，以避免过理合。更多的参数也就需要更多的数据来学习，传统ChatGPT3.5的数据量级是几百G的量级，ChatGPT4是几十TB的量级。多模态场景下的训练，比如Sora需要百PB的数据来进行训练。

第三是计算能力和效率。大模型的迭代需要持续更多的算力来推动它持续的参数增加。其次，在对硬件支援的同时，还需提升计算资源的效率，这不仅体现在训练场景，还有推理上的呈现。以现在国内的大模型推理市场举例，整个大模型的推理已经卷至千tokens到几厘的价格，这是对算力和算力的效率极致要求上的场景。

AIGC业务处理流程

接下来看对如此关键的数据，我们在整个业务流程中是如何来进行业务上的驱动。我们可以看到整个AIGC场景或者大模型场景是有悖于传统的AI场景的，传统的AI场景基本上只有数据的收集，数据的处理、数据模型的训练（模型的仿真和模型的推理），但是面向AIGC大模型场景，有RAG场景,这是为了解决搜索问题和生成文本时需要从更新更全的文档库中去搜索相关的信息，并通过大模型进行回答、综合推理，从而提高其预测的准确性，解决了我们知识的局限性/幻觉，或是某些企业数据安全性的问题。这个流程在传统AI流程里是没有的。

第二可以看到模型的精调或微调，近一年比较火的图生图的场景，要个人用户上传个人图片，利用这些图片进行二次的精调，修改这些模型的参数，来获取更个性化的推理图片的输出。这是两个关键的区别。

如图，我们把整个AIGC场景分为两大块，四个模块。整个AIGC流程分为离线和在线两部分。离线是数据的处理和模型的训练。在线部分是模型的精调和推理。相对于传统的AI场景，在线部分是更注重于时效性和稳定性，这和传统的基于端侧的推理是有重大区别的。

AIGC时代的数据湖的四大特点

接下来是基于这些新的业务流程，面向我们的数据处理训练和推理过程中，数据湖承载整个数据业务流主要分为四大特点：

第一，数据来源更广，数据的规模更大。传统的数据湖更多的是处理日志类、业务类、报表类等场景的数据分析。而现在面向AI场景下，特别是AIGC场景下，面向多模态，包括RAG爬虫数据的处理，数据量更大，而且往往通过外部的爬虫，或外部的信息来获取的这个数据的来源和数据的规模是不一样的。

第二，计算引擎不同。传统的数据湖场景的支撑是以Hadoop的计算框架来支撑的，如Spark type或flink这样的计算框架。新的AIGC场景不仅需要Hadoop的计算框架来对其数据进行处理，可能面向一些多模态的一些场景，可以用python友好型的RAG框架来进行数据处理。在模型的训练或推理过程中，整个transformer的应用框架是paper t，需要基于python的框架来更好的对数据进行读写，适配整个python的框架。

第三，处理数据时效性要求更高。传统的数据湖场景处理报表往往是以天级或周级来进行数据的批处理。AIGC这种场景，以RAG场景举例，需要对前一天爬虫的实时新闻数据进行更实效性的处理，需要小时级别把这些数据进行处理完后，生成对应的索引来支撑数据推理的准确性。其次还需对一些多模态的数据进行更高效的数据清洗，来支撑模型的快速迭代，时效性也是有区别的。

第四，传统的数据湖场景更多的是支撑离线的业务和少量的一些flink上的实时处理业务，这部分都是轻量的。但在面向AIGC的场景下，还会支撑这种模型的Fine-tune，或模型在线推理的加载。所以对模型的数据吞吐的时效性、稳定性要求更高。前半部分离线数据的处理，更多是持续性、刚性的吞吐需求。面向在线业务，突然一批的推理需求到来时，需要突发性的吞吐需求。

综合层面来讲，面向AIGC时代，整个数据湖需要更大的容量，需要支撑更多面向python Christmas框架的一些AI类的生态支持；其次还需要面向突发性吞吐场景的柔性吞吐带宽的需求。综上，是需要更高的性能。部分面向大模型或者是特别是多模态的一些场景。

新时代数据湖For AIGC的典型架构

接下来是典型的头部客户的典型的数据湖架构。

第一部分是数据的爬取/采集。面向大模型或多模态场景，不仅需要爬取国内产品的数据，还需要爬取一些海外的高质量数据。这部分数据，由于它的间歇性爬取，我们建议客户把数据先存在海外的一个bucket里，然后通过我们OSS的跨区域复制，再加全球传输加速的网络，使海外的爬虫数据更稳定的、高效的、近实时的避开国际网络抖动，更高效的传输到国内的bucket，进行数据的层面的处理。

第二部分是数据处理层面，这里分为两大块，一是传统的自然语言类的数据处理。这块数据处理，很多客户更倾向于Hadoop框架。以RAG场景举例，把每天网页爬虫的数据通过Spark进行数据清洗，再写入h base这种显示器进行正排，作为知识库，然后在此基础之上对应的建索引。这其实是以Hadoop框架来进行数据处理的。阿里云的OSS的OTPFS面向传统数据库管理是非常成熟的性能和功能生态上的结构。二是面向多模态场景，很多的头部客户用RAY框架进行数据的转码、杰森，还有其他类似的处理。RAY框架直接调用OSS的更高清的一个SDK来保证单流性能的稳定性和数据的吞吐。

第三部分，是数模型的训练和微调。训练主要是以高性能的并行文件存储存储来进行承载。但在面向多模态场景，还有一些特殊的check point重新加载的场景，比如直接需要快速、便捷的直接从OSS进行数据的层面的加载，这一部分是通过适配底层的框架pattern然后出了一个更高性能的一个connector, 来保证单流性能更高。在某些头部客户实测来看，性能至少提升两倍以上。这样，提升数据加载的效率，间接的提升计算资源的利用率。

第四部分，是推理。推理最大的挑战是模型一批次的推理需求到来，需要批量的去加载模型文件。比如以fine tree这种场景，最佳实践是把模型文件提前加载到加速器里，这样可以更实时的进行弹性性能的吞吐兑付，来满足模型加载上的性能需求。另一部分，有些客户更习惯于使用mass进行模型数据的加载，可以通过OSFS把它直接挂载上容器平台，通过nas接口来进行数据层面的加载。在OSFS最新的版本中，已经把整个性能提升了两倍以上。

在面向基础模型，特别是多模态模型场景下，围绕计算生态，我们做了持续性的优化，让数据存得下，并且成本更低。通过各种生命周期的管理能力，让它沉降到更低的存储成本。其次我们对接了更多的AI生态，比如说刚刚讲到的python的生态和RAY生态，使计算效率更高性能更好。

阿里云AIGC场景存储解决方案全景

最后来回顾一下面向AI场景阿里云在存储方面全局的解决方案。

刚刚讲到的是数据的处理、训练和推理。训练场景更推荐的是高吞吐、低延迟、高LPS的场景，我们推荐的是使用阿里云的自转CPFS. 其次面向推理结果的处理，或是标准化的多模态的一些数据处理场景，我们可以用OSS的IMM来进行数据安全性的检测，或基础的抽帧，来保证数据层面的处理、卸载。面向RAG场景，可以把数据的知识库和索引库建立在最新table store的向量数据库引擎上，这样进行更高效的数据检索，来支撑上面推理的准确性和实时性。