存儲(chǔ)系統(tǒng)在分布式LLM訓(xùn)練中扮演著關(guān)鍵角色，需要滿足幾個(gè)關(guān)鍵要求。

1. 應(yīng)與 GPU 的計(jì)算能力相匹配，以最大限度地利用其性能，避免因存儲(chǔ)瓶頸造成的資源浪費(fèi)。
2. 應(yīng)支持大規(guī)模結(jié)構(gòu)化和非結(jié)構(gòu)化訓(xùn)練數(shù)據(jù)集的存儲(chǔ)，并在分布式處理環(huán)境中具備可擴(kuò)展性。
3. 模型checkpoint的存儲(chǔ)和檢索在 LLM 訓(xùn)練中也帶來了挑戰(zhàn)，需要系統(tǒng)滿足模型大小和訓(xùn)練時(shí)長(zhǎng)所決定的讀寫帶寬要求。
4. 滿足傳統(tǒng)企業(yè)級(jí)要求，例如數(shù)據(jù)保護(hù)、高可用性和安全性。

本文參考了論文 Llama3.1 405B Paper， Efficient Training of Large Language Models on Distributed Infrastructures: A Survey 以及公號(hào)之前的零一萬物《萬卡集群的AI Infra實(shí)踐分享》。兩篇paper已上傳到知識(shí)星球。

以Meta Llama 3 405B模型訓(xùn)練的基礎(chǔ)設(shè)施為例。該模型是在一個(gè)配備16,000個(gè)GPU的集群上進(jìn)行的訓(xùn)練。支撐這一訓(xùn)練的存儲(chǔ)系統(tǒng)由7500臺(tái)服務(wù)器組成，提供了高達(dá)240PB的SSD存儲(chǔ)容量。

在設(shè)計(jì)上，該存儲(chǔ)系統(tǒng)旨在支持持續(xù)讀寫帶寬達(dá)到2TB/s，并且在爆發(fā)式讀寫操作時(shí)，讀寫帶寬可以提升至7TB/s。這樣的設(shè)計(jì)充分考慮了Llama 3 405B模型訓(xùn)練過程中的數(shù)據(jù)讀寫需求。

此外，考慮到訓(xùn)練數(shù)據(jù)龐大且數(shù)量眾多，即使是文本格式，原始數(shù)據(jù)通常也是TB級(jí)別的，而語音和多模態(tài)數(shù)據(jù)則通常達(dá)到百TB的規(guī)模。因此，240PB的存儲(chǔ)規(guī)劃是合理的，可以滿足模型訓(xùn)練過程中的數(shù)據(jù)存儲(chǔ)需求。

文件系統(tǒng)的高速度可以支持每一步都可以記錄一個(gè)checkpoint，當(dāng)訓(xùn)練過程中出現(xiàn)問題時(shí)，可以迅速從上一個(gè)checkpoint恢復(fù)訓(xùn)練。這種設(shè)計(jì)大大縮短了容災(zāi)恢復(fù)的時(shí)間，提高了訓(xùn)練的效率。

Checkpoint

在LLM的訓(xùn)練過程中，checkpoint的數(shù)量和大小都是巨大的。模型參數(shù)量越大，所需寫入的數(shù)據(jù)量也越大，這要求存儲(chǔ)系統(tǒng)提供更大的寫入帶寬。例如，具有70B參數(shù)的LLM的checkpoint大小大約980GB。

在Llama3 的paper中，Meta表示采用分布式文件系統(tǒng)Tectonic使數(shù)千個(gè)GPU能夠同時(shí)保存和加載模型checkpoint，從而為廣泛的訓(xùn)練操作提供了高效且可擴(kuò)展的存儲(chǔ)解決方案。在字節(jié)的MegaScale系統(tǒng)，HDFS被用于集中式模型檢查點(diǎn)維護(hù)，確保在規(guī)模上的一致性和可靠性。為了緩解checkpoint恢復(fù)期間的帶寬瓶頸。

分布式對(duì)象存儲(chǔ)，如Ceph對(duì)象存儲(chǔ)，則提供了更易于擴(kuò)展的特性。這種優(yōu)勢(shì)源于其沒有層次化的目錄樹或命名空間，從而簡(jiǎn)化了一致性維護(hù)。正因如此，對(duì)象存儲(chǔ)已在模型checkpoint存儲(chǔ)中得到廣泛應(yīng)用。零一萬物的數(shù)據(jù)中心就采用了Ceph。

訓(xùn)練數(shù)據(jù)

LLM訓(xùn)練的原始數(shù)據(jù)集是巨大的。Llama 3在超過15萬億token上進(jìn)行了訓(xùn)練，而Llama 2的數(shù)據(jù)集只有1.8萬億token。每個(gè)token大約2字節(jié)，相當(dāng)于大約30TB的數(shù)據(jù)。準(zhǔn)備訓(xùn)練數(shù)據(jù)集涉及廣泛的預(yù)處理步驟，包括數(shù)據(jù)抓取和清理，需要大量的實(shí)驗(yàn)。通常，這些步驟處理的數(shù)據(jù)超過最終訓(xùn)練數(shù)據(jù)集大小的100倍 。例如，WanJuan-CC數(shù)據(jù)集有選擇性地提取了大約680億個(gè)文檔，生成了大約1萬億個(gè)高質(zhì)量標(biāo)記，相當(dāng)于在丟棄99%的原始數(shù)據(jù)后，數(shù)據(jù)大小為2TB。因此，LLM訓(xùn)練的總數(shù)據(jù)量預(yù)計(jì)將超過數(shù)十PB。

并行文件系統(tǒng)，如Lustre、GPFS和BeeGFS，經(jīng)常部署在領(lǐng)先的高性能計(jì)算系統(tǒng)上，以確保高效的I/O、持久存儲(chǔ)和可擴(kuò)展性能。這些系統(tǒng)也被廣泛用于訓(xùn)練集群的數(shù)據(jù)加載，為高效處理大規(guī)模訓(xùn)練數(shù)據(jù)提供了必要的基礎(chǔ)設(shè)施。此外，文件系統(tǒng)還必須使工程師能夠?qū)κ褂脭?shù)千個(gè)GPU的工作進(jìn)行交互式調(diào)試，因?yàn)榇a更改需要立即對(duì)所有節(jié)點(diǎn)可用 。

在大多數(shù)LLM的訓(xùn)練過程中，每個(gè)token通常只遇到一次。然而，采用數(shù)據(jù)緩存策略仍然至關(guān)重要，以緩解數(shù)據(jù)加載期間的I/O瓶頸。這種策略涉及從較慢的后端存儲(chǔ)預(yù)取訓(xùn)練數(shù)據(jù)到更快的緩存存儲(chǔ)。Alluxio和JuiceFS通過從HDFS或?qū)ο蟠鎯?chǔ)等底層存儲(chǔ)系統(tǒng)高效緩存訓(xùn)練數(shù)據(jù)，增強(qiáng)了LLM訓(xùn)練。Quiver支持跨多個(gè)作業(yè)和用戶透明地重用緩存數(shù)據(jù)。Fluid利用Alluxio進(jìn)行數(shù)據(jù)緩存，并引入了一種機(jī)制，可以根據(jù)I/O條件實(shí)現(xiàn)緩存的自適應(yīng)擴(kuò)展。

本文轉(zhuǎn)載自公眾號(hào)AI時(shí)代窗口 作者：郁愈

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