ライブプレビューを有効にすると、ローカル画像生成が遅くなるのはなぜですか?

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

ライブプレビューでは、ノイズ除去の実行中に中間潜在表現のデコード、変換、コピー、表示を行う必要があるため、ローカル画像生成の速度が低下します。

拡散モデルは通常、最終画像の準備が整うまで、中間状態をコンパクトな潜在表現のまま保持します。ライブプレビューを使用すると、サンプリングステップの間に追加処理が挿入されます。デコーダーがピクセルを再構成し、ランタイムがデバイス処理を同期し、サーバーがフレームをエンコードして送信する場合もあります。この処理を高解像度で繰り返すと、生成処理自体と計算資源やメモリ帯域幅を奪い合う可能性があります。

プレビューでは、最後に1回だけ行うデコードが複数回の中間デコードになる

プレビューを使わない場合、サンプラーは多数のステップで潜在テンソルを更新し、完了間際に画像デコーダーを1回呼び出します。各ステップでプレビューを表示すると、近似デコーダーまたは完全なデコーダーが繰り返し呼び出されるため、最終的なノイズ除去の軌道を改善しない処理が増加します。

プレビューのデコードオーバーヘッドに関するドキュメントでは、完全なVAEプレビューによって処理時間が大幅に増加する可能性がある一方、小型プレビューデコーダーを使うとコストは軽減されるものの、完全には解消されないと報告されています。この比較では、デコーダーの選択とプレビュー頻度が主要な変数であることが示されています。

デコードされた特徴マップと出力フレームは解像度に応じて増加するため、ピクセル数が多いほど速度低下も大きくなります。512ピクセルで5ステップごとにプレビューを表示する場合は十分軽量でも、各ステップでフル解像度のデコードを行うと、短時間で完了する高速サンプリング処理でもプレビューが大半の時間を占める可能性があります。

デバイス同期とメモリ転送がサンプリングループを中断する

アクセラレーターのカーネルは通常非同期で実行されるため、ランタイムは効率的に処理をキューに追加できます。プレビューをホスト側に読み戻すと、同期が強制され、画像バッファーが割り当てられ、共有メモリまたはPCIe経路を通じてデータが移動し、サンプリングを再開する前に変換の完了を待つ必要が生じる場合があります。

潜在拡散アーキテクチャは、潜在拡散が圧縮空間で高コストな画像合成を行い、オートエンコーダーを使ってピクセルと潜在表現を相互変換する理由を説明しています。各プレビューでは、最終出力のみを生成する処理経路よりも早い段階で、より頻繁にこの境界を越えることになります。

ユニファイドメモリシステムでは明示的なPCIeコピーを避けられますが、帯域幅とキャッシュ容量の競合は依然として発生します。一方、専用GPUでは転送と同期のコストが発生する可能性があります。そのため、表示されるプレビューフレームには、ニューラルデコードだけでなくシステム側のオーバーヘッドも含まれます。

デコードを最適化すると、表示用エンコードがボトルネックになることがある

ローカルのウェブインターフェースでは、プレビューのリサイズ、色変換、JPEGまたはPNGへのエンコード、シリアライズ、ソケット経由での送信、ブラウザーによるデコードと描画が行われることがあります。数十回繰り返される小さな処理が、高速な小型デコーダーよりも長い時間を要する場合があります。

リアルタイム拡散パイプラインに関する研究では、バッチ処理とパイプライン最適化によってストリーミング拡散のレイテンシーを削減しており、リアルタイム出力には単一のモデルカーネルではなく、実行経路全体が関係することが示されています。プレビューの転送処理は、デノイザーの理論上のステップ数には含まれません。

プレビューの描画が、実行時間の増加原因だと常に考えるのは誤りです。異なるシード、ウォームアップ、温度制限、モデルのオフロード、別のGPU負荷などによって、処理時間は変化します。プレビューを無効にした状態と、他の設定をすべて維持した状態で同一のリクエストを比較してください。

ステージと頻度ごとにプレビューのコストを測定する

同じプロンプト、シード、モデル、サンプラー、ステップ数、解像度、バッチサイズを使い、プレビューなし、10ステップごと、5ステップごと、各ステップで実行します。合計時間、ノイズ除去時間、デコード時間、画像エンコード時間、転送バイト数、ブラウザーの描画レート、ピークメモリ、デバイス使用率を記録してください。

メモリと計算量の測定値をリソースボトルネックのテストと関連付け、その後、小型デコーダーと完全なVAEを使って再実行します。すべての実行で最終画像のデコードを有効にし、中間プレビューによる追加分だけを比較できるようにしてください。

有用なフィードバックを得られる範囲で、最も遅いプレビュー頻度を選びます。デコードが支配的な場合は、より小型のプレビューデコーダーまたは低い解像度を使用します。エンコードと転送が支配的な場合は、フレームをまとめて送信します。ノイズ除去時間が変化する場合は、同期とメモリ圧迫を調査してください。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.