学習の基盤

大きなモデルや大量のデータを学習すると、GPU 1枚では時間がかかりすぎたり、そもそもモデルがメモリに載らなかったりします。複数の GPU にどう分けるかは学習の費用と期間を大きく左右し、「GPU を倍にしたのに速くならない」という問題の多くは、分け方と GPU 間の通信から来ます。

GPU は、同じ計算を大量に並べて同時に行うのが得意で、ニューラルネットの行列の計算に向いています。1台で時間がかかりすぎるときや、モデルが1枚の GPU のメモリに載らないときに、複数の GPU で分けて学習します（分散学習）。

大きなモデルでは、これらを組み合わせます。データ並列でも、モデルの重みやオプティマイザーの状態を GPU に分けて持ち、メモリを節約する方式（FSDP・ZeRO）がよく使われます。

データ並列では毎回の更新で勾配をそろえる通信が入るので、GPU 間・サーバー間の通信が遅いと、台数を増やしても速くなりません。サーバーをまたぐ学習では、高速なネットワーク（InfiniBand など）が要ります。

下の「ブラウザで試す」の図は、データ並列で4台の GPU が勾配をそろえる通信（リング all-reduce）です。最初に全員が rank 0 に集まって住所を教え合い、各自が勾配を計算したあと、勾配を4つに分けて右隣へ送りながら足し合わせ（reduce-scatter）、完成した切れをまた回して全員に配ります（all-gather）。毎回の更新でモデルと同じ大きさのデータが GPU の間を流れることと、1台が遅いと全員が待つことに注目すると、最後の段落の「通信が遅いと台数を増やしても速くならない」理由が見えます。

混合精度（mixed precision）：計算の多くを 32 ビットではなく 16 ビットの数（FP16・BF16）で行う方法です。メモリが約半分になり、最近の GPU では計算も速くなります。FP16 は表せる範囲が狭く、値が小さすぎて 0 になる問題があるので、損失を拡大して計算する仕組み（loss scaling）と組み合わせます。BF16 は範囲が 32 ビットと同じなのでこの問題が起きにくく、対応する GPU ならまず BF16 を選びます。PyTorch では torch.autocast で使えます。

「このモデルは何 GB の GPU に載るか」は、パラメーターの数からおおまかに見積もれます。面接でもよく聞かれる計算です。

学習では、重みのほかに勾配、32ビットの重みの控え、Adam の2つの状態を持つので、重みだけの何倍ものメモリを使います。さらに、層ごとの途中の計算結果（活性化）がバッチサイズと系列の長さに比例して増えます。足りないときは、バッチを小さくして勾配をためる（勾配累積）、途中の計算を保存せず再計算する（gradient checkpointing）、FSDP・ZeRO で分けて持つ、LoRA で学習する重みを減らす、を組み合わせます。

GPU のサーバーは高価で、計算していない時間にも料金がかかります。学習が遅いと GPU を増やしたり大きくしたりしたくなりますが、本当の原因はその手前の「データを GPU まで届ける部分」にあることが少なくありません。ここを直せば、同じ GPU のまま学習が速くなり、費用も下がります。

GPU がどんなに速くても、データが届くのが遅ければ GPU は待つだけです。GPU の使用率が低いのに学習が遅いときは、まずデータの読み込みを疑います。

基本の対策：読み込み・デコード（画像の展開など）・前処理を、複数のプロセスで並列に行い、GPU が今のバッチを計算している間に次のバッチを用意しておきます（先読み）。PyTorch の DataLoader なら num_workers（並列の数。CPU のコア数を目安に調整）、prefetch_factor、pin_memory=True を設定します。前処理が重すぎる場合は、学習の前に済ませて保存しておきます。

S3 からの読み込み：オブジェクトストレージ（S3 など）は、1回のリクエストの待ち時間が長めですが、同時にたくさん読めば全体の速さは出ます。小さなファイル（画像1枚ずつなど）を何百万個も1つずつ読むと、待ち時間ばかりになって遅くなります。

• 小さなファイルを数百 MB 程度の大きなファイルにまとめ、順に読む（WebDataset の tar、TFRecord など）。
• 並列でたくさんのリクエストを出す。
• 同じデータを何周も読むなら、ローカルの SSD にコピーするかキャッシュする。
• GPU のサーバーと S3 を同じリージョンに置く（別のリージョンだと遅く、転送料金もかかる）。

S3 の基本は SRE の解説で

下の「ブラウザで試す」の図では、学習のサーバーが VPC エンドポイント経由で S3 からファイルの一覧を取り、1つのファイルを 8MB ずつに分けて Range ヘッダーで並列に読み、206 で範囲だけを受け取る流れを追えます。混みすぎたときの 503 SlowDown と、読みながら学習する（先読み）手順もあります。上の箇条書きの「大きなファイルにまとめる」「並列でたくさんのリクエストを出す」が、どの手順にあたるかに注目してください。

大きな表データは、日付などで分けたフォルダ（パーティション）に Parquet で置くと、必要な期間と列だけを読めて速く安くなります。画像や音声は、数百 MB 程度の tar などにまとめると、S3 から順に速く読めます。

GPU のインスタンスは、普通のサーバーより1桁以上高いことが多く、ML のチームの費用の大部分を占めがちです。「使っている時間を減らす」「安い買い方をする」「使っている間は使い切る」の3つで抑えます。

スポットと中断への備え：スポットインスタンス（クラウドの余っている計算機を安く借りる仕組み）は、通常の料金より大きく安くなることがありますが、クラウドの都合で短い予告で止められます。学習に使うなら、止められても続きから再開できるようにします。

• チェックポイントを定期的に保存する：モデルの重みだけでなく、オプティマイザーの状態・学習率のスケジュール・何ステップ目か・乱数の状態も保存します。保存先は S3 などインスタンスの外にします。
• 保存の間隔は、「止められたときに失ってもよい時間」と、保存にかかる時間で決めます（例：30分ごと）。
• 中断の通知を受けたら、すぐチェックポイントを保存する処理を入れる。
• 起動したら、最新のチェックポイントがあれば自動でそこから再開するようにしておく。

止められると困る本番の推論や、締め切りの迫った学習には、オンデマンドや予約（長期の利用を約束して割引を受ける）を使います。

クラウドの費用の管理全般は SRE の「FinOps」で

使用率の監視：nvidia-smi や DCGM のエクスポーターで、GPU の使用率とメモリの使用量を記録し、ダッシュボードで見えるようにします。

• 使用率がずっと低い：データの読み込みが遅い、バッチが小さすぎる、GPU が大きすぎる。
• 何もしていない GPU：使い終わったノートブックや開発用のインスタンスが付けっぱなし。一定時間使われなければ自動で止める仕組みを入れます。
• チームやプロジェクトごとにタグを付け、誰がいくら使っているかを見えるようにします。