Login / Register
AIモデルのトレーニング効率を高めるためのシステムの構築方法
2018年12月に、Intel、Google、NVIDIAによってMLPerfの最初のベンチマーク結果が提出されました。これらの結果は、一定の精度に達するまでに必要なトレーニング時間の観点から、提出元のさまざまなハードウェアを使って各種の機械学習アルゴリズムのパフォーマンスを測定したものです。ただし、これらの結果は豊富な情報を提供しているにもかかわらず、公式のプロセスでは、主要なコンピュートリソース以外のシステムに関する記述がやや不足しています。
その点を考慮して、深層学習トレーニングがどのようにシステムリソースにストレスを掛けるかをより正しく理解するため、私はマイクロンのストレージカスタマーラボで、同じベンチマークを実行しています。マイクロンでは、データの移動、アクセス、分析に目覚しい改善をもたらす、メモリとストレージのイノベーションを追求しています。この記事では、これまでに得た所見について概要を説明します。近日中に、さらに新しい結果を追って公開する予定です。
これらのテストを実行するために私が使用したシステムは、SuperMicro SYS-4029GP-TVRTサーバーです。これは、NVIDIA DGX-1とほぼ同じGPUコンピュートパフォーマンスを持つ8-GPUサーバーです。主な仕様は以下の通りです。
- 2x Intel Xeon Platinum 8180M CPU
- 28コア @ 2.5 GHz
- 3TB Micron DRAM
- 24x 128GB DDR4 2666 MHz DIMM
- 8x NVIDIA V100 GPU
- SXMフォームファクタ
- GPUあたり32GBのHBM2メモリ
- NVLink CubeでGPU間をメッシュ相互接続
- 8x 7.68TB Micron 9300 Pro NVMeドライブ、RAID-10構成、データセット用
OSは、すべての更新を適用済みのUbuntu 18.04.2です。テストの実行は、NVIDIAが提出したコード（v0.5.0提出時）で定義されるドッカーコンテナを使用して行いました。
私がまず最初に答えを出したかった疑問は、MLPerf結果が再現可能なものなのかどうかです。MLPerfはまだ開発の真っ最中なので、これらの結果が再現可能であることを示すのは、このプロセスにおける重要なステップです。
私が自分で行ったテストの結果は、NVIDIAが提出した結果を裏付けるものでした。これは意外でも画期的でもありませんが、重要なことです。
実際の結果をご覧いただく前に、少し寄り道をして、これらのアプリケーションのベンチマーキングのため私が使用したプロセスの1つをご説明します。ベンチマーキングに使用可能なデータセットのサイズが小さいので、トレーニング中にコンテナがアクセスするメモリの量を制限し、データセット全体がファイルシステムキャッシュに収まらないようにしました。もしメモリの量を制限しなかったら、アプリケーションは最初のトレーニングエポックでデータセットをメモリに読み込み、後続のエポックでは、ディスクから読み取る代わりに、ファイルシステムキャッシュからデータを取り出すようになるでしょう。
これはアプリケーションを実行する方法としては理想的ですが（データセット全体が収まる十分なメモリを使用）、やや非現実的です。このベンチマークで使用される最大のデータセットは、136GBでクロックインする画像分類ベンチマーク用のImageNetデータセットです。マイクロンにはトレーニング用の数テラバイトのサイズのデータセットがあり、これらのベンチマークで使用されるデータセットよりも、実働データセットのほうがかなり大きいことは、お客様からもよく言われることです。
これらのベンチマーク用のデータセットは変更できませんが、より現実に近い結果を得るために、システムの構成を変更することはできます。
コンテナメモリの制限が、目的通りに作用したかどうかを見てみましょう。メモリを制限しない状態では、ほぼ無視できる程度の平均ディスクスループットが見られました。しかし、データセットのごく一部分しかメモリに収まらないように、各コンテナのメモリ容量を制限すると、まったく違ったディスク利用率が見られるようになりました（これら2つのグラフで、縦軸の目盛りが異なる点にご注意ください）
Image Classificationに関しては、コンテナのメモリ容量を制限した後に、ディスク利用率が61倍も高くなっています。（トレーニングプロセスは62エポックの長さであり、制限しないメモリ構成では、ディスクから読み取る必要があるのは最初のエポックだけなので、これは非常に辻褄が合います。）
以上のように、コンテナが使用できるメモリを制限すると、ディスク利用率が変化することが分かりました。でも、これはトレーニングプロセスのパフォーマンスにどのように影響するのでしょうか？ 結局は、十分に高速なストレージを使用する限り、アプリケーションへの影響は無視できる程度であることが分かります。
この結果は、見かけ以上に重要です。上記の結果から、トレーニングプロセス中にストレージが遅れずに処理を続行できれば、データセットが大きすぎてローカルメモリに収まらない場合でも、（ソフトウェアスタックによっては）GPUをフルに利用できることが読み取れます。
以上、ストレージについて解明したので、次にシステムの残りの部分を見ていくことにしましょう。
ここに示すCPU利用率は正規化されていません。つまり、500%という値は、大まかに言うと、5個のコアが100%利用されている（または10個のコアが50%利用されている）状態に相当します。
これらのGPU特化型アプリケーションを実行すると、トレーニングサーバーのCPUにもストレスが加わる可能性があります。このデータは、実行するアプリケーションに応じて、CPUを節約しても構わないことを示唆している場合もあれば、トップエンドのCPUに投資する必要があることを示唆している場合もあります。それでも、AIトレーニングサーバーを最適に構築するには、ワークロードを確実に理解する必要があります。
GPU利用率に関しては、GPUプロセッサーの利用率は総じて高いのに対し、メモリ利用率は、ベンチマークによってはかなり低い場合があることが分かりました。ただし、GPUメモリ利用率データは、割り引いて解釈することをお勧めします。メモリ利用率は、主にデータセットの総サイズに影響されます。コンテナで利用可能な総メモリ容量を制限することはできましたが、GPUメモリは制限できませんでした。
これらのアルゴリズムのトレーニングに使用されるパラメーターは、必要な精度に最速で達するようにチューニングされています。チューニング可能な主要パラメーターの1つであるバッチサイズは、使用可能なGPUメモリと、データセットの総サイズによって大きく左右されます。つまり、小さいデータセットなら、GPUメモリをフルに利用しない小さいバッチサイズで、より速くトレーニングすることが可能です。ここで私たちが見ているのは、この作用だと思います。
以上、1台のサーバー上でAIアプリケーションを単独で実行する際のシステム要件を探ってきました。結果は興味深いものであり、システム構築に利用できる情報を提供してくれますが、全体像が見えたわけではありません。私はこのテストの実行にあたり、すべてのMLPerfデータセット（合計約400GB）をAIトレーニングサーバーのローカルストレージに読み込み、各トレーニングワークロードを順に実行しました。
しかし、実働システムでは、トレーニングサーバーにすべてのトレーニングデータセットを格納できる十分なストレージ容量があることはめったにありません。AIサーバーのローカルストレージは、キャッシュとして頻繁に使用されます。このキャッシュにデータセットを読み込み、モデルをトレーニングし、キャッシュからデータセットをフラッシュします。さらに、一連のモデルをトレーニングする場合、前のモデルをトレーニングしている間に、次のモデル用のデータセットを読み込む必要があります。
同時データ取り込みを実行する場合、ベンチマークにどのような影響があるか検証してみましょう。以下のデータについて、MLPerfベンチマークの精度要件を下げ、各トレーニングプロセスがより早く終わるようにしました。これにより、さまざまなデータ取り込みパラメーターを使用して、テストをより多く反復することができました。さらに、Micron 5200 Pro SATA SSDをMicron 9300 Pro NVMe SSDと比較しました（各ドライブを8個ずつRAID-10構成で使用しました）。
まず、同時データ取り込みを実行しない場合、NVMeはSATAと比較してどのような結果を示すでしょうか？
AIトレーニングワークロードを単独で実行する場合、SATAドライブとNVMeドライブは、非常によく似たパフォーマンスを示しています。この結果は特に意外ではありません。先ほど見たディスクスループットの数字から、8個の5200 SATAドライブには、最も集約型のトレーニングワークロード（1.2GB/秒のImage Classification）を十分に処理できるパフォーマンスがあることが簡単に推測できます。
次に、モデルのトレーニングと並行して、どれほど速くデータを取り込めるかを見てみましょう。以下のグラフ用に、複数のジョブのある「同期」IOエンジンを使用したファイル書き込みを生成するため、ツールFIOを使用しています。
今回は大きく異なる結果となっています。AIモデルのトレーニング中でも、NVMeは目覚ましく高いデータ取り込み速度を支えています。この結果から、前述した「データ取り込み」と「モデルトレーニング」の並行処理に、NVMeが明らかに対応可能であることが分かります。ただし、この大量の取り込みが、トレーニングプロセスのパフォーマンスに影響しないことを確認する必要があります。
このグラフから、いくつか興味深い事実が読み取れます。
Image Classificationはディスク利用率が最も高いベンチマークですが、SATAでもNVMeでも、同時データ取り込みには影響されていません。
Single Stage Detectorは、SATAの場合、データ取り込みによる大きなパフォーマンスヒット（約30%）を引き起こしています。
逆に、Object Detectionベンチマークは、NVMeでは約7%のパフォーマンスヒットを引き起こしましたが、SATAではパフォーマンスを維持しています。
なぜこうなるのか、理由は今のところ不明ですが、それでも私たちはパフォーマンス損失を軽減する方法を探ってみました。パフォーマンス損失を軽減するために簡単に試せる2つの方法は、より大きいブロックサイズ（128kではなく1MB）で取り込みを実行することと、取り込みスループット速度を制限することです。
上記2つのケースに対し、これらの選択肢がうまく行くかどうか見てみましょう。SATAでのSingle Stage Detectorについては、結果は以下の通りです。
データ取り込みのブロックサイズを大きくすることで、データ取り込みの実行によるパフォーマンス損失のほぼすべてを回避することができました。
一方、Object Detectionベンチマークは、
この場合、状況がやや異なります。ブロックサイズを大きくすることで、パフォーマンス損失が部分的に軽減されましたが、完全なアプリケーションパフォーマンスに達するには、取り込み速度を低くする必要がありました。
以上、私たちが学んだ教訓をまとめてみましょう。
- AIモデルのトレーニングは、GPUにストレスを掛けるだけでなく、ストレージ、システムメモリ、CPUリソースにもストレスを掛けます。AIシステムの構築に際しては、これらの点を考慮に入れる必要があります。
- Micron 9300 PRO NVMe SSDは、エンタープライズSATA SSDよりも著しく高いデータ取り込みに対応します。これは並行データサイエンスパイプラインの実現に役立ちます。
- 大量のデータ取り込みは、モデルのトレーニング所要時間に悪影響を及ぼす可能性があります。これはトレーニングの読み取りスループットと単純に相関するわけではありません。
- データ取り込みのブロックサイズを大きくするか、書き込みスループット速度を制限すると、同時データ取り込みの実行によるパフォーマンス損失を軽減できます。
私たちは今後も引き続き、AIおよびデータサイエンスアプリケーションのパフォーマンスについて調査し、お客様のワークロードに最適なソリューションの設計方法を解明していきます。この絶え間なく変化するエコシステムについて、さらに多くを学び、この場で発表します。
