「公式が 768P に対応した」を、手元で 768P が回る話として読むと外す。2026年8月3日の ComfyUI v0.30.0 は、音声つき動画モデル MiniMax-H3 のネイティブ対応を本体に入れると同時に、パートナーノードの 768P 対応も入れた。前者はローカルの GPU で回す話で、後者は API の向こう側で回る話になる。筆者は VRAM 8GB の機械にネイティブ側を載せて測ってあり、16:9 で実用になったのは 800×448 だった。changelog を原文で読み直して、どちらがどちらなのかを分けておく。
目次
v0.30.0 の changelog は5つの区分に分かれている
原文を開くと、v0.30.0 は5つの区分に分かれていて、全部で21項目ある。新規オープンソースモデル対応が2件、新規ノードが3件、パートナーノード更新が2件、性能と安定性が9件、バグ修正が5件。本稿で扱うのはこのうち4項目になる。
MiniMax-H3 audio-video model support (CORE-375)
VAEDecodeAudio can decode nested audio latents
Added CRF option to Save Video node
Added 768P resolution for MiniMax H3 partner nodes
出典は ComfyUI 公式の changelog、v0.30.0（2026年8月3日）の項。日本語にすると、順に「MiniMax-H3 の音声動画モデル対応」「VAEDecodeAudio は入れ子になった音声 latent をデコードできる」「Save Video ノードに CRF 指定を追加」「MiniMax H3 のパートナーノードに 768P 解像度を追加」となる。
| 項目 | changelog 上の区分 | どこで走るか |
|---|---|---|
| MiniMax-H3 のネイティブ対応 | 新規オープンソースモデル対応 | 手元の GPU |
| VAEDecodeAudio | 新規ノード | 手元の GPU |
| Save Video CRF | 新規ノード | 手元（保存時） |
| MiniMax H3 の 768P | パートナーノード更新 | API の向こう側 |
PrunaVAED という項目も新規オープンソースモデル対応の枠に入っている。名称は changelog の原文どおりで、LTX 2.3 のデコードを速くするもの。H3 のワークフローとは走る道が違うので、本稿では触らない。
768P はパートナーノード側で、ローカルの上限とは別の軸
パートナーノードは API 経由で外部のサービスを叩くノードになる。生成そのものは手元の GPU で走らない。768P に対応したのはこちら側だ。
ネイティブ対応のほうは、本体がモデルの重みを読んで手元で回す。同じ「MiniMax H3」という名前が両方に付いているので、changelog を区分ごと読まないと混ざる。混ざるとどうなるかというと、「公式が 768P に対応したのだから、うちの 8GB でも 768P が回るはずだ」という読み方が生まれる。
ここは実際の数字で切っておきたい。
ローカルのネイティブ実行だと、8GB の実用上限は 800×448 だった
測ったのは VRAM 8GB の RTX 2070 SUPER で、H3 用に立てた別インスタンスになる。常用している ComfyUI とは分けてある。そちらは 0.19.1 で、カスタムノードが18個ぶら下がる環境だ。H3 側は 2026年8月6日に master の 2340099 を入れてあって、custom_nodes の中身は空、comfy_extras/nodes_minimax_h3.py が入っている。H3 はカスタムノードを1つも介さず、本体の実装で走っている。
版の書き方に1つ注意がいる。このコミットの自己申告は 0.30.0 だが、タグが追いついていないので v0.30.0 のリリースタグを取ってきても同じコードにはならない。再現するならコミットで合わせる。
もう1つ、VRAM の話に隠れやすい要件がある。システム RAM が 64GB 要る。モデルは RAM 側にステージされてから GPU へ渡るので、VRAM より先にこちらが詰まる。GPU が 8GB あっても、RAM が 32GB なら別の壁に当たる。
GPU NVIDIA GeForce RTX 2070 SUPER 8,192 MiB / ドライバ 596.21
CPU Intel Core i7-14700K
RAM 64GB 実装（実質的な要件。生成中はここが先に埋まる）
OS Windows 11 Pro build 26200
Python 3.12.13
torch 2.13.0+cu126 / CUDA 12.6
ComfyUI master コミット 2340099（自己申告の版は 0.30.0。タグは追いついていない）
起動 --lowvram（8GB では要る）
生成条件 フレーム数 124 / 20ステップ / sampler res_multistep / scheduler simple / fps 24この条件で、解像度だけを変えて測った結果が下になる。
| 解像度 | 画素 | 総時間 | ピーク VRAM |
|---|---|---|---|
| 800×448 おすすめ | 358,400 | 29.3分 | 7,831 MB（95.6%） |
| 832×448 | 372,736 | 78.1分 | 7,922 MB（96.7%） |
| 768×512 | 393,216 | 74.6分 | 7,828 MB（95.6%） |
3本とも完走している。OOM では落ちていない。ピーク VRAM は 7,8xx〜7,9xx MB の帯に張り付いていて、画素が 9.7% 違う 800×448 と 768×512 の差は 3MB しかない。増えたぶんは全部時間に出ている。
天井を決めていたのは待ち時間だった。導入手順と測定の全体はガイド記事に書いた。
16:9 で使うなら 800×448 が実用上限になる。768×512 は 3:2 なので、16:9 に切ると 768×432 まで落ちて、後段クロップでは 800×448 より画素が減る。
崖は 358,400 と 372,736 画素のあいだにある
800×448 の 29.3分と、832×448 の 78.1分。画素の差は 14,336 で 4.0% しかないのに、時間は 2.7倍になる。崖はこの2点のあいだにある。
効いてくるのがテンプレートの既定値だ。公式テンプレートは 864×480（414,720画素）で来る。画素数でいえば崖の向こう側に入る。
何分かかるのかは測っていない。上の表から推し量ることもできない。崖の向こう側で測れているのは 832×448 の 78.1分と 768×512 の 74.6分の2点で、画素の多い 768×512 のほうが速い。画素順に伸びる形になっていないので、あいだに落ちる 864×480 を2点で挟んで決めることができない。
言えるのは、800×448 なら 29.3分で1本目が出るということだけになる。
だから最初の1本は解像度を 800×448 に落としてから回す。所要時間の分かっている条件で始めたほうが、うまくいかなかったときの切り分けが楽になる。
0.5MP の 960×544（522,240画素）も測っていない。141フレーム（5.2秒指定）が通るかも未検証になる。
音声の取り出し口も本体側にある
MiniMax-H3 は音声つきで動画を出すモデルになる。ComfyUI のグラフの上では、映像の latent を画像へ戻す口と、音声の latent を波形へ戻す口が別々に要る。v0.30.0 で入った VAEDecodeAudio が後者にあたり、実体は comfy_extras/nodes_audio.py にある。ここもカスタムノードではない。
changelog の原文は VAEDecodeAudio can decode nested audio latents。入れ子という言い方から、音声側の latent は生成結果の構造に抱えられた形で渡ってくると読める。独立した出力が生えているわけではなさそうだ。実際のテンソルの形は確認していない。
音が出ているかどうかの確認は2段階でやる。ファイルに音声ストリームが入っているかを ffprobe で見て、そのあと中身が無音でないかを ffmpeg の volumedetect で見る。最後に自分の耳で聴く。ストリームが1本あるだけで音が鳴っていない、という失敗の仕方があるので、存在の確認だけを通過扱いにしない。
# 音声ストリームがあるか
ffprobe -v error -select_streams a \
-show_entries stream=codec_name,sample_rate,channels \
-of default=noprint_wrappers=1 output.mp4
# 中身が無音でないか（max_volume が -90dB 近辺なら無音）
ffmpeg -i output.mp4 -af volumedetect -f null -耳で聴く工程を残しているのには理由がある。スケジューラを normal にしたときだけ、音にノイズが乗った。simple と beta は正常だった。波形の有無だけを見ていたら通過させていた。
Save Video CRF は保存容量の話で、測定のあいだは固定する
Save Video CRF は、動画を保存するときの圧縮率を指定できるようにするものになる。CRF は値が小さいほど画質が上がってファイルが大きくなる向きの指標で、x264 系のエンコーダで昔から使われている。指定できる範囲と既定値は changelog に書かれていないので、ノードを開いて確認することになる。
効いてくるのは検証を繰り返す場面だ。同じ設定を何度も回して比べるとなると、出力を全部残すことになる。
測定中は CRF を1つの値に固定する。圧縮率を条件ごとに変えるのは、体重計に乗るたびに服を着替えるようなものだ。画質の比較が圧縮の影響を受けるうえ、所要時間にも保存の時間が混ざり込む。動かす変数は解像度だけにしておきたい。
版をまたいだ数字を、同じ表に並べない
上の表を3行に絞ったのには理由がある。640×352 で 6,788MB という実測も持っているものの、これは v0.30.0 へ上げる前に測った値になる。同じ表に入れると、版の違う点を1本の線でつなぐことになる。
筆者は一度これを踏んでいる。その 640×352 の 6,788MB を基点にして、768×448 に上げたときの必要量を外挿し、8GB では届かないと書いた。実際に回したら完走した。原因は、基点が古い版での測定で、当てた先が新しい版での測定だったこと。数字そのものはどちらも実測なので、間違っているように見えないところが厄介だった。
短い試走で代用することもしない。5フレーム・4ステップの試走では、800×448 が 7,355 MB、768×512 が 7,378 MB だった。画素が 34,816 も違うのに差は 23 MB しか出ていない。試走のピークは本番のピークを予告してくれなかった。
測るなら、同じ版で、本番と同じフレーム数とステップ数で測る。
踏むライセンスは4本ある
ローカルで H3 を回すと、性質の違う条文を同時に踏む。配布元の LICENSE 本体を取得して確かめた結果を置いておく。
| 対象 | ライセンス | 確認した場所 |
|---|---|---|
| MiniMax H3 の重み | MiniMax H3 Community License Agreement（独自規約） | MiniMaxAI/MiniMax-H3 の LICENSE |
| テキストエンコーダ Qwen3-VL-32B | Apache 2.0 | 上記 LICENSE 末尾の Additional Note |
| ComfyUI 本体 | GPL-3.0 | ComfyUI の LICENSE 先頭行 |
| PrunaVAED / LTX 2.3 | 本稿の範囲外（使っていない） | 使うなら配布元の条文を各自で確認 |
重みの側で効いてくるのが地域の条項になる。ここは読む向きを取り違えると結論が反転するので、定義から順に追う。第I条3項の Applicable Territory は worldwide, excluding the Excluded Territories。第I条5項がその Excluded Territories を the European Union, the United Kingdom, the Republic of Korea and the United States of America と定めている。第V条4項が禁じているのは Applicable Territory の外での利用・複製・改変・配布・表示になる。制限がかかるのはこの4地域のほうで、日本は許諾の範囲に入る。
商用については、年商2,000万米ドルを超える場合に MiniMax からの書面による事前許諾が要る、と第IV条1項が定めている。
「MiniMax H3 はオープンソース」とひとまとめに書くと、ここが独自規約であることも、ComfyUI 本体が GPL-3.0 であることも消える。条文を1件ずつ読んだときの記録は別記事にまとめた。ライセンスの条文は改訂される。本稿の記述を根拠にせず、使う日に配布元を開いて確かめてほしい。
AnimeGen のときも条文まで読んでから記事にした。本体が対応したことと、自分の用途で使ってよいことは、別々に確かめることになる。
筆者はどう扱うか
ネイティブ対応の値打ちは、速度ではなく版を合わせる相手が減ることにある。カスタムノードは配布元ごとに更新の間隔が違うので、本体を上げた翌日にどれかが付いてこられずに止まることがある。H3 用のインスタンスを custom_nodes 空のまま保てているのは、本体に実装が入ったからだ。半年後に同じ JSON をもう一度回したいとき、控えておく版が1つで済む。
解像度は 800×448 に置いたままにする。公式が 768P と書いたのはパートナーノード側で、手元の GPU の天井を動かす話ではない。Kimi K3 のウェイトが 594GB で公開されたときも、対応の有無と自分の機械に載るかどうかは別の軸で決まった。Inkling が手元では動かないと書いたときも同じ判断のしかたをしている。
同じことを試すなら、先にシステム RAM を確かめてほしい。GPU が 8GB でも RAM が 32GB なら、解像度を落としても届かない。64GB 積んだうえで、公式テンプレートの既定 864×480 を 800×448 へ落としてから最初の1本を回す。既定のままだと何分かかるのかは測っていない。
参考
未測定として残るもの。テンプレート既定の 864×480（414,720画素）と 0.5MP の 960×544 の所要時間、141フレームが通るか、Save Video CRF の指定範囲と既定値。パートナーノード経由の 768P も、API 側なので手元では測っていない。上の表の3行は、いずれも master コミット 2340099 のネイティブ実行で、124フレーム・20ステップ・--lowvram に揃えて測った値になる。
