日本のテック業界では、ソフトバンクによるNVIDIA H100の大規模導入と、国内最大級のAI計算基盤構築が注目されています。海外でも、日本の計算資源への投資に関心が高まっています。
しかし、ここで皆さんに重要な問いを投げかけたいと思います。
「あなたのチームのデータパイプラインは、H100の圧倒的な処理能力を十分に活かしきれる設計になっていますか？」
実務の現場では、高額な高性能GPUを導入したにもかかわらず、データ供給がボトルネックとなり、学習が遅々として進まないケースが散見されます。これは、GPUがデータを待ちぼうけしてしまう「GPU Starvation（スタベーション＝飢餓状態）」と呼ばれる状態です。
高性能GPUを導入しても、データ処理が追いつかなければ、その真価は発揮できません。これは単なる技術的な問題にとどまらず、経営的なコスト効率の観点からも深刻な課題となります。
この記事では、H100の性能を最大限に引き出すためのデータ供給網（パイプライン）の設計について解説します。生成AIモデルの構築だけでなく、それを支えるデータエンジニアリングの重要性について、経営と現場の両方の視点から掘り下げていきましょう。
H100時代の「データ処理」は何が変わるのか？
計算速度の飛躍的向上と「GPUスタベーション」のリスク
NVIDIA H100 Tensor Core GPUは、コストパフォーマンス重視の中規模プロジェクトで活躍する前世代のA100と比較して、大規模言語モデル（LLM）の学習や推論において圧倒的なパフォーマンスを発揮します。特に「Transformer Engine」の搭載により、FP8（8ビット浮動小数点）精度での演算が可能となり、スループットは飛躍的に向上しました。また、コンシューマー向けで主力となるRTX 50シリーズ（32GBのVRAMを搭載するRTX 5090など）においても、FP8やNVFP4を活用したVRAM消費の抑制技術が導入されており、ハードウェア全体で計算効率が劇的に高まっています。
現在、後継となるH200やBlackwellアーキテクチャ（B200等）への移行も進んでいますが、H100は依然として多くの大規模学習プロジェクトにおける主力基盤です。しかし、この計算処理の高速化は、新たな課題を浮き彫りにしました。システム全体のボトルネックが、計算そのものからI/O（入出力）、メモリ帯域、そして前処理へと完全に移行したのです。
これが「GPUスタベーション（飢餓状態）」と呼ばれる現象です。GPUが演算を終えているにもかかわらず、次のバッチデータが届かず待機してしまう状態を指します。nvidia-smi コマンド等でGPU使用率（Volatile GPU-Util）を確認した際、数値が低い、あるいは激しく変動している場合は、データパイプラインの供給不足を疑うべきです。せっかくの高級スポーツカーも、ガソリンの供給が滞ればエンストしてしまうのと同じですね。
国内大規模AI基盤とインフラの進化
日本国内でも、ソフトバンクをはじめとする通信キャリアやクラウドベンダーによるH100の大規模導入が進んでいます。直近の動向として、さくらインターネットがH100を8基搭載した専有プランの提供を開始するなど、国内におけるハイエンドな計算リソースへのアクセス性は着実に高まっています。
これらの基盤では、GPU間の高速通信を担うNVLinkやInfiniBandネットワーク、最適化されたストレージが組み合わされ、ハードウェアレベルでの性能は極限まで高められています。しかし、どれほど強力なインフラがあっても、それを使いこなすためのソフトウェア設計、特にデータ供給の仕組みが伴わなければ、高価なGPUリソースを浪費することになりかねません。経営者としては、投資対効果（ROI）を最大化するためにも見過ごせないポイントです。
ボトルネックは「計算」から「データ供給」へ移動する
かつての画像処理中心のディープラーニングでは、計算負荷が高く、GPUが処理している間にCPUが次のデータを準備する「プリフェッチ」の時間的余裕がありました。
しかし、TransformerベースのモデルやH100のFP8演算においては、計算が一瞬で完了します。計算速度の向上は著しく、従来のWebアプリケーション開発の延長線上にあるようなデータローダーの実装では、供給が追いつかないケースが頻発しています。さらに、Hugging Face Transformersの最新メジャーアップデートでは、モジュール型アーキテクチャへの移行に伴いTensorFlowやFlaxのサポートが終了し、PyTorch中心のエコシステムへと最適化が進んでいます。これにより、旧来のフレームワークに依存したコードから脱却し、PyTorchネイティブな高速化手法へ移行することが、データパイプライン構築における新たな標準となっています。
AIエンジニアには、モデルのアーキテクチャ設計だけでなく、「いかに速くデータをGPUのメモリ（VRAM）に届けるか」というデータ供給のエンジニアリングが、これまで以上に求められています。サポートが終了したレガシーな機能から最新のモジュール構成へと移行手順を整備し、システム全体を最適化することが不可欠です。Blackwell世代などの次世代GPUを見据えれば、この「データ供給の最適化」という課題はさらに重要度を増していくと言えます。
参考リンク
ステップ1：高速演算に耐えうる「データ形式」の再定義
非構造化データの効率的な格納フォーマット（TFRecord, Parquet等）
画像ファイル（JPEG/PNG）やテキストファイル（TXT/JSON）を個別のファイルとしてファイルシステムに保存し、学習時に1つずつ open() するのは効率的ではありません。
OSのファイルシステムにとって、多数の小さなファイルを扱うのは負荷が高く、ランダムアクセスやメタデータのルックアップに時間がかかります。これは「Small File Problem」と呼ばれます。
H100を使用する際は、データをシーケンシャルリード（連続読み出し）に最適化されたコンテナフォーマットにまとめることが推奨されます。
- TFRecord (TensorFlow): プロトコルバッファ形式でシリアライズされたバイナリ形式で、高速に読み込めます。
- WebDataset (PyTorch): TARアーカイブをベースにした形式で、シーケンシャルアクセスに強く、大規模データセットに適しています。
- Parquet / Arrow: 表形式データやテキストデータの場合、列指向フォーマットであるApache ParquetやApache Arrowが効率的です。
これらの形式を使用することで、ディスクのヘッド移動やIOPSの消費を抑え、高速なデータ読み込みが可能になります。まずは手元のデータ形式を見直すことから始めてみましょう。
I/O負荷を軽減する圧縮技術の選定
データ転送のボトルネックを解消するには、データ量を減らすことが有効です。ただし、圧縮率が高すぎると、解凍（デコード）のためにCPU負荷が高まる可能性があります。
- 画像: JPEGやWebPなどの不可逆圧縮はデコード負荷とのバランスが良いですが、医療画像など精度が重要な場合はPNGやTIFFを使用する必要があります。その場合、デコードをGPUで行うことを検討します。
- テキスト/数値: LZ4 や Zstandard (zstd) がおすすめです。これらはGzipと比較して、圧縮率は同程度で解凍速度が速いアルゴリズムです。
小さなファイルを大量に扱わないためのグルーピング戦略
データをコンテナフォーマット（例えばTFRecord）にまとめる際、1ファイルあたりのサイズも重要です。一般的には、100MB〜200MB程度にまとめるのが良いとされています。これは、ストレージシステムのブロックサイズやネットワークのスループットに対して効率が良いサイズ感です。
ファイルサイズが大きすぎると、並列読み込みの粒度が粗くなり、シャッフル（データのランダム化）の効率が落ちます。逆に小さすぎると、ファイルオープンのオーバーヘッドが無視できなくなります。
データセットを「シャード（Shard）」と呼ばれる単位に分割し、各シャードに数千〜数万のサンプルを含める設計が推奨されます。これにより、分散学習時のデータ配分もスムーズになります。
ステップ2：GPUを待たせない「前処理パイプライン」の構築
ETL処理のCPUオフロードと並列化
データは読み込んだ後、リサイズ、正規化、トークナイズ、Augmentation（データ拡張）などの前処理が必要です。これを学習ループの中で同期的に行うと、GPUが停止します。
PyTorchの DataLoader にある num_workers 引数は、この前処理を複数のサブプロセスで並列実行するためのものです。ただし、PythonのGIL（Global Interpreter Lock）の制約や、プロセス起動のオーバーヘッドには注意が必要です。
Prefetch（先読み）機能も重要です。GPUが現在のバッチを計算している間に、CPU側で次のバッチを準備してメモリに待機させておくことで、GPUのアイドル時間を減らすことができます。PyTorchでは prefetch_factor で制御できます。
オンザフライ前処理 vs 事前加工データのストレージ保存
「前処理を毎回計算する（On-the-fly）」か、「前処理済みのデータを保存しておく（Offline）」かは、トレードオフの関係にあります。
- On-the-fly: ストレージ容量を節約でき、ランダムなAugmentationを適用しやすいですが、CPU負荷が高いです。
- Offline: CPU負荷は低いですが、ストレージ容量を消費し、Augmentationの多様性が失われる可能性があります。
H100のような環境では、CPUが前処理の速度に追いつけないケースが増えています。その場合、可能な限りOfflineで処理を済ませておくか、GPUでの前処理を検討します。
NVIDIA DALI (Data Loading Library) の活用基礎
NVIDIA DALI は、画像のリサイズ、デコード、Augmentationなどの処理をGPU上で実行するためのライブラリです。
H100のような環境では、計算能力に余裕があることが多いため、GPUを前処理に活用することで、CPUボトルネックを解消できます。
DALIを使用すると、JPEGデータのデコードから学習用テンソルへの変換までをGPU内で完結でき、CPUとPCIeバスの帯域を節約できます。
ステップ3：ソフトバンク事例に学ぶ「分散学習」前提のデータ分割
データ並列処理におけるシャーディング戦略
大規模なモデルを学習する場合、複数ノードを使った分散学習（Data Parallelism）が前提となります。データセットを各ノードに効率的に配るかが重要になります。
単純に全データを全ノードにコピーするのはストレージの無駄であり、起動時間も遅くなります。ネットワーク越しに毎回データを取得すると通信がボトルネックになります。
基本戦略はシャーディング（Sharding）です。データセット全体をN個のシャードファイルに分割し、各ノード（または各GPU）が担当するシャードだけを読みに行くようにします。WebDatasetなどのフォーマットは、このシャーディングと相性が良いです。
ネットワーク帯域を圧迫しない同期タイミング
分散学習では、各GPUが計算した勾配（Gradients）を同期するために通信が発生します（All-Reduce通信など）。これと、データの読み込み通信が重なると、パフォーマンスが低下します。
データローディングの通信と、学習の通信が干渉しないよう、データは可能な限りローカルストレージ（NVMe SSD）にキャッシュするか、計算と通信をオーバーラップさせる設計が必要です。
ローカルキャッシュと共有ストレージの使い分け
理想的な構成は以下の通りです。
- マスターデータ: 信頼性の高い共有オブジェクトストレージ（S3互換など）に保存。
- 学習開始時: 必要なシャードを各計算ノードのローカル高速SSDにコピー（キャッシュ）。
- 学習中: ローカルSSDから読み出してGPUへ転送。
多くのクラウドストレージやAIプラットフォームには、アクセス頻度の高いデータを自動的に高速な層にキャッシュする機能があります。ストレージの階層構造を意識し、「GPUに一番近い場所」にデータを置くことが重要です。
ステップ4：品質管理とコスト最適化のバランス
不要なデータを流さないためのフィルタリング自動化
Garbage In, Garbage Out（ゴミを入れればゴミが出てくる）はAIの原則ですが、H100を使う場合、「ゴミを処理するコスト」が増加します。
エラーを含む画像、極端に短いテキスト、フォーマットが壊れたファイルなどは、学習を停止させるだけでなく、GPU時間を浪費させます。前処理パイプラインには、エラーハンドリングだけでなく、データの品質をチェックして除外するフィルタリング機能を組み込むことが重要です。
例えば、読み込みに失敗したデータはスキップし、ログに残すだけに留めることが考えられます。
チェックポイント保存とストレージコストの管理
大規模学習は数日、数週間続くことがあります。途中でインフラ障害やプリエンプション（優先度の高いジョブによる強制終了）が起きる可能性も考慮する必要があります。
定期的なチェックポイント（モデルの途中経過保存）は必須ですが、頻繁すぎるとストレージ容量を圧迫し、保存時のI/O待ち時間も発生します。H100クラスのモデルサイズになると、チェックポイントひとつで数百GBになることもあります。
非同期でのチェックポイント保存や、古いチェックポイントの自動削除、差分保存などの戦略を検討し、コストとリスクのバランスを取りましょう。
学習中断リスクへの備えとリカバリ設計
データパイプラインの状態（どこまで読み込んだか）も、モデルの重みと一緒に保存・復元できるようにしておくことが望ましいです。DataLoader の状態保存は重要です。学習を再開したとき、データの最初から読み直してしまうと、モデルが同じデータばかり学習して過学習（Overfitting）する可能性があります。
まとめ：自社に最適な「データ供給網」から始めよう
いきなりH100フル活用を目指さない段階的アプローチ
H100を使いこなすためのデータエンジニアリングについて解説しました。最初から完璧なパイプラインを作る必要はありません。
まずは、小さなデータセットでパイプラインを回し、nvidia-smi やプロファイリングツール（PyTorch Profilerなど）でボトルネックを特定することから始めましょう。そこで「データロード待ち」が発生していると分かってから、TFRecord化やDALIの導入を検討します。まずは動くプロトタイプを作り、仮説を検証しながらアジャイルに改善していくことが、成功への最短距離です。
外部基盤（IaaS）と自社データの接続性確認
外部基盤を利用する場合、自社のデータセンターやクラウドにあるデータを、どうやってその基盤まで持っていくかも重要な課題です。専用線接続なのか、インターネット経由なのか、物理搬送なのか。この「最初のデータ移動」の計画も、プロジェクト初期段階で立てておく必要があります。
まずは小規模なPoCでパイプラインの詰まりを検知する
高性能なGPUは、開発スピードを劇的に上げてくれます。しかし、それはデータ供給の準備が整っていればの話です。
大規模なAI開発プロジェクトを立ち上げるのであれば、いきなり本番環境を構築するのではなく、データパイプラインの検証を含めたPoC（概念実証）を行うことを強く推奨します。技術の本質を見極め、スピーディーに検証を繰り返すことで、ビジネス価値の創出に直結するAI基盤を築き上げてください。
コメント