8 月 5 日，全球權威 AI 工程聯盟 MLCommons 發布了最新的 MLPerf? Storage v2.0 基準測試結果。本次評測吸引了眾多廠商參與，包括 Cloud、Shared File、Fabric-Attached Block、Direct-Attached Block 這幾大類存儲廠商。

由于各廠商在硬件配置、節點規模和應用場景上的差異，直接進行橫向比較存在局限性。因此，本文將聚焦于共享文件系統這一類別，分析其在相同測試標準下的表現。

JuiceFS 是支持云上以及機房部署的高性能分布式文件系統。在多個 AI 訓練負載下，JuiceFS 均取得了優異的成績，尤其在帶寬利用率、可擴展性等方面均處于領先水平。接下來，本文將結合具體測試結果展開分析，并進一步介紹支撐這些表現的關鍵特性。

01 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 中。由于涉及海量小文件的分布式讀取，系統不僅要具備足夠的整體吞吐能力，還需要在元數據處理和尾延遲控制上表現穩定，否則隨著節點規模的增加，延遲波動會顯著放大并拖慢整體訓練速度。

此外，此次 V2.0 版本中還提供了一類全新的 Checkpointing 負載，用于模擬大模型訓練中的 checkpoint 落盤與恢復，主要表現為大文件多并發順序寫負載。在 JuiceFS 架構下，checkpoint 數據通過 JuiceFS 寫入到對象存儲中，性能瓶頸取決于作為數據持久層的對象存儲帶寬上限。

02 性能比較：產品類別、彈性擴展能力與資源利用率

在這次 MLPerf Storage v2.0 的測試中，參與的廠商數量眾多，涉及塊存儲和共享文件系統等多種類型，但由于這些類型的存儲系統在架構和應用場景上差異大，且各廠商在測試中使用的硬件配置與節點規模差異顯著，因此橫向對比意義有限。

本文將重點分析共享文件系統這一類別下的結果。在共享文件系統陣營中，還可以進一步細分為兩類：

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

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

在展開結果解讀之前，我們先介紹此次比較所依據的標準。

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

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

03 JuiceFS 測試結果解讀

在 3D-Unet 負載中，JuiceFS 實現了高達 108 GiB/s 的數據讀取帶寬，支撐了 10 節點共 40 張 H100 GPU的訓練規模，網絡帶寬利用率達到 86.6%， GPU 利用率是 92.7%。

在 CosmoFlow 負載中，JuiceFS 支撐了 10 節點共 100 張 H100 GPU 的訓練規模，GPU 利用率為 75%。這一負載對存儲延遲的穩定性要求極高，對網絡帶寬的要求較低，性能瓶頸并不在帶寬。由于需要處理海量小文件的并發訪問，IO 延遲大小及延遲穩定性直接決定了整體擴展能力，并限制了 GPU 的利用率。

在 ResNet-50 負載中，JuiceFS 的數據讀取帶寬達到 90 GiB/s，網絡帶寬利用率為 72%，整體 GPU 利用率為 95%。

?? 需要說明的是，本次測試在 GCP 上選用的機型中，單個可用區能穩定開啟的彈性實例數量有限，因此我們提交的測試最大規模為 10 節點。這并不代表 JuiceFS 系統的最大承載能力，系統在更大規模節點下仍可提供更高的聚合帶寬和訓練規模。

背景回顧：GPU 規模受限于存儲網絡的帶寬能力

JuiceFS 參與 MLPerf 測試已經進入第三年。第一年我們基于 v0.5 版本自行進行了完整的測試，當時使用的是 V100 GPU 進行模擬。

由于 V100 的單卡帶寬需求較低，在較長區間內，GPU 利用率始終維持在 99% 附近，隨著訓練的 GPU 規模擴大而緩慢下降至 98%左右。直到總帶寬接近網卡帶寬上限時，才出現拐點，此后隨著 GPU 數量增加，利用率便迅速下降。具體分析可參考我們之前的文章：千卡利用率超98%，詳解JuiceFS在權威AI測試中的實現策略。根據圖中的數據，在 GPU 利用率為 90% 時，大約能支持 110 張 V100 GPU，這一規模上限主要受制于存儲網絡的帶寬能力。

3D-Unet：JuiceFS 以最高帶寬與帶寬利用率領跑同類系統

3D-Unet 訓練負載屬于大文件連續讀取負載，這類負載對存儲系統的讀帶寬提出了較高要求。

從下圖可以清楚看到，在所有基于傳統以太網的存儲系統中，JuiceFS 的表現最為優秀：在 10 節點、40 張 H100 的規模下，實現了 108 GiB/s 的數據讀取帶寬，網絡帶寬利用率達到 86.6%，在同類系統中均為最高。這意味著 JuiceFS 不僅能夠提供更高的總帶寬，同時也能更充分地發揮網絡和硬件資源的性能，從而在性價比上具備顯著優勢。

下面這部分是使用 IB 網絡和 RoCE 網絡（RDMA over Converged Ethernet）的參測廠商結果。這兩類廠商的硬件規格整體都非常高，最低的網絡總帶寬在 400 GiB/s 左右，最高的甚至超過 1500 GiB/s。因此，它們能夠為訓練業務提供極高的總帶寬。值得一提的是 JuiceFS 在彈性擴展分布式緩存節點數后，亦能達到類似的帶寬水平，近期測試中，基于 100 臺 GCP 100Gbps 節點組成的分布式緩存集群，其聚合讀帶寬已達到 1.2 TB/s。

從利用率的角度來看，隨著單張網卡帶寬的提升，網絡帶寬利用率會越來越難以提高。在 400 Gb/s 甚至更高規格的網卡配置下，要將帶寬利用率做到接近 80% 都是非常有挑戰性的。

Cosmoflow：JuiceFS 支撐百卡規模，擴展能力領先

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

下圖橫軸表示系統能夠支撐的 GPU 總數，即 H100 GPU 的數量，JuiceFS 的表現繼續領先。通過 10 個客戶端同時運行，成功支撐了 100 張 H100 GPU 的 Cosmoflow 訓練任務，GPU 利用率保持在規定閾值以上。

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

ResNet50： JuiceFS 支持最多 H100， 帶寬利用率最高

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

在該測試中，JuiceFS 在同類系統中支撐了最多數量的 500 張 H100 GPU，并在所有基于以太網的方案里實現了最高的網絡帶寬利用率，達到 72%，遠高于其他廠商普遍約 40% 的水平。同時，GPU 利用率保持在 95%。這一結果表明，JuiceFS 在高并發隨機 I/O 場景下，能夠充分發揮軟件層面的優化能力，高效利用硬件資源，從而展現出領先的性能和效率。

04 JuiceFS 在 MLPerf 測試中的系統配置

本次測試中，JuiceFS 的系統拓撲主要分為三層：

1. 客戶端層：最上層為 10 個客戶端節點，統一運行在 GCP 的同一機型上，各節點的帶寬配置完全對等，保證了客戶端側的均衡性。
2. 緩存集群層：中間層為緩存集群，共 10 個緩存節點，緩存節點使用云盤并結合本地內存作為緩存，加速數據訪問。
3. 冷數據存儲層：數據最終都保存在 GCS 中。

在訓練開始前，冷數據會從 GCS 預熱到緩存集群；訓練過程中，客戶端則直接從緩存集群中讀取數據。這種方式避免了在訓練中訪問高延遲的對象存儲，能夠提供穩定的高帶寬和低延遲訪問，從而滿足大規模 AI 訓練的持續數據需求。

本輪 MLPerf Storage 測試中，規則允許增加一輪“預熱測試”。因此，即便是不支持主動預熱功能的系統，也能在測試前提前將預熱數據加載到緩存中，保證了測試的公平性；此外，大家還能夠享受到 page cache 帶來的性能提升，這對于延遲敏感的負載（cosmoflow）來說也十分關鍵。

在當前配置下，10 個客戶端與緩存集群能夠支撐約 40 張 H100 GPU 的訓練規模。如果訓練規模繼續擴大，例如 GPU 數量翻倍，只需按比例擴展緩存集群節點數，即可匹配新的帶寬需求。這種架構展現了高度的靈活性和彈性，能夠適配更大規模的訓練任務。

JuiceFS 在本次測試中取得的好成績，首先依賴于高性能的元數據引擎。該引擎具備非常高的 IOPS 和極低的延遲性能，同時在客戶端也集成了元數據緩存，從而顯著降低了訪問延遲。這一能力對 CosmoFlow 負載尤為關鍵，因為該場景涉及大量小文件并發訪問，對延遲高度敏感，穩定的低延遲保證了 GPU 利用率和整體擴展性。

另一個核心優勢是分布式緩存。實測表明，JuiceFS 的緩存集群可提供高達 1.2 TB/s 的聚合帶寬（基于 100 臺 GCP 100Gbps 節點，數量上限受制于 GCP 上該機型選定分區下的可用機器數量 ），并將訪問延遲降低至亞毫秒級。緩存集群支持彈性擴縮容，既能在帶寬上提供極致性能，也能根據任務需求擴展 IOPS和帶寬。在 ResNet-50 負載中，JuiceFS 的高 IOPS 性能起到了決定性作用。在以太網環境下的對比中，JuiceFS 依靠 IOPS 優勢脫穎而出，帶寬利用率達到 72%，GPU 利用率保持在 95%。

05 小結

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

JuiceFS 在此次測試的不同 AI 訓練負載下展現出穩定的低延遲和高效的資源利用率。作為一款全用戶態、云原生的分布式文件系統，它利用分布式緩存實現高吞吐與低延遲，同時借助對象存儲保證了成本優勢，為大規模 AI 訓練提供了無需依賴昂貴專有硬件的可行選擇。

我們希望本文中的一些實踐經驗，能為正在面臨類似問題的開發者提供參考，如果有其他疑問歡迎加入 JuiceFS 社區與大家共同交流。