設計工具
應用程式

建構系統以實現更高效的 AI 模型訓練

Wes Vaske | 2019 年 6 月

如何建構系統以實現更高效的 AI 模型訓練

2018 年 12 月,Intel、Google 和 NVIDIA 提交了 MLPerf 的首個基準測試結果。這些結果衡量了不同的機器學習算法在提交者的各種硬體上的效能,並以訓練到準確率閾值所需的時間來表示。不過,即使這些提交報告提供了豐富的資訊,官方程序在描述主要運算資源之外的系統方面仍有一定的欠缺。

有鑑於此,我一直在美光儲存裝置客戶實驗室執行相同的基準測試,以更加瞭解深度學習訓練對系統資源的壓力。在美光,我們一直在追求記憶體和儲存裝置創新,以便在移動、存取和分析資料方面實現長足進步。本貼文將概述我的發現,並且我們將很快公佈更多結果。

我用來進行這些測試的系統是一台 SuperMicro SYS-4029GP-TVRT 伺服器。這是一台 8 GPU 伺服器,其 GPU 運算效能與 NVIDIA DGX-1 幾乎相同。主要規格如下:

  • 2 個 Intel Xeon Platinum 8180M CPU
    • 28 核心 @ 2.5 GHz
  • 3TB Micron DRAM
    • 24 條 128GB DDR4 2666 MHz DIMM
  • 8 個 NVIDIA V100 GPU
    • SXM 規格尺寸
    • 每個 GPU 32GB HBM2 記憶體
    • GPU 之間透過 NVLink Cube Mesh 互連
  • 8 塊 7.68TB 美光 9300 Pro NVMe 硬碟,採用 RAID-10 配置,用於儲存資料集

作業系統為 Ubuntu 18.04.2,已安裝所有更新,測試使用 NVIDIA 為其 v0.5.0 版提交報告所提交的代碼中定義的 docker 容器執行。

我想回答的第一個問題是,MLPerf 提交報告是否具有可再現性。由於 MLPerf 仍在全力研發中,因此證明結果可再現是過程中的重要一步。

MLPref 結果

我自己的測試結果證實了 NVIDIA 提交的結果。這並不令人驚訝或具有突破性,但卻非常重要。

在深入瞭解實際結果之前,讓我先簡單介紹一下我對這些應用程式進行基準測試的過程。由於可用於基準測試的資料集較小,我限制了容器在訓練期間可存取的記憶體容量,以確保檔案系統快取不包含完整的資料集。如果我不限制記憶體,應用程式會在第一個訓練週期將資料集讀入記憶體,然後所有後續週期都會從檔案系統快取中獲取資料,而不是從磁碟讀取資料。

雖然這是執行應用程式的理想方式——有足夠的記憶體來容納整個資料集——但並不現實。基準測試所使用的最大資料集是用於影像分類基準測試的 ImageNet 資料集,其容量高達 136GB。在美光,我們用於訓練的資料集有幾 TB 大小,而且我們也從客戶那裡瞭解到同樣的情況:生產資料集比這些基準測試中使用的資料集大很多。

雖然我無法改變這些基準測試所使用的資料集,但我可以改變系統的配置方式,使結果更能代表我們在現實世界中看到的情況。

讓我們看看限制容器記憶體是否有效。在不限制記憶體的情況下,我看到的平均磁碟吞吐量幾乎可以忽略不計。但是,一旦限制了每個容器的記憶體容量,使得記憶體只能容納資料集的一小部分。我看到了截然不同的磁碟利用率:(注意,這兩張圖表中縱軸的刻度不同)

無限記憶體與有限記憶體的平均磁碟吞吐量對比圖

對於影像分類,在限制了容器的記憶體容量後,磁碟利用率提高了 61 倍。(這很有道理,因為訓練過程長達 62 個週期,而無限記憶體配置只需要在第一個週期從磁碟讀取資料。)

好了,我們知道限制容器的可用記憶體會改變磁碟利用率,但這對訓練過程的效能有什麼影響呢? 事實證明,只要儲存裝置速度足夠快,對應用程式的影響可以忽略不計:

MLRef 結果

這個結果比最初看起來要重要得多。我們已經證明,只要您的儲存裝置在訓練過程中跟得上,即使由於資料集過大,本地記憶體無法容納,您也能充分利用 GPU(取決於軟體棧)。

在介紹了儲存裝置之後,讓我們來看看系統的其他部分:

CPU 利用率

這裡列出的 CPU 利用率是非標準化的利用率。這意味著 500% 大約相當於 5 核心 100% 的利用率(或 10 核心 50% 的利用率)。

執行這些以 GPU 為中心的應用程式仍會對訓練伺服器的 CPU 造成壓力。根據您的應用程式,這些資料可能暗示您可以節省 CPU 的用量,也可能表明您需要投資頂級 CPU。無論如何,請務必瞭解您的工作負載,以便對 AI 訓練伺服器進行最佳架構設計。

GPU 核心記憶體利用率圖

在 GPU 利用率方面,我們看到 GPU 處理器利用率普遍較高,但記憶體利用率可能相當低,具體取決於基準測試。不過,我建議謹慎對待 GPU 記憶體利用率資料。我認為記憶體利用率主要受總資料集大小的影響。雖然我可以限制容器的可用總記憶體,但無法限制 GPU 記憶體。

這些算法在訓練中使用的參數經過調整,確保以最快的速度達到準確性。其中一個主要的可調整參數——批次大小——高度依賴於 GPU 可用記憶體以及資料集的總大小。這意味著,如果批次較小,不能充分利用 GPU 記憶體,那麼小資料集的訓練速度可能會更快,並且我估計在這裡也能看到這種效果。

我們已經探索了在單台伺服器上單獨執行 AI 應用程式的系統要求,雖然結果很有趣,並為我們提供了可用於架構系統的資訊,但這並不能說明問題的全部。在測試過程中,我將所有 MLPerf 資料集載入到 AI 訓練伺服器的本地儲存裝置中,總容量約為 400GB,然後依次執行每個訓練工作負載。

然而,在生產系統中,我們的訓練伺服器很少有足夠的儲存容量來容納所有訓練資料集。人工智慧伺服器中的本地儲存裝置經常被用作快取——將資料集載入到快取中,訓練模型,從快取中重新整理資料集。此外,對於一連串正在訓練的模型,下一個模型的資料集應在訓練前一個模型時載入。

循序與平行資料摘要

讓我們看看執行同步資料攝取時對基準測試結果的影響。對於以下資料,我降低了 MLPerf 基準測試的準確度要求,以便更快地完成每個訓練過程。這樣,我就可以使用不同的資料攝取參數進行更多的迭代測試。此外,我還將美光 5200 Pro SATA SSD美光 9300 Pro NVMe SSD 進行了比較(我在 RAID-10 配置中使用了 8 塊硬碟)。

首先,當我們未執行同步資料攝取時,NVMe 與 SATA 相比如何?

基準測試結果時間

單獨執行 AI 訓練工作負載時,SATA 和 NVMe 硬碟的效能非常相似。從上面的磁碟吞吐量資料來看,8x 5200 SATA 硬碟能夠提供足夠的效能以處理我們最密集的訓練工作負載(影像分類,速度為 1.2GB/s)。

現在,讓我們來看看在模型訓練時,我們能以多快的速度攝取資料。在下面的圖表中,我使用了 FIO 工具,利用「同步」IO 引擎和多個作業來生成檔案寫入內容。

資料攝取率

現在結果明顯不同;NVMe 支援在訓練人工智慧模型時大幅提高資料攝取率。這清楚地表明,NVMe 將支援上述平行資料攝取 + 模型訓練流程。不過,我們需要驗證這種重度攝取不會影響訓練過程的效能。

執行時間圖

從這張圖表中可以看出一些有趣的東西:

影像分類雖然是磁碟利用率最高的基準測試,但對在 SATA 或 NVMe 上同步進行的資料攝取並不敏感。
單級偵測器顯示,資料攝取對 SATA 造成了很大的效能衝擊——大約 30%。
相反,物體偵測基準測試在 NVMe 上的效能下降了約 7%,而在 SATA 上的效能保持不變。
這種行為的原因目前尚不清楚,但這並不妨礙我們探索如何減少效能損失。有兩個簡單方法可以嘗試減少效能損失:以更大的區塊大小(1MB 對 128k)進行攝取,以及限制攝取吞吐率。

讓我們看看這些方法在這裡提到的兩種情況下如何發揮作用。對於 SATA 上的單級偵測器,結果如下:

損失減輕圖

透過增加資料攝取的區塊大小,我們可以減少資料攝取造成的幾乎所有效能損失。

現在看看物體偵測基準測試:

物體偵測減輕圖

這裡的情況略有不同。我們透過增加區塊大小減輕了部分效能損失,但需要降低資料攝取率才能充分發揮應用程式效能。

那麼,我們學到了什麼?

  • 訓練 AI 模型不僅會對 GPU 造成壓力,還會對儲存裝置、系統記憶體和 CPU 資源造成壓力。架構 AI 系統時,一定要考慮到這些因素。
  • 與企業級 SATA SSD 相比,美光 9300 PRO NVMe SSD 支援更高的資料攝取率,有助於實現平行資料科學管道
  • 重度資料攝取會對訓練模型的時間產生負面影響,而且與訓練模型的讀取吞吐量並不簡單相關。
  • 增加資料攝取的區塊大小或限制寫入吞吐率可以減少進行同步資料攝取導致的效能損失。

我們將繼續探討 AI 和資料科學應用程式的效能,以及如何為您的工作負載建構最佳解決方案。我們將在這裡發佈與這一不斷變化的生態系統有關的詳細資訊。

一個人邊走邊拿著筆記型電腦

SMTS Systems Performance Engineer

Wes Vaske

Wes Vaske is a principal storage solution engineer with Micron.