AIワークロードのI/O要件を理解する

ビデオ書き起こし

この書き起こしは、明確性と簡潔性を得るために編集されています。

ロジャー・コーレル: こんにちは、ロジャー・コーレルです。 ソリューション・マーケティングおよびコーポレート・コミュニケーションのディレクターです。 今日は、カルティック博士にお越しいただいています。まずは、カルティック博士、このソリダイムとのディスカッションに参加していただきありがとうございます。人工知能にとってのストレージの重要性と、AIパイプラインにおける5つの異なるフェーズ（取り込み、データ準備、モデル・トレーニング、モデル・チェックポイント、推論）に対する、VAST Dataの見解についてお聞きしたいと思います。 これらの各々のフェーズについて、各フェーズのI/O特性、これらのI/O特性によって各フェーズにもたらされるストレージの課題について、少しだけ説明していただけますか？

スブラマン・カルティック博士: もちろんです。ご想像の通り、実際のデータの取り込みは、完全にライトにバウンドされています。外部ソースからデータを取得することになります。 一般的に、公開されている初期トレーニングセットから始める場合は、クラウド・リソースから始めることができます。 企業内の内部ソースからである可能性もあります。この場合、より従来のETL的なプロセス¹になります。これらはインバウンドの書き込みが多く、本質的にシーケンシャルになりがちで、これはみなさん²が得意とする分野でしょう。私達も非常に得意としています。しかし、実際のデータ準備は、正直言って、かなり苦痛です。

データは汚れていることが多く、何らかの正規化を経る必要があるからです。 不良データは調査する必要があります。 ここには非常に複雑なパイプラインが通っています。このパイプラインは、CPUに大きく依存しています。 そのため、大量の読み取りと書き込みがありますが、実際にはI/Oにバウンドされるのではなく、CPUにバウンドされています。 協力するタスクもしばしば発生します。ですからワークロードは、ビュー・クラスターというよりは、HPCクラスターのように見えます。 

コーレル: データ準備段階では、リードとライトについて言及されましたね。 たしかに書き込みもいくつかありますが、以前にはたくさんのデータを読み込んでいるとおっしゃっていたと思います。ETLやデータクレンジング、正規化などのプロセスを経て、最終的に書き戻すデータは、読み込むデータよりもはるかに少ない量になります。

カルティック博士: その通りです。 書き込むデータの量は読み込むデータほど多くはなりません。リードが主流になる傾向にあります。これについては疑問の余地はありません。しかし、処理においては、いくぶんシーケンシャルな傾向があります。 特にこのフェーズではそうです。 これは、トレーニングで目にするものとまったく対照的です。 

トレーニングでは、I/Oパターンはランダムです。 データをモデルに提示する方法をランダム化する必要があるため、I/Oをランダム化します。理由は非常に簡単です。 モデルは非常に賢いです。 同じデータを同じ順序で見せると、どうすると思いますか？データの順序を記憶するんです。 これは非常にGPUにバウンドされています。 理由は、モデルが膨大で、複数のGPUに分散する必要があるからで、それに伴うディープ・パイプラインがあります。 データを並列化するために使用される非常に興味深いテクニックです。 GPU全体でモデルを並列化することは、複数のGPUサーバー全体でパイプラインを並列化することであり、最終的には、これらのパイプラインとモデルセットの各クラスターがデータの一部を処理できるように、データアクセスを並列化することになります。非常に読み取り負荷が高くなります。GPUに取り込まれるデータが膨大だからです。I/Oの観点からは理不尽なことではありませんが、いったんデータがGPUに取り込まれると、ここで発生する必要のあるGPU作業が山ほど発生し、GPUバウンドになりがちです。トレーニング・フェーズの出力は、そのままでは単なるモデルそのものです。一連の数字です。 バッチ処理の方法は、私が話したハイパーパラメーターの1つです。バッチサイズがどのくらいの大きさになるかです。これは通常、モデルサイズやGPUの数、モデルの導入、そしてその方法によって異なります。 それに伴う最適なバッチサイズもあります。 512トークンほどの小さいものであることもあります。 ここにあるように、数千のトークンになる可能性もあります。 しかし、基本的にはデータを塊で取り込むことになります。そして、それを処理して、次のセットを塊で取り込みます。通常は、データローダーやPyTorchのレベルで設定します。もしこれが取り組んでいるフレームワークであるならです。  そしてこれは、大規模な言語モデルのトレーナーが、何よりも最適化しておきたいパラメータです。 そのため、ストレージには実質的な影響はありません。 トレーニング中にストレージから読み出されるパターンであり、チェックポイント中ではありません。チェックポイントは大きなブロックのシーケンシャル書き込みであり、1GPUあたり1スレッドです。そういう仕組みです。トレーニングでは、システムに読み込まれる大量のリードが見られます。 場合によっては、システムがその一部をプリフェッチしてメモリに貼り付けることで、次のバッチがすでにステージングされ、メモリ上で準備できていることがあります。しかし、どんな場合でも、1秒あたり10ギガバイト、1秒あたり50ギガバイトの読み取りが持続することはめったにありません。 散発する読み取りの塊が見られるでしょう。

コーレル: チェックポイントに移りましょう。

カルティック博士: そうですね。チェックポイントに移り、チェックポイントがどういうものかについて話しましょう。 ロジャーさん、不都合な真実があります。常にうまくいくわけではないんです。

コーレル: そうですね。

(笑) カルティック博士: 悪いことが起こることもあります。どんな悪いことが起こるのでしょうか？ 2000台のGPUのうちの1台のGPUが故障します。それは困りますね。または、メモリ・エラーが発生します。 なんてことだ。いいですか？非常に良くないですね。何かがクラッシュします。 ソフトウェアの問題が発生します。バグが生じます。サーバーボックスがまずいことになります。そうなったら、トレーニング全体が中断されるだけでなく、非常にピンチな状態です。GPUクラスター全体で1つ以上のメンバーが突然消えてしまったために、すべてを失うことになります。この時点で、この作業は時間がかかるものになります。韓国のある企業では、2000台以上のV100 GPUを使って、ハングル文字のGPT3を6カ月かけてトレーニングしていました。トレーニングを6カ月です。1つの仕事のために、6カ月連続でトレーニングするんです。

コーレル: それでチェックポイントというのは、さっきも言及した思いますが、チェックポイントは頻繁に発生するんですよね？ NVIDIAは、4時間間隔を推奨しているのではないでしょうか？ そのくらいだったと思うのですが。

カルティック博士: 以前はそれを推奨していました。今では、もう少し頻繁なものになり始めていますが、これはエンドユーザーによります。 4時間おきかもしれません。 1時間おきかもしれません。30分おきかもしれません。 どんな間隔であれ、重要なのは、チェックポイントでは、モデルとパイプラインの実行中の状態全体がディスクファイルにキャプチャされるという点です。  そして、あらゆる種類の壊滅的な出来事から戻らなければならないとき、あるいは前のステージに戻らなければならないときもあります。モデルのトレーニングが計画通りに進んでおらず、前述したハイパーパラメータの1つを調整してモデルを収束させる必要があるときなどには、チェックポイントが絶対に必要になります。 チェックポイントに関しては、簡単な目安があります。パラメータごとに14バイトがチェックポイントのサイズとなり、これがチェックポイントのステータスです。

GPT 3のような1,750億のパラメータ・モデルがある場合、チェックポイントのステータスは2.4テラバイトになります。 5,000億のパラメータ・モデルの場合、チェックポイントのステータスは7テラバイトになります。 このように計算できます。関係性は直線状です。 チェックポイントのたびに、それだけの量のデータをダンプする必要があります。 ですから、GPT 3のチェックポイントは2.4テラバイトになります。これをディスクに書き込む必要があります。 そして、かなり高速にする必要があります。

コーレル: なるほど。 GPUは書き込み中にアイドル状態になりますからね。 

カルティック博士: そうです。アイドル状態になります。 また、これは、NVIDIAが非常に好むモデルなど、特定の導入モデルに固有のものです。一般的には、非同期チェックポイントを利用し始めるところもあります。ですが、ここでは同期チェックポイントのことであり、データをダンプするとジョブが停止します。 ですから、可能な限り迅速にこれを行うことが、すべての人にとって非常に重要になります。 大量の容量を生成しますから、チェックポイントの頻度には注意する必要があります。 そしてチェックポイントでは、できるだけ効率的に実行した方がよいでしょう。NVIDIAからの基本的な目安では、チェックポイントの時間は、チェックポイント頻度の合計時間の5%以下にするべきとされています。ですから1時間に1回チェックポイントを行うのであれば、1時間のうち5％のみをチェックポイントに費す必要があります。いくつになりますか？コーレル: 3分です。

カルティック博士: 3分ですね。 3分でチェックポイントを実行できるはずです。 ここで、簡単な計算をします。 3分で2.4テラバイトを書き込む必要があります。 なんてことだ。数値が出ましたね。これが、必要な帯域幅です。 

コーレル: スループットもあります。

カルティック博士: スループットもありますね。 コーレル: はい。 良い説明です。 次に進む前に、チェックポイントについて他に何かありますか？ 

カルティック博士: ええ。 重要なのはチェックポイントだけではありません。 チェックポイントは、復元できてこそ初めて意味があります。 コーレル: リードについてですね。

カルティック博士: ええ。 チェックポイントは、トレーニングに参加しているGPUのサブセットによってのみ行われるため、読み込みは書き込みよりもずっとずっと負荷が激しくなります。復元は、すべてのGPUに対して100％行われます。 この数値は、モデルのサイズやいくつかのパラメータによって異なりますが、一般的に、私が行った計算では、リードとライトの比率はおよそ8対1でした。ですから、3分で2.4テラバイトを書き込む場合3分程度で復元したい場合は、8倍の速度で読み込んで復元する必要があります。 ですから、リードの負荷は非常に高くなります。  これは、VASTアーキテクチャーに非常に適しています。なぜなら、当社のリードは、ライトよりもはるかに優れているからです。 ライトが悪いというわけではありませんが、リードが非常に優れているのです。  また、ソリディグムのおかげで、リードの耐久性に影響がありません。NANDの耐久性機能に影響を与えることなく、必要なだけのリードを実行できるので、非常に優れています。  もう1つの気付くべき点は、チェックポイントと復元が非常に非対称であるということです。 復元は、チェックポイントよりもはるかに負荷が高くなります。チェックポイントでは適切な帯域幅が必要ですが、チェックポイントの周波数に大きく依存します。 注意深く確認して計算してください。 非常に良い小さなサイズがありますので、もし本当に必要であれば喜んで皆さんと共有します。コーレル: チェックポイントについて説明していただきありがとうございます。 では、最後のフェーズである推論に移りましょう。 

カルティック博士: 推論は GPU に依存しないため、推論はさまざまな点で興味深いものです。なぜでしょうか？なぜなら、トレーニングでは、ニューラル・ネットワーク、モデル、およびいわゆるフォワード・プロパゲーション・パスを通じてデータを移動してから、重みを再調整するためにモデルにデータを戻す必要があるからです。これはバック・プロパゲーション・パスと呼ばれます。  推論はフォワード・パスのみであるため、非常に高速で簡単です。 これは、非常にI/Oにバウンドされる傾向にあります。 実際、CPUとGPUが飽和するまでは、好きなだけデータを送り続けることができますが、GPU上で待機することはありません。GPUはストレージ上で待機します。 ですが、特徴は同じです。推論はほぼ100%がリードです。 そして通常は、非常に高いスループットのリードが発生します。大きな画像では特にです。まれに、モデル自体が画像を出力することもあります。例えば、安定した拡散モデルは、画像を生成したり、ビデオを生成したりします。 GPUは、書き出すイメージを構築しなければならないため、ある程度GPUにバウンドされる傾向にあります。書き込みではありますが、ライトにバウンドされているというわけではありません。 リードでは、非常に多くデータを処理できるため、皆さんにも私にも非常に適しています。 

コーレル: ありがとうございました。 楽しいお休みをお過ごしください。ありがとうございました。

カルティック博士: ええ、光栄です。お招きいただきありがとうございました。 注 [1] ETLは、複数のソースからのデータを1つのデータウェアハウス・リポジトリに結合するプロセスを指します。 ETLの略語は、Extract (抽出)、Transform (変換)、Load (ロード)を意味します。  このプロセスでは、生のデータをクリーンアップして整理し、ストレージ、データ分析、機械学習用に準備するルールセットを使用します。

[2] これは企業であるソリダイムと、VAST DataがAIアプリケーションで使用するソリダイムのSSDを指しています。