存储人视角：人工智能AI + 大模型

原文来自于知乎存储专栏：

存储人视角：人工智能AI + 大模型

前沿

我的角色	背景	AI 出场	效果
一个宠娃狂魔	娃喜爱并有奥特曼玩具	她的奥特曼玩具会跳舞了	娃对我的崇拜和爱又多了一分......amazing
杭州网商路艾弗森	球队需要制作LOGO	形象生动的LOGO生成了	......amazing
历史/地理爱好者	我想了解古代所有著名关隘	所有关隘名称，位置，典故都出来了	......amazing

人工智能AI & 大模型实在是太火了，并且太有用了，作为一个存储从业者，免不了和各类人工智能相关团队打交道。在这个过程中，接触到了一系列名词术语：AIGC，AGI，大模型(LLM)，ChatGPT ，NLP，RGA等， --- 这些都是何物？他们之间有哪些微妙的联系？在阅读了海量相关资料后，我这个外行算是了解了一点点，所以这里希望可以理清一下(如有疏漏请指正)。

当然，因为数据是人工智的基石，所以作为一个存储人，最重要的还是希望弄清楚这些人工智能产物和我们存储有什么内在的关系。然后，也希望了解一下我们业界的存储系统都在这方面做了哪些有趣的事情。

人工智能简介

上图勾勒了AI的全貌，要是想了解更多细节，参考文献里面有很多很好的资料(对我这种非专业的人来说)。另外，为了避免文章台臃肿了，上图里的嵌套图会放在留言区里

存储和AI的关系

"数据集"是AI与存储之间的桥梁，AI & 大模型要做的事情就是利用海量数据进行训练，然后获得相应的知识。不同的数据集(文本，视频，图片)会有不同的总容量和单文件大小，自然对存储的需求也是不一样的。

数据集

大模型的典型数据集

机器学习数据集

AI 下的存储

这里先以使用kimi或者通义千问为例，简单来说可以分为两个部分：使用者 & AI 服务提供商(kimi)，流程大概如下3步：

使用者：使用者输入想了解的问题
服务提供商(kimi)：kimi的线上推理模型收到使用者的提问信息后，生成提问对应内容
使用者：收到搜索结果

那么其实这里的关键就在上述的第2步：也即kimi的线上推理模型是什么？这个推理模型是怎么构建的？

推理模型的构建：收集海量数据(数据集)，在此基础上进行训练，获得相关知识推理模型，然后把这个推理模型部署在线上。

大模型全流程可以划分为四个主要的环节：海量数据的存储和处理，模型开发，模型训练，模型推理。

大模型环节	描述	存储需求
海量数据存储&处理	数据采集导入、清洗、标注、归档	海量数据，不同类型的数据
模型开发	数据科学家进行模型开发	POSIX 兼容、可靠性和可共享
模型训练	GPU集群读取数据，进行训练，得到推理模型	-------
推理模型部署	把训练完的模型快速分发部署到线上，服务用户	过程高频、反复发生，既要求高并发、高吞吐，又要求整个流程尽量简单高效

这里重点说下模型训练对存储的需求：对于一个典型的训练来说，可能迭代多轮 epoch。在每个 epoch 内，首先需要对数据集进行随机打散，然后将打散后的数据划分为若干 batch，每读取一个 batch 的数据，进行一次训练迭代。同时会周期性保存 checkpoint 用于故障快速恢复：

1. shuffle阶段是纯元数据操作的过程，主要依赖大量文件的 LIST

2. 数据读取过程则元数据和数据操作都有

3. CheckPoint：大模型单个节点的 checkpoint 通常就能达到几十上百 GB。而多个训练节点同时写，需要恢复时又同时读，对存储提出了很高的吞吐要求。同时一个关键的问题是 checkpoint 期间整个训练是中断的

当前AI使用的存储分类

存储类型	代表性系统
本地文件	NVME SSD + 本地文件
分布式文件系统	CephFS,HDFS,GPFS,NFS,DAOS
对象存储	Minio,NVIDIA/aistore
文件网关+对象存储	Alluxio，JuiceFS，CurveFS
向量数据库	Milvus
商业存储	VAST DATA，WeakFS，焱融YRCloudFile百度沧海，阿里云文件存储 CPFS等

我的存储系统适合AI么

工作中参与了Ceph以及CurveFS，所以基于这两款产品简单聊聊。

Ceph

Ceph的rados其实还是比较适合AI训练的，因为基于rados集群的可扩展性以及BlueStore的io特性，其能够提供不错的带宽能力。

但是可惜的是Ceph的元数据在大规模小文件下可能会成为瓶颈，我个人理解可能主要有2点原因吧：

目录分区(扩展性不足)导致的竞争：虽然CephFS提供了静态子树分区以及动态子树分区，但是动态子树分区太复杂且尚未成熟，当前业界一般使用静态子树(PIN),但是这种方式又带来了运维的复杂性。

CEPH多Client的强一致性：比如你当前只有一个Client在写，其默认是可以写到Client的内存Buffer的么，但是如果这时候又有一个Client挂载过来了，那么MDS就会要求之前的老的Client把之前写的Buffer全部刷到osd数据池子里面去，那么这个过程有可能是比较的。

一些小小的优化：

只读快照：如果所有针对训练数据的操作都是读取的，那么将数据集驻留在只读块设备的快照上可能会更好。例如，使用Ceph创建RBD卷，其中放入数据集，获取快照，然后将该快照映射为多个实例(这些实例都需要访问相同的图像集)上的只读快照
lazyio模型：如果对数据的可靠性和一致性没有那么高，可以考虑下CephFS的lazyio模型
减少小文件操作：将数据预处理为类似TFRecords这样的格式是一个巨大的优化。
Ceph本身的性能优化：参考分布式存储性能优化的几点(Ceph篇)

CurveFS

简单说一些亮点吧：