デザインツール
ストレージ

NVIDIAのテクノロジーを使用してBaMを追求するMicron 9400 NVMe SSD

ジョン・マジー | 2024年1月

データセットの学習規模は、数十億のパラメーターを超えて拡大し続けています。大型化したモデルは、システムメモリに収まらない場合があります。このような場合、データローダーはさまざまな方法でフラッシュストレージに置かれたモデルにアクセスする必要があります。その方法の1つがSSD上で保存されるメモリマップドファイルであり、これにより、データローダーはファイルがメモリにあるかのごとくアクセスできますが、CPUとソフトウェアスタックのオーバーヘッドが学習システムのパフォーマンスを大幅に低下させます。そこで必要になるのが、Big accelerator Memory(BaM)*とGPU-Initiated Direct Storage(GIDS)*データローダーです。

BaMとGIDSとは何ですか?

 

BaMは、SSDの低レイテンシー、極めて高いスループット、高密度、および耐久性を活用するシステムアーキテクチャーです。BaMの目標は、GPUスレッドがSSDのデータセットにきめ細かくアクセスできるよう効率的な抽象化を提供し、GPUのストレージ要求においてCPUを使うソリューションよりも圧倒的に優れたパフォーマンスを提供することです。BaMの加速化には、特にストレージデバイスに直接アクセスするというGPUの内在的並行性を可能にするよう設計されたカスタムストレージドライバーを使用します。BaMはGPUからSSDへの通信を作成する際にCPUに依存する必要がないため、NVIDIA Magnum IO™ GPUDirect®ストレージ(GDS)とは異なります。

マイクロンにはこれまでもNVIDIA GDSと連携した実績があります。

GIDSデータローダーはBaMのサブシステム上に構築され、GPU-accelerated Graph Neural Network(GNN)学習用のメモリ容量要件に対処すると同時にストレージのレイテンシーをマスキングします。GIDSはSSD上のグラフの特徴データを保存することでこれを達成します。このデータは通常、大型グラフのグラフデータセット全体の最も大きな部分を占めるからです。特徴データよりも一般的にはるかに小さいグラフ構造データは、システムメモリに固定され、高速GPUグラフサンプリングを可能にします。最後に、GIDSデータローダーは、ストレージアクセスを減少させるため、最近アクセスされたノードに関してGPUメモリにソフトウェア定義のキャッシュを割り当てます。

GIDSを使ったグラフニューラルネットワーク学習

 

BaMとGIDSのメリットを示すため、私たちはIllinois Graph Benchmark(IGB)のヘテロジニアスフルデータセットを使用して、GNN学習を実行しました。このデータセットのサイズは2.28TBで、大半のプラットフォームのシステムメモリに収まりません。私たちは単一のNVIDIA A100 80GB Tensor Core GPUを使用して学習時間を100イテレーションに設定し、図1および表1に示すように、SSDの数を変化させて幅広い範囲の結果を求めました。

図1:IGB-ヘテロジニアスフルデータセットのGIDS学習時間 - 100イテレーション

 

 

GIDS(4 SSD)

GIDS(2 SSD)

GIDS(1 SSD)

DGLメモリマップの抽象化

サンプリング

 4.75

 4.93

 4.08

 4.65

特徴集約 

 8.57

 15.9

 31.6

 1,130

学習

 1.98

 1.97

 1.87

 2.13

エンドツーエンド

 15.3

 22.8

 37.6

 1,143

表1:IGB-ヘテロジニアスフルデータセットのGIDS学習時間 - 100イテレーション


学習の最初の部分は、GPUによるグラフサンプリングとシステムメモリ内のグラフ構造データへのアクセスによるグラフサンプリングです(青で表示)。システムメモリに保存されている構造はこれらのテスト間で変化しないため、この値は異なるテスト設定間で大きな変化は見られませんでした。

もう1つは実際の学習時間です(右端に緑色で表示)。この部分はGPUに大きく依存し、予想どおり、複数のテスト設定間で大きな変化は見られませんでした。

最も重要な部分は特徴集約で、ここに大きな変化が見られました(金色で表示)。このシステムでは、特徴データはMicron 9400 SSDに保存されており、Micron 9400 SSDを1枚から4枚に増やすと特徴集約の処理時間が大きく向上(削減)したことがわかります。SSDを1枚から4枚に増やすと、特徴集約は3.68倍向上しました。

私たちはまた、ベースライン計算で特徴データにアクセスする際にメモリマップの抽象化とDeep Graph Library(DGL)データローダーを使いました。この特徴データへのアクセス方法は、GPUによる直接アクセスの代わりにCPUソフトウェアスタックの使用が必要となるため、学習中にGPUの飽和状態を維持するにはCPUソフトウェアスタックがいかに非効率的であるかわかります。ベースラインに対する特徴の抽象化の向上は、GIDSを使用した1枚のMicron 9400 NVMe SSDでは35.76倍、4枚のMicron 9400 NVMe SSDでは131.87倍でした。他の視点からこのデータを見たものとして、図2と表2にこれらのテストの実行中における有効帯域幅とIOPSを示しました。

図2:GIDS学習対ベースラインの有効帯域幅とIOPS

 

 

DGLメモリマップ

GIDS(1 SSD)

GIDS(2 SSD)

GIDS(4 SSD)

有効帯域幅(GB/s)

0.194

6.9

13.8

25.6

達成したIOP(M/s)

0.049

1.7

3.4

6.3

表2:GIDS学習対ベースラインの有効帯域幅とIOPS


データセットが拡大するにつれ、合理的な時間内にモデルを訓練し、主要GPUが提供する改善を活用するためには、パラダイムシフトが必要であることがわかります。BaMとGIDSは出発点として優れており、私たちは今後もこのタイプのシステムが増えて活用できるようになることを期待しています。

テストシステム

 

コンポーネント

詳細

サーバー

Supermicro® AS 4124GS-TNR

CPU

2x AMD EPYC™ 7702(64 Core)

メモリ

1 TB Micron DDR4-3200

GPU

NVIDIA A100 80GB

メモリクロック:1512 MHz

SMクロック:1410 MHz

SSD

4x Micron 9400 MAX 6.4TB

OS

Ubuntu 22.04 LTS、Kernel 5.15.0.86

NVIDIA Driver

535.113.01

ソフトウェアスタック

NVIDIA Dockerコンテナで動作するCUDA 12.2、DGL 1.1.2、Pytorch 2.1


参考資料のリンク


BaMに関する論文とGitHub
GPU-Initiated On-Demand High-Throughput Storage Access in the BaM System Architecture (arxiv.org)
GitHub - ZaidQureshi/bam

GPU Initiated Direct Storageに関する論文とGitHub
Accelerating Sampling and Aggregation Operations in GNN Frameworks with GPU Initiated Direct Storage Accesses (arxiv.org)
GitHub - jeongminpark417/GIDS
GitHub - IllinoisGraphBenchmark/IGB-Datasets: Largest real-world open-source graph dataset - Worked done under IBM-Illinois Discovery Accelerator Institute and Amazon Research Awards and in collaboration with NVIDIA Research.

*注:NVIDIA Big Accelerator Memory(BaM)とNVIDIA GPU Initiated Direct Storage(GIDS)データローダーはNVIDIA Researchによるプロトタイププロジェクトで、一般向けリリースは予定されていません。

MTS, Systems Performance Engineer

John Mazzie

John is a Member of the Technical Staff in the Data Center Workload Engineering group in Austin, TX. He graduated in 2008 from West Virginia University with his MSEE with an emphasis in wireless communications. John has worked for Dell on their storage MD3 Series of storage arrays on both the development and sustaining side. John joined Micron in 2016 where he has worked on Cassandra, MongoDB, and Ceph, and other advanced storage workloads.