複数の GPU ノードにまたがってバッチサイズを拡大し、LLM の学習を高速化する分散学習手法群の総称。データ並列・モデル並列・パイプライン並列を組み合わせた 3D 並列化により、数千〜数万 GPU でのスケーリングを実現する。All-Reduce 通信のボトルネック、ストラグラー問題、障害耐性がスケール限界を決定づけるため、ソフトウェアとネットワークの協調設計が不可欠である。
分散バッチスケーリング（Distributed Batch Scaling）は、LLM の学習において複数の GPU（数十〜数万台）にわたってバッチを分配し、並列に処理することでグローバルバッチサイズを拡大する技術群を指す。単一 GPU ではメモリと計算速度の制約からバッチサイズに物理的な上限があるが、分散学習により論理的なバッチサイズを GPU 台数に比例して拡大できる。
2026 年現在、フロンティアモデルの学習には数千〜数万台の GPU クラスタが使用されており、Llama 3 405B は 16,384 台の H100、GPT-4 は推定 25,000 台以上の A100/H100 で学習された。これらの超大規模クラスタでバッチサイズを効率的にスケールするには、単純なデータ並列だけでは通信ボトルネックが深刻になるため、データ並列・モデル並列・パイプライン並列を階層的に組み合わせる「3D 並列化」が標準となっている。
データ並列は分散バッチスケーリングの最も基本的な手法である。同一のモデルを N 台の GPU に複製し、グローバルバッチを N 分割して各 GPU に配布する。各 GPU がローカルバッチの勾配を計算し、All-Reduce 通信で全 GPU の勾配を平均した後、同一のパラメータ更新を行う。
| データ並列手法 | メモリ効率 | 通信量 | スケーラビリティ | 代表実装 |
|---|---|---|---|---|
| 単純 DDP | 低（全複製） | 2×モデルサイズ/ステップ | 〜64 GPU | PyTorch DDP |
| ZeRO Stage 1 | 中（オプティマイザ分散） | 2×モデルサイズ/ステップ | 〜256 GPU | DeepSpeed |
| ZeRO Stage 2 | 高（勾配も分散） | 2×モデルサイズ/ステップ | 〜512 GPU | DeepSpeed |
| ZeRO Stage 3 / FSDP | 非常に高（全分散） | 3×モデルサイズ/ステップ | 〜1024 GPU |
| DeepSpeed, PyTorch FSDP |
| ZeRO++ | 非常に高 | 1.5×モデルサイズ/ステップ | 〜2048 GPU | DeepSpeed |
ZeRO（Zero Redundancy Optimizer）はオプティマイザ状態・勾配・パラメータの冗長な複製を排除し、メモリ効率を大幅に向上させる。Stage 3 では各 GPU がパラメータの 1/N のみを保持し、フォワード・バックワード時に必要な分だけ All-Gather で収集する。メモリは N 分の 1 に削減されるが、通信量は増加する。
大規模 LLM の学習では、データ並列・テンソル並列・パイプライン並列を組み合わせた 3D 並列化が標準である：
テンソル並列（Tensor Parallelism, TP）：Transformer の個々のレイヤー内の行列演算を複数 GPU に分割する。Self-Attention のヘッドを GPU ごとに分割、FFN の行列を列方向・行方向に分割するのが典型的。NVLink/NVSwitch（900GB/s）の高帯域通信が必須で、通常は同一ノード内の 8 GPU に制限。
パイプライン並列（Pipeline Parallelism, PP）：モデルのレイヤーをグループに分割し、各グループを異なるノードの GPU に配置する。ノード間通信は隣接ステージ間の活性化テンソルのみで、テンソル並列に比べ帯域要件が低い。マイクロバッチングでパイプラインバブルを最小化する。
データ並列（Data Parallelism, DP）：テンソル並列とパイプライン並列でモデルを分割した上で、その分割単位を複数セット複製して並列にバッチを処理する。
具体的な構成例（Llama 3 405B 推定）：
| 並列種別 | 並列度 | 対象 | 通信種別 |
|---|---|---|---|
| テンソル並列 | 8 | 同一ノード内 8 GPU | NVLink 900GB/s |
| パイプライン並列 | 16 | 16 ノード（128 GPU） | InfiniBand 400Gbps |
| データ並列 | 128 | 128 グループ（16,384 GPU） | InfiniBand All-Reduce |
合計 GPU 数 = 8 × 16 × 128 = 16,384
分散バッチスケーリングの最大の課題は通信オーバーヘッドである。N 台の GPU で All-Reduce を行う場合、通信量はモデルサイズ（パラメータ数 × バイト数）に比例し、Ring All-Reduce アルゴリズムでは 2×(N-1)/N × モデルサイズの帯域が必要となる。
| 通信最適化手法 | 効果 | 実装 |
|---|---|---|
| 勾配圧縮（1-bit Adam） | 通信量 32 倍削減 | DeepSpeed |
| 勾配スパース化 | Top-K で 90〜99% 圧縮 | 研究段階 |
| 非同期 All-Reduce | 通信と計算の重畳 | PyTorch DDP（デフォルト） |
| 階層的 All-Reduce | ノード内 → ノード間の 2 段階 | NCCL（自動選択） |
| SHARP In-Network Reduction | スイッチ内で集約 | NVIDIA InfiniBand |
| ZeRO++ 量子化通信 | FP16→INT8 で半減 | DeepSpeed |
NVIDIA の InfiniBand NDR（400Gbps）と SHARP（Scalable Hierarchical Aggregation and Reduction Protocol）技術により、ネットワークスイッチ内で All-Reduce の一部を処理し、エンドポイント間の通信量を削減する。16,384 GPU クラスタでは階層的 All-Reduce の設計が計算効率を 10〜20% 左右する。
分散バッチスケーリングの効率を測定する主要指標：
線形スケーリング効率：N GPU でのスループット / （1 GPU でのスループット × N）。理想は 100% だが、通信オーバーヘッドで低下する。
| GPU 数 | 典型的な線形スケーリング効率 | 主なボトルネック |
|---|---|---|
| 8（1 ノード） | 95〜99% | NVLink で充分 |
| 64（8 ノード） | 90〜95% | InfiniBand All-Reduce |
| 256 | 85〜92% | All-Reduce + ストラグラー |
| 1,024 | 75〜85% | 通信 + ロードバランス |
| 16,384 | 60〜75% | 全要因 + 障害復旧 |
Meta の報告によると、Llama 3 の学習では 16,384 GPU で約 90% のモデル FLOPs 利用率（MFU）を達成したとされるが、これはテンソル並列やパイプライン並列を含む複合指標であり、データ並列の線形スケーリング効率とは異なる。
数千〜数万 GPU の学習では、GPU 障害、ネットワーク障害、ソフトウェアバグによる中断が日常的に発生する。Meta は Llama 3 の学習で 54 日間に 419 回の障害を経験し、平均障害間隔（MTBF）は約 3 時間だったと報告している。
障害への対処手法：
コンテキスト並列（Context Parallelism, CP）: シーケンス長方向にバッチを分割する新しい並列軸。Llama 3 の 128K コンテキスト学習で導入された。Ring Attention や Striped Attention がベース技術。
エキスパート並列（Expert Parallelism, EP）: Mixture of Experts（MoE）モデルで各エキスパートを異なる GPU に配置する並列軸。Mixtral 8x7B や DeepSeek-V3 で採用。バッチの各トークンが異なるエキスパートにルーティングされるため、ロードバランスが新たな課題。
FP8 学習: H100 の FP8 Tensor Core を活用し、計算スループットを FP16 比で 2 倍に向上。NVIDIA の Transformer Engine が自動的に精度を管理。通信も FP8 で行えば帯域ボトルネックも緩和。
A: 技術的には可能だが、実運用では非推奨。異種 GPU（たとえば A100 と H100 の混在）では計算速度の差がストラグラー問題を引き起こし、最も遅い GPU に全体が律速される。さらに、テンソル並列ではすべての GPU が同じタイミングで通信する必要があるため、速度差が直接的にバブルとなる。異種 GPU を活用する場合は、同じ速度の GPU をテンソル並列グループにまとめ、パイプライン並列で異速グループを接続する構成が検討されるが、バブル率の上昇は避けられない。
A: 2026 年時点で H100 80GB の価格は約 35,000 ドル、クラウド（AWS p5）のスポット価格は約 2〜3 ドル/GPU-hour である。年間 8,000 時間稼働を前提とすると、オンプレミスの償却コストは約 4.4 ドル/GPU-hour（3 年償却、電力・冷却含む）で、クラウドのオンデマンド（約 4 ドル/GPU-hour）とほぼ同等。ただし、オンプレミスは初期投資が巨大（1,024 GPU × $35K = $35.8M + インフラ）で、GPU 世代交代リスクがある。Meta や Google は自社クラスタ、スタートアップはクラウドという棲み分けが一般的。
A: 超大規模分散学習のデバッグは最も困難な課題の一つである。主なアプローチ：（1）小規模再現：まず 8〜64 GPU で問題を再現し、通信パターンや勾配挙動を確認する。（2）勾配モニタリング：各 GPU のローカル勾配のノルム、NaN/Inf の検出、レイヤーごとの勾配分布をリアルタイムで監視。Weights & Biases や MLflow で可視化する。（3）通信プロファイリング：NVIDIA Nsight Systems で All-Reduce の遅延とスループットを計測し、ネットワークのホットスポットを特定する。（4）確定的再現：乱数シードの固定で結果を再現可能にする（ただし性能は 10〜20% 低下）。
A: 概念的には適用可能だが、実用上は大きな制約がある。エッジデバイス（スマートフォン、IoT）は通信帯域が低く（WiFi: 数百 Mbps、5G: 数 Gbps）、GPU クラスタの InfiniBand（400 Gbps）と桁違いの差がある。Federated Learning（連合学習）は分散バッチスケーリングの一変種とみなせるが、通信頻度を極端に下げ（数十〜数百ステップに 1 回の同期）、FedAvg や FedProx のような非同期アルゴリズムで対処する。オンデバイスの LLM ファインチューニングでは、各デバイスのローカルバッチで数ステップ学習し、差分（LoRA アダプタの重み等）のみをサーバに送信する方式が 2026 年に実用化されつつある。