AIトレーニングでGPUが無駄に待機状態になってしまっている理由とAdobeが行った対処とは？

NVIDIAが2026年3月に開催した開発者向けカンファレンス「GTC 2026」で、AdobeのCTOであるエリー・グリーンフィールド氏がカスタム大規模生成AIモデルを構築するまでの道のりやパイプラインについて講演を行い、初期のトレーニング実行時に数千基のGPUのうち約3分の2がアイドル状態となっていたことが明かされました。この問題について、クラウドストレージサービスを提供するBackblazeが解説しています。

Why GPUs Sit Idle: The AI Training Data Pipeline Problem
https://www.backblaze.com/blog/why-your-gpu-is-sitting-idle-the-data-pipeline-problem-no-one-talks-about/

Adobeは生成AIモデルをゼロから開発するため、数千基のGPUを利用した大規模な学習環境を構築しました。しかし、各GPUが実際の計算にどれだけの時間を費やし、どれだけの時間をアイドル状態に費やしていたかを正確に視覚化した「初期のトレーニング実行時のプロファイラ出力結果」を分析すると、GPU時間の約3分の2がアイドル状態(データの待ち時間)に費やされていたことが明らかになりました。

このアイドル時間にも、GPUを稼働させるコストがかかっています。グリーンフィールド氏は「もしトレーニングに100万ドル(約1億5900万円)を費やしていたとしたら、60万ドル(約9500万円)は何もせずに放置されたGPUに無駄に費やされていたことになります」と語りました。

AdobeはGPUがアイドル状態となった2つの原因を突き止めました。1つ目は「学習に必要なデータがGPUに十分な速さで到達できるかどうか」という点、2つ目は「データが到着した後、そのデータが表す作業が均等に分散されるかどうか」という問題で、どちらもAdobe特有の問題ではないそうです。

1つ目のデータの速度について、AdobeのAIトレーニングデータはペタバイト(約100万ギガバイト)規模の分散型クラウドストレージに保存されており、標準イーサネット経由で数千台のGPUに絶えず送信される必要がありました。データセット自体も膨大かつ多様で、画像や動画、低解像度や高解像度、シンプルなフォーマットから複雑なコーデックまで、あらゆるものが同時に転送されていました。

従来の標準ネットワークは、個々のファイルを要求に応じて取得するために構築されているため、このような持続的かつ並列的なペタバイト規模のデータ転送には対応していません。さらに、安全策としてトレーニング実行時には定期的にモデルの完全なコピーがストレージに書き込まれる「チェックポイント処理」を行っていましたが、これらのチェックポイントのほとんどは二度と必要になることはなかったにもかかわらず、書き込みと読み込みには実際のGPU時間が消費され、多額の費用がかかったとしています。

Adobeはこの問題を解決するため、まず標準的なイーサネットから、分散型AIトレーニングで発生するペタバイト規模のトラフィックに対応するために設計された高性能ネットワークファブリックに置き換えました。これにより、GPUが必要とする速度でデータを転送できるようになったとのこと。

加えて、チェックポイントの保存方法も変更しました。従来はモデル全体を1つの巨大なファイルとして書き込んでいましたが、モデルをより小さな断片に分割し、一度に複数の場所に保存するようにしました。これにより、チェックポイントの保存と読み込みにかかる時間が以前よりも大幅に短縮されました。分割されたチェックポイントを再構成する場合には少し時間がかかりますが、チェックポイントが必要になることはほとんどないことが分かっているため問題にはならない一方で、数千個のGPUで24時間体制で継続的に行われている書き込み処理の方は大きく短縮できるというわけです。

2つ目の「データが到着した後、そのデータが表す作業が均等に分散されるかどうか」という問題は、Backblazeは「データローダーの問題」と表現しています。

AIモデルを複数のGPUで学習させる場合、トレーニングデータを均等なサイズのチャンクに分割し、クラスタ内の各GPUに1つのチャンクを割り当てます。しかし、均等なサイズのチャンクが均等な作業量を意味するわけではなく、一部のGPUは数秒で処理できる単純なアセットを受け取った一方で、他のGPUは数分かかる大規模で複雑なファイルを受け取るなどの差が生じ、素早く処理を終えたGPUは遅いGPUが追いつくのを待って待機状態になっていました。

問題を解決するため、Adobeはすべてのデータを同じものとして扱うのをやめたと説明しています。すべてのGPUがほぼ同時に処理を完了するように作業を分散させる「独自開発のバランス型データローダー」を構築することで、待機状態に生じる無駄なコストを大幅に削減しました。

2つの問題の原因に対処した結果、AdobeのGPUは約80％の利用率で稼働するようになりました。GPU同士の調整などで発生するオーバーヘッドを考慮すると、80％という稼働率は実質的な上限に近い数値であるとのこと。

また、完璧にバランスの取れたデータローダーであっても、待機しているデータがまだ到着していない場合はアイドル状態になります。そのため、データが到着した後の処理を最適化するローダーだけではなく、データが存在するかどうかを決定するストレージも重要となるそうです。そこでBackblazeは、Adobeが直面したようなストレージ面の問題に対処できるオブジェクトストレージ「Backblaze B2 Overdrive」を宣伝しています。