HunyuanVideo(t2v,i2v)のWaveSpeedのエラー対策をした話＠ComfyUI
<追記>
記事を出した際に確認漏れをしていましたが、本家のリポジトリでも最初の修正方法のPRを採用してアップデートされています。
そのため、上記のエラーは改善していると思います。表題に若干の誤解があり申し訳ありませんでした。
v2のエラーについては、対策は見出したのですが、計算などで時間がかかるため、高速化できないため意味を成さない残念なものになってしまいました。でもせっかくなので残しておきます。
もう一息AIが賢くなったら改善してもらう感じでしょうか。
＜高速化出来ないけどv2も動くやつ＞
<前記事>
Hunyuanvideoのimg2videoのfixedモデルが出て、それに対応するコードになってから、WaveSpeedはエラーを吐いて動かなくなっていました。
個人的にスクリプトの修正をいくつか試して、なかなかうまくいかない感じが続いていたのですが、wan2.1も含めて色々調整しているカスタムノードを公開されている方がおられました。
理由は良く分かりませんが、私が使用したところ、エラーは出なくなったのですが、高速化については、効果があまり無い様な副作用が出てしまいました。
ちなみにwavespeedのエラーですが、以下の記事にも記載していますがComfyUIが更新された際のスクリプトが関連してエラーが出たようです。
HunyuanVideoのi2vモデルのバク改善とかComfyUIの対応について｜shiba*2
その後、ComfyUI側でもいくつか関連したと思われる更新がされましたが、ネイティブでHuntuanVideo i2vモデルだとエラーは続いています。
上のIssueで簡単な改善方法が提案されています。
エラーログの内容から、singble blocksのところに、不要なデータが渡された影響でエラーが起きているとのこと。そのため、以下のように3行を追加して、そのデータを無視する事で対応でエラーを回避すると言う方法です。
これで、「HunyuanImageToVideo」をV1モードで実行した際にエラーがでなくなります。
ただ、使用してみると、生成動画の質が低下しています。
これは、single blocksに適切なものが渡されていない可能性もありそうかなということで、「Gemini2.5」との壁打ちを行って別な修正方法を検討してもらいました。
最終的に1200行くらいのフルスクリプトを出してくれたので優秀ですね。
＜修正の内容の概要的なもの by Gemini＞
SingleStreamBlock の定義に基づき、WaveSpeed がこのブロックを呼び出す際に正しい引数 (modulation_dims) を渡し、不要な引数 (modulation_dims_img, modulation_dims_txt) を確実に除去するように first_block_cache.py を修正します。
その他いくつか追加して修正したものです。
使用方法
以下のスクリプトを置き換える
このスクリプトだと以前までの設定で行うと、キャッシュスキップが少なくなるせいなのか生成時間が長くなることが分かりました。
以下がもともとしていたものです。
0.1の閾値でヒットするキャッシュが上の設定だとかなり低く20%くらいでした。
低すぎると、違いを計算したりする方にかかる時間の方が長くなり、結局はカスタムノードを使用しない場合と変わらない結果になります。そのため、キャッシュスキップがある程度なされないと効果が少なく、効果範囲が質の低下が出ないレベルで調整する必要がありました。
以下がとりあえず変えてみた値です。これで30%くらいになりました。
この設定をすると、WaveSpeedの高速化の恩恵が出てきます。
今回はresmultistep + betaで行いました。
おそらくサンプラーとスケジューラーでキャッシュ閾値の設定は変わるのかと思います。
課題としては計算リソースがよりかかってしまっている印象がある点です。
この方法で対処できたのですが、V2モードで実行すると別なエラーを吐くようになります。
V2モードはHunyuani2vの修正版の際に使用するものですので、それはそれで使い勝手が悪くなってしまいます。
ちなみにV2モードは、ComfyUI_Patches_llだとエラーなく動作しますがwavwrspeedの高速化は感じにくい可能性があります。
Stability matrixで試してみた感じだと、今回の修正したものの方が高速化している印象。HunyuanVideoだとt2vとi2vのv1のみ稼働します。
個人的にはV1で良いのが出ればそれで良いのでは？という気もしたりしています。
