大模型训练集群的存储设计 原创

存储系统在分布式LLM训练中扮演着关键角色，需要满足几个关键要求。

1. 应与 GPU 的计算能力相匹配，以最大限度地利用其性能，避免因存储瓶颈造成的资源浪费。
2. 应支持大规模结构化和非结构化训练数据集的存储，并在分布式处理环境中具备可扩展性。
3. 模型checkpoint的存储和检索在 LLM 训练中也带来了挑战，需要系统满足模型大小和训练时长所决定的读写带宽要求。
4. 满足传统企业级要求，例如数据保护、高可用性和安全性。

本文参考了论文 Llama3.1 405B Paper， Efficient Training of Large Language Models on Distributed Infrastructures: A Survey 以及公号之前的零一万物《万卡集群的AI Infra实践分享》。两篇paper已上传到知识星球。

以Meta Llama 3 405B模型训练的基础设施为例。该模型是在一个配备16,000个GPU的集群上进行的训练。支撑这一训练的存储系统由7500台服务器组成，提供了高达240PB的SSD存储容量。

在设计上，该存储系统旨在支持持续读写带宽达到2TB/s，并且在爆发式读写操作时，读写带宽可以提升至7TB/s。这样的设计充分考虑了Llama 3 405B模型训练过程中的数据读写需求。

此外，考虑到训练数据庞大且数量众多，即使是文本格式，原始数据通常也是TB级别的，而语音和多模态数据则通常达到百TB的规模。因此，240PB的存储规划是合理的，可以满足模型训练过程中的数据存储需求。

文件系统的高速度可以支持每一步都可以记录一个checkpoint，当训练过程中出现问题时，可以迅速从上一个checkpoint恢复训练。这种设计大大缩短了容灾恢复的时间，提高了训练的效率。

Checkpoint

在LLM的训练过程中，checkpoint的数量和大小都是巨大的。模型参数量越大，所需写入的数据量也越大，这要求存储系统提供更大的写入带宽。例如，具有70B参数的LLM的checkpoint大小大约980GB。

在Llama3 的paper中，Meta表示采用分布式文件系统Tectonic使数千个GPU能够同时保存和加载模型checkpoint，从而为广泛的训练操作提供了高效且可扩展的存储解决方案。在字节的MegaScale系统，HDFS被用于集中式模型检查点维护，确保在规模上的一致性和可靠性。为了缓解checkpoint恢复期间的带宽瓶颈。

分布式对象存储，如Ceph对象存储，则提供了更易于扩展的特性。这种优势源于其没有层次化的目录树或命名空间，从而简化了一致性维护。正因如此，对象存储已在模型checkpoint存储中得到广泛应用。零一万物的数据中心就采用了Ceph。

训练数据

LLM训练的原始数据集是巨大的。Llama 3在超过15万亿token上进行了训练，而Llama 2的数据集只有1.8万亿token。每个token大约2字节，相当于大约30TB的数据。准备训练数据集涉及广泛的预处理步骤，包括数据抓取和清理，需要大量的实验。通常，这些步骤处理的数据超过最终训练数据集大小的100倍 。例如，WanJuan-CC数据集有选择性地提取了大约680亿个文档，生成了大约1万亿个高质量标记，相当于在丢弃99%的原始数据后，数据大小为2TB。因此，LLM训练的总数据量预计将超过数十PB。

并行文件系统，如Lustre、GPFS和BeeGFS，经常部署在领先的高性能计算系统上，以确保高效的I/O、持久存储和可扩展性能。这些系统也被广泛用于训练集群的数据加载，为高效处理大规模训练数据提供了必要的基础设施。此外，文件系统还必须使工程师能够对使用数千个GPU的工作进行交互式调试，因为代码更改需要立即对所有节点可用 。

在大多数LLM的训练过程中，每个token通常只遇到一次。然而，采用数据缓存策略仍然至关重要，以缓解数据加载期间的I/O瓶颈。这种策略涉及从较慢的后端存储预取训练数据到更快的缓存存储。Alluxio和JuiceFS通过从HDFS或对象存储等底层存储系统高效缓存训练数据，增强了LLM训练。Quiver支持跨多个作业和用户透明地重用缓存数据。Fluid利用Alluxio进行数据缓存，并引入了一种机制，可以根据I/O条件实现缓存的自适应扩展。

本文转载自公众号AI时代窗口 作者：郁愈

原文链接：​​https://mp.weixin.qq.com/s/FrDSfj7F-PKOV4xVj0ZM9Q​​​