這是 AI 大底座系列云智公開課的第三期內(nèi)容。前兩期我的兩位同事已經(jīng)向大家介紹了高性能網(wǎng)絡(luò)和 GPU 容器虛擬化的相關(guān)內(nèi)容。今天我們把目光聚焦在存儲(chǔ)方向，一起來看看面向大模型的存儲(chǔ)加速方案的設(shè)計(jì)和實(shí)踐。

今天將從以下三個(gè)方面來展開這次分享：

• 介紹大模型全流程對(duì)存儲(chǔ)帶來的全新挑戰(zhàn)；
• 深入大模型全流程各個(gè)環(huán)節(jié)，看一看有哪些具體的存儲(chǔ)問題以及對(duì)應(yīng)的解決思路；
• 分享百度滄海·存儲(chǔ)的加速方案及實(shí)踐經(jīng)驗(yàn)。

1. 大模型對(duì)存儲(chǔ)的全新挑戰(zhàn)

從過去的經(jīng)典 AI，到今天人人談?wù)摰拇竽Ｐ停覀兛吹?AI 模型的參數(shù)規(guī)模呈現(xiàn)出指數(shù)級(jí)的爆發(fā)增長。一方面，大模型的應(yīng)用效果開始給大家?guī)矸浅４蟮捏@喜，另一方面，也給整個(gè)基礎(chǔ)設(shè)施帶來巨大的挑戰(zhàn)。

其一，模型規(guī)模大，訓(xùn)練時(shí)間長。一個(gè) 175B 參數(shù)的模型，萬卡同時(shí)訓(xùn)練仍然需要長達(dá) 22 天。這就要求基礎(chǔ)設(shè)施提供超高的性能和超長時(shí)間的穩(wěn)定。

其二，大模型要結(jié)合具體應(yīng)用才能發(fā)揮巨大的威力。大家今天談?wù)摯竽Ｐ停辉僦煌Ａ粼谀Ｐ捅旧恚嗟年P(guān)注已經(jīng)聚焦于結(jié)合業(yè)務(wù)的應(yīng)用落地。面對(duì)互聯(lián)網(wǎng)級(jí)的應(yīng)用迭代，要求我們具備大規(guī)模的敏捷部署能力。

第三，大模型離不開持續(xù)更新的海量數(shù)據(jù)，這就需要與整個(gè)數(shù)據(jù)生態(tài)互通，讓數(shù)據(jù)能在各個(gè)環(huán)節(jié)便捷地流動(dòng)。

圖片

在這樣的背景下，我們來對(duì)大模型全流程做一個(gè)拆分，大致可以劃分為四個(gè)主要的環(huán)節(jié)。

• 第一是海量數(shù)據(jù)的存儲(chǔ)和處理，包括采集導(dǎo)入、清洗、轉(zhuǎn)換、標(biāo)注、共享和長期歸檔，是后面各環(huán)節(jié)的基礎(chǔ)。這里對(duì)存儲(chǔ)的要求跟以前的大數(shù)據(jù)應(yīng)用具有很大的共性，也帶有大模型自身的特點(diǎn)，總結(jié)起來主要是生態(tài)的互通、高吞吐和大容量。
• 第二是模型開發(fā)，講究效率為王，包括實(shí)驗(yàn)管理、交互式開發(fā)和效果評(píng)估等。對(duì)存儲(chǔ)的要求更多集中在 POSIX 兼容性、可靠性和可共享等方面。
• 第三是模型訓(xùn)練。真正做過大模型訓(xùn)練的朋友一定深有體會(huì)，每分每秒都是經(jīng)費(fèi)在燃燒。所以時(shí)間就是金錢，拒絕等待，拒絕失敗。這里的主要場(chǎng)景，一是訓(xùn)練數(shù)據(jù)的讀取，二是為了容錯(cuò)做的 checkpoint 的保存和加載。數(shù)據(jù)集的部分就是要盡量讀得快，減少計(jì)算對(duì) I/O 的等待，而 checkpoint 主要要求高吞吐、減少訓(xùn)練中斷的時(shí)間。
• 最后是模型推理，需要把訓(xùn)練完的模型快速分發(fā)部署到線上，產(chǎn)生業(yè)務(wù)效果。而這個(gè)過程會(huì)高頻、反復(fù)發(fā)生，既要求高并發(fā)、高吞吐，又要求整個(gè)流程盡量簡(jiǎn)單高效。

從這四個(gè)環(huán)節(jié)的分析，我們總結(jié)出大模型對(duì)存儲(chǔ)的第一個(gè)挑戰(zhàn)：不同環(huán)節(jié)對(duì)存儲(chǔ)提出了復(fù)雜多樣的需求。

圖片

進(jìn)一步，我們又把大模型的各個(gè)環(huán)節(jié)按照業(yè)務(wù)流程串聯(lián)起來。整體上可分為大模型應(yīng)用、數(shù)據(jù)系統(tǒng)和 AI 系統(tǒng)三大部分。

其中數(shù)據(jù)系統(tǒng)的部分在過去的大數(shù)據(jù)應(yīng)用中大家都比較熟悉了，最終是讓數(shù)據(jù)與應(yīng)用產(chǎn)生一個(gè)正向反饋的閉環(huán)。

而加入 AI 系統(tǒng)以后，面臨著更多環(huán)節(jié)的數(shù)據(jù)流動(dòng)。首先經(jīng)過預(yù)處理的數(shù)據(jù)由數(shù)據(jù)系統(tǒng)流入 AI 系統(tǒng)被加載訓(xùn)練，訓(xùn)練結(jié)果進(jìn)入模型倉庫，再由模型倉庫部署到線上提供推理服務(wù)，而推理效果的相關(guān)數(shù)據(jù)又會(huì)回到數(shù)據(jù)系統(tǒng)，用于下一步的評(píng)估和后續(xù)迭代。

因此可以看到，大模型應(yīng)用、數(shù)據(jù)系統(tǒng)、AI 系統(tǒng)三大部分實(shí)際上構(gòu)成了一個(gè)更大的閉環(huán)。其中各環(huán)節(jié)間的銜接，本質(zhì)上都是對(duì)數(shù)據(jù)廣泛、高效流動(dòng)的需求。這是大模型對(duì)于存儲(chǔ)的第二個(gè)挑戰(zhàn)。

接下來，我們就帶著這兩個(gè)挑戰(zhàn)，一起來看大模型各環(huán)節(jié)具體存儲(chǔ)問題的解決思路。

圖片

2. 大模型全流程存儲(chǔ)問題的解決思路

我們首先來關(guān)注第二個(gè)挑戰(zhàn)，解決海量數(shù)據(jù)的存儲(chǔ)和流動(dòng)問題，這是解決其它問題的基礎(chǔ)。

當(dāng)我們把數(shù)據(jù)系統(tǒng)中，數(shù)據(jù)流入、處理和流出的具體手段稍作展開，就會(huì)發(fā)現(xiàn)大模型依賴的數(shù)據(jù)需要與如此廣泛的生態(tài)頻繁交互，基于原來的本地存儲(chǔ)或者自建的小規(guī)模商用存儲(chǔ)已經(jīng)無法充分利用這些生態(tài)的優(yōu)勢(shì)。因此數(shù)據(jù)湖存儲(chǔ)已經(jīng)成為這里事實(shí)上的首選方案。

圖片

而數(shù)據(jù)湖存儲(chǔ)其實(shí)有兩個(gè)主要的選擇。一是以 HDFS 為代表的分布式文件系統(tǒng)，另一個(gè)是對(duì)象存儲(chǔ)。從兩類系統(tǒng)的架構(gòu)來對(duì)比，可以觀察到兩點(diǎn)：

1. 其一是擴(kuò)展能力。HDFS 采用集中式元數(shù)據(jù)管理，規(guī)模相對(duì)受限，而對(duì)象存儲(chǔ)通常采用分布式平坦元數(shù)據(jù)，具有更強(qiáng)的水平擴(kuò)展能力，單集群可支持萬億文件、EB 級(jí)規(guī)模。在我們對(duì)于實(shí)踐的觀察中，曾經(jīng)有業(yè)務(wù)基于 HDFS 做大模型訓(xùn)練，受限于擴(kuò)展能力，不得不將海量小文件進(jìn)行打包存儲(chǔ)，在訓(xùn)練時(shí)再下載解壓，實(shí)際上引入了非常多的流程開銷；
2. 其二是成本考量。HDFS 誕生于存算一體的時(shí)代，而對(duì)象存儲(chǔ)天然面向存算分離設(shè)計(jì)，結(jié)合 EC 編碼、分級(jí)存儲(chǔ)等豐富的能力，可以實(shí)現(xiàn)大規(guī)模數(shù)據(jù)長期保存的更優(yōu)成本。

圖片

另外，從可用性、吞吐、生態(tài)支持等方面來對(duì)比，對(duì)象存儲(chǔ)也具有一定的優(yōu)勢(shì)。所以雖然 HDFS 起步較早，但綜合來看對(duì)象存儲(chǔ)才是數(shù)據(jù)湖存儲(chǔ)的更優(yōu)選擇。

圖片

尤其是在今天這個(gè)云原生的時(shí)代，基于對(duì)象存儲(chǔ)的數(shù)據(jù)湖更是成為了云上的數(shù)據(jù)中樞。

圖片

帶著這個(gè)結(jié)論回到我們開始的問題，可以看到利用基于對(duì)象存儲(chǔ)的云原生數(shù)據(jù)湖就能很好地解決數(shù)據(jù)系統(tǒng)內(nèi)各環(huán)節(jié)的銜接。但是 AI 系統(tǒng)各環(huán)節(jié)的數(shù)據(jù)流動(dòng)和銜接問題，能否也用同一套存儲(chǔ)來解決呢？

圖片

假如答案是肯定的，那么我們就能得到一個(gè)非常統(tǒng)一和簡(jiǎn)潔的存儲(chǔ)架構(gòu)。最下面是數(shù)據(jù)湖，上面承接從數(shù)據(jù)系統(tǒng)到 AI 系統(tǒng)所有環(huán)節(jié)的需求，數(shù)據(jù)流動(dòng)會(huì)被大大簡(jiǎn)化，各環(huán)節(jié)的銜接運(yùn)轉(zhuǎn)效率也會(huì)得到很大的提升。

而這里的關(guān)鍵就是要接著回答我們最開始提出的第一個(gè)挑戰(zhàn)，如何用對(duì)象存儲(chǔ)滿足大模型開發(fā)、訓(xùn)練、推理等各環(huán)節(jié)的多樣化需求。

圖片

首先我們以大家比較關(guān)心的模型訓(xùn)練環(huán)節(jié)為例做一個(gè)分析。

對(duì)于一個(gè)典型的訓(xùn)練來說，可能迭代多輪 epoch。在每個(gè) epoch 內(nèi)，首先需要對(duì)數(shù)據(jù)集進(jìn)行隨機(jī)打散，然后將打散后的數(shù)據(jù)劃分為若干 batch，每讀取一個(gè) batch 的數(shù)據(jù)，進(jìn)行一次訓(xùn)練迭代。同時(shí)會(huì)周期性保存 checkpoint 用于故障快速恢復(fù)。

圖片

如果我們把訓(xùn)練過程進(jìn)一步展開，可以觀察到這樣的時(shí)序關(guān)系。每一輪 epoch 的耗時(shí)都是由數(shù)據(jù) shuffle、數(shù)據(jù)讀取等待、checkpoint 和真正的訓(xùn)練時(shí)間相加得到。因此為了盡量提高訓(xùn)練效率，減少 GPU 的空閑，我們的主要優(yōu)化就集中在三個(gè)思路：

• 優(yōu)化 shuffle 過程，盡量將耗時(shí)控制在較小比例；
• 優(yōu)化讀取過程，盡量讓每一輪讀取數(shù)據(jù)的耗時(shí)小于計(jì)算耗時(shí)，這樣就能讓 I/O 時(shí)間被計(jì)算時(shí)間完全隱藏掉；
• 優(yōu)化 checkpoint 過程，盡量縮短 checkpoint 耗時(shí)，減少訓(xùn)練中斷時(shí)間。

接下來我們先分析數(shù)據(jù)的 shuffle 和讀取，checkpoint 過程隨后再討論。

圖片

如果我們對(duì) shuffle 和讀操作進(jìn)行具體的分析，就會(huì)發(fā)現(xiàn)，shuffle 是一個(gè)純?cè)獢?shù)據(jù)操作的過程，主要依賴大量文件的 LIST，讀取過程則元數(shù)據(jù)和數(shù)據(jù)操作都有。

而對(duì)于大模型訓(xùn)練用到的 KB 級(jí)小文件而言，文件越小，元數(shù)據(jù)操作的耗時(shí)占比也就越高；I/O 越小，延時(shí)和 QPS 越超過吞吐成為主要矛盾。因此，對(duì)于小文件的 shuffle 和讀取，延時(shí)和 QPS 是提升性能的關(guān)鍵。

圖片

分析完典型的訓(xùn)練過程以后，我們?cè)賮砜磳?duì)象存儲(chǔ)面對(duì)小文件時(shí)有哪些影響性能的因素。

其一，元數(shù)據(jù)方面，對(duì)象存儲(chǔ)采用分布式 KV 或 NewSQL 維護(hù)平坦目錄元數(shù)據(jù)，很好地解決了小文件的規(guī)模擴(kuò)展問題。雖然大部分操作性能很好，但恰恰 shuffle 用到的 LIST 操作性能在部分場(chǎng)景下不夠理想，延時(shí)偏高；

其二，對(duì)象存儲(chǔ)協(xié)議的整個(gè)處理路徑較長，對(duì)于大文件吞吐為主的場(chǎng)景可以忽略，但對(duì)于小文件的頻繁讀取則會(huì)帶來不可忽視的延時(shí)開銷。

圖片

不難發(fā)現(xiàn)，對(duì)象存儲(chǔ)的高吞吐能力給小文件讀取帶來的幫助比較有限，而在延時(shí)上也并不具有優(yōu)勢(shì)。面對(duì)這樣的問題，我們有哪些解決思路呢？

我們分為幾個(gè)方向來總結(jié)：

• 讓敵人變?nèi)酰簿褪峭ㄟ^一些打包格式減少小文件元數(shù)據(jù)操作的占比。比如 TFRecord、HDF5 等格式已經(jīng)被大量應(yīng)用。如果存儲(chǔ)能配合這些格式做一些優(yōu)化，那么效率將得到進(jìn)一步提升；
• 讓自己變強(qiáng)。硬件上通過燃燒經(jīng)費(fèi)購買高性能硬件不需要過多解釋。軟件上則一般通過架構(gòu)升級(jí)提升系統(tǒng)的擴(kuò)展能力，縮短 I/O 路徑，這里的典型方案就是并行文件系統(tǒng)；
• 盡可能近身攻擊。讓存儲(chǔ)和計(jì)算靠得更近，這里的典型方案就是緩存系統(tǒng)。利用數(shù)據(jù)集只讀的特點(diǎn)，將元數(shù)據(jù)和數(shù)據(jù)緩存到計(jì)算節(jié)點(diǎn)，或者靠近計(jì)算節(jié)點(diǎn)的地方，也能大幅提高數(shù)據(jù)的訪問效率。

從整體來看，前面我們已經(jīng)基于對(duì)象存儲(chǔ)的云原生數(shù)據(jù)湖解決了海量數(shù)據(jù)的存儲(chǔ)和流動(dòng)問題。這里我們可以進(jìn)一步基于并行文件系統(tǒng)或緩存系統(tǒng)的數(shù)據(jù)存儲(chǔ)加速層來彌補(bǔ)對(duì)象存儲(chǔ)的短板，滿足大模型各環(huán)節(jié)的性能需求。

圖片

有了這一套「數(shù)據(jù)湖 + 加速層」的思路，我們就來詳細(xì)看看大模型的訓(xùn)練、推理幾個(gè)具體場(chǎng)景下的問題如何被一一解決。

第一個(gè)場(chǎng)景，先來看數(shù)據(jù)集的讀取加速。

假如數(shù)據(jù)已經(jīng)進(jìn)入加速層，那么讀性能的問題就能得到很好的解決。剩下需要解決的是數(shù)據(jù)怎么進(jìn)入加速層的問題。

在過去我們大量依賴人工和外圍工具做不同存儲(chǔ)之間的數(shù)據(jù)流轉(zhuǎn)，帶來不少弊端。今天的加速層設(shè)計(jì)，通常會(huì)選擇內(nèi)置自動(dòng)的數(shù)據(jù)流轉(zhuǎn)功能。比如在加速層通過 bucket link 建立對(duì)象存儲(chǔ)某一個(gè) bucket 到加速層的關(guān)聯(lián)，就能自動(dòng)完成數(shù)據(jù)在兩層之間的流動(dòng)。這種方式有諸多優(yōu)點(diǎn)：

• 同步速度快，各節(jié)點(diǎn)可以并發(fā)同步數(shù)據(jù)，大大加快數(shù)據(jù)流轉(zhuǎn)效率；
• 同步策略可定制，可以按照?qǐng)鼍靶枨筮M(jìn)行增量同步、選擇性同步；
• 能夠與調(diào)度器集成，實(shí)現(xiàn)數(shù)據(jù)準(zhǔn)備與資源調(diào)度的高效配合；
• 避免了人工方式需要處理各類異常，做垃圾回收的問題。

圖片

這里就是一個(gè)基于自動(dòng)數(shù)據(jù)流轉(zhuǎn)實(shí)現(xiàn)調(diào)度優(yōu)化，減少訓(xùn)練過程數(shù)據(jù)讀取等待的例子。當(dāng)兩個(gè)任務(wù)都需要先加載數(shù)據(jù)然后才能開始訓(xùn)練，通過訓(xùn)練平臺(tái)的流水線化調(diào)度，在一個(gè)任務(wù)做訓(xùn)練的同時(shí)發(fā)起下一個(gè)任務(wù)所需數(shù)據(jù)的提前加載，就能大大提高計(jì)算資源的利用率。

圖片

第二個(gè)場(chǎng)景，我們接著來看訓(xùn)練中的 checkpoint 部分。

與訓(xùn)練數(shù)據(jù)以小文件為主不同，大模型單個(gè)節(jié)點(diǎn)的 checkpoint 通常就能達(dá)到幾十上百 GB。而多個(gè)訓(xùn)練節(jié)點(diǎn)同時(shí)寫，需要恢復(fù)時(shí)又同時(shí)讀，對(duì)存儲(chǔ)提出了很高的吞吐要求。同時(shí)一個(gè)關(guān)鍵的問題是 checkpoint 期間整個(gè)訓(xùn)練是中斷的。因此通過提高吞吐，將 checkpoint 耗時(shí)控制在盡量小的占比，對(duì)于減少訓(xùn)練等待、提高計(jì)算資源利用率同樣非常重要。

在之前有一種樸素的做法。訓(xùn)練程序先將 checkpoint 寫到性能相對(duì)容易保證的本地存儲(chǔ)，然后再通過外圍工具向遠(yuǎn)端對(duì)象存儲(chǔ)上傳。這里需要考慮一個(gè)問題，如果要保證每個(gè) checkpoint 都成功寫入，那么總耗時(shí)就等于寫本地耗時(shí)加上傳對(duì)象存儲(chǔ)的耗時(shí)，總體等待時(shí)間較長。因此實(shí)際應(yīng)用中也有延遲一個(gè) checkpoint 異步上傳的方案。但無論如何，都引入了額外的復(fù)雜度，需要外圍工具來處理各種異常情況。

圖片

現(xiàn)在基于數(shù)據(jù)湖存儲(chǔ)加速以后，我們可以有新的做法。訓(xùn)練程序直接將 checkpoint 寫入加速層的 Memory 或 NVME SSD，加速層采用流式上傳的方式，不必等待 checkpoint 數(shù)據(jù)全部寫完就開始向?qū)ο蟠鎯?chǔ)上傳。此外，加速層也會(huì)采用分塊上傳的辦法，充分利用對(duì)象存儲(chǔ)的后端并發(fā)能力。

這個(gè)方案看上去比樸素方案有了很大的進(jìn)步，但是由于需要保證 close 完成時(shí)數(shù)據(jù)已經(jīng)完整寫入對(duì)象存儲(chǔ)，因此吞吐瓶頸仍然可能出現(xiàn)在上傳對(duì)象存儲(chǔ)的帶寬限制上。我們稱這種方案為同步方案。

圖片

其實(shí)對(duì) checkpoint 場(chǎng)景稍加分析就能發(fā)現(xiàn)，我們并不一定需要同步方案，因?yàn)橛?xùn)練過程的 checkpoint 會(huì)周期不斷地進(jìn)行，而發(fā)生故障恢復(fù)不應(yīng)該是常態(tài)。因此要突破上傳對(duì)象存儲(chǔ)的帶寬限制，異步寫是一種值得嘗試的思路。

這個(gè)方案最大的變化，就是對(duì) checkpoint 文件的 close 操作變成了異步，訓(xùn)練程序不用等待數(shù)據(jù)上傳完成，即可恢復(fù)訓(xùn)練，剩下的工作全部交給加速層透明完成。此時(shí)耗時(shí)主要取決于加速層的 Memory 和 NVME SSD 寫入能力，可以大大縮短 checkpoint 寫入時(shí)間。

另外，這里還有一個(gè)相關(guān)的優(yōu)化，就是對(duì)于最新的一個(gè) checkpoint 采用異步寫的同時(shí)，讓它駐留在加速層的緩存內(nèi)。當(dāng)訓(xùn)練需要恢復(fù)的時(shí)候就能直接從加速層讀取，解決了 checkpoint 的快速加載問題。

圖片

最后我們來看第三個(gè)場(chǎng)景，也就是推理階段的模型分發(fā)部署。大模型的部署通常是百 GB 模型文件的高并發(fā)重復(fù)讀取。由于推理服務(wù)規(guī)模大，模型迭代更新頻繁，我們需要從提高吞吐和縮短流程兩個(gè)方面考慮如何優(yōu)化。

首先來看過去常用的基于鏡像分發(fā)的方案。

訓(xùn)練產(chǎn)出的模型首先需要落到臨時(shí)存儲(chǔ)，完成鏡像的制作，包括數(shù)據(jù)打包、壓縮等過程，然后再從臨時(shí)存儲(chǔ)寫入持久化的鏡像倉庫。在推理部署時(shí)，再從鏡像倉庫并發(fā)拉取到各推理實(shí)例的本地存儲(chǔ)，然后進(jìn)行解壓和數(shù)據(jù)校驗(yàn)。可以看到在這個(gè)方案下，吞吐主要取決于鏡像倉庫底層存儲(chǔ)的能力，而流程上在鏡像制作和鏡像分發(fā)兩個(gè)階段都需要引入額外的開銷。

圖片

如果基于數(shù)據(jù)湖存儲(chǔ)加速的方案，整個(gè)過程會(huì)變得非常簡(jiǎn)單。

首先從流程上看，訓(xùn)練產(chǎn)出的模型直接寫入統(tǒng)一的數(shù)據(jù)湖存儲(chǔ)。這時(shí)可以通過對(duì)象存儲(chǔ)的事件通知機(jī)制，讓加速層立即感知并提前把模型文件的元數(shù)據(jù)和數(shù)據(jù)預(yù)加載到靠近推理服務(wù)的緩存內(nèi)。當(dāng)啟動(dòng)模型部署時(shí)，就能直接從緩存讀取到數(shù)據(jù)。

其次從吞吐上看，基于 Memory 或 NVME SSD 提供靠近推理服務(wù)的分布式緩存，提供了很強(qiáng)的讀吞吐能力，并且多實(shí)例重復(fù)讀取同一份模型數(shù)據(jù)時(shí)不需要消耗大量的對(duì)象存儲(chǔ) I/O 和帶寬。

另外，加速層可以通過不同的策略滿足不同規(guī)模的分發(fā)加速需求。比如對(duì)于幾十實(shí)例以下的小規(guī)模部署，采用單副本即可將所有緩存盤的 I/O 能力均衡地利用起來，滿足讀性能要求，同時(shí)還能大幅節(jié)省緩存空間，保證更多模型數(shù)據(jù)的緩存命中率。而對(duì)于數(shù)百實(shí)例的部署規(guī)模，采用多副本即可提高加速層的讀吞吐能力。到了數(shù)千實(shí)例的規(guī)模，還能進(jìn)一步結(jié)合客戶端的 P2P 加速滿足性能需求。

圖片

到這里為止，我們分析了模型訓(xùn)練、推理等環(huán)節(jié)的三個(gè)具體場(chǎng)景。可以看到，在引入數(shù)據(jù)湖存儲(chǔ)加速層以后，這些場(chǎng)景的具體問題都一一得到了解決。

因此，「數(shù)據(jù)湖 + 加速層」能夠同時(shí)解決最開始提出的兩個(gè)挑戰(zhàn)，為大模型全流程提供了統(tǒng)一的存儲(chǔ)解決方案。

同時(shí)也能看到，使用「數(shù)據(jù)湖 + 加速層」這套統(tǒng)一的存儲(chǔ)方案，既能獲得如同過去使用本地盤的便捷體驗(yàn)，又能充分享受背后數(shù)據(jù)湖存儲(chǔ)帶來的擴(kuò)展性、高性能和繁榮的生態(tài)。這正是一直以來大家對(duì)于存儲(chǔ)的一大夢(mèng)想。

圖片

3. 百度滄海·存儲(chǔ)加速方案和實(shí)踐

接下來我向大家介紹百度滄海·存儲(chǔ)加速的解決方案以及具體實(shí)踐。

這是百度滄海·存儲(chǔ)加速方案的產(chǎn)品架構(gòu)圖。底層是我們的對(duì)象存儲(chǔ) BOS，提供了大規(guī)模、可擴(kuò)展、低成本的云原生數(shù)據(jù)湖存儲(chǔ)產(chǎn)品，支持豐富的周邊生態(tài)和便捷的數(shù)據(jù)流動(dòng)。中間就是我們的數(shù)據(jù)湖存儲(chǔ)加速層，有兩類產(chǎn)品可供選擇。一是并行文件系統(tǒng) PFS，通過獨(dú)立部署、高性能硬件和網(wǎng)絡(luò)、全并行軟件架構(gòu)滿足極致性能需求。二是數(shù)據(jù)湖存儲(chǔ)加速 RapidFS，通過近計(jì)算部署提供更具性價(jià)比的分布式緩存加速能力。最上面是我們的 AI 計(jì)算，包括異構(gòu)算力、高速網(wǎng)絡(luò)、云原生 AI 平臺(tái)等。

在云原生時(shí)代，大模型全流程的存儲(chǔ)需求在百度滄海存儲(chǔ)得到了很好的答案：

• 對(duì)象存儲(chǔ) BOS 及周邊生態(tài)提供了云原生數(shù)據(jù)湖的完整方案，解決了海量數(shù)據(jù)的存儲(chǔ)和流動(dòng)，以及大模型各環(huán)節(jié)間的銜接問題。
• RapidFS / PFS 提供了數(shù)據(jù)湖存儲(chǔ)加速的能力，滿足了大模型各環(huán)節(jié)內(nèi)的存儲(chǔ)性能需求。
• 同時(shí) RapidFS / PFS 通過與 AI 框架和訓(xùn)練平臺(tái)的配合完成資源調(diào)度優(yōu)化，整體效率做到最優(yōu)。

這是 PFS 和 RapidFS 在云環(huán)境下的部署和應(yīng)用模式。

數(shù)據(jù)入湖后，無論選擇哪種存儲(chǔ)加速產(chǎn)品，使用模式都足夠簡(jiǎn)單。只需選擇好 BOS 中待加速的數(shù)據(jù)和加速策略，PFS 和 RapidFS 即可自動(dòng)完成數(shù)據(jù)集的加載和預(yù)熱，無需任何操心。當(dāng)訓(xùn)練任務(wù)完成后，PFS 和 RapidFS 透明地將訓(xùn)練結(jié)果同步回 BOS，并回收資源。

最后跟大家分享幾組我們具體實(shí)踐中的存儲(chǔ)加速效果。

首先是訓(xùn)練加速，可以看到使用 RapidFS 相對(duì)直接使用 BOS，整體訓(xùn)練耗時(shí)有數(shù)倍的縮短，與使用本地存儲(chǔ)的效果基本一致。

同時(shí)，RapidFS 和 PFS 兩個(gè)加速方案下，GPU 資源利用率相對(duì)直接使用 BOS 均有大幅提升。

圖片

第二個(gè)場(chǎng)景是 checkpoint 寫加速。基于本地盤的方案耗時(shí) 245s，上傳 BOS 的耗時(shí) 355s。因此如果同步寫完 BOS，整體耗時(shí)為兩者相加，接近 10 分鐘。而使用 RapidFS 方案，整體耗時(shí)大幅縮短到 2 分鐘，加速效果明顯。

圖片

最后是模型分發(fā)場(chǎng)景。橫軸是推理實(shí)例數(shù)量，縱軸是 RapidFS 的模型分發(fā)總吞吐。從這三條曲線的變化可以看出，RapidFS 用滿了緩存盤的所有能力，并且隨著緩存節(jié)點(diǎn)規(guī)模的增加可以實(shí)現(xiàn)接近線性的性能擴(kuò)展。

圖片

以上就是今天分享的全部?jī)?nèi)容。希望今天的分享能夠幫助大家更好地理解大模型背景下存儲(chǔ)面臨的挑戰(zhàn)和可能的解法。

「加速」從來不止于單純的性能提速，流程的高效和環(huán)節(jié)的順暢也同樣重要。希望百度滄海·存儲(chǔ)加速的整體方案能夠幫助大家掃清障礙，加快實(shí)現(xiàn)大模型帶來的時(shí)代紅利和業(yè)務(wù)價(jià)值。