動画生成用 Next-Frame Prediction モデルにおける入力フレームのコンテキストパッキング活用

 (lllyasviel.github.io)
2 ポイント 投稿者 GN⁺ 2025-04-21 | 1件のコメント | WhatsAppで共有
  • FramePack は、13B の動画拡散モデルを 6GB のノート PC GPU メモリでも長尺動画生成に使うための、Next-Frame Prediction ベースのアプローチ
  • 入力フレームを同じ長さとして扱わず、フレームごとに patchifying kernel を変えることで、予測対象に近い重要なフレームへより多くの GPU リソースを割り当てる
  • HunyuanVideo 基準で 480p フレームは (1, 2, 2) で約 1536 トークン、(2, 4, 4) で 192 トークンまで削減でき、ストリーミング計算量は O(1)
  • FramePack Scheduling はフレーム重要度と圧縮率を調整し、image-to-video では開始フレーム群を同じ重要度として扱うスケジューリングも可能
  • 長尺動画生成で累積誤差により生じる drifting を抑えるため、causality を破る双方向サンプリングを使用し、inverted anti-drifting sampling は image-to-video に適している

FramePack の入力フレームコンテキストパッキング

  • FramePack は、Next-Frame または Next-Frame-Section Prediction モデルで複数の入力フレームを受け取り、新しいフレームを拡散生成する方式
  • 目標性能と利用条件は次のとおり
    • 13B モデルで 6GB のノート PC GPU メモリ上で fps 30 の数千フレームを生成
    • 単一の 8xA100/H100 ノードで 13B 動画モデルを batch size 64 でファインチューニング
    • 個人用 RTX 4090 で最適化前は 2.5 秒/フレーム、teacache 使用時は 1.5 秒/フレームで生成
    • timestep distillation なし
  • 核心は、入力フレーム画像を単純に連結するのではなく、論理的な GPU メモリレイアウト上でフレームごとのコンテキスト長を変えて配置すること
  • フレームごとのコンテキスト長は、異なる patchifying kernel で調整する
    • HunyuanVideo で 480p フレームは (1, 2, 2) patchifying kernel 使用時に約 1536 トークン
    • (2, 4, 4) patchifying kernel に変えると 1 フレームあたり 192 トークン
  • 次フレームの予測対象に近いフレームのように、より重要なフレームにはより長いコンテキストを与える
  • ストリーミング計算量は O(1) であり、O(nlogn) や O(n) ではない

スケジューリングとドリフト防止

  • FramePack Scheduling は、フレーム重要度が単純なパターンに従わない場合、圧縮率を変える場合、ユーザーが指定したフレームをより重要に扱う場合に対応する
  • image-to-video では最初のフレームが重要なため、開始フレーム群を同じ重要度にするスケジューリングを使用できる
  • すべてのスケジューリングは O(1) であり、複数のスケジューリングに関する評価は Paper に含まれている
  • Next-Frame Prediction モデルでは、動画が長くなるほど品質が低下する drifting が一般的な問題
    • 最後に生成したフレームを繰り返し入力して長尺動画を作ると、5〜6 回後に急速に崩れ、約 10 回後には大きく劣化する可能性がある
    • この問題は error accumulation または exposure bias とも呼ばれる
  • history noise augmentation、special cfg guidance、rolling diffusion timesteps といった既存手法に関する実験も論文に含まれている
  • drifting を根本的に扱うには、causality を破ってサンプリングを 双方向にする必要がある
    • vanilla sampling だけが causal 方式
    • anti-drifting sampling と inverted anti-drifting sampling は双方向方式
    • inverted anti-drifting sampling はすべての推論で最初のフレームを近似対象として扱い、image-to-video に適している

デモ条件と参考資料

  • デモ結果は RTX 3060 6GB ノート PC と 13B HY variant で計算された
    • image-to-5-seconds: 30fps、150 フレーム
    • image-to-60-seconds: 30fps、1800 フレーム
    • GitHub リポジトリに合わせるため、動画は h264crf18 で圧縮されている
  • 関連資料として Paper、Code、FramePack-P1 Preview が提供されている

関連記事

1件のコメント

 
GN⁺ 2025-04-21
Hacker News のコメント

  • この人は天才だ。知らない人もいるかもしれないが、ControlNet もこの人が作ったものだ。
    コンシューマー向けハードウェアで動く、初めて実用的な 動画生成モデルという点で大きな意味があり、近いうちに ControlNet のポーズ対応も出てくると期待している。

    • IC-Light もこの人が作った。なぜまだオープンソースに貢献しているのか不思議だ。
      大企業から途方もないオファーがあったはずなのに。本当に才能が抜きん出ている。
    • 動画生成は気が短くてちゃんと試していないんだけど、Wan も一般的なハードウェアでかなり良いのでは？

  • 人をどうしても踊らせようとしているのが面白い。インタビューのために座っている人まで、座ったまま踊り始める。

    • おそらくプロンプトに踊りが入っているからだと思う。プロンプトを変えれば別の動作もさせられるだろうけど、面白さは減りそう。
    • 多くの動画研究者が使っている大規模な公開 TikTok 学習データセットの影響に見える。
    • 興味深い観察だ。
      静止画像では常に 目を探し、動画では常に ダンスを探すようになる。

  • 例はかなり印象的だが、作成に使ったリソースは実質的には大したものではない。前世代のコンシューマー向けハードウェアでも推論を動かせそうに見える。
    いつか 5090 での推論スループットの数値も見てみたい。

  • これを空間方向にもできるだろうか？ たとえば画像を一度に生成するのではなく、上から下へ生成するようなことが可能なのか気になる。

  • これを外挿ではなく 動画補間に使えるだろうか？

    • 論文で言っている “inverted anti-drifting” は、基本的にはまず大きく外挿してから、逆向きに 補間する方式に近い。

  • 驚きだ。RAM のようなリソースがもっと多ければ、さらに速くなるのだろうか？ H100 や H200 では速度をもっと引き出せるのかも気になる。

  • できる動作が実質的に ダンスだけのように見える。

    • ダンスではない動きもかなりある。足の動きがダンスではない例は一つか二つだけだが、動いているのは足だけではない。
    • 画像入力に加えて テキストプロンプトも受け取るので、例にダンスを入れた可能性が高い。