分散推論

分散推論は、ワークロードを複数のGPUに分散して処理します。これにより、より大きなモデルをメモリに収めることができ、同時に多くのプロンプトを処理できます。

Diffusersは4つの戦略をサポートしています。それぞれに独自のガイドがあり、このページではその選択を支援します。

戦略の選択

各戦略は異なる問題を解決するため、リソースの制約に基づいて1つを選択してください。

戦略	分割	削減	1つのプロンプトのレイテンシ	最も適しているのは
データ並列性	レプリカ間のプロンプト	各GPUが完全なコピーを保持しているため、何もしません	変更なし	モデルがすでに収まり、プロンプトが多数ある場合
device_map	デバイス間で分散されたコンポーネント	重みのメモリ	やや劣る	モデルが収まらず、インターコネクトが遅い
コンテキスト並列性	入力シーケンス	アクティベーションメモリ	lower	シーケンスが長い場合、例えば高解像度の画像や動画など
テンソル並列性	重み行列	重みのメモリ	lower	あるコンポーネントの重みが収まらず、インターコネクトが高速な場合

実用的なガイドライン:

• モデルがすでに収まり、プロンプトが多数ある場合は、データ並列性を使用してください。モデルを変更することなく、GPU の数に応じてスループットをスケーリングでき、単一プロンプトのレイテンシには影響しません。AccelerateまたはPyTorch Distributedで設定します。
• 単一のコンポーネントの重みが収まらない場合は、メモリとレイテンシの両方を低減できるため、まずテンソル並列化を試してください。テンソル並列化はブロック境界ごとに通信を行うため、NVLinkのような高速なインターコネクトが必要です。PCIeでは、レイヤーごとのトラフィックが計算の節約を上回る可能性があり、その場合はdevice_mapの方が適切な選択となります。device_mapは、コンポーネントが個別には問題ないが全体として大きすぎるケースも処理できます。
• 問題が重みではなくアクティベーションにある場合は、コンテキスト並列性を使用してください。これは、多くのフレームを持つ大きな画像や動画のような長いシーケンスに役立ちます。Context parallelismガイドのベンチマークからバックエンドを選択してください。
• 重みとシーケンスの両方が大きすぎる場合、Diffusers は同じモデルにテンソル並列化とコンテキスト並列化を適用できません。ParallelConfig は両方の設定を渡すとエラーを発生させ、enable_parallelism はすでに並列化済みのモデルに対して2回目に呼び出すことはできません。

xDiTおよびParaAttentionのコミュニティ統合は、それぞれ独自のコンテキスト並列性実装を提供しています。

Update on GitHub