見出し画像

MiniMax H3が2.17倍速くなった：原因はComfyUI同梱のPyTorchだった

たぬ｜生成AIを使い倒す人

RTX 4060 Ti 16GBのマシンに、公開されたばかりの動画生成モデルMiniMax H3を入れました。5秒の動画を1本作るのに12分50秒。遅い、というのが最初の感想です。

ただ、この「遅い」には引っかかるところがありました。ComfyUI公式ブログはH3について、RTX 3060のようなGPUでもローカルで動くと書いています。3060は12GBで、こちらは16GB。VRAMでは上回っているのに、体感がそれに見合わない。

原因は設定でもGPUの性能でもなく、ComfyUI portableに同梱されているPyTorchのバージョンでした。入れ替えたら12分50秒が5分55秒になりました。2.17倍です。

同じ環境の人はそこそこいるはずなので、たどり着くまでの経緯と、確認のしかたを書いておきます。

あわせて、H3のライセンスも一度読んでみました。オープンウェイトと言われて想像するものとはずいぶん違っていて、読み物としても面白かったので、面白かった点と押さえておきたい点は記事の最下部に余談としてまとめてあります。

ほか、長くなりすぎたので作成したもの、工夫、skill化については別記事を予定しています。ちょっとだけ「おまけ」に掲載します。しかし、ローカル環境でここまでの品質というのは改めて驚きます。


1. 起動ログに答えが書いてあった

ComfyUIを起動すると、大量のログが流れます。普段は読み飛ばす部分ですが、今回はそこに答えがありました。

WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations.
Found comfy_kitchen backend cuda: {'available': True, 'disabled': True, ...}

comfy_kitchenというのは、ComfyUIがH3のために用意した量子化演算のバックエンドです。H3の拡散モデル本体はint8 convrotという独自形式で量子化されていて、その計算を高速に処理するための専用カーネルが入っています。

そのCUDAバックエンドが、available: True（使える）なのにdisabled: True（無効化されている）。使えるのに、わざわざ切られている状態です。

なぜ切られるのか。ComfyUI本体のソースを見ると、comfy/quant_ops.pyにこう書かれていました。

cuda_version = tuple(map(int, str(torch.version.cuda).split('.')))
if cuda_version < (13,):
    ck.registry.disable("cuda")
    logging.warning("WARNING: You need pytorch with cu130 or higher ...")

PyTorchが参照しているCUDAのバージョンが13未満なら、問答無用で無効化する。それだけの単純なバージョンゲートです。

そして手元のPyTorchは2.8.0+cu129。CUDA 12.9でした。0.1足りません。

2. なぜ古いPyTorchが入っていたのか

ここが今回の落とし穴です。自分が入れていたのはComfyUIのportable版（ZIPを展開して使うタイプ）で、配布物には専用のPython環境がまるごと同梱されています。そのPython環境に、配布時点のPyTorchが焼き込まれている。

自分の環境の配布物は2025年10月版でした。当時としては新しく、Python 3.13にPyTorch 2.8.0+cu129という妥当な組み合わせです。実際、この構成でWan 2.2などは問題なく動いていました。

ComfyUI本体を最新に更新しても、この同梱PyTorchは更新されません。update_comfyui.batが更新するのはComfyUIのコードとその依存パッケージであって、PyTorch本体は対象外です。

つまり、本体を最新にした結果として「H3のコードは入っているのに、H3用の最適化カーネルは無効」という組み合わせが生まれます。エラーは出ません。警告が1行出るだけで、動くには動く。ただしフォールバック実装で。

自分で意識してPyTorchを入れ替えない限り、この状態に気づかないまま使い続けることになります。

3. 入れ替えの手順と、事前に確認したこと

やることはPyTorch本体、torchvision、torchaudioの3つをcu130ビルドに差し替えるだけです。ただし動いている環境に手を入れるので、先に2点だけ確認しました。

ひとつはNVIDIAドライバのバージョンです。CUDA 13系はドライバの下限が上がるため、古いままだと入れ替えた瞬間にGPUを認識しなくなります。nvidia-smiで確認したところ610.47で、余裕で条件を満たしていました。

もうひとつは、そもそもcu130のwheelが自分の環境向けに存在するかどうか。埋め込みPythonは3.13なので、cp313かつwin_amd64のビルドが必要です。PyTorchの配布インデックスを確認して、存在することを確かめました。

そのうえで、python_embededフォルダをまるごとコピーして退避しました。数GBありますが、これがあれば失敗しても完全に元へ戻せます。ComfyUIを起動したままだとWindowsがCUDAのDLLをロックしてpipが中途半端に失敗するので、必ず終了させてから実行します。

インストール自体はpipに解決させました。

pip install --upgrade torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130

結果として入ったのは、torch 2.13.0+cu130、torchvision 0.28.0+cu130、torchaudio 2.11.0+cu130でした。番号の刻みが揃っていないのが気になりますが、pipが3つを同時に解決して衝突を出さなかったので、依存メタデータ上はこれが正しい組み合わせです。バージョンを手で指定しなくて正解でした。

変更されたのはこの3つだけで、numpy、pillow、transformersといった他の依存はすべてalready satisfied。巻き添えはありませんでした。

4. 何が変わったか

再起動後、警告は消えました。

Found comfy_kitchen backend cuda: {'available': True, 'disabled': False, ...}
Native ops: float8_e5m2, float8_e4m3fn, convrot_w4a4, int8_tensorwise
emulated ops: nvfp4, mxfp8

注目すべきはconvrot_w4a4とint8_tensorwiseがネイティブ実装に切り替わった点です。convrotはH3の拡散モデル本体が使っている量子化形式そのものなので、一番効いてほしいところに効いています。

肝心の時間です。864×480、124フレーム、20ステップ、同一シードで測りました。

2.17倍。ComfyUIがH3向けに謳っている最適化が、ようやく効いた形です。

ついでに分かったこととして、モデルのRAMキャッシュはほとんど効いていません。初回13分21秒に対して2回目が12分50秒で、31秒しか縮まっていない。42GBのモデルを読み込む時間より、サンプリング本体のほうが圧倒的に支配的だということです。

画については、同一シードでも完全一致はしませんでした。PSNR 32.2dB、SSIM 0.950。カーネルの実装が変われば数値がわずかに変わり、拡散モデルは20ステップかけてその差を増幅するので、これは正常です。「同じシードから生まれた別サンプル」になります。目視では劣化を感じませんでしたが、この指標では「別物だが同等」と「劣化」を区別できないので、そこは断定できません。

5. 既存環境が壊れていないかの確認

torch 2.8から2.13は、マイナーバージョン5個分のジャンプです。H3が速くなっても、それまで使っていたWanなどが壊れたら差し引きで損になります。

確認には、Wan 2.2の14Bモデルを使うテンプレートを選びました。fp8スケール量子化の演算、LoRAのパッチ適用、複数モデルの切り替えを一度に通るので、壊れているなら高い確率でここに出ます。

結果は23分24秒で完走。出力も640×640・81フレームで正常でした。

この数字の評価には、ちょうどよい比較対象がありました。テンプレート自身が「RTX 4090D 24GBで1段目およそ536秒、2段目およそ513秒」と明記していたのです。合計1049秒、約17分29秒。4060 Tiの1404秒は、その約1.34倍でした。

ただし、これをもって「PyTorch更新による性能回帰は起きていない」と言い切ることはできません。比較相手が別環境のRTX 4090Dであって、更新前の同じ4060 Tiではないからです。厳密に確かめるなら、入れ替える前にWan 2.2でも一度測っておくべきでした。ここで言えるのは、Wan 2.2が正常に完走し、出力も壊れていなかった、という機能面の確認までです。

そのうえで、16GBのミドルレンジが24GBのハイエンドに対して1.34倍という数字自体は、健闘していると思います。

6. 解像度を上げると、想像以上に重くなる

高速化とは別に、測っていて分かったことをひとつ。

H3のローカルでの品質上限は1344×768です。864×480から上げると、ピクセル数は2.49倍になります。では時間は2.49倍かというと、そうではありませんでした。

面積比の1.7倍近く伸びています。

理由ははっきりしていて、H3は本来native sparse attentionで訓練されているのですが、公開されている推論実装は現時点ではフルアテンションです。アテンションはトークン数の二乗で効くので、解像度を上げると面積以上に重くなる。ここは設定でどうにかなる話ではなく、sparse attentionの実装が公開されるのを待つ部分です。

実用上は、低解像度で言い回しを詰めてから本番解像度で焼く、という運用が現実的でした。ただし解像度を変えると潜在空間の形状が変わるため、同じシードでも構図は再現されません。低解像度は完成形のプレビューにはならず、あくまで「指示が効くかどうか」を確かめる用途です。

7. ログの読解はAIに手伝わせてよい

今回の作業は、Claude CoworkでOpus 5に伴走してもらいながら進めました。起動ログを渡して（見に行って）怪しい箇所を洗い出し、quant_ops.pyのどこでバックエンドが切られているかを特定し、前後比較の測定条件を設計する。この記事に載せた数字の多くは、その過程で取ったものです。

同じことは読者のみなさんにもできます。ComfyUIを起動したときのログをそのままコピーして、ClaudeなりChatGPTなりに「無効化されている機能や、フォールバックしている処理はありますか」と聞けばいい。ログは長くて読む気が起きませんが、AIは全部読みます。今回のように、警告1行に重要な情報が埋もれているケースは拾ってくれます。

この記事自体を渡して「自分の環境が同じ状態か診断して」と頼むのも有効です。手順が構造化されているので、判断の材料としてそのまま使えます。

ただし、AIが正しいとは限りません。実際、今回の作業中にも間違いがありました。H3向けの高速化LoRAについて調べたとき、二次的な情報をもとに「これは軽量化された版のモデルでは動かない」という説明を受けたのですが、作者本人のモデルカードを読みに行ったら、そちらには「軽量化版でも動く」と明記されていました。ノード側が自動的に対応する仕組みが入っていたのです。二次情報を鵜呑みにしていたら、34GBの再ダウンロードという無駄な作業をしていました。

AIは調査と整理を速くしてくれますが、結論は一次ソースで裏を取る。この順番を崩さなければ、かなり強力な相棒になります。

まとめ

ComfyUI portableを使っていてH3が遅いと感じているなら、起動ログの最初のほうを見てください。You need pytorch with cu130 or higherという警告が出ていれば、最適化カーネルが無効のまま動いています。

確認と対処はこの順番です。

  1. 起動ログにdisabled: Trueのcomfy_kitchen cudaバックエンドがないか見る

  2. nvidia-smiでドライバがr580以降か確認する

  3. python_embededをコピーして退避する

  4. ComfyUIを終了させてから、cu130インデックスでtorch三点を入れ替える

  5. 同じシード・同じ設定で前後を測る

戻し方も単純で、python_embededを削除して退避したフォルダをリネームするだけです。

自分で全部読むのが面倒なら、起動ログをAIに渡して「無効化されている機能はありますか」と聞くところから始めても構いません。

今回の件で改めて思ったのは、警告文は読んだほうがいい、という当たり前のことでした。エラーで止まってくれれば嫌でも気づきますが、警告1行で静かにフォールバックされると、そういうものだと思って使い続けてしまいます。ベンチマークの数字が他の人の報告と噛み合わないときは、たいてい理由があります。

なお本記事の数値は、RTX 4060 Ti 16GB、Core i7-14700KF、RAM 64GB、ComfyUI 0.30.0という単一構成での実測です。各条件1回の測定であり、統計的な主張ではありません。参考値として扱ってください。

余談：このモデルのライセンスは、けっこう独特です

本題からは外れますが、H3を触っていて「これは書いておいたほうがいいな」と思ったことがひとつあります。ライセンスの話です。

H3は「オープンウェイト」で公開されていますが、Apache 2.0やMITではありません。MiniMax H3 Community License Agreementという独自の契約で、2026年8月2日付。権利者はシンガポール法人のNanonoble Pte. Ltd.、準拠法は香港法、紛争の管轄も香港の裁判所です。オープンと言われると条件反射でApache 2.0あたりを想像してしまいますが、中身はかなり違います。

いちばん目を引くのは地域制限です。ライセンスが有効な範囲は「全世界。ただし除外地域を除く」と定義されていて、除外地域としてEU、英国、韓国、アメリカ合衆国が名指しされています。日本は除外リストに入っていないので、この記事のような使い方は許諾の範囲内ということになります。除外地域の人向けには「個別に連絡してくれれば、適切な統制のもとでライセンスを検討する」という但し書きが付いています。

ここで少し引っかかったのが、制限がモデル本体だけでなく生成物にもかかっている点です。第V条4項は、H3やその出力を除外地域の外で使用・複製・配布・表示してはならない、と書いています。素直に読むと「生成した動画を除外地域に向けて公開すること」も想定されていない。しかしブログに動画を貼れば、当然アメリカからもEUからも見えます。ここが実際どう運用される想定なのか、ちょっと判断がつきませんでした。日本国内で生成し日本語で公開する分にはまず問題にならないだろう、というのが常識的な感覚ですが、契約書の文面としてはそう書いてある、ということは共有しておきます。

一方で、出力物の権利関係はすっきりしています。第VI条4項に「MiniMaxは、あなたが生成した出力物に対していかなる権利も主張しない」と明記されていて、責任もすべて生成した側にある、という書き方です。商用利用に別途承認が要るのは年間売上2,000万ドル超の場合なので、個人が趣味で作って無償で公開する分には、実質的な障害はありません。ただし商用の製品やサービスに組み込む場合は、売上規模にかかわらずUI上に「MiniMax H3」を目立つ形で表示せよ、という条項が別にあります。

そしてもうひとつ、読んでいて思わず笑ってしまった箇所があります。第III条3項の「推奨事項」です。義務ではなく努力目標として、こう並んでいます。

  • 「Powered by MiniMax H3」の表示を出すこと

  • 生成ファイルにAI生成であることの識別子を付けること

  • H3を使ってみた経験について、技術ブログ記事か公開声明を最低1本出すこと

3つめ、まさにこの記事です。書いてから気づきました。

なお推奨事項とは別に、利用規約Acceptable Use Policyのほうには「機械生成であることを明示せずに公開環境へ出してはならない」という禁止項目が入っています。こちらは推奨ではなく禁止事項なので、公開するなら明記が必要です。本記事に載せた動画は、すべてMiniMax H3で生成したものです。

細かい話をもうひとつ。テキストエンコーダに使われているQwen3-VL-32Bは、本体とは別にApache 2.0だと注記されています。ライセンスが層ごとに違うので、真面目に扱うなら分けて考える必要があります。

念のためですが、自分は法律の専門家ではありません。上に書いたのは原文を読んだ範囲の理解であって、法的な助言ではありません。判断に迷う使い方をするなら、原文を読むか、専門家に確認してください。それでも、ライセンスファイルを一度開いてみる価値はあると思います。「除外地域」や「技術ブログを1本書くことを推奨」といった条項は、Apache 2.0を眺めていても出てこないので。

おまけ

動画そのものとGIF化したもの。動画ファイルにはプロンプトデータ等が格納されているようです。

いいなと思ったら応援しよう！