> [!abstract] 概要 > DNN 訓練は極めて時間がかかるため、複数アクセラレータへの効率的な並列化が必要である。現在の並列化手法の主流は、1 反復を複数ワーカーに分割するバッチ内並列化(intra-batch parallelism)だが、ワーカー数が増えると逓減収益に悩まされる。本論文では PipeDream を提案する。PipeDream はバッチ内並列化にバッチ間パイプライン化(inter-batch pipelining)を加えることで並列訓練スループットをさらに向上させ、計算と通信のオーバーラップを促進しながら通信量を削減する。従来のパイプライン化と異なり、DNN 訓練は双方向であり、フォワードパスの後にそのフォワードで使った状態・中間データを用いるバックワードパスが続く。単純なパイプライン化ではフォワードとバックワードで使う重みバージョンが一致しないか、過度なフラッシュによる低効率を招く。これらの課題に対処するため、PipeDream はモデルパラメータのバージョン管理(重みスタッシング)で数値的に正確な勾配計算を実現し、最小限のパイプラインストールで異なるミニバッチのフォワードとバックワードを異なるワーカーで並行実行する 1F1B スケジュールを提案する。また PipeDream はDNN レイヤーをワーカー間で自動的に分割し、作業を均衡させながら通信を最小化する。多様な DNN タスク・モデル・ハードウェア構成での広範な評価によれば、PipeDream は一般的なバッチ内並列化手法と比較して最大 5.3 倍の高精度達成時間短縮を示した。 ## 論文情報 | 項目 | 内容 | |------|------| | タイトル | PipeDream: Generalized Pipeline Parallelism for DNN Training | | 著者 | Deepak Narayanan, Aaron Harlap, Amar Phanishayee, Vivek Seshadri, Nikhil R. Devanur, Gregory R. Ganger, Phillip B. Gibbons, Matei Zaharia | | 所属 | Microsoft Research / Carnegie Mellon University / Stanford University | | 会議 | SOSP 2019 (ACM Symposium on Operating Systems Principles) | | 発表日 | 2019-10-27〜30 | | DOI | 10.1145/3341301.3359646 | | URL | https://people.eecs.berkeley.edu/~matei/papers/2019/sosp_pipedream.pdf | ## 概要 PipeDream は DNN 訓練に**パイプライン並列化(pipeline parallelism)**を導入したシステムである。モデルを複数ステージに分割し、各ステージを独立した GPU に割り当てて、異なるミニバッチのフォワードとバックワードを時間方向に重ね合わせる。これにより、バッチ内並列化(データ並列化・モデル並列化)が抱える高通信コストを回避しながら高いハードウェア効率を達成する。 従来の(同期的)パイプライン化は GPipe のように一定数のマイクロバッチをフォワード→バックワードの順に流し、定期的なフラッシュによって統計効率を維持する。一方 PipeDream は非同期に複数のミニバッチをパイプラインに注入し、重みスタッシングで正確な勾配を保証する。 ## 問題設定 **データ並列化の通信ボトルネック**: 32 GPU でのデータ並列訓練では、モデルによって通信によるストール時間が全体の 90% に達する(VGG-16、1080Ti クラスタ)。GPU 計算速度の向上とともに通信ボトルネックはさらに深刻化する。 **モデル並列化の低稼働率**: モデル並列化(レイヤーを GPU に分割)は GPU が 1 台ずつしか稼働せず、4 ワーカー構成でも低稼働率を招く(図 2)。 **GPipe のフラッシュによる効率低下**: GPipe はパイプライン深度 m のミニバッチを注入後に全フラッシュを行うため、$m=4$ の場合でも約 75% の計算時間がフラッシュのストールになる(図 3)。 PipeDream はこの 3 問題を同時に解決することを目指す。 ## 提案手法 ### 全体設計 PipeDream はモデルの連続レイヤー群を**ステージ**に分割し、各ステージを GPU(ワーカー)に割り当てる。動作は「ワークフロー(プロファイリング → 最適化 → 実行)」の 3 段階から成る(図 6)。 ### 課題 1: ワーク分割(§3.1) **問題**: 最も遅いステージがパイプライン全体のスループットを律速する。ステージ間通信も効率を低下させる。 **解法: 動的計画法による自動分割** PipeDream はまず単一 GPU 上で 1,000 ミニバッチのプロファイリングを実施し、各レイヤー $l$ について以下を記録する: - $T_l$: フォワードとバックワードの合計計算時間 - $a_l$: 出力アクティベーションのサイズ(バイト) - $w_l$: 重みパラメータのサイズ(バイト) 次に **2 段階の動的計画法**でレイヤーを $N$ ステージに分割する。目的関数は「最も遅いステージの処理時間を最小化すること」であり、最適部分構造を持つため多項式時間で厳密解が求まる。階層型トポロジ(サーバ内・サーバ間の 2 階層)に対応し、大きな出力は高帯域リンクへ優先的に送るよう考慮する。 さらに**ステージの複製**(データ並列化)も許容することで負荷均衡を促進する。例えば VGG-16 では畳み込み層群(計算量大)を複製し、全結合層(重み大)を複製しない「15-1」構成が自動生成される。実行時間は全モデル・全ハードウェア構成で 8 秒未満。 ### 課題 2: スケジューリング(§3.2) **問題**: 双方向パイプライン(フォワード→バックワード)での各ワーカーの動作をどう決定するか。 **解法: 1F1B スケジュール** 定常状態では各ワーカーが「フォワード → バックワード → フォワード → バックワード …」を厳密に交互に繰り返す(**1F1B: One-Forward-One-Backward**)。 パイプラインを満たすのに最小限必要なミニバッチ数は: $\text{NOAM} = \frac{\text{総ワーカー数}}{\text{入力ステージの複製数}}$ この数だけスタートアップ時にミニバッチを注入し、定常状態では常に全 GPU が何らかのミニバッチを処理する(図 4)。バックワードがフォワードの 2 倍の時間がかかる一般的な場合でも成立する。 ステージが複製されている(データ並列化)場合は、ミニバッチ ID に基づく**決定論的ラウンドロビン**でワーカーを選択する(**1F1B-RR**)。フォワードとバックワードで同一ワーカーが処理することを保証し、高コストな分散調整を不要にする。 ### 課題 3: 効果的な学習(§3.3) **問題**: 単純なパイプライン化では、ミニバッチのフォワードとバックワードで異なる重みバージョンが使われ、無効な勾配が生じてモデルが収束しない。 **解法: 重みスタッシング(Weight Stashing)** 各ステージはフォワードパスを実行した後、その時点での重みのコピーを保存(**スタッシュ**)する。バックワードパスではスタッシュした重みを使い、同一バージョンで勾配を計算する。 数学的には、ステージ $n$ のパイプラインに対して更新式は: $w^{(t+1)} = w^{(t)} - \nu \cdot f(w_1^{(t-n+1)}, w_2^{(t-n+2)}, \ldots, w_n^{(t)})$ 重みスタッシングなし(単純パイプライン化)では、この勾配はいかなる $w$ の有効な勾配にもならない。 **垂直同期(Vertical Sync)** はオプションの追加機構で、すべてのステージで同一バージョンの重みを使うことを保証する。有効にすると、更新式はデータ並列化(BSP)の $n$ ワーカー版と意味論的に同等になる。ただしデフォルトは無効(追加メタデータが必要なため)。 **メモリオーバーヘッド**: $n$ ステージのパイプラインでは最大 $n$ ミニバッチが同時に処理中になるが、各ステージは全重みではなく $1/n$ の重みのみ保持するため、ピーク時のメモリ使用量はデータ並列化と同水準に収まる。 ## 新規性 PipeDream の新規性は以下 3 点に集約される: 1. **1F1B + 重みスタッシングの組み合わせ**: フラッシュなし(高効率)と正確な勾配計算(高統計効率)の両立を実現。GPipe はフラッシュが必要で、単純非同期パイプラインは正確な勾配を保証できなかった。 2. **自動最適分割**: 動的計画法によるモデル・ハードウェア両方を考慮した分割の自動化。従来は手動または強化学習(リソース集約型)のみ。 3. **インタバッチとイントラバッチ並列化の統合**: データ並列化をステージ複製として組み込み、ストレートパイプラインと同一フレームワーク内で扱う。 **GPipe との比較**: GPipe は同期的パイプライン化でフラッシュが必要。GNMT-16 の 16 GPU 実験では、PipeDream は GPipe(NOAM 設定)に対して 55%〜71% のスループット優位を示した。GPipe が最大深度を使っても 35〜42% の優位が残る。 ## 実験設定 **クラスタ**: - Cluster-A: Azure NC24 v3、4×V100(PCIe)、10Gbps Ethernet - Cluster-B: AWS p3.16xlarge、8×V100(NVLink)、25Gbps Ethernet - Cluster-C: 非公開クラスタ、1×Titan X、40Gbps Ethernet **モデル**: VGG-16 / ResNet-50 / AlexNet(画像分類)、GNMT-8 / GNMT-16(機械翻訳)、AWD-LM(言語モデル)、S2VT(動画キャプション) **評価指標**: ターゲット精度到達時間(TTA: Time-to-Accuracy)、エポック時間 **フレームワーク**: PyTorch 1.1 + NCCL / Gloo、fp32 精度 ## 実験結果 **データ並列化との比較(表 1)**: | モデル | 構成 | スピードアップ(エポック時間) | スピードアップ(TTA) | |--------|------|------|------| | VGG-16 | 4サーバ×4GPU (Cluster-A) | **5.28×** | **5.28×** | | VGG-16 | 2サーバ×8GPU (Cluster-B) | 2.98× | 2.46× | | AlexNet | 4サーバ×4GPU (Cluster-A) | 4.92× | N/A | | GNMT-16 | 2サーバ×8GPU (Cluster-B) | 3.14× | 3.14× | | AWD-LM | 1サーバ×4GPU (Cluster-A) | 4.25× | 4.25× | | S2VT | 4サーバ×1GPU (Cluster-C) | 3.01× | 3.01× | ResNet-50 はデータ並列化が最適(畳み込み層は軽量な重み・大きな出力アクティベーション → パイプラインより全対全通信が有利)。 **他の手法との比較**: - モデル並列化と比較: VGG-16 で **14.9×**、AlexNet で **6.5×** 高速 - ハイブリッド並列化と比較: 最大 **80%** スループット向上 - FlexFlow(ハイブリッド)と比較: **1.9×** 高速(Cluster-B、AlexNet) - GPipe と比較: 35〜71% のスループット優位 **通信削減**: VGG-16 では DP 比 **85%** 以上の通信削減、AWD-LM では **88%** 削減。 **メモリ**: 4 ステージ構成でもデータ並列化と同等のメモリフットプリント(図 16)。 **最適化器の精度**: VGG-16 と GNMT-16 で精度 vs エポック数のグラフ(図 11)が DP とほぼ同等であることを確認。TTA スピードアップとエポック時間スピードアップが一致する行では、統計効率が保たれている(重みスタッシングが有効であることの証拠)。 ## 考察 PipeDream の効果は主に 2 つのメカニズムによる: 1. **通信削減**: パイプライン並列化では隣接ステージ間のアクティベーションとその勾配のみを通信するため、全対全のパラメータ通信(データ並列化)に比べて通信量が大幅に少なく、点対点通信として実現できる。 2. **計算・通信オーバーラップ**: 非同期的なステージ間通信が後続ミニバッチの計算と重なるため、通信によるストールが生じない。 ResNet-50 が恩恵を受けない理由は、畳み込み層の重みが小さく出力アクティベーションが大きいため、パイプライン化でも通信量がデータ並列化を上回るためである。モデルの特性(重みサイズ・アクティベーションサイズ)を考慮した分割選択の重要性を示す。 ## 強み / 弱点・課題 **強み**: - 自動分割: モデルとハードウェアのプロファイルから最適構成を 8 秒未満で計算 - 幅広いモデルへの適用性: 画像分類・翻訳・言語モデル・動画キャプションで実証 - 低メモリオーバーヘッド: データ並列化と同等のメモリフットプリント - 既存フレームワークとの統合: PyTorch 既存コードへの追加が約 3,000 行のライブラリ追加 **弱点・課題**: - ResNet-50 のような「重みが軽く出力アクティベーションが大きい」モデルでは効果なし - 垂直同期のデフォルト無効化: デフォルトではクロスステージの重みバージョン不一致が残り、厳密な BSP セマンティクスではない - LLM 時代の長コンテキスト/大規模 MoE への適用: 1F1B 以降のパイプラインスケジュール(Zero Bubble、DualPipe)や Sequence Parallelism との統合は後継研究(Megatron-LM、PipeDream-2BW 等)が対応 - バッチサイズの制約: NOAM が GPU 数に比例するため、ステージ複製がない場合は大規模では巨大バッチが必要 ## 後継・関連研究 - **GPipe** (同期型): フラッシュあり・再計算あり・メモリ最適化を優先 - **Megatron-LM**: テンソル並列化と 1F1B の組み合わせ、LLM 主流構成の礎 - **Zero Bubble Pipeline**: バックワードパスを複数チャンクに分け bubble をほぼゼロに - **DualPipe** (DeepSeek-V3): 双方向パイプラインで bubble を $(PP/2 - 1)$ に圧縮、通信完全隠蔽 - **PipeDream-2BW**: より少ないメモリで重みスタッシングを実現 詳細は [[並列化戦略]] §パイプライン並列化 を参照。