演講嘉賓｜張文濤

編輯 ｜ Kitty

策劃 ｜QCon 全球軟件開發(fā)大會

在深度學習領域中，數(shù)據(jù)是基石，算力是引擎。訓練一個模型，需要大量的數(shù)據(jù)和算力 ，并且需要反復迭代和驗證才能得到想要的模型。 為了提升訓練效率，縮短訓練時間，所有組件之間都需要快速響應，這其中就包括了計算和存儲之間的交互。對于?個 AI 系統(tǒng)而言，模型的能力隨著模型尺寸和訓練數(shù)據(jù)的增加而顯著提升，但隨著數(shù)據(jù)集和模型規(guī)模不斷增加，訓練任務載?訓練數(shù)據(jù)所消耗的時間越來越長，進而影響了訓練效率，緩慢的 IO 嚴重拖累 GPU 的強大算力。

在 InfoQ 舉辦的QCon 全球軟件開發(fā)大會（北京站）上，焱融科技 CTO 張文濤分享了“高性能全閃并行文件系統(tǒng)的設計和實踐”，他介紹了焱融的全閃文件存儲的整體架構和技術細節(jié)，并分享了 YRCloudFile 是如何解決 AI 訓練過程中遇到的海量小文件訪問慢、 帶寬峰值、 內存訪問瓶頸和多任務并發(fā)訪問性能干擾等問題的。

內容亮點

• YRCloudFile 高性能文件系統(tǒng)的核心技術

• 在 AI 訓練場景中遇到的疑難問題和解決方案

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

大模型時代的存儲挑戰(zhàn)

今天我給大家?guī)淼姆窒碇黝}是高性能全閃存儲。剛才幾位老師在講解對象存儲時，大多是站在降低成本的視角來設計系統(tǒng)，然后再考慮性能優(yōu)化。而我們則是反其道而行之，先從性能角度出發(fā)，再設法降低成本。這兩種視角存在明顯差異，下面我將分享我們在這一領域所開展的工作以及設計理念。

大模型時代的存儲面臨著諸多挑戰(zhàn)。從下圖可以看出，黑色圖是去年 Meta 公布的數(shù)據(jù)，其中綠色線代表過去兩年其容量的增長情況，橙色線則表示性能的增長情況。在過去兩年里，盡管 Meta 的數(shù)據(jù)量基數(shù)已經很大，但其容量仍翻了一番。而橙色線所顯示的吞吐情況，相比之前已接近原來的四倍。白色圖展示的是我們一個大客戶的存儲情況，僅代表他在我們 YRCloudFile 中的存儲數(shù)據(jù)量。我們統(tǒng)計了他這四年里的數(shù)據(jù)增長情況，發(fā)現(xiàn)在 2020 年到 2022 年之間，每年數(shù)據(jù)量增長接近 20T。但從 2022 年年底開始，到 2024 年年底，其數(shù)據(jù)量增長愈發(fā)迅猛，基本以每年 60T 的速度增長。這一增長情況與大模型時代到來的時間點相契合，即 2022 年下半年，尤其是年底 ChatGPT 爆發(fā)時，國內的大模型廠商紛紛跟進，數(shù)據(jù)量也隨之飛速增長，這便是數(shù)據(jù)增長方面所面臨的挑戰(zhàn)。

在 AI 的全流程中，與存儲相關的環(huán)節(jié)主要有四個。首先是數(shù)據(jù)采集環(huán)節(jié)，主要是將各種原始數(shù)據(jù)收集過來，方式多種多樣，比如編寫腳本爬取數(shù)據(jù)、從公共數(shù)據(jù)網站下載數(shù)據(jù)、購買數(shù)據(jù)，或者收集本行業(yè)及企業(yè)內部的數(shù)據(jù)等。在這個過程中，需要運用各種協(xié)議來同時訪問數(shù)據(jù)。第二個環(huán)節(jié)是數(shù)據(jù)處理，主要是針對數(shù)據(jù)進行清洗、格式轉換以及集成，為后續(xù)的數(shù)據(jù)訓練做好前期準備。這個流程較長，涉及多個類型的存儲挑戰(zhàn)，包括多種協(xié)議訪問、數(shù)據(jù)快速檢索以及 I/O 大小和讀寫方式的混合等。雖然該環(huán)節(jié)對存儲的挑戰(zhàn)是全方位的，但由于它不影響 GPU 的利用率，所以往往容易被大家忽視。第三個環(huán)節(jié)是數(shù)據(jù)訓練，這在 AI 存儲中是大家較為關注的場景。AI 訓練場景對存儲的挑戰(zhàn)主要體現(xiàn)在高并發(fā)場景的性能上，它的 IO 類型其實很簡單，主要有幾種情況：第一種是啟動訓練時模型的加載，屬于大量并發(fā)的順序讀；第二種是讀取數(shù)據(jù)集，又分為兩類，若數(shù)據(jù)集較小，會將數(shù)據(jù)集預熱到內存中，同樣是順序大 I/O 讀，若數(shù)據(jù)集過大，內存無法緩存，則更多采用直接訪問存儲的方式，此時為大量隨機小 I/O 讀；此外，還有 Checkpoint 本身，屬于大并發(fā)的順序大 I/O 寫。對于多模態(tài)情況，會增加一些特殊的小文件，如圖文對、視頻文本對、語音文本對等，從而產生海量小文件問題；第四個環(huán)節(jié)是推理，其對存儲的需求也很簡單，類型較少，主要有兩種。第一種是模型分發(fā)，第二種是最近很火的 KVCache，二者都屬于吞吐型，而 KVCache 還增加了延遲敏感，因為其以存代算，訪問延遲不能過高；最后是數(shù)據(jù)歸檔，需要進行數(shù)據(jù)的全生命周期管理，以降低整個存儲成本。

我們將 AI 存儲面臨的主要挑戰(zhàn)歸納為四種：第一種是高性能，各種場景都對存儲性能有較高要求，包括高 IOPS、高讀帶寬、高寫帶寬等；第二種是海量小文件問題，這同樣是性能問題，不過由數(shù)據(jù) I/O 性能轉變?yōu)樵獢?shù)據(jù)性能。由于文件系統(tǒng)中元數(shù)據(jù)操作相對復雜，所以這一挑戰(zhàn)較為棘手；第三種是橫向擴展，大模型時代存儲容量增長迅速，同時對性能的訴求也日益強烈，這就要求存儲能夠支撐大集群，實現(xiàn)容量和性能的線性擴展，以跟上計算能力的增長；第四種則是容量與成本問題，即在實現(xiàn)高性能的前提下，如何降低成本。如果成本降不下來，使用成本就會過高，這無疑會限制存儲技術的應用和發(fā)展。

YRCloudFile 的設計方案

YRCloudFile 在設計方案上進行了精心的取舍。文件系統(tǒng)本身在結構上大同小異，通常包含幾個關鍵模塊。首先，有一個提供 POSIX 私有客戶端的模塊，這是實現(xiàn)文件語義的入口。接著是 MGR（集群管理服務）和 MDS（元數(shù)據(jù)服務），MDS 負責存儲元數(shù)據(jù)信息。最后是數(shù)據(jù)管理服務，用于管理數(shù)據(jù)。這些組件共同構成了文件系統(tǒng)的基本架構。

針對性能問題，我們深知 I/O 路徑越簡單，效率越高。因此，我們采用了一種非常簡單的數(shù)據(jù)路由算法。在文件創(chuàng)建時，系統(tǒng)會劃分一組 OSD（數(shù)據(jù)存儲服務），確定文件將被打散并存儲在哪些磁盤上。這一過程是靜態(tài)的，在文件創(chuàng)建時就已固化。這種設計帶來了兩個顯著優(yōu)勢。首先，在訪問文件數(shù)據(jù)時，無需頻繁訪問元數(shù)據(jù)服務或數(shù)據(jù)服務，我們可以通過計算快速確定文件位于哪個磁盤的哪個位置。其次，由于文件被打散到多個磁盤上，能夠充分利用這些磁盤的能力。在 AI 場景中，常常涉及大量計算節(jié)點同時訪問某個大文件，因此大文件能夠提供的帶寬至關重要，這也是并行文件系統(tǒng)和分布式文件系統(tǒng)存在一些細微區(qū)別的原因之一。

除了簡化 I/O 路徑外，我們還做了其他工作，以將性能提升到更高水平。我們挑選了幾個具有借鑒意義的優(yōu)化措施。首先是 Multi-Channel 技術。對于全閃存儲而言，單盤帶寬本身很高，但如何充分發(fā)揮一個擁有十幾盤位或 24 盤位的全閃存儲設備的全部帶寬能力呢？網卡就成為了一個很大的瓶頸。我們需要進行網卡聚合，但 InfiniBand 網絡和 RoCE 網絡與以太網有所不同。以太網可以進行 bond 操作，但 InfiniBand 無法進行 bond，需要存儲系統(tǒng)做額外工作才能實現(xiàn)多網卡帶寬聚合，我們將其稱為 Multi-Channel。通過這種方式，可以將單個節(jié)點的吞吐量翻倍甚至翻四倍，極大地提升單節(jié)點的吞吐能力。其次是 NUMA 親和性，在高性能場景中，這一點至關重要。其核心問題是避免跨 NUMA 的內存訪問。以 AMD 平臺為例，如果發(fā)生跨 NUMA 訪問，帶寬將無法超過 15GB。只有避免跨 NUMA 訪問，才能充分發(fā)揮整個節(jié)點的帶寬能力。第三是 RDMA 的單邊編程模式。在 RDMA 中，有兩種編程模式，一種是 send-receive 方式，另一種是 read-write 單邊方式。單邊方式的核心優(yōu)勢在于減少內存拷貝。采用這種方式可以減少一次內存拷貝，從而帶來更穩(wěn)定的讀寫延遲和更低的 CPU 負載。

去年，我們發(fā)布了 F9000X 全閃一體機產品。該產品配備了第五代 Intel CPU 系列，4 張 400Gb 的 InfiniBand 網卡，以及 16 塊全閃盤。需要注意的是，由于 CPU 插槽數(shù)量的限制，我們只能插入 16 塊磁盤。這種配置下，一個三節(jié)點集群能夠達到 480GB/s 的帶寬和 750 萬的 IOPS，相比上一代 F8000X 產品，每 GBps 帶寬成本下降 60%。

在海量小文件問題上，各種解決方案都有其對應的場景和不適用的場景。存儲領域沒有一種架構能夠解決所有問題，只有場景適用與不適用之分。在文件系統(tǒng)中，常見的解決方案包括靜態(tài)子樹目錄哈?；騽討B(tài)子樹等架構。我們采用的是基于 Dentry Hash 的方式，它遵循三個原則。第一，在集群格式化時，根目錄會被固定下來。第二，在創(chuàng)建子目錄時，會重新進行哈希選擇 MDS，這樣隨著集群中目錄數(shù)量的增加，能夠保證目錄和文件均勻地分布在各個 MDS 中。第三，文件和根目錄位于同一節(jié)點，這保證了一定的本地性。在文件系統(tǒng)中，許多元數(shù)據(jù)操作，如 find 或者 ls 查詢等操作，都涉及到 readdir。如果缺乏本地性，很多優(yōu)化工作將難以開展。有了本地性后，我們可以進行一些預取等優(yōu)化操作。

除了架構層面，文件系統(tǒng)還有很多細節(jié)需要注意，其中包括緩存等。在訪問小文件時，主要涉及的元數(shù)據(jù)操作包括 lookup、getattr 獲取元數(shù)據(jù)、getxattr 獲取擴展屬性、open 打開文件、讀取和 close 關閉文件。對于小文件而言，真正讀取數(shù)據(jù)的 RPC 只有一次，其余的都是元數(shù)據(jù)操作。因此，在小文件場景中，元數(shù)據(jù)的重要性不言而喻。針對 AI 場景，我們進行了許多優(yōu)化。首先，我們有元數(shù)據(jù)緩存，它可以省去 getattr 或 getxattr 等 RPC 操作。其次，在訓練過程中，讀取文件時通常是只讀的，我們可以將 POSIX 語義弱化。因為在文件系統(tǒng)中，open 操作本身是一個很重的寫操作，我們可以將其變?yōu)橐粋€輕量級的讀操作，從而實現(xiàn) 10 倍以上的性能提升。還有 close 操作，它也是一個很重的寫操作，因為它需要更新元數(shù)據(jù)信息，如文件大小等。我們可以將 close 操作變?yōu)楫惒降模赃M一步優(yōu)化性能。

在項目早期，我們進行了一系列測試，主要針對不同數(shù)量的元數(shù)據(jù)服務（MDS）節(jié)點，如 1 個、2 個、3 個和 4 個節(jié)點時的性能表現(xiàn)。測試結果顯示，性能增長基本呈線性趨勢，這為我們后續(xù)的研發(fā)工作奠定了良好的基礎。在實際應用中，當客戶進行概念驗證（POC）測試時，他們也會關注元數(shù)據(jù)擴容后的性能表現(xiàn)，例如在元數(shù)據(jù)操作的 OPS（每秒操作次數(shù)）方面，是否會隨著擴容而實現(xiàn)成倍增長等。對此，我們進行了相應的測試，并與開源的 CephFS 進行了性能對比。在對比測試中，我們重點關注了兩個關鍵指標：creation（元數(shù)據(jù)寫操作）和 stat（元數(shù)據(jù)讀操作）。測試從一個空集群開始，逐步增加數(shù)據(jù)量，直至達到 1 億、10 億甚至 100 億的規(guī)模。結果顯示，YRCloudFile 在元數(shù)據(jù) OPS 方面表現(xiàn)穩(wěn)定，波動較小。而 CephFS 在數(shù)據(jù)量達到 1 億后，性能衰減較為嚴重，當數(shù)據(jù)量增至幾十億時，其性能幾乎無法滿足實際使用需求。這一對比結果充分證明了 YRCloudFile 在處理海量元數(shù)據(jù)時的優(yōu)越性能。

針對 AI 場景中的存儲需求，我們進行了深入研究和優(yōu)化。通常情況下，AI 存儲集群的規(guī)?？赡茉趲装倥_服務器左右，而客戶端數(shù)量可能在幾千臺左右，這已經是一個相當大規(guī)模的集群了。在這樣的集群環(huán)境中，我們開展了一系列工作，這些工作具有一定的借鑒意義。

首先，我們注意到集群規(guī)模較大的一個重要因素是心跳管理。為了確保集群中各節(jié)點的狀態(tài)能夠及時準確地被監(jiān)控和管理，我們設計了一種匯聚式的心跳上報機制，有效減輕了管理節(jié)點（MGR）的壓力。同時，我們還將心跳服務獨立管理，避免了在心跳上報過程中可能出現(xiàn)的阻塞問題，從而提高了整個集群的穩(wěn)定性和可靠性。

其次，我們采用了 UDP 協(xié)議進行集群事件同步，即事件通知。UDP 協(xié)議本身是無狀態(tài)的，可以批量發(fā)送大量數(shù)據(jù)，并且能夠實現(xiàn)高效的同步操作。然而，UDP 協(xié)議的一個缺點是數(shù)據(jù)包容易丟失。為了解決這一問題，我們采用了推拉結合的方式。一方面，我們會主動將事件推送給相關的客戶端或其他組件，使它們能夠及時感知到事件的變化；另一方面，如果數(shù)據(jù)包丟失，客戶端或其他組件會主動拉取事件信息，從而確保了事件通知的可靠性和及時性。

此外，管理節(jié)點（MGR）在集群中扮演著仲裁者的角色，負責管理和協(xié)調元數(shù)據(jù)服務（MDS）和數(shù)據(jù)存儲服務（OSD）。這種設計避免了引入外部仲裁者所帶來的復雜工程實踐問題，使得 MGR 能夠站在一個客觀的角度，準確地判斷各個服務節(jié)點的主從關系，從而提高了整個集群的管理效率和穩(wěn)定性。

我們的產品規(guī)格能夠支持 200 多臺全閃存儲節(jié)點的集群規(guī)模。這樣的集群能夠提供 TB 級別以上的帶寬，接近 10TBps，能夠滿足大規(guī)模 AI 計算的需求。在客戶端支持方面，針對 RDMA 協(xié)議，我們可以支持 2000 個客戶端；而對于基于 TCP 的以太網的客戶端，我們能夠支持的規(guī)?？蛇_ 10 萬個。這些性能指標充分展示了 YRCloudFile 在大規(guī)模集群環(huán)境下的強大性能和高擴展性。

我們的設計理念是先確保性能達到要求，然后再通過各種手段降低成本。具體來說，我們采用了智能數(shù)據(jù)分層的策略。YRCloudFile 本身作為一個高性能的熱層存儲空間，主要用于存儲頻繁訪問的熱點數(shù)據(jù)。而對象存儲則作為大容量、低成本的冷存儲空間，用于存儲不那么頻繁訪問的冷數(shù)據(jù)。對于業(yè)務應用來說，它們并不需要感知后端存儲的具體實現(xiàn)，它們看到的仍然是一個統(tǒng)一的文件系統(tǒng)視圖。

在智能數(shù)據(jù)分層功能中，管理員可以根據(jù)實際需求自定義冷熱數(shù)據(jù)的劃分策略。策略的定義主要基于兩個維度：時間和大小。從時間維度來看，管理員可以設定一個時間閾值，例如一天、一周或一個月，如果數(shù)據(jù)在設定的時間內沒有被訪問，那么這些數(shù)據(jù)就會被自動下沉到冷存儲中。從大小維度來看，對于小文件，由于它們本身占用的空間較小，可以一直保留在熱層存儲中，以避免小文件對對象存儲的訪問壓力。此外，智能數(shù)據(jù)分層還具備業(yè)務透明無感的特點，管理員可以通過命令行或者界面實時查看數(shù)據(jù)下沉的進度，并且后端存儲支持多種對象存儲類型。在 AI 場景中，數(shù)據(jù)預熱功能至關重要。這是因為 GPU 在進行計算時，無法等待從冷存儲中加載數(shù)據(jù)，因此我們需要提前將數(shù)據(jù)預熱到熱層存儲中，以確保 GPU 能夠快速訪問所需數(shù)據(jù)，從而提高整個 AI 計算的效率。

除了智能數(shù)據(jù)分層，我們還實現(xiàn)了數(shù)據(jù)智能加載功能。這一功能同樣有助于降低成本。在實際應用中，用戶可以將數(shù)據(jù)集或原始數(shù)據(jù)存儲在對象存儲中，無論是公有云的對象存儲服務，還是私有云的對象存儲系統(tǒng)都可以。當需要進行訓練時，再將這些數(shù)據(jù)加載到全閃文件系統(tǒng)中。傳統(tǒng)的做法可能是通過編寫腳本來實現(xiàn)數(shù)據(jù)的上傳和下載，但這種方式效率較低。而我們的數(shù)據(jù)智能加載功能則提供了一種更加高效的方法。它可以將對象存儲桶與文件系統(tǒng)的目錄進行映射，并允許用戶自定義加載策略。例如，用戶可以先將元數(shù)據(jù)預熱到文件系統(tǒng)中，使用戶能夠快速看到對應的數(shù)據(jù)，然后在后臺異步地將實際數(shù)據(jù)加載過來。此外，我們還支持對象存儲的變更訂閱功能。當對象存儲中的數(shù)據(jù)集發(fā)生變化時，我們可以及時將這些變更同步到全閃文件系統(tǒng)中，確保數(shù)據(jù)的一致性和實時性。

下圖是 YRCloudFile 的整體架構。在最上層是協(xié)議層，我們提供了多種協(xié)議支持，包括 POSIX 私有客戶端、大數(shù)據(jù)接口、CSI、NFS 以及 SMB 等。中間部分是我們的后端存儲服務，每個組件都采用了高可用架構，確保了整個系統(tǒng)的穩(wěn)定性和可靠性。在最底層，我們提供了數(shù)據(jù)生命周期管理的解決方案，包括智能數(shù)據(jù)加載和智能數(shù)據(jù)分層等功能。這些功能共同構成了 YRCloudFile 的完整架構，使其能夠滿足不同用戶在不同場景下的多樣化存儲需求。

高級運維特性

在存儲系統(tǒng)的構建和優(yōu)化過程中，穩(wěn)定性和可運維性是兩個至關重要的考量因素。今天，我將向大家詳細介紹我們在這些方面所采取的一些高級運維特性。這些特性可以大致分為幾個類別：首先是多租戶管理，這在 AI 訓練和推理場景中尤為重要；其次是數(shù)據(jù)訪問安全；最后是我們在構建底層技術設施時，針對多個網絡平面以及客戶現(xiàn)場棘手問題所提出的系統(tǒng)優(yōu)化方案。

多租戶管理的實現(xiàn)涉及到空間隔離、流量隔離和訪問隔離這三個關鍵方面。在空間隔離方面，我們通過配額管理來讓管理員能夠為不同的租戶分配不同的存儲空間。對于流量控制，我們設置了相應的目錄級別的 QoS，以此來限制某個租戶的流量上限，防止其對其他用戶造成影響。而在訪問隔離上，我們采用了基于 IP 白名單或 token 的認證掛載方式，確保租戶只能訪問自己的存儲空間。

在數(shù)據(jù)訪問安全方面，我們采取了多種措施。首先是訪問權限控制，我們實現(xiàn)了標準的 POSIX ACL，用戶可以通過 ACL 跟 LDAP 或 AD 這樣的域控服務來實現(xiàn)全局的用戶權限統(tǒng)一管理。其次是日志審計，這對于管理員來說極為重要，它能夠記錄用戶的高危操作，如 unlink（刪除鏈接）、rmdir（刪除目錄）、rename（重命名）以及 open（打開文件）等操作。日志審計可以記錄下是哪個用戶在什么時間、使用哪個節(jié)點、通過什么工具針對哪些文件進行了操作，這些信息還可以對接到 ELK 平臺，實現(xiàn)高效的審計檢索。最后是回收站功能，它主要用于應對用戶或管理員可能發(fā)生的誤操作。我們設計的回收站允許每個目錄自定義回收站，并且每個回收站都可以自定義清理策略，還可以動態(tài)開關。雖然回收站本身會對性能產生 5% 以內的影響，但它為數(shù)據(jù)安全提供了最后一道防線。

彈性數(shù)據(jù)網絡的本質是幫助用戶打通多個網絡平面，同時訪問一套存儲。在 AI 領域，這種需求非常常見。例如，訓練集群和推理集群對網絡的要求不同，訓練集群通常需要 200Gb、400Gb 的 IB 或 RoCE 高速無損網絡，而推理集群則一般使用 25Gb 或 100Gb 的以太網網絡。這兩種網絡在物理層面上是隔離的，如果想要實現(xiàn)數(shù)據(jù)共享，要么通過存儲系統(tǒng)本身支持多任務、多網絡平面的訪問，要么就需要進行額外的數(shù)據(jù)同步操作，這無疑增加了系統(tǒng)的復雜度。有了彈性數(shù)據(jù)網絡，就可以簡化存儲基礎設施，提高系統(tǒng)的靈活性和效率。

在特定場景下的性能優(yōu)化方面，由于文件系統(tǒng)是存儲領域中最為復雜的類型，其語義豐富，且性能與用戶的編碼水平直接相關，因此我們挑選了幾個在 AI 領域中典型的優(yōu)化案例。首先是針對單流業(yè)務的優(yōu)化。單流業(yè)務是指只有一個線程在工作的業(yè)務，如數(shù)據(jù)拷貝或解壓縮等。為了提升這類業(yè)務的性能，我們主要依賴緩存機制，通過預取、預讀或緩存寫操作來顯著提高性能。其次是 Cache 的 HardLimit（硬限制），在 AI 訓練中，尤其是訓練小模型時，如果數(shù)據(jù)集非常大，PageCache 可能無法完全緩存數(shù)據(jù)，這對 AI 訓練非常不利。因為訓練過程中每個數(shù)據(jù)集都要被讀取一遍，雖然是隨機讀取，但對 Cache 來說并不友好。此外，當緩存數(shù)據(jù)需要被置換時，如果數(shù)據(jù)量很大，會導致延遲抖動非常嚴重，這對 GPU 的效率非常不利。為此，我們設置了 Cache 的 HardLimit，例如對于一個 1TB 的 GPU 服務器，我們允許其使用的緩存最多為 100GB 或 200GB 的數(shù)據(jù)，這樣可以避免觸發(fā) PageCache 本身的閾值，從而減少抖動。最后是客戶端限速。這與前面提到的 QoS 有所不同，主要是為了解決在 IB 網絡場景中，當多個用戶共享一個集群時，某些計算節(jié)點的網絡帶寬過高會導致?lián)砣膯栴}。這種擁塞會擴散，影響整個集群的網絡帶寬。我們的解決方案是限制某些客戶端的速度，通過犧牲少量客戶端的峰值帶寬，來實現(xiàn)整個網絡的高吞吐量。

A 訓練推理解決方案

在 AI 訓練階段，性能是至關重要的。我們通過多種技術手段來提升性能，包括 Multi-Channel 技術、支持 GPU Direct Storage 以降低延遲、內核私有客戶端以及支持 400Gb 的 Infiniband 或 RoCE 無損網絡。此外，我們還提供了分布式元數(shù)據(jù)集群來進一步增強性能表現(xiàn)。在數(shù)據(jù)生命周期管理方面，我們實現(xiàn)了分層存儲和數(shù)據(jù)加載功能，這不僅有助于降低成本，還能打通混合云環(huán)境中的數(shù)據(jù)流轉。而在運維方面，我們提供了一系列功能，如 QoS、Quota、子目錄掛載、ACL、審計、回收站以及彈性數(shù)據(jù)網絡等，以確保整個大模型訓練過程的穩(wěn)定性和高效性。在智算中心的整體存儲架構中，對象存儲作為數(shù)據(jù)底座，而 YRCloudFile 則作為訓練存儲的加速層，為訓練階段提供高效支持。

在推理階段，我們的解決方案主要圍繞提升推理效率展開。我們針對 KVCache 進行了優(yōu)化，通過以存換算的方式提高推理效率。我們提供了一個 PB 級的 KVCache 緩存空間，這有助于提高 Cache 命中率，從而節(jié)省算力。由于 KVCache 本身是一個吞吐且延遲敏感型的應用，我們確保單個計算節(jié)點能夠提供 40GBps 的帶寬能力，并保證了 KVCache 訪問的低延遲。

在測試數(shù)據(jù)方面，我們在兩種場景下進行了性能對比。第一種場景是在長上下文情況下，使用 KVCache 后，TTFT 延遲顯著下降，性能提升了約 13 倍。第二種場景是在高并發(fā)情況下，針對不同上下文長度的對比測試。我們將使用 vLLM 原生方案與加入 YRCloudFile 后的數(shù)據(jù)進行對比，結果顯示，當上下文長度越長時，使用 KVCache 的效果越好。

我們在推理場景中還提供 DataInsight 的解決方案。目前，DataInsight 主要應用于知識庫平臺，當前許多知識庫平臺在數(shù)據(jù)層面存在最后一公里的問題。DataInsight 能夠幫助企業(yè)用戶從海量歷史數(shù)據(jù)中快速檢索出有價值的數(shù)據(jù)。它支持多種數(shù)據(jù)源，包括 S3、NAS 或 HDFS 等，并能夠實現(xiàn)百億級數(shù)據(jù)的秒級檢索返回。DataInsight 還支持多維度組合查詢，使管理員能夠精準檢索所需數(shù)據(jù)，并通過 DataFlow 按需將數(shù)據(jù)流轉到知識庫平臺中。同時，我們還實現(xiàn)了對第三方存儲增量數(shù)據(jù)的感知功能，這對于企業(yè)來說非常有用，因為它能夠確保知識庫平臺的信息保持更新，而無需侵入業(yè)務平臺。當業(yè)務數(shù)據(jù)寫入原有位置時，我們能夠自動感知這些增量數(shù)據(jù)，并將其同步到向量數(shù)據(jù)庫中，從而使知識庫平臺的用戶能夠及時獲取最新信息，如產品發(fā)布參數(shù)和最新行業(yè)法規(guī)等。

總結和未來規(guī)劃

總結一下，我們在性能方面主要關注元數(shù)據(jù)性能和數(shù)據(jù)性能兩大塊。在元數(shù)據(jù)性能上，我們采用了分布式元數(shù)據(jù)架構，并針對元數(shù)據(jù)操作進行了優(yōu)化。在數(shù)據(jù)性能層面，我們引入了 GPU Direct Storage、NVMe SSD、RDMA、Multi-Channel 以及 NUMA 親和性等多項優(yōu)化技術。

在運維層面，我們涵蓋了多租戶管理、數(shù)據(jù)安全訪問、彈性數(shù)據(jù)網絡以及監(jiān)控告警等功能，以確保系統(tǒng)的穩(wěn)定性和可維護性。在成本控制方面，我們通過智能數(shù)據(jù)分層和數(shù)據(jù)加載等功能來降低成本。

關于未來規(guī)劃，我們有以下幾個方面的考慮：

1. 在推理側，我們會繼續(xù)增強相關功能。目前我們已經實現(xiàn)了 KVCache 解決方案，未來將從“有到優(yōu)”進行進一步優(yōu)化，提升性能和效率。

2. 在降低成本方面，我們會采取兩種策略。一方面，我們引入 EC（Erasure Coding，糾刪碼）技術，并將其作為產品路線圖中的重點。另一方面，在存儲介質層面，我們將逐步采用 QLC SSD，因其單盤容量較大，目前已有 32TB 的產品，很快將推出 64TB 的 QLC SSD，這將有助于提高存儲密度并降低成本。

3. 在客戶端方面，我們會將工作負載卸載到 DPU 中。對于 GPU 服務器而言，其 CPU 和內存資源非常寶貴，因此我們將盡可能減少對這些資源的占用，把相關工作負載轉移到 DPU 上，以提高整體效率。

4. 在運維方面，我們會繼續(xù)增強系統(tǒng)的可運維性。對于存儲系統(tǒng)來說，性能、穩(wěn)定性和可運維性都是非常關鍵的指標。通過提升可運維性，能夠幫助管理員更高效地管理和使用存儲系統(tǒng)。

嘉賓介紹

張文濤，畢業(yè)于華中科技大學計算機專業(yè)碩士，專注于分布式存儲領域，擁有超過 15 年的大規(guī)模公有云存儲架構開發(fā)和 AI 存儲架構設計，參與主導了 YRCloudFile 高性能分布式文件存儲系統(tǒng)從 0 到 1 的設計研發(fā)及產品落地工作，并在 AI 場景應用落地方面具備一定的實戰(zhàn)經驗。在 AI 及高算力場景項目交付上，有著豐富的整體架構設計和性能優(yōu)化經驗。中國智能計算產業(yè)聯(lián)盟專委會技術專家組，上海 TGO 鯤鵬會成員。

會議推薦

QCon 上海站（10.23-25）干貨拉滿：Agentic AI、具身智能等前沿方向，疊加可觀測、AI 中間件等經典領域，熱點技術 + 落地難點一次性搞定！折上 9 折優(yōu)惠限時返場！今晚（9.30）結束，抓緊時機！掃碼還可以免費領資料包，咨詢票務經理 18514549229 了解更多。