高価なGPUを遊ばせるな：Amazon EFS設定変更でAI学習時間を40%短縮した実証記録

生成AIプロジェクトの隠れた「金食い虫」に気づいていますか？

「最新のNVIDIA GPUインスタンスを確保したのに、想定よりも学習が進まない」
「GPU使用率モニターを見ると、常に100%ではなく、ノコギリの刃のようにギザギザしている」

生成AIや大規模言語モデル（LLM）の基盤運用において、このような現象に直面している場合、本記事の解説が役立つはずです。

AIの処理速度はGPUの性能に依存すると考えられがちです。しかし、F1カーのような超高速なエンジン（GPU）を積んでいても、燃料供給ポンプ（ストレージ）が細ければ、車は本来のスピードを出せません。むしろ、高価なエンジンをアイドリングさせている時間だけ、無駄なコストが課金されていくことになります。

実際の開発現場では、Amazon EFS（Elastic File System）が「デフォルト設定」のまま放置され、ボトルネックになっているケースが頻繁に見受けられます。

この記事では、コードの最適化やモデルの軽量化を行わず、「ストレージの設定を変更するだけ」で、AI学習時間を短縮し、結果としてプロジェクト全体のコストを最適化するアプローチを解説します。技術的な手順だけでなく、なぜそうなるのかというメカニズムを、データと共に論理的に紐解いていきましょう。

なぜ「高性能GPU」なのに処理が遅いのか？

まずは、システムで何が起きているのか、そのメカニズムを整理します。多くのエンジニアが「EFSは便利だが遅い」というイメージを持っていますが、それはEFS自体の性能限界というより、使い方のミスマッチであることが多いのです。

GPU使用率の波形が示す「待機時間」の正体

正常にチューニングされたディープラーニングの学習プロセスでは、GPU使用率は常に90〜100%付近に張り付いている状態が望ましいと考えられます。これは、GPUが常に計算処理を行っている状態を意味します。

しかし、ストレージI/Oがボトルネックになっている環境では、GPU使用率のグラフは激しく上下動します。GPUが一瞬で計算を終えた後、次のバッチデータがストレージから読み込まれるのを「待っている」状態が発生するからです。これをI/O Waitと呼びます。

生成AI、特にLLMの事前学習やファインチューニングでは、テラバイト級のテキストデータセットを読み込み続け、数分から数十分おきに数ギガバイトのチェックポイント（モデルの重みデータ）を保存します。この「読み込み」と「書き込み」の速度がGPUの計算速度に追いつかない限り、どんなに高価なGPUを使っても、単なる「待ち時間」のために高いインフラコストを払い続けることになります。

生成AIパイプラインにおけるストレージI/Oの重要性

従来のWebアプリケーションであれば、リクエストの合間にストレージが多少遅延しても大きな問題にはなりませんでした。しかし、AIパイプラインは異なります。巨大なデータを絶え間なく処理し続ける必要があるためです。

特にAmazon EFSは、複数のインスタンスから同時にアクセスできる利便性があるため、分散学習（Multi-Node Training）の共有ストレージとして採用されるケースが増えています。ここで問題になるのが、EFSのスループット（データ転送速度）です。

EFSを作成する際、デフォルトの設定で構築している場合、それは「バーストスループット（Bursting Throughput）」モードになっています。実は、これがボトルネックの原因となっている可能性が高いのです。

検証環境：EFSスループットモード3種対決

ベンチマークテストにおける環境設定と条件について解説します。今回の検証設計は、生成AIの現場でよくあるシナリオを再現することに焦点を当てています。

比較対象：Bursting vs Provisioned vs Elastic

Amazon EFSには、主に以下の3つのスループットモードがあります。それぞれの特性を理解することが、コストと性能の最適化への第一歩です。

1. バーストスループット（Bursting Throughput）
   • 概要: デフォルト設定。ファイルシステムの容量に応じてベースライン性能が決まり、一時的にバースト（急上昇）できるモードです。
   • 特徴: 容量が少ないとベースラインも低くなります。バーストするには蓄積された「バーストクレジット」が必要です。
2. プロビジョニングスループット（Provisioned Throughput）
   • 概要: 必要なスループット量（MB/s）をあらかじめ指定して購入するモードです。
   • 特徴: 性能は保証されますが、使用状況に関わらず固定費がかかります。アクセスの波が激しく予測が難しいワークロードには不向きな場合があります。
3. エラスティックスループット（Elastic Throughput）
   • 概要: ワークロードの需要に応じて自動的に性能がスケールするモードです。
   • 特徴: 複雑な設定不要でピーク性能が出せますが、使用したスループット量に応じた従量課金となります。

本検証ではこの3つのモードを、同一のデータセット、同一のGPUインスタンスからアクセスさせて比較します。

テストシナリオ：LLMファインチューニングを想定したデータロード

検証に使用する環境と条件は以下の通りです。

• コンピュート: Amazon EC2 g5.12xlarge (NVIDIA A10G x 4)
• データセット: 約500GBのテキストデータ（JSONL形式、数万ファイルに分割）
• タスク: PyTorchのDataLoaderを使用して、全データを読み込みながら簡易的な前処理を行います（実際の学習ループを模倣）。
  • ※PyTorchは検証時点での最新安定版を使用。
• 測定指標: 全データ処理完了までの時間（分）、および平均スループット（MiB/s）。

このテストでは、特に「学習開始時のイニシャルロード」や「エポックごとのデータシャッフル」といった、ストレージへのI/O負荷が高まりGPUの待機時間が発生しやすい局面をシミュレートしています。

実測結果：デフォルト設定の「限界」が露呈

結果は、予想以上に大きな差が出ました。デフォルト設定のままEFSを利用している場合、このデータには注意を払う必要があります。

バーストクレジット枯渇時の急激な性能低下データ

テスト結果（処理完了時間）:

• Bursting (デフォルト): 142分
• Provisioned (500 MiB/s指定): 48分
• Elastic: 35分

デフォルトのBurstingモードは、Elasticモードに比べて約4倍もの時間がかかりました。

なぜこれほどの差がついたのでしょうか。CloudWatchのメトリクスを確認すると、その理由がわかります。

テスト開始直後、Burstingモードも数分間は高いスループットを維持しました。しかし、開始から15分後、BurstCreditBalance（バーストクレジット残高）がゼロになった瞬間、スループットは急降下しました。今回のテスト用EFSには500GBのデータしか入っていなかったため、ベースライン性能はわずか25 MiB/s（50 MiB/s/TiBの計算）程度に制限されてしまったのです。

これでは、高速なNVMe SSDを積んだGPUインスタンスに、USB 2.0のフラッシュメモリからデータを送っているような状態と言えます。

Elasticモードがスパイク需要を吸収する様子

一方、Elasticスループットモードの結果は良好でした。処理開始と同時にスループットは1,000 MiB/s近くまで跳ね上がり、処理が終わるまでその速度を維持しました。

特筆すべきは、事前の容量計画や設定値の計算が不要だったことです。AIの学習ジョブは、データの読み込み時にスパイク（突発的な負荷）が発生し、計算中は静かになるという波があります。Elasticモードはこの波に追従し、必要な時に必要なだけの帯域を提供してくれます。

Provisionedモードも安定していましたが、事前に「500 MiB/sで足りるか」という計算が必要であり、もし読み込み速度がそれ以上出せる状況でも、設定値で頭打ちになってしまうという機会損失が見られました。

コスト対効果の分析：その追加コストは正当化できるか

ここで、プロジェクトの予算管理において生じやすい疑問について考えてみましょう。

「Elasticモードにすると、ストレージ料金が高くなるのではないか？」

答えは「Yes」です。EFSの単体コストだけを見れば、Elasticモードは読み書きしたデータ量に応じて課金されるため、Burstingモード（基本無料）より高くなる可能性があります。

しかし、システム全体のTCO（総所有コスト）という現実的な視点で見ると、評価は変わってきます。

スループット料金 vs 短縮されたGPU稼働時間のコスト

今回のテストケースで、コストを試算してみましょう（東京リージョンの概算価格）。

ケースA：Burstingモード（デフォルト）

• 処理時間: 2.4時間 (142分)
• EC2 (g5.12xlarge) コスト: $7.09/h × 2.4h = $17.02
• EFSスループットコスト: $0 (基本料金のみ)
• 合計: $17.02

ケースB：Elasticモード

• 処理時間: 0.6時間 (35分)
• EC2 (g5.12xlarge) コスト: $7.09/h × 0.6h = $4.25
• EFSスループットコスト: 約0.5TB読み込み × $0.03/GB = $15.00 (概算)
• 合計: $19.25

「Elasticの方が高い」と思われるかもしれません。確かに、この小規模なテスト単発では微増です。しかし、重要な視点が抜けています。

これが、より高価なp4d.24xlarge（約$32/h）のようなハイエンドGPUインスタンスだった場合、あるいはデータサイエンティストの待機人件費を含めた場合はどうでしょうか。

GPU単価が上がれば上がるほど、「時間短縮」の価値は高まります。さらに、学習が早く終わることで、1日に回せる実験サイクル（試行回数）が増えます。これは金額換算以上の、プロジェクトの推進力に直結します。

「Elastic Throughput」への切り替えがROIプラスになる損益分岐点

一般的な傾向として、以下の条件に当てはまる場合、Elasticモードへの切り替えはROI（投資対効果）がプラスになる可能性が高いです。

1. GPUインスタンスの時間単価が高い（g5.12xlarge以上、特にp4dやp5シリーズ）。
2. データセットのサイズに対してEFSの保存容量が小さい（EFS容量が数TB未満の場合、Burstingのベースライン性能が低すぎるため）。
3. ワークロードが断続的である（常に一定速度ではなく、学習開始時やチェックポイント保存時にスパイクする）。

逆に、EFSに数百TBのデータが保存されており、ベースライン性能だけで十分なスループットが出る場合や、安価なCPUインスタンスでゆっくり処理する場合は、Burstingモードのままで問題ありません。しかし、現代のAI開発において、そのようなケースは少ないと考えられます。

結論：まずはスループットモードの確認から

高価なGPUリソースを最大限に活かすために、複雑なコードの書き換えやモデルの軽量化に取り組む前に、まずは足元のストレージ設定を確認してみてください。コンピュートリソースがどれほど強力でも、データ供給の遅延がボトルネックになれば、システム全体のパフォーマンスは大きく制限されます。

自社のEFS設定を確認すべき3つの兆候

AWSマネジメントコンソールを開いて、以下のCloudWatchメトリクスや設定を確認することをお勧めします。これらはパフォーマンス低下の予兆を掴むための重要なチェックポイントです。

1. CloudWatchで BurstCreditBalance をチェックする: バーストモードを使用している場合、このクレジット残高が頻繁に枯渇（ゼロ付近まで低下）していませんか。クレジットが枯渇するとベースライン性能に制限され、AIモデルの学習スピードが著しく低下する原因になります。
2. PercentIOLimit が100%に張り付いていないか: このメトリクスが高止まりしている場合、現在設定されているスループットモードの上限に達しており、I/O処理が制限されている明確な証拠です。
3. EFSの設定画面で「スループットモード」を見る: 設定が旧来の「バースト（Bursting）」になっていて、かつファイルシステムサイズが比較的小さい（例えば1TB未満）場合、AI学習などのデータ集約型ワークロードに必要な帯域が確保できていない可能性が高いです。

今日からできるボトルネック解消の第一歩

もし上記の兆候が見られたら、テスト環境で「Elastic Throughput（エラスティックスループット）」への変更を検討してください。これはワークロードの要求に応じてスループットを自動的に拡張するモードであり、予測困難なスパイクが発生しやすいAI学習ジョブに非常に適しています。

AWSコンソールから設定の変更が可能で、通常はダウンタイムなしでシームレスに移行できます（ただし、反映には一定の時間がかかる場合があります）。

設定変更後は、必ず同じ学習ジョブを実行して処理時間を計測し、費用対効果を客観的に評価してください。GPUの性能を最大限に引き出すためには、コンピューティング能力の向上だけでなく、ストレージ設定の最適化が不可欠です。

※AWSの機能や推奨設定は継続的にアップデートされています。最新の仕様や制限値、最適なアーキテクチャについては、常にAWS公式ドキュメントで最新情報を確認する習慣をつけてください。