- US - English
- China - 简体中文
- India - English
- Japan - 日本語
- Malaysia - English
- Singapore - English
- Taiwan – 繁體中文
輸入無效。不支援特殊字元。
隨著 AI 系統的複雜性和功能不斷擴展，對儲存基礎架構的需求也迅速演變。從訓練海量模型到提供即時推論，儲存裝置不再是被動的後端，而是 AI 堆疊中至關重要的效能元件。MLPerf Storage v2.0 基準套件提供全新視角，讓我們得以瞭解現代 SSD 如何處理從高吞吐量訓練到容錯檢查點的 AI 工作負載的獨特 I/O 模式。
但故事並不止於此。隨著推論工作負載轉向檢索增強生成 (RAG)，向量資料庫和鍵值 (KV) 快取也逐漸成為儲存最佳化的下一個前沿領域。這些工作負載帶來了新的挑戰。
在本文中，我將介紹最新的 MLPerf Storage 結果、解析其背後的工作負載，並探討未來基準測試如何適應向量搜尋和 KV 快取重複使用技術的興起。
如果您想深入瞭解，請參加 SNIA 開發人員大會 (SDC)，我將在 9 月 17 日上午 8：30 的演講中深入探討：MLPerf Storage 基準套件和 AI 儲存工作負載的討論與分析
MLPerf Storage v2.0s：關鍵結果和工作負載
眾所周知，對 AI 工作負載的儲存裝置進行基準測試非常困難。真實的訓練工作需要昂貴的加速器，而公開的資料集通常太小，無法反映生產規模的行為。
由 MLCommons 聯盟開發的 MLPerf Storage 填補了這一差距。該技術使用合成資料集和真實資料載入器（PyTorch、TensorFlow、DALI 等）模擬真實的 AI 訓練工作負載，同時以經過校準的休眠間隔取代運算來模擬 GPU 行為。此方法無需數千個 GPU，即可對儲存系統進行準確、可擴充的基準測試。
我們還發現工作負載的強度不同，如佇列深度直方圖所示。我們發現低 QD 作業與極高的 QD 作業混合。
自 MLPerf Storage 誕生以來，美光一直深度參與其中，並對 v0.5、v1.0 和現在 v2.0 等每個主要版本做出貢獻，提交結果並幫助塑造基準工作負載。
在 v2.0 中，MLPerf Storage 從訓練擷取擴展到檢查點工作負載。
訓練工作負載：ResNet50、CosmoFlow、Unet3D
我曾深入撰寫和討論過 MLPerf Storage 中的訓練工作負載，最近一次是在 FMS 2024。v2.0 中的訓練基準定義與 v1.0 相同，這表示我們可以比較兩個提交期間的結果。
我強烈建議回顧那篇演講，但重點是訓練攝取可以涵蓋各種工作負載。對於 MLPerf Storage 中顯示的三種模型，我們發現各種傳輸規模，具體取決於資料容器格式（TFRecord 會導致大量 4KB IO）。
這些特徵導致 AI 訓練的資料擷取比我們預期的要複雜得多。
檢查點工作負載：Llama 3 模型群
我們在 2023 年底開始研究檢查點工作負載，並很自豪地看到我們的工作成果被納入 MLPerf Storage。檢查點現在是一項一流的工作負載，本身可解決在訓練期間定期儲存模型和最佳化程式狀態的需求，尤其是在橫向擴充叢集上執行的大型語言模型 (LLM)。如需深入瞭解基準，請造訪我的部落格 mlcommons.org，其中公佈了新的檢查點工作負載。
該基準測試包括四種模型大小，檢查點範圍從 105 GB 到 18,000 GB 不等。對於每個模型，我們測量兩個檢查點階段：儲存檢查點和載入檢查點。
檢查點結果顯示了各種解決方案，可有效儲存檢查點，並從先前的檢查點復原。向 IBM 發出讚美之詞， 該公司在 1 兆參數模型中實現超過 600 GiB/s 的恢復速度！
值得慶幸的是，現代 SSD 非常適合隨機存取 4KB 資料組塊。
新興工作負載：向量資料庫
向量資料庫經過最佳化，可用於儲存和搜尋高維向量（通常是由 AI 模型產生的嵌入）。這些系統為推薦引擎、圖像和文字檢索、詐騙偵測，以及日益增加的 LLM 檢索增強生成 (RAG) 等應用程式中的相似性搜尋提供支援。
與傳統資料庫不同，向量 DB 優先考慮近似最近鄰 (ANN) 搜尋而非精確匹配，以精度換取速度和可擴充性。隨著資料集逐年增長，將向量指數從記憶體卸載到磁碟的需求使得儲存效能成為首要關注的問題。
雖然將儲存整合至向量搜尋系統的方法有很多，但主要方式是使用專為從快速儲存中查詢而設計的索引。在最近舉行的 FMS（記憶體和儲存的未來）大會上，我的團隊同事 Sayali Shirode 在討論和分析 MLPerf Storage 中新向量資料庫基準的會議中展示了她的一些研究成果。
在此次會議中，Sayali 展示了對在 1 億個向量資料集的 Milvus 中使用 DiskANN 的分析。本研究中決定儲存方案的重要發現為：
- 小規模 IO
- 佇列深度低，QD 突發極高
Sayali 表示，在延遲敏感型域（低批次大小、單一程序）會磁碟索引執行 100% 的 4KB 作業。此外，當擴充到最大吞吐量（高批次大小和多個同步程序）時，我們發現了相同的行為，即磁碟索引的 4KB 作業佔比 100%。
第二個發現建立在第一個發現的基礎上。當我們查看工作負載的佇列深度直方圖時，我們發現大多數 IO 都都插入到佇列中相對較低的位置。單一程序的峰值達到 QD7，尾端達到 QD35。64 程序測試顯示，在 15 的「低」佇列深度時出現了類似的峰值，但尾端達到 QD 400+。
將執行緒數量或批次大小擴充至高於測試值會導致延遲大幅增加，查詢吞吐量的提升卻微乎其微。這些結果共同表明，DiskANN 的儲存需求是提供大量 4KB IO，同時將延遲降至最低並最佳化 QoS。
您希望深入瞭解嗎？
如需深入瞭解向量搜尋和 DiskANN，請查看 Alessandro Concalves (Solidigm) 在 SDC 上的演講：使用 NVMe 擴充 RAG：DiskANN 的向量資料庫索引混合方法。自我們今年稍早啟動這項計畫以來，Alessandro 一直與 MLPerf Storage 工作小組進行向量資料庫基準測試。我們還提供一個可產生合成資料集和查詢的基準測試工具。該工具允許我們測試擴充的資料集，但不會驗證結果的準確性，如果沒有額外的準確性測試，則不應將其用於相互比較不同的索引。該工具正在積極開發中，因此請使用 GitHub 問題提交請求或錯誤。
KV 快取管理與重複使用
KV 快取是一個複雜的主題，其命名並不完善。需要瞭解的是，產生詞元的 LLM 需要 KV 快取才能查詢。KV 快取實際上是基於轉換器的 LLM 在推論過程中的短期記憶體。
KV 快取卸載是指在產生詞元時使用其他記憶體來儲存部分 KV 快取。這與我們在此處討論的工作流程不同。
KV 快取管理和重複使用是指在完成詞元產生後儲存查詢的 KV 快取，以便將來重複使用。
如果您在離開一段時間後與 LLM 進行對話，或者其他查詢需要參考相同的「上下文」（編碼助手對相同程式碼庫的連續查詢或關於長文件的多個問題），則可能會發生這種情況。從磁碟載入 KV 快取的速度可能比重新計算更快，並且可釋放運算資源來產生更多輸出詞元。
業界仍在開發此工作流程，有大量研發工作專注於優化這些程序。MLPerf Storage 工作組（除其他外）正努力開發並定義基準測試程序，以表示 KV 快取管理層及其與儲存裝置互動的方式。
我們的初步分析表明，工作負載主要是大型傳輸 (2MB+)，寫入吞吐量高，這在快取系統中很常見。在高吞吐量 GenAI 系統中，KV 快取產生速率可達每天每 GPU 數十 TB 以上。
這推動了注重最佳化底層系統耐用性的儲存裝置需求（過度配置、SLC、TLC 和 QLC 的比較、彈性資料放置等）。
您希望深入瞭解嗎？
如需深入瞭解使用 KV 快取儲存裝置，請查看 Ugur Kaynar (Dell) 在 SDC 上的演講：卸載 KV-cache 儲存裝置實現 LLM 有效推論。Ugur 也為 MLPerf Storage 工作小組在 v2.0 開發週期的多個領域做出貢獻。
請閱讀我上一篇討論 KV 快取管理細節的部落格文章，其中一些數字清楚說明了為何 KV 快取是一個重要主題。一百萬個詞元的上下文：好人、壞人和小人。
AI 系統儲存裝置的未來
在我們尋求對當今 AI 系統的儲存裝置進行基準測試及特性分析時，未來需求的前景一片光明。如果您有興趣追蹤 AI 儲存裝置的前沿領域，請查看 SDC 的以下演講：
John Mazzie（美光）：小粒度圖神經網路訓練與儲存裝置的未來
John Groves（美光）：Famfs：為大型分散共享記憶體池做好準備
CJ Newburn 與 Wen-Mei Hwu （Nvidia）：儲存裝置對新一代 AI 應用程式的影響
