HunyuanVideo-Avatar 悪戦苦闘記

誰にも絶対に試さないでほしい。

結論から言うと、HunyuanVideo-Avatarプロジェクト自体が根本的に未完成の『論文用コード（Paperware）』であり、過大広告だと思います。

私は純粋に広告を信じてリポジトリをクローンし、なんとかコードを修正して使おうと試みましたが、10時間の奮闘の末に得た結論です。10時間のデバッグの結果、私はこのHunyuanVideo-Avatarを躊躇なくrm -rfしました。

image of dev's anger toword paperware

なぜYouTubeのレビューもGitHubも静かなのか？

リリースから8か月が経過しても静かなままだと、オープンソースのエコシステムでは実質『死』と判断されます。このような現象は大手テック企業のAI研究所で頻繁に見られますが、今回の場合はテンセントがまさにそれでした。

私を騙した広告はおそらく厳選されたものだと思います。

プロモーション映像に使われた成果物は、内部のスーパーコンピュータクラスタで何十回も走らせて得られた唯一の奇跡的な結果でしょう。

  • KPI達成のための投げ込み: 研究者はSOTA（State of the Art）を達成したと主張する論文を書き、成果を認めてもらうためにコードをGitHubに『投げ込んだ』のでしょう。実際に一般ユーザーが使えるように最適化したり、バグを修正したり、保守することには全く関心がないようです。その証拠に、私がクローンしたコードはバグだらけで、無理矢理なハードコーディングも見受けられ、何よりtransformers 5.0がリリースされてかなり前なのに、4.5〜4.6でしか動かずにクラッシュします。（requirementsには4.50.0以上と書かれています。）数か月にわたり開発者はGitHubにコードを投げ込んだまま、デバッグも依存関係のアップグレードも行っていませんでした。

  • 地獄のようなエラーと非現実的なVRAM: Sparkは統合メモリ120GBで、推論のピーク時にメモリ使用量が80GBに達しますが、突然SIGKILL -9がOOM警告なしで発生します。（FP16はもちろん、FP8量子化を適用しフレームをたった17枚（0.7秒分）に減らした状態でも起きます。）これはシステム環境の問題ではなく、C++カーネルやPythonコード内部に致命的なメモリリークがあるか、アテンション演算の最適化が完全に崩壊していることを意味します。

  • このメモリリーク問題を経験した後、Issueを見るとA100すらメモリで落ちる、30分かかってやっと1枚生成したが品質がひどいという報告がありました。

  • あり得ないPyTorch基礎エラー（--cpu-offloadバグ） エラーが多すぎて--cpu-offloadオプションを試してみましたが、衝撃を受けました。

    Cannot generate a cpu tensor from a generator of type cuda.

このエラーはディープラーニングコードを書く際に起こる非常に初歩的なミスです。--cpu-offload機能を作ったのであれば、テンソルと乱数生成器（Generator）をすべてCPUに移して計算する分岐処理が必要ですが、コードのどこかで.cuda()とハードコーディングされて放置されていると考えられます。つまり、開発者はこのオプションを作ったものの、十分な実行テストを行わずにGitHubにアップロードしたということです。

  • そのほか、パッチを当てながら見つけた多数のバグや裏技的なコードはここでは列挙しません。

私なりの結論：修正して使えるコードではない

それでもテンセントの研究者を信じてもう少しだけ修正しようと、もう少しだけ…と10時間費やしましたが、他の人が同じような失敗をしないようにこの投稿を書きました。このコードは修正して使える範囲を超えています。

もし誰かがテストと使用に成功した例があれば教えてください。どのスペックでどんな結果が得られたか証拠とともに提示していただければ謝罪します。しかし、そんなことは起きないと考えています。

参考までに私がテストした環境は以下の通りです。

  • DGX‑Spark GB10 120GB VRAM, CUDA 13.0

関連記事