如何為 GPU 提供充足存儲：AI 訓練中的存儲性能與擴展性

作者 | 莫飛虎

在 AI 訓練中，業界往往將關注點集中在計算資源上，但如果存儲性能不足，GPU 無法被充分利用，計算效率將會大幅受限。因此，存儲系統的性能對於提升整體訓練效率至關重要。本文旨在通過分析最新的 MLPerf Storage v2.0 測試結果，探討不同存儲系統在大規模 AI 訓練中的表現，並幫助讀者理解如何根據實際需求選擇合適的存儲方案。

MLPerf Storage 基準測試作為業界權威評測體系，專門用於還原真實 AI 訓練負載，以全面檢驗存儲系統在不同場景下的表現。 8 月 5 日，全球 AI 工程聯盟 MLCommons 發佈了最新的 MLPerf® Storage v2.0 測試結果，本次評測吸引了包括雲存儲、共享文件系統、Fabric-Attached Block 以及 Direct-Attached Block 在內的眾多廠商參與。

由於各廠商在硬件配置、節點規模及應用場景方面存在差異，結果間的橫向比較存在一定侷限。因此，本文將重點聚焦於共享文件系統這一類別，在統一測試標準下對其表現進行分析。

MLPerf Storage v2.0 

及其測試負載

MLPerf 是 MLCommons 推出的通用 AI 基準評測套件，其中的 MLPerf Storage 通過多客户端模擬真實 AI 負載訪問存儲系統，能夠復現大規模分佈式訓練集羣場景存儲負載，從而全面評估存儲系統在 AI 訓練任務中的實際表現。

在最新的 v2.0 版本中，MLPerf Storage 提供了三類訓練負載，覆蓋了深度學習訓練中最具代表性的 I/O 模式。

在 3D U-Net 醫療分割負載中，系統需要處理大體積三維醫學圖像的順序和併發讀取。每個樣本平均大小約為 146 MB，並作為獨立文件存儲。這類任務主要考察存儲系統在大文件連續讀取場景下的吞吐性能，以及在多節點同時訪問時能否保持穩定的響應能力。

ResNet-50 圖像分類負載則完全不同，它是小樣本的高併發隨機讀取壓力。每個樣本平均大小隻有 150 KB，數據通過 TFRecord 格式打包存放在大文件中。這樣的數據組織方式使得訓練過程中存在大量隨機 I/O 和頻繁的元數據訪問，因此該負載對存儲系統的 IOPS 提出了極高要求，是衡量小文件場景下併發性能的重要測試。

CosmoFlow 宇宙學預測負載，強調的是跨節點場景下的小文件併發訪問和帶寬擴展性。每個樣本平均 2 MB，通常以單文件形式存儲在 TFRecord 中。由於涉及海量小文件的分佈式讀取，系統不僅要具備足夠的整體吞吐能力，還需要在元數據處理和尾延迟控制上表現穩定，否則隨着節點規模的增加，延迟波動會顯著放大並拖慢整體訓練速度。

MLPerf Storage v2.0 工作負載

此外，此次 V2.0 版本中還提供了一類全新的 Checkpointing 負載，用於模擬大模型訓練中的 checkpoint 落盤與恢復，主要表現爲大文件多併發順序寫負載。

  性能比較標準：產品類別、

彈性擴展能力與資源利用率

在這次 MLPerf Storage v2.0 的測試中，參與的廠商數量眾多，涉及塊存儲和共享文件系統等多種類型，但由於這些類型的存儲系統在架構和應用場景上差異大，且各廠商在測試中使用的硬件配置與節點規模差異顯著，因此橫向對比意義有限。本文將重點分析共享文件系統這一類別下的結果，為用户在類似場景中的選型提供更具參考價值的結論。

在共享文件系統陣營中，還可以進一步細分為兩類：

第一類是基於以太網的系統，包括 Alluxio、JuiceFS 和 Oracle，這些雲上系統依賴以太網環境提供分佈式存儲能力，從而實現高性能存儲。另有一些廠商，如 Nutanix 和華為，則採用了基於 RoCE 的以太網方案，單機通常配置更高帶寬的網卡。

第二類則是基於 IB 網絡的存儲解決方案，例如 DDN、Hewlett Packard、Ubix 和焱融。這些廠商提供的是完整的存儲軟硬一體機，通常基於 IB 網絡。其硬件配置非常高，整體成本較高，能夠提供極高的帶寬和性能上限。

在展開結果解讀之前，有必要説明本文采用的比較視角。本文在遵循 MLPerf 官方基本提交要求的基礎上，結合對軟件產品的理解，總結出一套用於橫向分析的參考框架。

MLPerf Storage 的文檔中要求提交的結果滿足 GPU 利用率閾值，並儘可能提高 GPU 數量，其中 3D U-Net 與 ResNet-50 的閾值為 90%，Cosmoflow 的閾值為 70%。在滿足 GPU 利用率閾值的前提下，真正體現差異的核心指標是存儲系統所能支撐的最大 GPU 數量，而這一規模實質上取決於系統能夠提供的最大聚合帶寬。能夠支撐更多 GPU 的存儲系統，意味着在大規模訓練場景中具備更強的可擴展性與穩定性。 尤其是在 Cosmoflow 這樣的負載中，由於涉及大量小文件且對延迟高度敏感，對存儲系統的擴展性提出了更嚴苛的考驗。

其次，還需要從資源利用率的角度來比較結果。對於軟件廠商而言，關鍵在於存儲軟件是否能夠充分發揮底層硬件的潛力。存儲系統的瓶頸通常是網絡帶寬，為此，我們採用網卡帶寬利用率作為參考指標：利用率越高，説明軟件的效率越高，也意味着在相同硬件條件下具備更高性能和性價比。

測試結果解讀

3D-Unet：大文件連續讀取對存儲帶寬的挑戰

3D-Unet 訓練負載是典型的大文件連續讀取場景，對存儲系統的讀帶寬提出了較高要求，並要求 GPU 利用率 保持在 90% 以上。在本次 MLPerf Storage v2.0 測試中，使用以太網的存儲產品在 GPU 支撐數量、總帶寬以及帶寬利用率等方面的表現如下圖所示。Oracle 和 JuiceFS 在這些指標上均表現出色，尤其是 JuiceFS 支撐了最多的 H100 GPU，並維持了較高的帶寬利用率 86.6%。這類存儲方案的優勢在於能夠充分發揮網絡和硬件資源的潛力，確保高效的性能，並在性能與成本之間實現良好的平衡。

下面這部分是使用 IB 網絡和 RoCE 網絡（RDMA over Converged Ethernet）的參測廠商結果。這兩類廠商的硬件規格整體都非常高，最低的網絡總帶寬在 400 GiB/s 左右，最高的甚至超過 1500 GiB/s。因此，它們能夠為訓練業務提供極高的總帶寬。不過，從利用率角度來看，隨着單卡帶寬的提升，採用 IB 網絡的產品通常會面臨較低的帶寬利用率，普遍低於 50%。

Cosmoflow：海量小文件訪問的考驗

CosmoFlow 訓練負載需要讀取海量小文件，這對存儲系統的元數據性能和讀延迟性能提出了極高要求，同時測試規定 GPU 利用率需達到 70% 以上。由於任務對延迟要求非常高，隨着 H100 數量的增加，多節點分佈式訓練的讀取延迟方差會顯著增加，從而使得 GPU 利用率快速下降，導致水平擴展十分困難。與 3D U-Net 相比，CosmoFlow 的提交結果總數明顯更少，這也反映了該負載優化難度較大。

下圖橫軸表示系統能夠支撐的 GPU 總數，即 H100 GPU 的數量，JuiceFS 和 Oracle 的表現繼續領先。JuiceFS 通過 10 個客户端同時運行，支撐了 100 張 H100 GPU 的 Cosmoflow 訓練任務。

與此同時，基於 IB 網絡的系統在該負載下表現尤為突出（如下圖所示）。這得益於 IB 網絡系統性提供了全鏈路的極低且高度穩定的延迟。儘管其成本較高，但在延迟敏感型任務中，IB 網絡的性能優勢依然是不可忽視的。

ResNet50： 高併發隨機讀的存儲壓力

ResNet-50 訓練負載屬於大文件高併發隨機讀負載，對存儲系統的 IOPS 提出了極高要求，並要求 GPU 利用率保持在 90% 以上。

在該測試中，JuiceFS 在同類系統中支撐了最多數量的 500 張 H100 GPU，並在所有基於以太網的方案里實現了最高的網絡帶寬利用率，達到 72%，其余產品在此次測試中的帶寬利用率大約在 40% 的水平。

下圖匯總了採用 InfiniBand (IB) 等專用高速網絡的解決方案的測試結果。可以看出，使用 InfiniBand 網絡的廠商憑藉更高的總帶寬和 IOPS，在支持的 GPU 數量 和 吞吐帶寬 上取得了較高的成績，但很多方案的網絡利用率並不突出。

小   結

本文分析了此次 MLPerf Storage v2.0 測試結果。在評估存儲產品的 GPU 利用率之前，用户首先需要了解存儲產品的類型，包括其架構、硬件資源及成本等因素。在 GPU 利用率達標的前提下，存儲系統的關鍵差異體現在其能夠支撐的最大 GPU 數量，能夠支持更多 GPU 的存儲系統意味着在大規模訓練場景中具備更強的可擴展性與穩定性。此外，還需關注資源利用率，即存儲軟件是否能夠充分發揮底層硬件的潛力。

多個類別的存儲系統參與了本次 MLPerf Storage v2.0 測試。與 InfiniBand 系統相比，基於以太網的存儲方案通常在靈活性和成本效益方面具有優勢，能夠在不依賴昂貴專有硬件的前提下，仍然提供出色的性能。以太網方案在大規模 AI 訓練中已經得到了廣泛應用，成為許多用户選擇的經濟且可擴展的解決方案之一。