LLM 学習の並列化戦略(5 次元)とパラメータチューニング¶
作成日: 2026-06-22 出典 / きっかけ: Software Design 2026年7月号 GPU 特集(p.206)。「学習パラメータの組み合わせが膨大」のくだりを整理 関連: gpu_数値精度fp16_tflops_整理
0. 要点(3行)¶
- 巨大 LLM は 1 枚の GPU に載らないので、「モデルとデータをどう切ってばらまくか」を複数の軸(次元)で同時に決める必要がある。その軸が 5 つある(テンソル/パイプライン/データ/コンテキスト/エキスパート並列)。
- さらに各軸の設定に加え、マイクロ/グローバルバッチサイズ・活性値再計算の粒度・混合精度(FP16/BF16/FP8)が乗る。「メモリに収める ↔ 通信を減らす ↔ 演算器を遊ばせない」の三つ巴で、1 つ動かすと他が連動する。
- だから最適解は手で総当たりできず、経験則+自動探索(Megatron 等のヒューリスティクス/オートチューナ)で詰めるのが実態。組み合わせ爆発こそが本質的な難しさ。
1. なぜ「並列化」が必要か — 1 枚に載らない¶
GPU 1 枚のメモリ(H100 SXM で 80GB)に対し、学習時に必要なメモリは「パラメータ+勾配+オプティマイザ状態(Adam なら param の数倍)+活性値(activations)」で、数百 B パラメータのモデルでは桁違いに足りない。そこで複数 GPU に分割する。分割の「切り方」が並列化戦略であり、切る軸が下記 5 つ。
直感: 1 つの巨大な計算を、どの方向に包丁を入れて分担するか。縦に切るか(層内)、横に切るか(層間)、束を分けるか(データ)、文の長さで切るか、専門家で切るか — の違い。
2. 5 次元の並列化戦略¶
| 次元 | 何を分割するか | 一言で | 主なコスト |
|---|---|---|---|
| データ並列 (DP) | 学習データ(バッチ) | モデルを各 GPU に複製し、別々のデータを食わせ、勾配を集約 | 勾配の all-reduce 通信 |
| テンソル並列 (TP) | 1 つの層の行列(重み)を層内で分割 | 1 枚に載らない大きな行列積を横に割る | 層ごとに頻繁な通信(高速接続必須) |
| パイプライン並列 (PP) | Transformer の層をステージに分け層間で分割 | 工場のライン。層 1-8 は GPU0、9-16 は GPU1… | パイプラインバブル(待ち時間) |
| コンテキスト並列 (CP) | 系列長(シーケンス)方向 | 長文を分割して各 GPU が一部のトークンを担当 | attention の系列方向通信 |
| エキスパート並列 (EP) | MoE のエキスパート(専門家 MLP) | 疎活性モデルで、専門家を GPU 間にばらまく | token を担当エキスパートへ送る all-to-all 通信 |
2-1. 切る「方向」のイメージ¶
1つのTransformer層 層のスタック(深さ)
┌───────────────────────┐ 層1 ─┐
│ 巨大な重み行列 W │ 層2 │ GPU0 が担当(PP ステージ0)
│ ←─ TP: ここを縦に分割 ─→ │ … ┘
└───────────────────────┘ 層9 ─┐
層10 │ GPU1 が担当(PP ステージ1)
入力 [バッチ, 系列長, 次元] … ┘
│ │
│ └─ CP: 系列長で分割
└─ DP: バッチ(データの束)で分割
MoE の場合: 専門家 e1,e2,…,eN を EP で GPU 間にばらまく
- TP(層内)と PP(層間)は直交: TP は「1 層を横に割る」、PP は「層の並びを縦に区切る」。両方同時に使える
- DP は最も素直(モデル丸ごと複製)。ただし複製分メモリを食うので、ZeRO/FSDP のように DP の中でさらに状態を分割する派生がある
- CP は長文学習(128K トークン等)で attention のメモリ・計算を分散するために効く
- EP は MoE(Mixture of Experts)専用。dense な MLP を「複数の専門家」に置き換え、トークンごとに一部だけ活性化 → 専門家を GPU に分散
実運用ではこれらを組み合わせる(ハイブリッド並列)。例: TP×PP×DP の 3D 並列が定番で、長文なら +CP、MoE なら +EP で 5D になる。
3. 並列化の「上」に乗るチューニングパラメータ¶
5 次元の分割を決めた後(or 同時)に、さらに以下が乗る。
| パラメータ | 何を決めるか | トレードオフ |
|---|---|---|
| マイクロバッチサイズ | PP の 1 回で流す小バッチの大きさ | 小さいとパイプラインバブルが増える/大きいとメモリを食う |
| グローバルバッチサイズ | 全 GPU 合計の実効バッチ(= micro × 蓄積回数 × DP 数) | 大きいほど学習は安定・効率的だが、収束特性(学習率)に影響 |
| 活性値再計算(recomputation)の粒度 | 順伝播の中間結果をどこまで「捨てて後で再計算」するか | 捨てるほどメモリ節約/その分の再計算で演算が増える(メモリ↔計算の交換) |
| 混合精度(FP16/BF16/FP8) | どの精度で計算・保持するか | 低精度ほど速く省メモリだが、範囲・精度の制約(→ gpu_数値精度fp16_tflops_整理) |
- 活性値再計算(gradient checkpointing): 順伝播の活性値は逆伝播で必要だが全部保持するとメモリが足りない。そこで一部だけ保存し、残りは逆伝播時に再計算する。「メモリを演算で買い戻す」発想
- 混合精度: 別ノート参照。BF16 が学習の主流、FP8 はさらに高速だがキャリブレーションが要る
4. なぜ難しいか — 相互依存と組み合わせ爆発¶
本文の核心は「しかもこれらは相互に依存している」。一例:
- TP を増やす → 1 枚あたりのメモリは減るが、層ごとの通信が激増 → 高速インターコネクト(NVLink)の範囲(=ノード内 GPU 数)に収めたい
- PP を増やす → メモリは分散できるがパイプラインバブルが増える → マイクロバッチを増やしてバブルを埋めたい → でもマイクロバッチを増やすとメモリを食う → 活性値再計算を強める → でも再計算は演算を増やす…
- グローバルバッチを変える → 学習率スケジュールの再調整が要る
- FP8 にする → メモリと速度は稼げるが、数値安定性のため一部を高精度に残す設計が要る
つまり「メモリに収める ↔ 通信を減らす ↔ 演算器を遊ばせない(高 MFU)」の三つ巴で、どれか 1 つを動かすと他が連動する。次元が多く各々が連続/離散値を取るため、組み合わせは指数的に膨らむ。
→ 実務では (1) ハード構成(ノード内 GPU 数・NVLink/InfiniBand 帯域)から制約を立て、(2) Megatron-LM 等の経験則・推奨設定を出発点にし、(3) 小規模で MFU(Model FLOPs Utilization: 理論演算性能をどれだけ引き出せたか)を測りながら詰める。
5. まとめ — 早見表¶
| 困りごと | まず動かす軸 | 連動して見る |
|---|---|---|
| モデルが 1 枚に載らない | TP(ノード内)→ PP(ノード間) | TP は NVLink 範囲に収める |
| 長文(長系列)で OOM | CP(コンテキスト並列) | attention の系列方向通信 |
| MoE モデル | EP(エキスパート並列) | all-to-all 通信が支配的に |
| スループットを上げたい | DP を増やす/グローバルバッチ拡大 | 学習率の再調整 |
| メモリがあと少し足りない | 活性値再計算を強める/FP8 化 | 再計算は演算増、FP8 は精度ケア |
| パイプラインの待ち(バブル)が多い | マイクロバッチを増やす | メモリ消費との綱引き |
直感的まとめ: 並列化は「巨大な計算をどの方向に包丁を入れて分けるか」の多次元選択で、各カットがメモリ・通信・演算効率に同時に効くから、単独最適化ができない。だから自動探索と経験則に頼る。
参考リンク¶
- Megatron-LM(NVIDIA、5D 並列の実装本体): https://github.com/NVIDIA/Megatron-LM
- MoE Parallel Folding(5D ハイブリッド並列の論文, arXiv 2504.14960): https://arxiv.org/html/2504.14960v1
- Data/Tensor/Pipeline/Expert/Hybrid parallelism 解説(BentoML LLM Inference Handbook): https://bentoml.com/llm/inference-optimization/data-tensor-pipeline-expert-hybrid-parallelism
- 出典: Software Design 2026年7月号 GPU 特集(技術評論社、Kindle 版 p.206)
作成: 2026-06-22 / 最終更新: 2026-06-22