1. WAN 2.2 LightningモデルとGGUFを活用した高速動画生成戦略 [0]

thumbnail

1.1. 従来のワークフローとGGUFモデルへの移行 [5]

  1. 従来のワークフローの問題点:

    1. Lightningモデルの公式ワークフローには、それぞれ25GBのSafeTensor拡散ファイルが2つ含まれており、これは非効率的である [8]
    2. この巨大なファイルはダウンロードする必要がない [7]

  2. 代替モデルと設定:

    1. 代わりに、高ノイズ(high noise)と低ノイズ(low noise)の2つのLoRAモデルをダウンロードして使用する [10]
    2. ダウンロード後、モデルを識別できるように「One 2.2」を先頭に付けてリネームすることが推奨される [13]
    3. これらのLoRAはComfyUIのLoRAフォルダに配置し、LoRAローダーでロードする [13]
    4. 以前にロードしたGGUFモデル（Q4モデルを使用）をUNetフォルダで使用する [13]
    5. 必須の追加モデルとして、UMT5 XXL FP8モデルが必要である [20]
    6. VAEには、Van 2.1 VAEが機能するため、これを使用する [23]

  3. プロンプトと初期設定:

    1. 使用したい画像を用意する [27]
    2. プロンプトは、画像が動きを示唆している場合は不要な場合があるが、特定の動きが必要な場合は設定する [31]
    3. ネガティブプロンプトには、提供されている中国語の設定をそのまま使用し、変更しない [34]
    4. サイズ設定（解像度）は、後の高速化ハックで非常に重要になる [28]

1.2. 4ステップKサンプラー設定による高速化 [37]

  1. Kサンプラーの変更点:

    1. 以前のワークフローとの違いは、Kサンプラーが4ステップでレンダリングされる点である [38]
    2. 最初のKサンプラー: 0ステップから2ステップまでをUlerサンプラーでレンダリングする [39]
    3. 2番目のKサンプラー: 2ステップ目から最終ステップ（4ステップ目）までをUlerサンプラーでレンダリングする [39]

  2. 追加機能:

    1. 初期動画が生成された後、必要に応じて補間（Interpolation）を使用してフレーム数を増やし、よりスムーズな動画を得ることができる [44]
    2. 補間はレンダリング時間をあまり消費しない [47]

2. レンダリング時間の比較とプレビュー高速化ハック [48]

thumbnail

  1. レンダリング時間の比較 (4080 GPU基準):

    1. 設定: 解像度640x640、初期フレーム数49フレーム [49]
    2. 従来の8ステップワークフロー: レンダリング時間は135秒であった [53]
    3. 新しいLightning LoRAワークフロー (4ステップ): レンダリング時間は80秒に短縮され、大幅な時間節約が実現された [56]

  2. 超高速プレビューのためのハック:

    1. 解像度の半減: 画像から動画への設定で、解像度を320x320に半減する [59]
    2. 目的: この低解像度動画は最終的な使用を目的とするものではないが、非常に迅速なプレビューを提供し、試行錯誤の時間を大幅に節約できる [60]
    3. 再レンダリング: プレビューで気に入った結果が得られた場合、シードを固定して同じ結果を保証した後、解像度を2倍に戻して再度レンダリングする [60]
    4. 結果: 49フレームの320x320動画のレンダリング時間は、4080 GPUでわずか36.4秒であり、これは非常に高速である [62]