分散学習の標準アーキテクチャ
文書基準: 2026年9月 | この文書は変化の速い領域であり、四半期ごとのレビュー対象です。
モデルとデータがGPU 1枚に全部入るなら悩むことはありません。問題は、最近のモデルがGPU 1枚のメモリを大きく超えることです。そこで仕事を複数のGPUに分けて学習しますが、分け方が大きく3種類あります。
大きな料理を複数の料理人で分担する状況にたとえると理解しやすいです。
- データ並列（DP） — 同じレシピ（モデル全体）を料理人ごとに1部ずつ持ち、客（データ）だけ分けて受け取り、各自作った後に結果を突き合わせます。
- テンソル並列（TP） — 料理一つが大きすぎて一人の料理人では作れないとき、その一皿を複数の料理人が同時に分けて作ります。
- パイプライン並列（PP） — 調理の段階を分けて、料理人Aは下ごしらえ、Bは焼き、Cは盛り付け、とリレーのように処理します。
大規模学習はこの3つを重ねて使い（3D並列化）、各方式は「どれだけ頻繁に通信が必要か / メモリをどれだけ節約するか / 実装がどれだけ複雑か」で長所短所が分かれます。
データ並列 (Data Parallelism, DP)
Section titled “データ並列 (Data Parallelism, DP)”データ並列 (Data Parallelism, DP)
Section titled “データ並列 (Data Parallelism, DP)”モデル全体をGPUごとに複製し、データだけ分けて各自処理した後、結果（勾配）をall-reduceで同期します。最も単純で、モデルがGPU 1枚に収まるときの標準として使います。（比喩: 同じレシピを料理人ごとに1部ずつ持ち、客だけ分けて受け取り、各自作った後に結果を突き合わせる。）
- 通信方式 — 学習ステップごとに全GPUが勾配を合わせます。（all-reduce = すべてのGPUの値を集めて合計し、再び全員に配り直す通信。）
- 限界 — モデル自体がGPU 1枚のメモリを超えると、この方式だけでは足りません。
- メモリ節約（FSDP/ZeRO） — モデルのパラメータ・途中状態をGPU群に細かく刻んで分散保存（sharding）します。データ並列を維持しながらGPU 1枚の限界を超えて、より大きなモデルを学習できます。
テンソル並列 (Tensor Parallelism, TP)
Section titled “テンソル並列 (Tensor Parallelism, TP)”単一レイヤー（モデルを構成する計算の層）の重みを複数のGPUがシャーディングして同時に計算します。一つの層がGPU 1枚に入らないほど大きいときに使います。
- 通信方式 — 層の内部でGPU同士が非常に頻繁にやり取りし、遅延に非常に敏感です。そのため主に1台のサーバー内（NVLinkで繋がれたGPU群）でのみ使います。
- 効果 — 層一つがGPUメモリを超えるときに必須。通信が頻繁なため、ノード間に広げると性能が急落することがあります。
パイプライン並列 (Pipeline Parallelism, PP)
Section titled “パイプライン並列 (Pipeline Parallelism, PP)”モデルの層をいくつかの段階（stage）に分けて別々のGPUグループに配置し、データを小さな断片（マイクロバッチ）に刻んでリレーのように流します。
- 通信方式 — 段階と段階の境界でのみ結果を渡すため、通信量が少ないです。そのため複数のサーバーへ広げやすいです。
- 限界 — リレーの性質上、前の段階を待って遊ぶ区間（パイプラインバブル）が生じ、データ断片の数を増やして緩和します。
3Dハイブリッド並列化
Section titled “3Dハイブリッド並列化”大規模な事前学習は3つの方式を階層的に組み合わせます。一般的にノード内はTP、ノード間はPP、その上にDPを重ねます。
| 並列化 | 通信量 | メモリ削減 | 遅延敏感度 | 推奨配置 |
|---|---|---|---|---|
| データ並列 (DP) | 高い（勾配all-reduce） | なし（FSDP/ZeRO使用時は大きい） | 中程度 | クラスター全体 |
| テンソル並列 (TP) | 非常に高い（レイヤー内部） | 大きい | 非常に高い | ノード内 (NVLink) |
| パイプライン並列 (PP) | 低い（段階の境界） | 大きい | 低い | ノード間 |
分散学習フレームワーク
Section titled “分散学習フレームワーク”| フレームワーク | 主な並列化 | 特徴 |
|---|---|---|
| PyTorch FSDP | DP (sharding) | PyTorchネイティブ、パラメータ/オプティマイザ状態を分散 |
| DeepSpeed | DP(ZeRO) + PP + TP | ZeRO段階別メモリ最適化、オフローディング対応 |
| Megatron-LM | TP + PP + DP | 大規模Transformer事前学習に最適化されたTP実装 |
チェックポイント戦略
Section titled “チェックポイント戦略”大規模学習は数時間～数週間実行されるため、ノード障害に備えたチェックポイントが必須です。チェックポイント設計は保存頻度とストレージ帯域のバランスの問題です。
- 頻度 — 頻繁すぎると保存オーバーヘッドでGPUがアイドル状態になり、まれすぎると障害時に失われる計算量が大きくなります。
- ストレージ帯域 — 数百GB～数TB級のチェックポイントを短時間で書き込む必要があるため、ストレージ層のスループットがボトルネックになります。
- 非同期・分散保存 — 学習を止めずにバックグラウンドで保存するか、各GPUが自身のシャードのみを並列保存して時間を短縮します。
- 自動再開 — 障害検知後に最後のチェックポイントから再開する流れは推論サービング・信頼性・コスト最適化 — 信頼性・障害対応で扱います。
- 次: Kubernetes・スケジューリング・gang scheduling — GPU Kubernetesとスケジューリング
- クラスターの通信層・ファブリック・配置 — GPUワークロードの特性とリファレンスアーキテクチャ
- 障害の自動再開・容量運用 — 推論サービング・信頼性・コスト最適化
- AIシステムライフサイクル内の学習パイプライン — AIシステムライフサイクルとエンジニアリング
よくある間違い
Section titled “よくある間違い”- 不要な3D並列化の導入 — 単一ノードで十分なモデルにテンソル・パイプライン並列を重ね、複雑さとデバッグコストのみが増加
- テンソル並列をノード間に拡張 — 遅延に敏感なTPをNVLinkの外に広げ、通信ボトルネックが発生
- チェックポイント頻度だけを上げる — ストレージ帯域を一緒に増やさず、保存中のGPUアイドル時間が増加
- オプティマイザ状態のメモリを見落とす — パラメータ以外にオプティマイザ状態・勾配が占めるメモリを計算せず、OOMが発生
チェックリスト
Section titled “チェックリスト”- モデル・オプティマイザ状態が単一GPU/単一ノードのメモリに収まるか計算したか
- 単一ノードで可能ならFSDP/ZeROデータ並列を優先的に検討したか
- テンソル並列をノード内（NVLink）に制限し、パイプライン並列をノード間に配置したか
- チェックポイント頻度とストレージ帯域を一緒に設計したか
- 障害時の自動再開の流れを検証したか