Buckets:

hf-doc-build/doc / diffusers /main /ja /training /distributed_inference.md
mishig's picture
|
download
raw
3.67 kB

分散推論

分散推論は、ワークロードを複数の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のコミュニティ統合は、それぞれ独自のコンテキスト並列性実装を提供しています。

Xet Storage Details

Size:
3.67 kB
·
Xet hash:
5e29d29dca01d36082ea49404ae77b467cec11b86bf8ff462bc9da240a20d19a

Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.