
AdobeがGTCで明かしたGPUのデータ待ち
Adobeが初期に行った学習では、GPU時間のおよそ2/3がデータ待ちで費やされていました。 GPU使用率は、GPUが実際に計算している時間の割合を指します。
計測結果はGTCで公開されました。GTCはNVIDIAが開く開発者向けのカンファレンスです。CTO(最高技術責任者)のGreenfield氏は、最先端の生成AIモデルをゼロから作ってきた3年間の道のりを、この場で語りました。
2/3という数字は、初期の学習を計測した結果だとBackblazeの記事は伝えています。Greenfield氏は会場で、学習に100万ドル(約1億5,970万円)を投じていたなら60万ドル(約9,581万円)は計算をしていないGPUに消えていた、と述べました。
Backblazeは、この数字を言い換えています。GPUの計算に使った費用のうち、約60%が無駄になっていたという表現です。
初期の学習実行で発生していたこと
| 指標 | 値 |
|---|---|
| データ待ちに使われたGPU時間 | 約2/3 |
| 100万ドル(約1億5,970万円)あたりの無駄 | 約60万ドル(約9,581万円) |
| 計算費用に占める無駄の割合 | 約60% |
表の数値はいずれも、GTCの講演をBackblazeの記事が伝えたものです。講演のページは、NVIDIA On-Demandに掲載されています。セッション名は「Build Custom Large-Scale Generative AI Models」、IDはS82197です。
"At NVIDIA’s GTC conference , Adobe’s CTO Ely Greenfield walked the audience through the company’s three-year journey building frontier generative AI models from scratch."/"It revealed that roughly two-thirds of GPU time was spent simply waiting for data."/"“If we were putting a million dollars into training,” he told the room, “that was $600,000 we were burning away on GPUs sitting and doing nothing.” In other words, roughly sixty cents of every dollar spent on GPU compute was being wasted."(冒頭)— Backblaze より公式情報を見る →
分散学習でストレージの供給はGPUのボトルネックなのか
Greenfield氏のチームは、無駄の原因を2つ突き止めました。 どちらもAdobeだけの問題ではありません。Adobeの学習では、ストレージからGPUへのデータ供給が1つ目のボトルネック(全体の速さを抑えてしまう部分)でした。
1つ目は、データが十分に速くGPUへ届かないことです。2つ目は、届いたデータの仕事量が各GPUへ均等に割り当てられないことです。
Adobeは、多数のGPUに作業を分担させて1つのモデルを学習させる分散学習を行っていました。その学習では、ストレージ側に次の負担がかかっていました。
- 学習データはペタバイト級の分散クラウドストレージにあり、数千基のGPUへ標準的なイーサネット(一般的なLANで使われる通信規格)で絶えず送信する必要があった
- チェックポイント(学習途中の状態を保存したデータ)の書き込みと読み出しにも、GPU時間を使っていた
チェックポイントのほとんどは、二度と必要になりませんでした。それでも書き込みと読み出しの費用は、使われても使われなくてもかかったとのこと。
Adobeは標準的なイーサネットを、高性能なネットワークファブリック(多数の機器を高速に接続する通信の仕組み)へ置き換えました。このファブリックは、ペタバイト級の分散AI学習で生じる通信量に合わせて設計されたものです。
"Greenfield’s team traced the waste to two culprits, neither of which is unique to Adobe: whether data can reach your GPUs fast enough, and whether the work it represents is distributed evenly once it arrives."/"Adobe’s training data lived in petabytes of distributed cloud storage and had to be shipped out to thousands of GPUs constantly, over standard Ethernet."/"Most of those checkpoints were never needed again. But writing and reading them still consumed real GPU time, which cost a lot of money whether they were used or not."/"they replaced standard Ethernet with a high-performance networking fabric designed for the petabyte-scale traffic distributed AI training generates."(Culprit #1 節)— Backblaze より公式情報を見る →
データ並列でも処理量が偏り、データローダーを自作
2つ目の原因は、等分したデータでも処理量が偏ることです。Adobeはデータローダーを自作して対処しました。Adobeはもともと、同じモデルを複数のGPUに置いて別々のデータを流すデータ並列という方式で学習していました。
Adobeのパイプライン(学習データをGPUへ流す一連の仕組み)は、データ並列を素直に使ったものでした。学習データを等しい大きさの塊に切り、クラスタ(GPUの集まり)の各GPUへ1つずつ割り当てていたのです。ところが、塊の大きさがそろっていても仕事量は同じではなく、受け取った素材によってGPUごとの処理時間は次のとおり異なりました。
等しい大きさの塊でも処理時間は揃わなかった
| GPUが受け取った素材 | 処理にかかった時間 |
|---|---|
| 単純で低解像度の素材 | 数秒 |
| 大きく複雑なファイル | 数分 |
Adobeは、データローダー(学習データをGPUへ供給するプログラム)を自作しました。このローダーは、素材ごとの処理コストを把握したうえで、全GPUがほぼ同時に終わるように仕事を割り当てます。Backblazeの記事は、ローダーはデータが届いた後の処理を改善するもので、データが届くかどうかはストレージ次第だとしています。
"Their pipeline used a straightforward data-parallelism approach: slice the training data into equal-sized chunks and assign one chunk to each GPU in the cluster."/"But equal-sized chunks weren’t equal work. Some GPUs got simple, low-resolution assets that processed in seconds; others got large, complex files that took minutes."/"They custom-built a balanced data loader that understood the processing cost of each asset and distributed work so every GPU finished at roughly the same time."/"The loader optimizes what happens once data is there, but storage determines whether it’s there at all."(Culprit #2 節)— Backblaze より公式情報を見る →
データパイプラインの改善でGPU使用率はどこまで上がるのか
2つの原因に対処した後、AdobeのGPU使用率はおよそ80%まで上がりました。 具体的には、標準的なイーサネットをネットワークファブリックへ置き換え、データローダーを自作しました。
数千基を同時に稼働させるときは、機器どうしの調整にオーバーヘッド(余分にかかる時間や手間)が必ず生じます。Backblazeの記事は、この調整分を考慮に入れると80%は実用上の上限に近いとしています。
対処の前後
| 状態 | 計測結果 |
|---|---|
| 初期の学習実行 | GPU時間の約2/3がデータ待ち |
| 2つに対処した後 | 使用率は約80% |
バランス型のデータローダーを作るには、相応の工数がかかります。Backblazeの記事によると、ストレージのボトルネックをまだ解消できていないチームは、ローダーの作り込みまで手が回らないことが多いとのこと。作り込みには次の作業が含まれます。
- 作業負荷の計測
- 分配方式の検証
- 全GPUがほぼ同じ速さで終わるまでの調整
"After addressing both culprits, Adobe’s GPUs ran at roughly 80% utilization. After accounting for the coordination overhead inherent to running thousands of machines together, 80% is close to the practical ceiling."/"And building something like Adobe’s balanced data loader takes real engineering investment, including time spent profiling workloads, testing distribution strategies, and tuning until every GPU finishes at roughly the same pace."/"Teams still fighting storage bottlenecks rarely get to that work."(From 40 to 80 cents 節)— Backblaze より公式情報を見る →
GPU使用率を下げた2つの原因は供給と分配
GPU使用率が上がらなかったAdobeの学習では、原因はデータパイプラインのうちストレージからの供給とデータローダーの分配にありました。 整理すると次のとおりです。
- 1つ目はストレージからの供給。標準的なイーサネットで数千基のGPUへデータを転送しており、高性能なネットワークファブリックへ置き換えた
- 2つ目はデータローダーの分配。等しい大きさに切ったデータの仕事量がそろわず、バランス型のデータローダーを自作した
- GPU使用率は、GPU時間の約2/3がデータ待ちだった初期の学習から約80%まで上がった
出所には注意が必要です。Backblazeはクラウドストレージの会社で、記事の後半は自社製品B2 Overdriveの訴求になっています。Adobeのような大規模な学習に使うGPU計算基盤の資金調達については、NVIDIAが金融6社と提携、5,000億ドル超の資金調達を目指すをご覧ください。
FAQ
- GPU使用率が上がらないのはなぜですか?
- Adobeの学習では、GPU時間の約2/3がデータ待ちで費やされていました。Greenfield氏は、学習に100万ドル(約1億5,970万円)を投じていたなら60万ドル(約9,581万円)は計算をしていないGPUに消えていた、と表現しました。
- 原因はいくつありますか?
- 2つです。データが十分速くGPUへ届くかというストレージ側の問題と、届いた後で仕事量が均等に割り当てられるかというデータローダー側の問題です。Backblazeの記事は、ローダーは届いた後の処理を改善するもので、届くかどうかはストレージ次第だとしています。
- 等分に切って割り当てればいいのではないですか?
- 大きさが等しくても仕事量は等しくなりません。Adobeでは、単純で低解像度の素材を受け取ったGPUは数秒で処理を終え、大きく複雑なファイルを受け取ったGPUは数分かかりました。
- 対処するとどこまで上がりますか?
- Adobeの場合は約80%です。Backblazeの記事は、数千基を同時に稼働させるときの調整のオーバーヘッドを考えると、80%は実用上の上限に近いとしています。



