大语言模型训练过程中，如何提供稳定训练断点保存和恢复的存储能力？

1、为支持和提升大模型分布式训练的断点重续能力，在存储上，需要提供TB级呑吐、千万级IOPS、毫秒级时延的分布式并行文件系统的存储高性能。
2、采用多级缓存技术，譬如蚂蚁金服针对容错过程中 Checkpoint 耗时长导致训练有效时间占比低的问题，在开源的DLRover 提出了 Flash Checkpoint 方案，实现秒 checkpoint 的导出和恢复。技术特点如下：
异步持久化：DLRover Flash Checkpoint 采用同步将训练状态写到共享内存，然后异步从共享内存写到存储系统，将训练阻塞时间降低到最小。
断点续存：故障发生后，DLRover 可以紧急将内存中的 Checkpoint 持久化到存储中。防止 Checkpoint 数据丢失，减少训练迭代时间的浪费。
内存热加载：如果非机器宕机故障，DLRover 可以直接重启训练进程，这时可以直接从主机内存中加载 Checkpoint，省去读存储文件的 IO 开销。

要提供稳定训练断点保存和恢复的存储能力，可以考虑以下几点：

1. 使用持久化存储 ：在训练大语言模型时，应使用持久化存储来保存模型的状态和参数。这样，即使在训练过程中出现中断，也可以从保存的状态和参数中恢复训练，而不是从头开始。
2. 定期保存模型状态 ：在训练过程中，可以设置一定的周期来保存模型的状态和参数。例如，每训练一段时间或一定数量的迭代次数后，保存一次模型的状态。这样，如果训练过程中断，可以从最新的保存状态中恢复训练，而不是从头开始。
3. 使用增量训练 ：增量训练是一种训练方法，它可以将训练过程划分为多个阶段，每个阶段只对模型的部分参数进行更新。通过使用增量训练，可以更有效地保存和恢复训练状态，因为每个阶段的训练状态和参数都相对较小。
4. 优化存储结构 ：在保存模型状态和参数时，可以使用压缩和编码技术来减少存储需求。同时，优化存储结构可以更有效地利用存储空间，提高存储效率。
5. 容错和冗余设计 ：在存储模型状态和参数时，可以考虑容错和冗余设计来确保数据的安全性和可靠性。例如，可以使用分布式存储系统来分散存储数据，并使用多个副本来提高数据的可用性和可靠性。

提供稳定训练断点保存和恢复的存储能力需要综合考虑多种因素，包括存储系统的选择、数据备份和容灾策略、存储硬件的性能和效率、以及元数据的管理等。通过这些策略的实施，可以有效地提高大模型训练的数据存储效率，确保训练的稳定性和可靠性。具体如下：
1.       采用分布式文件系统：使用如HDFS或Ceph等分布式文件系统，可以有效地管理大量的训练数据。这些系统可以在多个节点上分布数据，提供高可用性和容错性，从而确保训练数据的稳定性和可靠性。
2.       采用IB、RoCE网络：代替传统网络，大幅提升跨节点网络访问和交互效率。
3.       采用检查点（Checkpoint）机制：在训练过程中，定期保存模型的状态和参数，即检查点。这样，如果训练过程中出现中断，可以从最近的检查点恢复，而不需要从头开始训练。同时，通过保存多个检查点，还可以防止因为某个检查点损坏而导致无法恢复的情况。
4.       高效的存储硬件：使用高性能的存储硬件，如NVMe SSDs或分布式存储系统，可以大大提高数据读写速度，从而加快训练速度。同时，这些硬件通常也提供更好的数据一致性和可靠性。

增加 checkpoint frequency ，减少 checkpoint time 和 retrieval time 有助于提升故障恢复的效率。因此，从两方面优化：一方面，把断点尽量保存在 CPU 内存中， CPU 内存可以使本地或者远端的，从而避免去读写磁盘。另一方面，增加 checkpoint frequency ，减少算力浪费的时间。实现这两点有挑战：
第一点，用 CPU 内存存断点需要设计备份策略。因为如果一个节点出故障，那么这个节点 CPU 内存的内容肯定也没了。这就需要把这个 CPU 存的断点数据在其他地方备份一份，类似分布式文件系统的三副本原则。备份的地方可以包括其他节点的 CPU 内存或者是磁盘，这就要搞成一个层次化存储空间，因此就需要有些设计副本策略，来增加从 CPU 内存中恢复的概率。
第二点，上述存储断点的层次化存储空间是分布式的，这就需要不同节点的通信，这可能会和模型训练的通信互相干扰。稍有不慎增加了训练的总体开销，相比故障恢复的时间的节省反而得不偿失了。所以，如何避免额外通信引发的问题也有挑战。

1. 使用版本控制系统 ：可以使用版本控制系统（如Git）来跟踪训练过程中的权重和参数变化。这样，即使训练被中断，也可以轻松地恢复到之前的版本。
2. 定期保存模型状态 ：可以在每个训练周期结束后，保存模型的权重和参数。这样，即使在训练过程中断，也可以从保存的中间状态继续训练。
3. 选择合适的保存周期 ：保存周期太短可能导致频繁的I/O操作，影响训练速度；保存周期太长则可能在中断时丢失过多的计算资源。因此，需要根据实际情况选择合适的保存周期。
4. 使用分布式存储系统 ：对于大规模训练任务，可能需要使用分布式存储系统来存储模型权重和参数。这样可以提高存储的稳定性和可靠性，并支持多个节点同时读写。
5. 数据备份和恢复机制 ：为了防止数据丢失，需要建立完善的数据备份和恢复机制。可以使用专业的备份软件或云服务来定期备份训练数据和模型权重。
6. 硬件冗余和容错机制 ：为了提高存储的稳定性和可靠性，可以使用硬件冗余和容错机制。例如，可以使用RAID技术来提高磁盘的容错能力，或者使用多个存储节点来提高存储的可用性。
7. 监控和告警机制 ：可以建立监控系统来实时监控训练过程和存储状态。如果发现异常情况，可以及时发出告警，以便及时处理和恢复训练过程

Checkpoint是大模型里对存储要求比较突出的环节，如何提供稳定的存储支撑能力，业界在过往一年中有过一些摸索，到目前业界基本上已经形成了主流思路，利用分布式全闪存存储产品提供持久化存储能力，不少国内国外厂商都推出了相关产品方案。

Checkpoint 机制我认为可以类比为快照，它定期保存某些个时间点的完整模型状态的数据，如果发生故障，我们就可以调取最近的快照数据，将模型重新恢复到上个检查点的状态，从而提供数据保障能力，帮助恢复训练业务。

和快照类似， 从提高安全性出发，Checkpoint 应当设置得尽量多，断点越密集发生故障后的损失越小；但反过来，更多的断点对存储系统也有更高要求，如做断点时的性能高峰要求、写断点期间对系统本身正常业务的打扰，大量断点数据存储空间都是要考虑的因素。所以往往最终是取一个多方平衡的结果。

最初大模型的存储方案是五花八门的，放本地盘或是弄一台传统 NAS 都有人试过，规模小的时候问题不大，顶多是在数据预处理和第一次数据载入的环节会慢一点，但也可以忍受。而在模型规模和训练数据量增长后就不行了。规模变大导致训练周期变长，故障风险升高，因此 checkpoint 设置从无到有到很多，频繁的“打快照”（每次需要写入的 checkpoint 数据从几十 GB 到几个 TB ），导致此处成为对存储要求最高的环节。

针对此刻的应用特征进行分析，对存储的需求主要是超高性能带宽和高并发，此外存储本身的高可靠和高可用也是必须的。

这个时候，使用 NFS 协议的传统 NAS 存储性能就远远不够了。业界在 2023 年中时，还在互相交流在训练节点（服务器）本地多放几块 NVme 的 SSD 盘，突然就获得了性能上的大幅提升，大家惊喜的发现，做 checkpoint 不用再等个半天一天了，用我尊敬的某位老院士的原话：“嘿！一会就得！”。

但这个方案还有个明显的隐患未解，那就是本地NVMe盘的可靠性无法与成熟的存储系统相提并论。所以到了现在，使用 NVMe 协议的分布式全闪已经是最受认可的解决办法，既能满足超高的并发性能，也能提供存储的高可靠与高可用，还能支持弹性扩展，基本已经满足需求。

另外，从存储类型来看，块存储，文件存储和对象存储中，更适配的是文件存储，对象太慢，块没机会。

国外一家科技媒体明确提出：“ We think this will primarily benefit file access all-flash arrays using NVMe protocols and with GPUDirect support for Nvidia GPU servers. Suppliers suchas Dell, DDN, NetApp, Pure Storage (AIRI) and VAST Data are well-positioned to capitalize on this. Panasas sees an opportunity in edge AI. Object storage and block storage suppliers are not so well-positioned.
”
除了基于硬件存储的方案，并行文件系统软件的产品和一些数据管理软件如数据仓库也有不同的厂商在尝试，例如 IBM 的 GPFS （现在改名叫 storage scale ），据说某大厂在优化了以后用得还是满意的，具体细节情况因为商业秘密因素就不得而知。

除了找已有的产品搭建私有化解决方案，国外更习惯在云上进行训练和推理，为此云厂商也有针对性的优化措施，例如微软的Azure针对 大模型checkpoint 的应用场景，提供了一个新产品工具Nebula，号称能把checkpoint的时间从几小时降到几秒。 “Nebula is a fast, simple, disk-less, model-aware checkpoint tool in Azure Container for PyTorch (ACPT).“
链接如下：
https://learn.microsoft.com/en-us/azure/machine-learning/reference-checkpoint-performance-for-large-models?view=azureml-api-2

学术界则从算法设计上着手： 2024 年 1 月，来自爱丁堡大学和新加波南洋理工大的一篇联合论文里，提出一种 serverless LLM 方法，利用一种加载优化的格式设计，结合高效的多层的 checkpoint 加载系统，能够实现更快速的 checkpoint 加载 ;
论文链接： https://arxiv.org/abs/2401.14351https://arxiv.org/pdf/2401.14351.pdf

可以参考我的相关文章：

大模型里的Checkpoint和存储方案二三事
https://www.talkwithtrend.com/Article/269363