翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# モデルのパイプライン化
<a name="model-parallel-core-features-pipieline-parallelism"></a>

SageMaker のモデル並列ライブラリの主要機能の 1 つは、モデルトレーニング中にデバイス間で行われる計算やデータ処理の順序を決定する*パイプライン並列処理*です。パイプライン化は、複数の GPU にそれぞれ異なるデータサンプルで同時に計算させることで、モデル並列処理における真の並列化を実現し、逐次計算によるパフォーマンスの低下を克服する手法です。パイプライン並列処理を使うと、GPU 使用率を最大化するように、トレーニングジョブはすべてのマイクロバッチにわたってパイプライン方式で実行されます。

**注記**  
パイプライン並列処理は、モデルパーティショニングとも呼ばれ、PyTorch と TensorFlow の両方で使用できます。サポートされているフレームワークのバージョンについては、「[サポートされているフレームワークと AWS リージョン](distributed-model-parallel-support.md)」を参照してください。

## パイプライン実行スケジュール
<a name="model-parallel-pipeline-execution"></a>

パイプライン化は、ミニバッチのマイクロバッチへの分割に基づいており、マイクロバッチは、トレーニングパイプラインに 1 つずつ投入され、ライブラリランタイムで定義された実行スケジュールに従います。マイクロバッチは、トレーニングミニバッチのより小さなサブセットです。**パイプラインのスケジュールは、タイムスロットごとにどのマイクロバッチがどのデバイスで実行されるかを決定します。

例えば、パイプラインのスケジュールとモデルパーティションに応じて、GPU `i` はマイクロバッチ `b` で (フォワードまたはバックワードの) 計算を実行し、一方、GPU `i+1` はマイクロバッチ `b+1` で計算を実行するため、両方の GPU が同時にアクティブのままになります。1 回のフォワードパスまたはバックワードパスの間に、パーティショニングの決定に応じて、1 つのマイクロバッチの実行フローが同じデバイスに複数回アクセスする場合があります。例えば、モデルの先頭にあるオペレーションは、モデルの末尾にあるオペレーションと同じデバイス上に配置され、一方、その間のオペレーションは異なるデバイス上に配置されるため、このデバイスは 2 回アクセスされることになります。

ライブラリには、シンプルとインターリーブという 2 種類のパイプラインスケジュールがあり、SageMaker Python SDK の `pipeline` パラメータを使って設定できます。****ほとんどの場合、インターリーブパイプラインの方が GPU をより効率的に利用することで、より良いパフォーマンスを実現できます。

### インターリーブパイプライン
<a name="model-parallel-pipeline-execution-interleaved"></a>

インターリーブパイプラインでは、可能な限りマイクロバッチのバックワード実行が優先されます。これにより、アクティベーションに使用したメモリを迅速に解放し、メモリをより効率的に使用できるようになります。また、マイクロバッチ数をより多くスケールでき、GPU のアイドル時間を短縮できます。定常状態では、各デバイスはフォワードパスとバックワードパスを交互に実行します。これは、あるマイクロバッチのバックワードパスが、別のマイクロバッチのフォワードパスが終了する前に実行される可能性があることを意味します。

![\[2 つの GPU にわたるインターリーブパイプラインの実行スケジュールの例。\]](http://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/images/distributed/model-parallel/interleaved-pipeline-execution.png)


上の図は、2 つの GPU にわたるインターリーブパイプラインの実行スケジュールの例を示しています。図では、F0 はマイクロバッチ 0 のフォワードパス、B1 はマイクロバッチ 1 のバックワードパスを表しています。**Update** は、オプティマイザによるパラメータの更新を表しています。GPU0 は、可能な限り常にバックワードパスを優先 (例えば、F2 の前に B0 を実行)します。これにより、アクティベーションに使用したメモリをより早くクリアできます。

### 単純なパイプライン
<a name="model-parallel-pipeline-execution-simple"></a>

対照的に、シンプルパイプラインは、各マイクロバッチのフォワードパスの実行を終了してからバックワードパスを開始します。つまり、フォワードパスとバックワードパスのステージをそれぞれのステージ内でパイプライン化します。次の図は、2 つの GPU にわたる動作の例を示しています。

![\[各マイクロバッチのフォワードパスの実行後にバックワードパスを開始するパイプラインの例。\]](http://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/images/distributed/model-parallel/simple-pipeline-execution.png)


### 特定のフレームワークでのパイプライン実行
<a name="model-parallel-pipeline-frameworks"></a>

以降のセクションでは、SageMaker のモデル並列処理ライブラリが TensorFlow と PyTorch に対して行うフレームワーク固有のパイプラインスケジューリングの決定について学習します。

#### TensorFlow におけるパイプラインの実行
<a name="model-parallel-pipeline-execution-interleaved-tf"></a>

次のイメージは、自動モデル分割を使い、モデル並列処理ライブラリによってパーティショニングされた TensorFlow グラフの例です。グラフが分割されると、結果の各サブグラフは B 回レプリケートされます (変数を除く)。ここで、B はマイクロバッチの数です。この図では、各サブグラフは 2 回レプリケートされます (B=2)。`SMPInput` オペレーションがサブグラフの各入力に挿入され、`SMPOutput` オペレーションが各出力に挿入されます。これらのオペレーションは、ライブラリのバックエンドと通信し、互いにテンソルを転送します。

![\[自動モデル分割を使い、モデル並列処理ライブラリによって分割された TensorFlow グラフの例。\]](http://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/images/distributed/model-parallel/interleaved-pipeline-tf.png)


次のイメージは、B=2 で分割された 2 つのサブグラフに勾配演算を追加した例です。`SMPInput` オペレーションの勾配は `SMPOutput` オペレーションであり、その逆も同様です。これにより、バックプロパゲーションの間に勾配を逆方向に流すことができます。

![\[B=2 で分割された 2 つのサブグラフに勾配演算を追加した例。\]](http://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/images/distributed/model-parallel/interleaved-pipeline-tf.gif)


この GIF は、B=2 マイクロバッチと 2 つのサブグラフを含むインターリーブパイプライン実行スケジュールの例を示しています。各デバイスは、サブグラフのレプリカを 1 つずつ順番に実行し、GPU 使用率を向上させます。B が大きくなると、アイドル時間のスロットの割合はゼロになります。特定のサブグラフレプリカで (フォワードまたはバックワードの) 計算を実行するときはいつでも、パイプラインレイヤーは対応する青の `SMPInput` オペレーションに信号を送って実行を開始します。

1 つのミニバッチ内のすべてのマイクロバッチからの勾配が計算されると、ライブラリはマイクロバッチ全体の勾配を結合し、それをパラメータに適用できます。

#### PyTorch におけるパイプライン実行
<a name="model-parallel-pipeline-execution-interleaved-pt"></a>

概念的には、パイプラインは PyTorch でも同様の考えに従います。ただし、PyTorch は静的グラフを含まないため、モデル並列処理ライブラリの PyTorch 機能はより動的なパイプラインパラダイムを使います。

TensorFlow と同様に、各バッチは複数のマイクロバッチに分割され、各デバイスで一度に 1 つずつ実行されます。ただし、実行スケジュールは、各デバイスで起動された実行サーバーを介して処理されます。別のデバイスに配置されたサブモジュールの出力が現在のデバイスで必要になるたびに、実行リクエストがサブモジュールへの入力テンソルと共にリモートデバイスの実行サーバーに送信されます。次に、サーバーは指定された入力でこのモジュールを実行し、現在のデバイスに応答を返します。

リモートサブモジュールの実行中、現在のデバイスはアイドルであるため、現在のマイクロバッチのローカル実行は一時停止し、ライブラリランタイムは実行を現在のデバイスがアクティブに動作できる別のマイクロバッチに切り替えます。マイクロバッチの優先順位は、選択されたパイプラインスケジュールによって決定されます。インターリーブパイプラインスケジュールの場合は、計算のバックワードステージに存在するマイクロバッチが可能な限り優先されます。