パイプライン並列とマイクロバッチスケジューリング

なぜ層を割ると「待ち時間」が生まれるのか

分散学習の全体像 で触れたように、パイプライン並列はモデルの層をステージに分け、別々のGPUへ縦に並べる分割です。GPU0が第1〜8層、GPU1が第9〜16層…と担当を割り、データはステージ間をバケツリレーで流れます。テンソル並列のように1つの行列を割らないので、通信はステージ境界の活性化（中間出力）の授受だけで済み、ノード間にまたがらせやすいのが利点です。

問題は稼働率です。順伝播は先頭ステージから末尾へ一方向に進み、逆伝播は末尾から先頭へ戻ります。1つのミニバッチをそのまま流すと、ある瞬間に働けるのは1ステージだけで、残りは入力か勾配を待ってアイドルになります。この遊休がパイプラインバブルです。

ステージ↓ / 時間→   素朴な実行（ミニバッチ1個をそのまま流す）
S0:  F . . . . . . B
S1:  . F . . . . B .
S2:  . . F . . B . .
S3:  . . . F B . . .
（F=順伝播, B=逆伝播, .=アイドル）

ステージ数を p とすると、1個のバッチが端から端まで進むのに p ステップ、戻るのに p ステップかかり、各ステージは大半の時間を空けています。台数を増やすほど1ステージが受け持つ層は減って速くなりそうですが、素朴に流すかぎりアイドル時間も比例して増えるため、スループットは伸びません。

マイクロバッチ：充填でバブルを薄める

打開策がマイクロバッチ化です。ミニバッチを m 個の小片（マイクロバッチ）に刻み、間を置かず次々に投入します。先頭マイクロバッチがS1へ渡った直後、S0は2個目を処理でき、パイプラインが充填（fill）されると全ステージが同時に稼働します。最後のマイクロバッチが流れ切る**排出（drain）**まで、定常状態では遊休が消えます。

GPipe: マイクロバッチ4個（番号）を全部前進→全部後退
S0: F1 F2 F3 F4 .. .. .. .. B4 B3 B2 B1
S1: .. F1 F2 F3 F4 .. .. B4 B3 B2 B1 ..
S2: .. .. F1 F2 F3 F4 .. B4 B3 B2 B1 .. ..
S3: .. .. .. F1 F2 F3 F4 B4 B3 B2 B1 .. .. ..
（最終ステージS3はF4の直後に同じマイクロバッチをB4で後退できる）

残るのは充填と排出にかかる立ち上がり・立ち下がりだけです。前進・後退あわせた所要を考えると、バブルが占める割合はおおよそ次式になります。

バブル率 ≈ (p - 1) / (m + p - 1)

ここで p はステージ数、m はマイクロバッチ数です。m を p に対して十分大きく（経験則で m が p の4倍以上）とればバブル率は小さくなります。たとえば p = 4、m = 16 ならバブル率は 3/19 ≒ 16%、m = 32 なら 3/35 ≒ 9% まで下がります。マイクロバッチを増やすほど効率は上がる——これがパイプライン並列の中心原理です。

GPipe と 1F1B：活性化メモリで効くスケジュール差

マイクロバッチをどの順で前進・後退させるかがスケジュールで、代表が GPipe と 1F1B（PipeDream系）です。両者のバブル率はほぼ同じですが、保持する活性化メモリが決定的に違います。

GPipe は素直に「全マイクロバッチを前進させてから、全マイクロバッチを後退させる」方式です。逆伝播は順伝播の活性化を要するため、m 個ぶんの活性化を後退開始まで全部抱え続けることになります。マイクロバッチを増やすほどバブルは減りますが、活性化メモリが m に比例して膨らむジレンマを抱えます。

1F1B（one-forward-one-backward）は、充填後に1回前進したら1回後退するよう交互に走らせます。先に流したマイクロバッチを早めに後退させて活性化を解放するため、各ステージが同時に抱える活性化はマイクロバッチ数 m ではなくステージ数 p 程度で頭打ちになります。バブル率を保ったまま活性化メモリを m から p オーダーへ落とせるのが核心で、PipeDream-Flush（同期版1F1B）として大規模学習の標準になっています。

メモリと通信のトレードオフ

パイプライン並列の設計は、バブル（時間の無駄）・活性化メモリ・通信の三者のやりくりです。

• バブル対策はマイクロバッチを増やすこと。ただしGPipeでは活性化メモリと正面衝突するため、1F1Bで活性化を p オーダーに抑えるのが前提になります。
• それでも活性化が支配的なら、活性化再計算（勾配チェックポイント）を重ねます。順伝播の中間活性化を保存せず捨て、逆伝播で必要になった区間だけ順伝播をやり直して作り直します。活性化メモリを大きく削れる代わりに、順伝播ぶんの計算が増える（おおよそ1.3〜1.5倍）交換です。パイプラインのステージ境界は再計算の区切りと相性がよく、両者は併用されます。
• 通信はステージ境界の活性化のみで、テンソル並列のような層ごとの高頻度AllReduceは不要です。授受するのはマイクロバッチ1個ぶんの活性化テンソルで、しかも隣接ステージ間のP2P送受信に閉じます。だからネットワークが相対的に細いノード間に展開しても破綻しにくいのです。

3D並列のなかでの位置づけ

実際の超大規模学習では、パイプライン並列は単独では使われず、3つの並列軸を掛け合わせる3D並列の一角を担います。割り当ての原則は「通信が高頻度なものほど内側（近い）GPUへ」です。

典型構成は、ノード内の8枚をテンソル並列で密結合し、その単位を複数ノードにまたぐパイプラインステージとして並べ、さらにこのパイプライン全体をデータ並列で複製します。たとえば「テンソル並列8 × パイプライン並列4 × データ並列N」のように、各軸の積が総GPU数になります。パイプライン並列が担うのは、テンソル並列だけではモデルが載りきらず、しかもノード間で高頻度通信を避けたい中間レンジの分割です。

まとめ：充填率という1つの問いに還元する

パイプライン並列は、突き詰めれば「各ステージをどれだけ遊ばせずに充填できるか」という1問に帰着します。バブルはステージ間の依存が生む構造的な遊休で、マイクロバッチはそれを時間方向に重ねて隠す手段、スケジュール（GPipe/1F1B）はその重ね方を活性化メモリと引き換えに最適化する選択です。

この見立てを持つと、「ステージを増やしたのに速くならない」「マイクロバッチを増やしたらメモリが溢れた」「ノードをまたいでも意外と速い」といった現象が、充填率・活性化メモリ・通信パターンの言葉で一貫して説明できます。メモリ全体の内訳は 分散学習：データ並列・モデル並列・ZeRO と、活性化や状態の精度を落として帯域を稼ぐ理屈は 混合精度学習 と、なぜここまでして巨大化するのかは スケーリング則 と合わせて読むと、巨大モデルを学習可能にする工夫の全体像が線でつながります。