Video-Rate Streaming Stylization on a Vision-Aware MLLM-Conditioned Edit Diffusion: Asymmetric Batched Inference on a Distilled UNet + MLLM Text Encoder

技術要約：ビジョン認識型MLLMを条件付けとしたエディット・ディフュージョンにおけるビデオレート・ストリーミング・スタイライゼーション

問題提起
ディフュージョンモデルを用いたリアルタイムのビデオ変換は、伝統的に、U-Netデノイザーがフレームごとの計算ボトルネックとなり、テキストエンコーダーは軽量なCLIPクラスのネットワーク（パラメータ数 約125M）であるテキスト条件付き画像ディフュージョンスタックに依存してきました。しかし、「ビジョン認識型」のエディット・ディフュージョンにおいて、システムがソース画像とテキスト指示の両方を処理する必要がある場合、デノイザーを強力に蒸留（4ステップまたは1ステップの生徒モデルへ削減）すると、このボトルネックが逆転します。これは、テキストエンコーダーが重いマルチモーダル大規模言語モデル（MLLM、例：Qwen3-VL、2.13Bパラメータ）に置き換わるためです。

この「小型蒸留デノイザー＋重量級MLLMエンコーダー（SDD-MTE）」レジームでは、MLLMテキストエンコーダーがクリティカルパスとなります。標準的なストリーミング技術は、デノイザー主導のパイプライン向けに設計されているため、ここでは機能しません。その理由は以下の通りです：

1. エンコーダーのレイテンシ： MLLMエンコーダーはデノイザーよりも大幅に大きく、回転位置エンコーディング（RoPE）などの内部的なCPU-GPU同期ポイントを含んでいるため、単純なシングルストリーム・ディスパッチができません。
2. 時間的一貫性のオーバーヘッド： ControlNet-LLLiteのような既存のテンポラルアダプターは、Pythonの分岐やテンソル同一性チェックに依存しており、これが torch.compile のグラフキャプチャを破壊し、ナイーブな実装ではベースとなるU-Netよりも約3.5倍遅くなります。
3. 数値的不安定性： 広範囲なMLLM出力（標準偏差=37、最大値=1160）はFP16アテンション機構をオーバーフローさせ、StreamDiffusionなどのシステムが依存するTensorRTパスを利用不能にします。

本論文は、この逆転したボトルネック・レジームにおいて、単一のコンシューマーGPU内でビデオレートのストリーミング・スループットを実現するという課題に取り組んでいます。

手法
著者らは、0.39Bの蒸留U-Net（DreamLite-mobile）と2.13BのQwen3-VLエンコーダーを組み合わせた、3つの特定のエンジニアリング・メカニズムに基づいたストリーミング・パイプラインを提案しています。

1. 非対称サイドストリーム／メインストリーム・パイプライニング：

   • パイプラインは2つの並行するCUDAストリームに分割されます。メインストリームは、現在のバッチ（$n$）のコンパイル済みU-NetデノイジングとVAEデコーディングを処理します。
   • サイドストリームは、次回のバッチ（$n+1$）のMLLMテキストエンコーディング（TE）とVAEエンコーディングを並行して処理します。
   • この設計により、MLLMエンコーダー固有の同期レイテンシを、U-Netの計算の背後に隠蔽します。
   • バッチ・アモチゼーション（バッチによる償却）： パイプラインの各呼び出しの前に、$B$ フレーム（例：$B=8$ または $16$）をバッファリングします。MLLMエンコーダーはバッチサイズに対してサブ線形にスケールする（$B=8$ においてサブ線形性 $s \approx 0.226$）一方で、コンパイル済みU-Netはほぼ線形にスケールする（$s \approx 0.77$）ため、バッチ化によってU-Netのコストを比例的に増大させることなく、フレームあたりのTEコストを大幅に削減できます。
   • 静的プロンプト・キャッシング（オプション）： 固定された指示を持つストリームの場合、システムは代表的な1フレームをエンコードし、そのキー/バリューテンソルをバッチ全体にブロードキャストするか、あるいは$N$バッチごとにエンコーディングを更新することができます。

2. コンパイルフレンドリーなControlNet-LLLiteの再定式化：

   • torch.compile 最適化を有効にするため、著者らはControlNet-LLLiteアダプターをリファクタリングし、以前は毎フレームDynamoの再コンパイルを強制していたPythonの分岐やテンソル同一性の変更を排除しました。
   • 主な変更点として、条件付けエンベディングを固定サイズのバッファとして登録し、インプレース更新を行うこと、トレーニング専用のパス（ドロップアウト、dtypeチェック）を削除すること、および専用の forward_inference メソッドを公開することが挙げられます。
   • これにより、U-Netとアダプターの全スタックを単一の融合グラフに折り畳むことが可能になり、エージ（eager）参照実装と比較して4.75倍の高速化を実現しました。

3. 周期的なコンディショニング更新とフック・サブセット：

   • 更新スケジュール： 前フレームをワープさせたものから派生するLLLiteコンディショニングエンベディングを毎バッチ再計算する代わりに、システムは$N$バッチごと（例：$N=8$）にこれを再構築します。これにより、LLLiteパスの実行時間を支配するコンディショニングCNNのコストを償却します。
   • フック・サブセット： 全108個のフックから、down_blocks にのみ存在する38個のフックのサブセットへと削減しました。これにより、コンディショニングエンコーダーのワークロードを約65%削減しつつ、全108個のフックを使用した場合に発生する空間的な鮮鋭度の喪失（「滑らかな紫色のアーティファクト」を生む傾向がある）を回復させています。
   • 非同期フロー： Farneckオプティカルフローの計算は、プリフェッチ中に非同期でスレッド化され、次のサイドストリームのスロットとオーバーラップするように実行されます。

主な貢献

• システム・アーキテクチャ： 逆転したボトルネック・レジームにおける、MLLMエンコーダーを別個の並行ワークロードとして扱う新しい非対称パイプライニング戦略。
• コンパイラ最適化： torch.compile と互換性のあるリファクタリングされたControlNet-LLLite実装により、テンポラルアダプターの融合グラフ実行を可能にした。
• 効率化メカニズム： バッチによるTEの償却、周期的なコンディショニング更新、およびフック・サブセットの選択を組み合わせることで、品質の大幅な低下を招くことなく、フレームあたりのレイテンシを削減。
• 実証的検証： コンシューマー向けハードウェア（RTX 3090 Ti, 4090, 5090）上での包括的な評価により、インドメインおよびクロスデータセットのシナリオにおける持続的なスループットと時間的一貫性を実証。

結果
解像度512×512、バッチサイズ $B=8$、1ステップ推論（$K=1$）において、単一のRTX 3090 Tiで評価：

• スループット： パイプラインは、480フレームの実行において、27.4 FPS（p50レイテンシ ~0.5s）および $B=16$ で 29.6 FPS（p50レイテンシ ~1.0s）を維持。
• ハードウェア・スケーリング： パフォーマンスは、RTX 4090で 54.9 FPS、RTX 5090で 74.1 FPS までスケール。
• 品質： 「チャンピオン」構成（down_blocksフック・サブセット ＋ 周期的な更新）は、LLiteなしのベースライン（22.97）と比較して、フリッカーを20%低減した 18.34 のワーピング誤差（$\epsilon_w$）を達成しつつ、空間的詳細（Sobelスコア 4.74 vs ベースライン 5.10）を維持。
• 汎用性： リリースされたテンポラルアダプターは、未使用のDAVIS-2017シーケンスおよび7つの非DAVISソースからの15個のクリップに対して、インドメインのチャンピオンモデルのノイズ範囲内のパフォーマンスで、良好に一般化。
• プロンプトの一般化： 未知のスタイルプロンプト（例：ゴッホ）に対しても良好に動作するが、訓練マニフォールド外の高周波テクスチャを持つスタイル（例：コミックのハーフトーン）については性能が低下する。

意義と主張
本論文は、ベンチマークの優位性を主張するものではなく、システム研究としての位置付けを行っています。著者らは、StreamDiffusionクラスのシステム（CLIPエンコーダーを使用するもの）に対する優位性を主張しているのではなく、文脈を提供するために、同じスタックを用いたStreamDiffusionの再実行結果と比較しています。

主要な意義は、テキストエンコーダーが重いMLLMであっても、システムアーキテクチャを再設計すれば、単一のコンシューマーGPU上でビデオレートのストリーミングが可能であることを示した点にあります。著者らは、標準的なデノイザー加速技術ではこのレジームには不十分であり、提案されたメカニズム（非対称パイプライニング、コンパイルフレンドリーなアダプター、および償却されたコンディショニング）がリアルタイム性能を解放するために必要であることを強調しています。

また、本論文は、実践者へのガイドとしても機能しており、この特定の領域における一般的なエンジニアリングの行き止まりを避けるための負の結果（例：ナイーブな潜在変数混合、MLLM出力によるTensorRT FP16の失敗、および平滑化アーティファクトの指標としてワーピング誤差のみを使用することの落とし穴）を文書化しています。