目錄

引言

第一章節(jié) LLM&AIGC時代的計算架構(gòu)特征??

第二章節(jié) AIGC時代的存儲主要挑戰(zhàn)?

第三章節(jié) LLM&AIGC時代的元數(shù)據(jù)挑戰(zhàn)??

第四章節(jié) LLM&AIGC時代的IO特征分析??

結(jié)論??

引言

在以前做傳統(tǒng)塊存儲的時代，我們針對很多的行業(yè)做了workload的調(diào)研，包含塊大小、隨機(jī)讀，讀寫比例等等，在傳統(tǒng)存儲場景，知道行業(yè)的workload對于預(yù)估業(yè)務(wù)的IOPS性能有很好地指導(dǎo)意義，其次，也可以制作針對行業(yè)的存儲配置最佳實(shí)踐。

很多年前獲取這些信息是一個比較難的過程，畢竟傳統(tǒng)的存儲設(shè)備是直接銷售到了客戶的現(xiàn)場，缺乏有效地權(quán)利來獲取運(yùn)行信息，一般都是在進(jìn)行性能調(diào)優(yōu)及其他配置升級的時候進(jìn)行獲取的，這些很大意義上對于很多客戶來說也算是機(jī)密數(shù)據(jù)。

針對AIGC的場景，我其實(shí)是比較好奇的，大模型的訓(xùn)練和推理對于存儲的訴求怎么樣？因?yàn)槲覀冊谔嗟腜PT里面聽到的描述是，大模型訓(xùn)練對于存儲有高性能的訴求，到底多高的性能、什么樣的特征，從來語焉不詳，今天我們解讀weka的一個報告，來看看他們所謂的AIGC領(lǐng)域的存儲IO特征。

第一章節(jié) LLM&AIGC時代的計算架構(gòu)特征??

存儲的變化都是基于計算和存儲介質(zhì)造就的。在最早的IBM大型機(jī)時代是提供大型機(jī)適配的大硬盤（那是IBM的專屬時代，雖然有少量的兼容機(jī)廠商也在做。

隨著介質(zhì)的變化，小型的硬盤和內(nèi)存技術(shù)興起，更多的是商務(wù)的大幅下降，催生了陣列存儲的產(chǎn)生，并且快速的替代了大硬盤。其后隨著關(guān)系型數(shù)據(jù)庫這個上一個時代最值錢的數(shù)據(jù)不斷的發(fā)展，產(chǎn)生了各種的高端存儲，架構(gòu)也隨著一些硬件技術(shù)的進(jìn)步做了很多的演進(jìn)，從scale-out到scale-out，但是依然是價格高企，單價居高不下。?? ?

高端存儲的PPT里面宣傳的主要方向是高性能、高可靠、高擴(kuò)展，各種名詞堆上去的企業(yè)級存儲平臺。心情好的話我們再加點(diǎn)對于業(yè)務(wù)的描述，比如說business-critical 、mission critical。為什么MKT要構(gòu)造這么多詞，很多做技術(shù)的同學(xué)也非常不喜歡，說是生造。其本質(zhì)就是要給自己的存儲高溢價找到合理的理由。

?在企業(yè)存儲的賽道之外，其實(shí)一直都有另一個賽道存在，那就是HPC存儲，但是這個存儲主要面對的是科研機(jī)構(gòu)（上個時代），有些科研機(jī)構(gòu)錢多點(diǎn)有的少點(diǎn)。因此這個市場的存儲廠商銷售量一直不是很大，在上個時代，這里的代表廠商是IBM、DDN等，dell和HPE和Netapp也有涉獵。?? ?

High performance computing (HPC) storage systems vendor market share worldwide in 2021

回到20年前，HPC系統(tǒng)已經(jīng)在處理幾個PB的數(shù)據(jù)了，而在這個時代，產(chǎn)生的大數(shù)據(jù)技術(shù)或多或少也從這里得到了靈感。從我個人的角度來看，google的三駕馬車就是一個HPC+DBMS的結(jié)合體，取了HPC架構(gòu)的精華，構(gòu)造了傻瓜式調(diào)用的并行處理框架mapreduce，然后講DBMS放棄了ACID的部分功能，構(gòu)造出了bigtable來適配互聯(lián)網(wǎng)的業(yè)務(wù)。前微軟亞洲研究院 (MSRA) 首席研究員張霖濤有個“三十年” 理論：要解決一個難題，就去讀三十年前的文章。

比如神經(jīng)網(wǎng)絡(luò)，最早就是上世紀(jì) 80 年代提出的，2010 年左右重新火了起來。近十年、二十年的創(chuàng)新作者還活躍在科研一線，如果他當(dāng)年的方法能解決現(xiàn)在的問題，他自己早就解決了。但三十年前的創(chuàng)新作者大多數(shù)都已經(jīng)不在一線了，這時候封存在故紙堆里的老方法可能就有用了。另外，在很多領(lǐng)域，系統(tǒng)架構(gòu)也是螺旋式發(fā)展的，例如瘦客戶端和胖客戶端、集中式和分布式、統(tǒng)一指令集和異構(gòu)計算等，當(dāng)前新的架構(gòu)在上一個歷史周期里可能都是玩剩的。?? ?????

當(dāng)年的存儲架構(gòu)設(shè)計都是基于這樣的想法，即為計算提供最快的存儲層是HDD（當(dāng)時還沒有SSD加入到存儲中，EMC主存儲加SSD也到了08年左右）。由于HDD的限制，作業(yè)通常大小為盡可能多地加載到內(nèi)存中，避免換出，并且需要檢查點(diǎn)（checkpoint）以確保如果在加載或?qū)⒆鳂I(yè)寫入HDD會發(fā)生什么樣的問題，你不可能因?yàn)橐粋€中間錯誤就去重新加載數(shù)據(jù)并重新開始任務(wù)，畢竟計算的時長太長了。

但是眾所周知，HDD是數(shù)據(jù)中心中最慢的部件，或者說存儲是數(shù)據(jù)中心中最慢的部件。后來出現(xiàn)了SSD，但是性能和成本是永恒的矛盾，分層存儲就出現(xiàn)了。

?首先，從傳感器或者其他領(lǐng)域獲取到數(shù)據(jù)，存儲到一個高性能的存儲設(shè)備（歷史上分層存儲居多）。這個存儲設(shè)備首先必須是一個共享存儲，畢竟HPC是一個多個計算節(jié)點(diǎn)并行執(zhí)行的任務(wù)，因此一般都是文件存儲或者對象存儲（歷史上都是文件存儲，對象存儲是這幾年云時代的到來，很多數(shù)據(jù)上云的第一站需要跨越互聯(lián)網(wǎng)到來，因此以對象存儲來承載）。?? ?

其次，數(shù)據(jù)經(jīng)過預(yù)處理之后加載到計算節(jié)點(diǎn)的本地NVMe SSD或者cache中，上面這個圖畫的不一定精準(zhǔn)，其實(shí)很多時候預(yù)處理之后寫入到了并行文件系統(tǒng)中，比如說典型的HPC高性能存儲并行文件系統(tǒng)（GPFS、BeeGFS、Lustre）。

最后，將數(shù)據(jù)進(jìn)行相關(guān)的備份或者隨著生命周期轉(zhuǎn)冷。

在AI的領(lǐng)域，他非常類似于HPC，或者說AI的訓(xùn)練其實(shí)是另一個基于GPU的HPC而已。他的數(shù)據(jù)流典型處理如下。這里面會有幾個批次的copy工作。從原始數(shù)據(jù)預(yù)處理到并行文件系統(tǒng)，從并行文件系統(tǒng)系統(tǒng)到GPU本地的NVme SSD,從本地NVMe到顯存。這幾個過程不可避免，并且成為制約AI最大的性能瓶頸之一（另一個則是內(nèi)存墻）。NVIDIA GPUDirect Storage協(xié)議是一個可能的解題思路，可以跳過本地NVMe SSD，但是對于存儲系統(tǒng)本身的性能可能更是一個關(guān)鍵，畢竟通過網(wǎng)絡(luò)的時延可能高于本地NVMe SSD的訪問。

第二章節(jié) AIGC時代的存儲主要挑戰(zhàn)?

微軟的研究Analyzing and Mitigating Data Stalls in DNN Training中明顯的可以看到，dataset在SSD情況下是否緩存住對于每個epoch的時間沖擊并沒有想象的那么大，但是如果存儲性能太差，那么epoch的時間沖擊將極大。當(dāng)然這個是DNN場景，在LLM大模型的transformer模型是否也是類型并不清晰。理論上，如果網(wǎng)絡(luò)效果好，全閃存，理論上可以逼近本地盤的效率（假設(shè)dataset cache率沒有那么高）。?? ?

如果使用對象存儲配合本地盤來做訓(xùn)練，也有一組測試數(shù)據(jù)，除了第一個epoch性能較差，其他的根本底盤差異并不大。（這里其實(shí)有點(diǎn)偷換概念，本質(zhì)上后面的測試都是cache了）

不管其他論文怎么描述，其實(shí)本質(zhì)上，存儲性能做到足夠好，可以讓大模型訓(xùn)練對存儲不敏感，但是如果存儲性能不好，則可能帶來訓(xùn)練時長成倍的增長這個已經(jīng)是個共識。針對AI訓(xùn)練尤其是以大模型的訓(xùn)練，在存儲上省錢就是大量的浪費(fèi)GPU算力，在現(xiàn)在GPU算力緊張的時代，首先做到存儲用最高性能的是AI訓(xùn)練的基本原則。以前在HPC時代，由于存儲帶來的CPU閑置可能是在10-50%，在GPU時代，GPU時間閑置甚至可能達(dá)到80-90%，加入使用的性能較差的存儲。?? ?

如何完成AI數(shù)據(jù)鏈路的整合？

很多時候我們沿用了大數(shù)據(jù)提出的數(shù)據(jù)湖的概念，大數(shù)據(jù)領(lǐng)域的湖倉一體。在AI領(lǐng)域也是遵循這個概念，在數(shù)倉時代的相關(guān)數(shù)據(jù)流在AI時代其實(shí)一樣存在。

雖然當(dāng)前的基礎(chǔ)設(shè)施每年都在飛速的發(fā)生這變化，AI模型也是按天發(fā)生的變化，但是，整個數(shù)據(jù)流的架構(gòu)并沒有什么大的變化還是遵循這上面這個大概的流程。我們現(xiàn)在每天在討論這GPT-4以及各種大模型，其實(shí)大模型領(lǐng)域各個廠商的護(hù)城河并沒有想象的那么寬廣。

套用semianalysis的一個評論，“OpenAI is keeping the architecture of GPT-4 closed not because of some existential risk to humanity but because what they’ve built is replicable. In fact, we expect Google, Meta, Anthropic, Inflection, Character, Tencent, ByteDance, Baidu, and more to all have models as capable as GPT-4 if not more capable in the near term.”

OPENAI的領(lǐng)先優(yōu)勢并不是他們算法上的精妙，而是他們工程上的架構(gòu)設(shè)計以及先發(fā)優(yōu)勢，一旦其他廠商加入，可能很快都能追上，他還點(diǎn)名了Tencent, ByteDance, Baidu，竟然沒有點(diǎn)名阿里巴巴，看來整個世界都在看衰阿里嗎？

第三章節(jié) LLM&AIGC時代的元數(shù)據(jù)挑戰(zhàn)??

回到存儲角度，大規(guī)模的訓(xùn)練帶來的第一個挑戰(zhàn)是混合IO特征的需求，這個需求在前十年的集中存儲、虛擬化存儲、私有云存儲時代都被不斷地出現(xiàn)且完善。

其次是針對元數(shù)據(jù)的管理，這個才是這個時代的難題。以前大家用樹形的分布式文件系統(tǒng)，一般可以處理十億百億級的文件，之后在互聯(lián)網(wǎng)時代大家為了處理海量的文件，使用了對象存儲的KV架構(gòu)，不在追求文件樹形架構(gòu)因此也沒有目錄、文件夾這個概念。對象存儲我們可以看到大多數(shù)云廠商的承諾在幾千到上萬的qps，而對于帶寬云廠商則更加寬容。

而在AI處理場景下，不管是當(dāng)前的大語言模型、圖片類模型，訓(xùn)練的語料經(jīng)常是大量的小文件，小文件下的元數(shù)據(jù)處理經(jīng)常會被忽略，其實(shí)很多時候元數(shù)據(jù)的qps大于數(shù)據(jù)的qps。

在預(yù)處理期間，ingest數(shù)據(jù)被處理到到模型訓(xùn)練期望能夠使用的狀態(tài)。這可能涉及注釋/標(biāo)記、圖像縮放、對比度平滑、索引等。當(dāng)您有多個研究人員/科學(xué)家處理相同的數(shù)據(jù)時，每個人可能需要以不同的方式預(yù)處理數(shù)據(jù)，這取決于他們打算訓(xùn)練或重新調(diào)整模型的內(nèi)容。即使使用相同的數(shù)據(jù)集，每個研究人員執(zhí)行的預(yù)處理步驟之間也存在巨大差異。其結(jié)果是一個用于預(yù)處理的混合IO環(huán)境，最多可占用epoch訓(xùn)練時間的50%。（這是一個很可怕的結(jié)果）??

IO的影響是巨大的。當(dāng)訪問大量小文件（LOSF）時，您不僅會遇到IO Blender問題，而且現(xiàn)在還會有數(shù)百萬個文件操作，讀取和寫入，其中IO大小和操作各不相同。

以一個使用TensorFlow在ImageNet上進(jìn)行深度學(xué)習(xí)的客戶為例（訓(xùn)練數(shù)據(jù)庫包含1400萬張圖片）

階段1：預(yù)處理函數(shù)在讀取、修改和寫回數(shù)據(jù)時，會對與之關(guān)聯(lián)的小文件進(jìn)行大量寫入。當(dāng)這種預(yù)處理與系統(tǒng)中的所有其他IO混合在一起時，將再次遇到IO混合器問題，但有一點(diǎn)不同：可能會耗盡系統(tǒng)中的寫緩存，并陷入必須執(zhí)行額外IO來刷緩存到持久化層的惡性循環(huán)，從而導(dǎo)致系統(tǒng)速度降低，并延長完成這些元數(shù)據(jù)密集型流水線階段所需的時間。

階段2：對元數(shù)據(jù)產(chǎn)生巨大影響的第二個階段是深度學(xué)習(xí)訓(xùn)練階段。這往往是較少的寫密集型，但有很多隨機(jī)讀取小文件。數(shù)據(jù)處理通常遵循以下一些變化：

l整個數(shù)據(jù)集的隨機(jī)子集上的mini-batch和重復(fù)

l對每個mini-batch進(jìn)行訓(xùn)練

l整個數(shù)據(jù)集的完整歷元處理，通常以隨機(jī)順序進(jìn)行（就是一個典型shuffle）?? ?

l設(shè)置某種形式的超參數(shù)來控制過程（例如，所需的精度，epochs的數(shù)量等）

在這個過程會導(dǎo)致大量文件打開、文件統(tǒng)計信息以及更多不顯示為傳統(tǒng)IO的信息。在下面的圖表中，您可以看到WEKA客戶在ImageNet上使用TensorFlow進(jìn)行訓(xùn)練的示例，訓(xùn)練數(shù)據(jù)庫包含1400萬張圖像。在此訓(xùn)練期間，30%的讀取是文件打開（open）。這種開銷表示深度學(xué)習(xí)訓(xùn)練和ResNet-50類型的遷移學(xué)習(xí)負(fù)載，讀取比例一般在25-75%之間，具體取決于部署的訓(xùn)練類型和文件大小。這種“隱藏IO”會在數(shù)據(jù)平臺上產(chǎn)生開銷，隨著工作負(fù)載的增加，開銷會變得更大。設(shè)想一個1000萬次讀取的IOP環(huán)境，在此基礎(chǔ)上您需要額外處理500萬次元數(shù)據(jù)IOP。（這個就是典型的元數(shù)據(jù)隱藏IO）

事實(shí)上我在其他的AI場景觀測到甚至元數(shù)據(jù)IO比例超過實(shí)際數(shù)據(jù)IO比例的情況。（如果使用對象存儲做訓(xùn)練的數(shù)據(jù)源，這個將是最大挑戰(zhàn)）

文件的大小也很重要。在同一個TensorFlow管道中，WEKA發(fā)現(xiàn)數(shù)據(jù)大小要么非常?。ㄐ∮?00字節(jié)），要么是10 KB-1 MB的中等大小。由于文件大小的差異，數(shù)據(jù)平臺需要能夠同時處理非常小的隨機(jī)IO和順序IO，以加快訓(xùn)練的epoch時間。其實(shí)當(dāng)前看到大多數(shù)大模型訓(xùn)練都是小IO為主。?? ?

第四章節(jié) LLM&AIGC時代的IO特征分析??

說明：WEKA正在幫助許多世界領(lǐng)先的GenAI公司加速其GenAI工作負(fù)載，這些用例在多個行業(yè)和AI/GenAI類型中各不相同。顯示的數(shù)據(jù)和圖表直接來自WEKA Home遙測。WEKA Home是一個基于云的電話總部支持和分析工具，客戶可以在其中管理他們的WEKA環(huán)境。

首先看一個自然語言處理（NLP）例子。這家GenAI客戶正在構(gòu)建人工智能模型，以支持語音轉(zhuǎn)文本（voice-to-text）和語音轉(zhuǎn)操作（voice-to-action）功能。?? ?

在此環(huán)境中，我們看到這是一個完全混合的混合IO管道，由相對一致的讀取數(shù)量和寫入時的IO峰值組成（讀寫是同時發(fā)生的）。這些信息可以映射到后端服務(wù)器的負(fù)載情況。

深紫色和淺紫色表示最大利用率和平均利用率。這顯示了該客戶的AI管道的強(qiáng)烈突發(fā)性。如果我們只看平均值，我們會認(rèn)為系統(tǒng)未充分利用率約為5%。實(shí)際情況是，它每隔幾分鐘就會出現(xiàn)劇烈的波動，導(dǎo)致其利用率經(jīng)常達(dá)到80-100%。（這在自動駕駛和AI場景非常的常見，對于共享的云存儲集群來說，如何來處理這種場景的性能突發(fā)以及資源爭用，并且最大化的利用資源是個比較復(fù)雜的問題。集群的qos管理是云存儲廠商需要不斷下功夫的地方）?? ?

對于這個NLP業(yè)務(wù)來說，讀/寫比例是47/53，但值得注意的是IO大?。鹤xIO大（300-500K)，寫IO小(100-200K)。在本例中，客戶獲取了通常小于100 k的小樣本，將它們append到一個較大的文件中，并對該文件進(jìn)行閱讀，就好像它是一個流一樣。但為什么寫的都是小IO呢？這不僅是GenAI和AI工作負(fù)載的共同主題，也是許多HPC工作負(fù)載的共同主題：Checkpoint。

Checkpointing?

當(dāng)運(yùn)行長時間的培訓(xùn)或操作作業(yè)時，檢查點(diǎn)是確保在發(fā)生故障時有一個“checkpoint”的方法。故障可能是任何硬件，其中運(yùn)行作業(yè)的服務(wù)器出現(xiàn)硬件故障，也可能是GenAI工作流中的錯誤，其中功能嵌入到層中但未完成。檢查點(diǎn)允許您恢復(fù)作業(yè)的狀態(tài)，但也可以用于停止模型訓(xùn)練，評估，然后重新啟動，而無需從頭開始。檢查點(diǎn)涉及將作業(yè)或內(nèi)存狀態(tài)寫入存儲器。在內(nèi)存轉(zhuǎn)儲的情況下，這可以是大量的數(shù)據(jù)，或者在AI嵌入/訓(xùn)練檢查點(diǎn)的情況下，這可以是較小的增量步驟。在這兩種情況下，延遲都是一個重要的關(guān)鍵指標(biāo)，因?yàn)閷懖僮魉ㄙM(fèi)的時間越長，作業(yè)必須等待的時間就越長。???

接下來，讓我們看看AI/ML模型開發(fā)環(huán)境。在這個用例中，客戶正在構(gòu)建NLP和ML函數(shù)的組合，以實(shí)現(xiàn)text-text and text-action?功能。這種數(shù)據(jù)管道更加隔離，重疊較少，因?yàn)樗鼈冞€沒有滿負(fù)載運(yùn)行。我們在這里看到，混合IO，讀/寫比例大概為48%/52%。此外，讀取的IO大小往往大于寫入。

這里最重要的是所有預(yù)處理對IO模式的影響。由于獲取數(shù)據(jù)在構(gòu)建到H5文件之前進(jìn)行了大量的預(yù)處理以規(guī)范化數(shù)據(jù)，因此讀取的IO范圍要窄得多，并且更可預(yù)測。這是在做大量的前期預(yù)處理工作使訓(xùn)練IO更容易，或者做更少的工作并使訓(xùn)練IO變得更加可變和難以處理之間的權(quán)衡。

最后，如果我們看一個圖像識別訓(xùn)練的例子，其中已經(jīng)完成了自動圖像預(yù)處理，（注意這與之前描述的元數(shù)據(jù)例子不同;客戶沒有告訴我們這是TensorFlow還是PyTorch），我們看到客戶正在做一個經(jīng)典的隔離環(huán)境，只是為了在圖像訓(xùn)練中讀取。但在他們目前的運(yùn)營規(guī)模下，他們決定將訓(xùn)練與所有其他工作流程隔離開來，而不是每天將圖像批量傳輸?shù)酱鎯哼M(jìn)行訓(xùn)練。?? ?

正如預(yù)期的那樣，總體吞吐量由大小非常一致的讀取控制。然而，寫入差異很大。這些寫操作大多是對文件的元數(shù)據(jù)更新、進(jìn)程數(shù)據(jù)的回寫和checkpoint操作。正如我們之前所指出的，監(jiān)測的數(shù)據(jù)說明了實(shí)際的數(shù)據(jù)傳輸;雖然這些寫入的所有元數(shù)據(jù)操作都不會顯示為數(shù)據(jù)傳輸，但它們可能會對訓(xùn)練模型的性能產(chǎn)生重大影響。

結(jié)論??

1，AI訓(xùn)練過程中，隨著流程的復(fù)雜以及并行度的加劇，IO的特征是一個非?；祀s的場景，讀寫以及IO大小都是一個彈性多變的，并且出了數(shù)據(jù)IO還有大量的隱藏的元數(shù)據(jù)IO，很多時候會被忽略，但是它對于性能影響更大。AI過程對于IO最敏感的是時延而不是吞吐。低延遲是系統(tǒng)整體性能的主要指標(biāo)，因?yàn)樗鼤绊懨總€操作。整體延遲越低，AI流程就越快進(jìn)入模型工作流中的下一個迭代/epoch/retune/enrichment/embedding周期。

2，AI存儲的主要挑戰(zhàn)：

(1)如果期望通過RDMA技術(shù)加速傳統(tǒng)NFS等協(xié)議可能不一定是個好想法，還是要考慮另起爐灶，考慮新的實(shí)現(xiàn)方式。比如說自研客戶端，做并行文件存儲（pnfs也行），GDS適配等。

(2)低時延問題，文件存儲本質(zhì)上復(fù)雜度要高于塊存儲，所以在塊存儲場景的低時延在大規(guī)模小文件場景如何實(shí)現(xiàn)。

(3)混合IO,很多時候我們的存儲系統(tǒng)內(nèi)部的條帶深度、塊大小、緩存算法、qos策略等都是默認(rèn)設(shè)置好的，在AI時代如何精細(xì)化的適配?

(4)海量小文件的元數(shù)據(jù)效率，假設(shè)10億文件場景的海量小文件，如何保障批量元數(shù)據(jù)操作的效率以及數(shù)據(jù)隨機(jī)遍歷的性能？

AI時代的存儲是不是HPC存儲的升級和輪回？并行文件系統(tǒng)是不是一個好的答案？

?文章來源地址http://www.zghlxwxcb.cn/news/detail-789406.html

到了這里，關(guān)于AIGC內(nèi)容分享(六)：AIGC世界的IO特征研究的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！