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

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

• 介紹大模型全流程對存儲帶來的全新挑戰(zhàn)；

• 深入大模型全流程各個環(huán)節(jié)，看一看有哪些具體的存儲問題以及對應(yīng)的解決思路；

• 分享百度滄?！ご鎯Φ募铀俜桨讣皩嵺`經(jīng)驗。

一、模型對存儲的全新挑戰(zhàn)

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

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

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

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

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

• 第一是海量數(shù)據(jù)的存儲和處理，包括采集導(dǎo)入、清洗、轉(zhuǎn)換、標(biāo)注、共享和長期歸檔，是后面各環(huán)節(jié)的基礎(chǔ)。這里對存儲的要求跟以前的大數(shù)據(jù)應(yīng)用具有很大的共性，也帶有大模型自身的特點，總結(jié)起來主要是生態(tài)的互通、高吞吐和大容量。

• 第二是模型開發(fā)，講究效率為王，包括實驗管理、交互式開發(fā)和效果評估等。對存儲的要求更多集中在 POSIX 兼容性、可靠性和可共享等方面。

• 第三是模型訓(xùn)練。真正做過大模型訓(xùn)練的朋友一定深有體會，每分每秒都是經(jīng)費在燃燒。所以時間就是金錢，拒絕等待，拒絕失敗。這里的主要場景，一是訓(xùn)練數(shù)據(jù)的讀取，二是為了容錯做的 checkpoint 的保存和加載。數(shù)據(jù)集的部分就是要盡量讀得快，減少計算對 I/O 的等待，而 checkpoint 主要要求高吞吐、減少訓(xùn)練中斷的時間。

• 最后是模型推理，需要把訓(xùn)練完的模型快速分發(fā)部署到線上，產(chǎn)生業(yè)務(wù)效果。而這個過程會高頻、反復(fù)發(fā)生，既要求高并發(fā)、高吞吐，又要求整個流程盡量簡單高效。

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

進(jìn)一步，我們又把大模型的各個環(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)生一個正向反饋的閉環(huán)。

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

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

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

二、大模型全流程存儲問題的解決思路

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

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

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

1. 其一是擴(kuò)展能力。HDFS 采用集中式元數(shù)據(jù)管理，規(guī)模相對受限，而對象存儲通常采用分布式平坦元數(shù)據(jù)，具有更強(qiáng)的水平擴(kuò)展能力，單集群可支持萬億文件、EB 級規(guī)模。在我們對于實踐的觀察中，曾經(jīng)有業(yè)務(wù)基于 HDFS 做大模型訓(xùn)練，受限于擴(kuò)展能力，不得不將海量小文件進(jìn)行打包存儲，在訓(xùn)練時再下載解壓，實際上引入了非常多的流程開銷；

2. 其二是成本考量。HDFS 誕生于存算一體的時代，而對象存儲天然面向存算分離設(shè)計，結(jié)合 EC 編碼、分級存儲等豐富的能力，可以實現(xiàn)大規(guī)模數(shù)據(jù)長期保存的更優(yōu)成本。

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

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

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

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

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

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

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

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

• 優(yōu)化 shuffle 過程，盡量將耗時控制在較小比例；

• 優(yōu)化讀取過程，盡量讓每一輪讀取數(shù)據(jù)的耗時小于計算耗時，這樣就能讓 I/O 時間被計算時間完全隱藏掉；

• 優(yōu)化 checkpoint 過程，盡量縮短 checkpoint 耗時，減少訓(xùn)練中斷時間。

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

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

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

分析完典型的訓(xùn)練過程以后，我們再來看對象存儲面對小文件時有哪些影響性能的因素。

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

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

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

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

• 讓敵人變?nèi)?，也就是通過一些打包格式減少小文件元數(shù)據(jù)操作的占比。比如 TFRecord、HDF5 等格式已經(jīng)被大量應(yīng)用。如果存儲能配合這些格式做一些優(yōu)化，那么效率將得到進(jìn)一步提升；

• 讓自己變強(qiáng)。硬件上通過燃燒經(jīng)費購買高性能硬件不需要過多解釋。軟件上則一般通過架構(gòu)升級提升系統(tǒng)的擴(kuò)展能力，縮短 I/O 路徑，這里的典型方案就是并行文件系統(tǒng)；

• 盡可能近身攻擊。讓存儲和計算靠得更近，這里的典型方案就是緩存系統(tǒng)。利用數(shù)據(jù)集只讀的特點，將元數(shù)據(jù)和數(shù)據(jù)緩存到計算節(jié)點，或者靠近計算節(jié)點的地方，也能大幅提高數(shù)據(jù)的訪問效率。

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

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

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

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

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

• 同步速度快，各節(jié)點可以并發(fā)同步數(shù)據(jù)，大大加快數(shù)據(jù)流轉(zhuǎn)效率；

• 同步策略可定制，可以按照場景需求進(jìn)行增量同步、選擇性同步；

• 能夠與調(diào)度器集成，實現(xiàn)數(shù)據(jù)準(zhǔn)備與資源調(diào)度的高效配合；

• 避免了人工方式需要處理各類異常，做垃圾回收的問題。

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

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

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

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

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

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

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

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

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

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

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

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

如果基于數(shù)據(jù)湖存儲加速的方案，整個過程會變得非常簡單。

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

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

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

到這里為止，我們分析了模型訓(xùn)練、推理等環(huán)節(jié)的三個具體場景?？梢钥吹剑谝霐?shù)據(jù)湖存儲加速層以后，這些場景的具體問題都一一得到了解決。

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

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

3. 百度滄?！ご鎯铀俜桨负蛯嵺`

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

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

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

• 對象存儲 BOS 及周邊生態(tài)提供了云原生數(shù)據(jù)湖的完整方案，解決了海量數(shù)據(jù)的存儲和流動，以及大模型各環(huán)節(jié)間的銜接問題。

• RapidFS / PFS 提供了數(shù)據(jù)湖存儲加速的能力，滿足了大模型各環(huán)節(jié)內(nèi)的存儲性能需求。

• 同時 RapidFS / PFS 通過與 AI 框架和訓(xùn)練平臺的配合完成資源調(diào)度優(yōu)化，整體效率做到最優(yōu)。

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

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

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

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

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

第二個場景是 checkpoint 寫加速?；诒镜乇P的方案耗時 245s，上傳 BOS 的耗時 355s。因此如果同步寫完 BOS，整體耗時為兩者相加，接近 10 分鐘。而使用 RapidFS 方案，整體耗時大幅縮短到 2 分鐘，加速效果明顯。

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

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

「加速」從來不止于單純的性能提速，流程的高效和環(huán)節(jié)的順暢也同樣重要。希望百度滄?！ご鎯铀俚恼w方案能夠幫助大家掃清障礙，加快實現(xiàn)大模型帶來的時代紅利和業(yè)務(wù)價值。

—— END ——

推薦閱讀：

百度APP iOS端包體積50M優(yōu)化實踐(五) HEIC圖片和無用類優(yōu)化實踐

百度知道上云與架構(gòu)演進(jìn)

百度APP iOS端包體積50M優(yōu)化實踐(四)代碼優(yōu)化

百度App啟動性能優(yōu)化實踐篇

掃光動效在移動端應(yīng)用實踐

Android SDK安全加固問題與分析文章來源地址http://www.zghlxwxcb.cn/news/detail-632529.html

到了這里，關(guān)于面向大模型的存儲加速方案設(shè)計和實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！