新しい ComfyUI 環境でのHunyuanVideo FastVideo の復活は難航。妥協してどうにか完遂。
最後に新しい ComfyUI 環境で HunyuanVideo FastVideo の復活を
目指しました。正直、これの復活が大本命であり、それまでの
pyramidflow-miniflux、HunyuanVideo、 LTXV i2v Lightricks の復活
は助走というか「新しい環境に対して初回構築と同様に外部情報と
リソースを取り込んで来て作れば、旧環境が壊れた事態からは隔離
出来たものをゼロから作り込める」という確認に過ぎませんでした。
t2v の HunyuanVideo はさておき、i2v に関しては過去の比較において、
KlingAI ≧ CogStudio ＋ Dain-APP（32 fps）≧ LTXV i2v Lightricks
> pyramidflow-miniflux（384p）
の人物動画での優劣は確定していました。
万一 HunyuanVideo FastVideo が復活出来ないならば、FLUX.1 on
Stable Diffusion Web UI Forge で静止画原画を 1 バッチ投入で大量に
生成させて厳選し、KlingAI（Kling 1.6）や Pinokio - CogStudio ＋
Dain-APP（32 fps ）を使って動画を生成させる過去の工程に立ち
戻ることになります。
ただ HunyuanVideo FastVideo だけが時折、その事前想定レベルを
超えた動画を、なおかつ 10 分で生成する驚きを持っているのでした。
直近の LTXV i2v Lightricks の再構築の際に、参考にした外部サイト
からワークフローを何故かダウンロード出来ず、旧環境に保存して
いたワークフローを持って来てイージーに再構築を完了できたのに
味を占めて、HunyuanVideo FastVideo に関しても同じく旧環境から
ワークフローを新環境に持ってくれば良いではないかと考えました。
しかし、それで実行するも現在の壊れた旧環境と同じく OOM 終了を
回避出来ませんでした。
なので今回は初回と同様に、まずは基本のワークフローでの例題プロンプト
の実行から目指し直しました。
初段の「拡張モデルを読み込む」ノードで OOM 終了する状態は
HunyuanVideo の再構築時と同じく、PC の再起動で GPU VRAM 上の
残渣をクリアすることで切り抜けました。
しかし最終目的である 2 LoRA <lora:hunyuan_vivi_model20:0.6> ,
<lora:AsirAsianPhotographyflux:3> を加えたワークフローの実行では
過去記事や過去に参考にさせて頂いた記事の画像に残る設定と逐一比較
して値を設定するも、処理最終段の 「VAE でコード（タイル）」に
入り処理本体画面に描画の横棒グラフが出るところで OOM 終了が
回避出来ません。
全く埒があきません。途方に暮れてしまいました。
そのうちふと、pyramidflow-miniflux（768 p）を今回の環境復活で初めて
成功させるに至った際と同様、生成させるデータ量を減らしてはどうか、
と思い至りました。
pyramidflow-miniflux（768 p）の際のように、動画生成時間を短くする
選択もありましたが、既に動画生成秒数がわずか 3 秒だったこともあり、
それまで 848 × 480 pixels だった動画サイズを 720 × 480 pixels に縮めて
みました。
それでようやく動画が生成出来ました。
outdoor, medium shot,wearing gray and black nano-suits, wide hip, large breasts, perfect slender young girl body, perfectly glossy skin ,25 yo mature girl,picture of a vivid, masterpiece,perfect lighting, asian beauty, Machine background ,spaceship outdoors background, Mecha Transport parts, dark and foggy environment, heavy fog environment, battlefield behind,
<lora:hunyuan_vivi_model20:0.6> , <lora:AsirAsianPhotographyflux:3>
ComfyUI 全環境が壊れる前には 848 × 480 pixels で OOM 終了は全くあり
ませんでした。裏で note 記事を纏めていたり webp から GIF への変換
処理をしていても OOM 終了にはなりませんでしたし、実行を 4 多重
などにしても問題はありませんでした。
以前と異なり、何故 720 × 480 pixels に縮めなければメモリ不足に
なるのか原因は分かりませんし、もしかしたらその動画サイズなら
旧環境でも動画生成が為されるのかもしれません。
しかし不正発生の契機が何であったのかは分からないままです。
HunyuanVideo の i2v 化失敗によって環境を変えても影響が波及する
ほどの何を壊してしまったというのでしょう。
この妥協を飲むしかありません。クリエータとして表現力の復活を
優先しました。以前と同様に多重実行も可能のようです。
この動画は長い記事公開待ち期間のうちに一旦ボツにしていたものを
公開までに復活させました。（動画として不連続な瞬間が気になった
ものの美人度が勝ってしまった^^;）
寒そう…（あえて描画 AI にツッコむ当方は生粋の関西人…。）
瞬きすら不自然だった LTXV i2v Lightricks や pyramidflow-miniflux と
比較して、この自然な素振りは当たり前に自然過ぎますが、まさに
そこを評価されて然るべきなのでした。
これも長い記事公開待ち期間のうちにボツから復活させました。
何かを追うように目から先に動き、その後首が連動するという実に
解剖学的に正しい動きが見事です。
従来の t2v では考えられなかったほどの人物像や世界観の統一ぶりも
強い魅力です。
これまでは生成動画ごとに雰囲気や、酷い場合はアニメ調になったりの
制御不能でも我慢するしかなかった t2v でしたが、これはもう異次元の
完成度と言えます。
縦構図のときは特にそうでしたが、長辺 848 pixels は必須のサイズでは
ありませんでした。縦横比率も他の動画生成方法と統一出来ました。
（＝負け惜しみ^^）
より大きな動画サイズ生成に関しては Dain-APP は何も CogStudio
にのみ有効なのではなく、HunyuanVideo FastVideo や他の動画生成
結果に対しても有効です。
これで ComfyUI 全環境の破壊を受けての新しい環境の再構築作業は
2025/02/05（水）に完了しました。（その当日に執筆した本記事の公開が
2025/04/14（月）にまでなってしまうのは考え物です。現在公開待ち
記事数は 41 記事でその末尾記事の公開予定は 2025/07/05（土）….。）
臨む様々な用途に対して、今や性能的には RTX4060 （GPU VRAM 8GB）
機で必要充分だと分かって来たのでした。
しかし今までと違ってもう 1 台 PC を欲しくなったのは、環境を壊しても
影響の波及が無い、という理由です。想像もしなかった新たな要件による
ものでした。
今回環境の復旧に要する時間を含めて相当に心底懲りました。
現状、i2v に対しては FLUX.1 on Stable Diffusion Web UI Forge を
原画生成に用いて、KlingAI（Kling 1.6）や Pinokio - CogStudio ＋
Dain-APP（32 fps ）を超えてのローカル動画生成の登場にはもはや
期待していませんし、t2v については HunyuanVideo FastVideo、
HunyuanVideo の使い分けで特に不満もありません。
むしろその環境で何を描画して動画化（活きた動き、という「描画に
命を注ぎ込む」）するのかに遺された時間と魂を費やすべきです。
一旦この復旧した ComfyUI 全環境を外付け SSD に全コピーしておき
ました。
ペースト先ではドライブ名などが異なるためにそのままでは動かない
でしょうが、現在の外付け HDD の動作環境上で今回のような構築失敗
での不可解な大規模環境破壊が再びあった場合は、それを潰して現時点
の環境を外付け SSD の退避先から呼び戻すことが出来ます。
その後も HunyuanVideo 系の i2v ワークフロー紹介の記事は拝見する
ものの、恐る恐るワークフローに不足ノードの追加を ComfyUI-Manager
で完了しても、肝心のワークフロー内に指定されているモデル、LoRA、
VAE がネット検索しても出て来ない（勿論、紹介記事にも所在記載がない）
内容ばかりで、正直もういいかな、という気持ちが強まりました。
HunyuanVideo FastVideo、HunyuanVideo の表現の意外性が i2v でも
発揮されるなら興味があるとは思ってみたものの、それらの紹介記事
での動画を拝見しても、そもそも原画が 2 次元系で「女の子が動く～ ♪」
ばかりで表現の新奇性や新鮮さは感じませんでしたので。
HunyuanVideo FastVideo はその処理速度の魅力以上に、フルサイズの
HunyuanVideo を上回るといえる（上掲 LoRA の組合せを踏まえた場合）
独特の描画力にあるので、ゴールが見える予定調和の中で動く i2v の
ツールに転ずることは、その魅力を大きく減ずるものと言えますから。
原画から想定するゴール像の動画をぶっ壊すほどの意外性、というものは
元来 i2v に求めるものではありません。
当方、NSFW 系表現には全く触手が動きませんので、i2v なら有償契約を
続けている KlingAI が最もお手軽で、これまで未体験ながら仮に KlingAI
が受付拒否する原画が出たら、Pinokio - CogStudio ＋ Dain-APP で好み
のサイズの 32 fps 動画を生成させれば良いのでした。
むしろ CogStudio の縦構図対応や横黒枠除去などを cogstudio.py 内を
精査しつつ検討すべき時期に来ているかと考えます。
ご覧いただきありがとうございます。
（2025/02/05 執筆・2025/02/08 一部加筆）
