MiniMax H3をVRAM 16GBで速くする｜latent upscaler・context windows・軽いVAEはどれを使うか

この記事の要点

MiniMax H3 の生成時間を大きく縮めたのは latent upscaler と context windows で、映像VAEの差し替えで縮んだのは、測った範囲では最後の復号の部分だった。

代わりに latent upscaler で作った動画は、直接作った動画とは別の構図になった。context windows を使った1本では、窓なしで出た人物がカメラへ近づく動きが出ず、看板や屋台が入れ替わり続けた。

復号を縮めるなら、fp16 との一致がいちばん高かったのは int8 の映像VAEで、復号がいちばん短い Light は等倍で見ると細部が平らになった。ComfyUI 0.44.0 の生成時間は、0.37.1 で測った値と大きくは違わなかった。

ComfyUI 0.44の新機能でMiniMax H3は速くなるか

RTX 5080 で測った範囲では、時間を大きく縮めたのは latent upscaler と context windows を使った場合だった。新しい機能を使わない ComfyUI 0.44.0 の生成時間は、親記事の 0.37.1 での値と大きくは違わなかった。映像VAEの差し替えで測ったのは最後の復号の時間で、サンプリングの設定は変えていない。代わりに latent upscaler で作った動画は直接作った動画と構図が変わり、context windows を使った窓ありの1本（864×480・362フレーム）ではプロンプトにある人物の動きが出なかった。窓だけによる差かは切り分けていない。

1344×768・192フレーム（約8秒）の動画は、1段で生成する直接生成の 1169.0秒が、latent upscaler を挟むと 616.1秒または 396.7秒になった。1344×768・362フレーム（約15秒）の動画は、窓なしの 3571.9秒が窓ありで 2262.6秒になった。映像VAEの復号は fp16 の映像VAEで 33.6秒（復号だけを回した2回目の値。直接生成の内訳では 32.6秒）で、差し替えで縮められるのはこの部分にとどまる。

latent upscaler と context windows は RTX 5080 で各条件1回ずつ測り、映像VAEの復号は RTX 5060 Ti でも測って2回目の値を使った。比べる相手は同じ ComfyUI 0.44.0 での直接生成と窓なしで、ComfyUI のバージョンの比較だけは親記事の 0.37.1 の値を相手にしている。速さ以外の違いは、同じ seed の動画を目で見た範囲で書いている。

生成そのものを速くしたい場合は、この記事の3つとは別に、ステップ数を減らす方法もある。ただし、ステップを減らしたときに画が元と同じになるとは限らない。この方法を扱った記事へのリンクは最後のまとめに置いた。

MiniMax H3 の導入手順や必要なファイル、VRAM 16GB のカードで動く理由はMiniMax H3をVRAM 16GBで動かす｜ComfyUIでの導入手順とRTX 5080・5060 Ti実測にまとめてある（以下、親記事）。まだ動かしていない場合は、先にそちらで環境を整えてから読むと手順を追いやすい。

0.39〜0.44で増えた映像VAE・latent upscaler・context windows

ComfyUI のリリースノートでは、この記事で扱う映像VAE・latent upscaler・context windows への対応が、3つのリリースに分かれて入っている。v0.39.0（2026年10月5日）で LynnReal の軽い映像VAE、v0.41.0（2026年10月15日）で LightVAE、v0.44.0（2026年11月4日）で latent upscaler のモデル、Sol-H3-VAE、context windows への対応が入った。日付は GitHub のリリースの公開日（UTC）で、日本時間では v0.39.0 が10月6日、v0.41.0 が10月16日になる。

この記事で使ったファイルと大きさ、配布元は「使ったファイル」の表のとおり。

役割	表での呼び名	ファイル	大きさ	配布元	対応した ComfyUI
映像VAE (基準)	fp16	`minimax_h3_video_vae_fp16.safetensors`	5.21GB	Comfy-Org/MiniMax-H3	既存
映像VAE	int8	`minimax_h3_video_vae_int8_convrot.safetensors`	2.81GB	Comfy-Org/MiniMax-H3	既存
映像VAE	Lynn	`minimax_h3_lynnreal_light_vae_int8_convrot.safetensors`	2.14GB	Kijai/MiniMax-H3-experimental	0.39.0
映像VAE	Light	`minimax_h3_lightvae_lite_vae_int8_convrot.safetensors`	1.04GB	Kijai/MiniMax-H3-experimental	0.41.0
映像VAE	Sol	`sol_h3_vae.safetensors`	6.47GB	Efficient-Large-Model/Sol-H3-VAE	0.44.0
latent upscaler	upscaler	`minimax_h3_latent_upscaler_3d_conv_v1_bf16.safetensors`	0.69GB	LBH-123-AI/Minimax_h3_latent_Upscaler	0.44.0

大きさは配布元の Hugging Face の表示に合わせた10進の GB。「対応した ComfyUI」は、その機能に対応したリリースを指す。Comfy-Org が別に配る fp16 / int8 の Sol-H3-VAE は測っていないので、「使ったファイル」の表には入れていない。

基準の fp16 と比べる4種の映像VAE

基準にしたのは MiniMax H3 の fp16 の映像VAEで、ほかに4つの映像VAEを試した。この記事ではどれもエンコーダは差し替えず、生成が終わった latent を映像に戻す復号にだけ使っている。

int8 は、Comfy-Org の MiniMax-H3 の配布に含まれる int8 の映像VAE（minimax_h3_video_vae_int8_convrot.safetensors）。ComfyUI 0.44.0 に同梱されている MiniMax H3 の公式テンプレート（テキストから動画）も、この int8 の映像VAEを使う設定になっている。配布物は Comfy-Org/MiniMax-H3 の Hugging Face のファイル一覧で、テンプレートは 0.44.0 に同梱のものを開いて、どちらも2026年11月7日に確かめた。

Lynn は LynnReal の軽いVAEで、元の配布は stdstu123/LynnReal-Onmi-light-vae（ライセンスの表示は minimax-h3-community）。配布元のページによると、MiniMax H3 のエンコーダはそのままで、映像のデコーダを26ブロックに蒸留したものだという。この記事で使ったのは Kijai 氏が int8 に変換したファイルで、Kijai 氏は復号が約1.3倍速いと書いている。何と比べた倍率なのかは書かれていない。

Sol は Sol-H3-VAE のことで、Efficient-Large-Model が配布する MiniMax H3 用の速いデコーダ。配布元は、36層の H3 のデコーダを、そこから蒸留した24層・1.62B パラメータのデコーダに置き換えたものと書いていて、重みは MiniMax-H3 のライセンスに従うとしている。この記事で測ったのは配布元のファイル（sol_h3_vae.safetensors、6.47GB）そのものだ。Comfy-Org は2026年10月29日に、Sol を fp16（3.60GB）と int8（1.99GB）にしたファイルを Comfy-Org/MiniMax-H3 に追加しているが、この2つは測っていない。この記事の測定では、ComfyUI のログに出る映像VAEの dtype は、Sol も含めて5種とも float16 だった。ただし int8 の映像VAEは、ComfyUI 0.44.0 が量子化した重みを見つけると専用の計算経路に切り替えるので、この表示はすべての計算が float16 だったという意味ではない。int8 で実際にどの計算が使われたかまでは確かめていない。Comfy-Org の2つのファイルで VRAM や時間がどうなるかは測っていない。

Light は lightx2v が配布する LightVAE の系統で、lightx2v のページによると、LightVAE は圧縮した VAE で、MiniMax H3 用にはブロックを刈り込んだ Lite のエンコーダとデコーダがある。この記事で使ったのは Kijai 氏のリポジトリにある minimax_h3_lightvae_lite_vae_int8_convrot.safetensors で、エンコーダは元の H3 のものを使い、復号にだけこのファイルを使った。

latent upscaler

latent upscaler（LBH-123-AI/Minimax_h3_latent_Upscaler、ライセンス Apache-2.0）は、配布元の README によると、MiniMax H3 の latent のまま縦横の解像度を上げ、時間方向はそのまま保つモデル。配布元は、低い解像度で作ってから latent を拡大し、目的の解像度で仕上げ直すことで高解像度の生成を速くする使い方を説明している。この記事で使ったのは v1 の bf16 のファイル（0.69GB）。

context windows

context windows は、長い動画を重なりのある短い区間（窓）に分けてサンプリングする仕組み。ComfyUI 0.44.0 の MiniMaxH3ContextWindows ノードの説明は、窓の区切りを17フレーム単位にそろえて映像と音声を同期させるとしている。

新しい機能を使わないComfyUI 0.44.0の生成時間

新しい機能を使わずに ComfyUI 0.44.0 で生成した時間とメモリを、「0.44.0 での生成時間」の表にまとめた。

GPU	解像度とフレーム数	1本目	2本目	VRAMのピーク	メインメモリのピーク
RTX 5080	864×480・56フレーム	63.6秒	54.6秒	15,471MiB	14.2GiB
RTX 5060 Ti	864×480・56フレーム	130.7秒	121.5秒	14,918MiB	12.5GiB
RTX 5080	1344×768・192フレーム	1169.0秒	測っていない	15,468MiB	24.0GiB

時間は、ComfyUI が実行の開始を知らせてから（execution_start）完了を知らせるまで（execution_success）で、キューに入って待つ時間は含まない。1本目はモデルの読み込みを含む。VRAM のピークはカード全体の使用量の最大値で、RTX 5080 は画面出力の分（約1,800MiB）を含む。メインメモリは ComfyUI のプロセスの作業セットのピーク。1344×768・192フレームは1回だけで、2本目は測っていない。

親記事が ComfyUI 0.37.1 で測った値は、864×480・56フレームで RTX 5080 が 58.7秒、RTX 5060 Ti が 121.0秒（どちらも2回目以降の中央値）、1344×768・192フレームが 1208.8秒（1本目）だった。0.44.0 の値と比べて、どれも大きくは変わっていない。

0.44.0 は各1回（56フレームは1本目と2本目の2回）、0.37.1 は親記事の値で、測定日も回数も違う。差は数%の範囲なので、どちらが速いとは言えない。

RTX 5060 Ti の生成時間は、864×480・56フレームで RTX 5080 の約2倍（1本目は 130.7秒と 63.6秒、2本目は 121.5秒と 54.6秒）だった。latent upscaler と context windows は RTX 5060 Ti では測っておらず、以後の節の生成時間はどれも RTX 5080 の値になる。

以後の節で「直接生成」と呼ぶのは、この 1344×768・192フレームを1段で生成した動画で、RTX 5080 の 1169.0秒が比べる基準になる。

映像VAEを差し替えると復号は何秒になるか

映像VAEの復号はサンプリングの後の最後の処理で、直接生成の1本（1169.0秒）のうち、映像の復号は 32.6秒だった。サンプラーは 1125.9秒かかっていた。この記事では映像VAEを復号にだけ使っているので、差し替えてもサンプリングの設定は変わらない。ただし、映像VAEの読み込みを含め、差し替えたうえで生成全体を通した時間は測っていない。この内訳は RTX 5080・fp16 の映像VAE・1回のノードごとの時間で、「映像VAE別の復号」の表の fp16 の 33.6秒（復号だけを回した2回目）とは測り方が違う。

復号の時間と、復号だけのVRAM

直接生成のときの latent を保存し、映像VAEだけを差し替えて復号した（音声は復号していない）。各映像VAEで2回ずつ復号し、映像VAEを読み込み済みの2回目を「映像VAE別の復号」の表に載せた。時間は VAEDecode ノードの時間。

表の PSNR は、fp16 の出力とどれだけ一致するかの指標。復号して保存した画像（RGB 各8bit）を、fp16 の映像VAEの画像と同じフレーム番号どうしで全画素比べ、フレームごとの値を192フレームで平均した。

エッジの強さは、隣り合う画素の値がどれだけ急に変わるかを表す数字で、細かい模様や輪郭のほかに、明るさの差やノイズでも変わる。192フレームから12フレームおきに選んだ16枚をグレースケールにし、4近傍のラプラシアンの分散を1枚ずつ求めて平均した値を、fp16 を100として表した。丸める前は int8 が 100.4、Lynn が 99.7 で、表ではどちらも 100 になる。どちらの指標も画のよしあしを直接測った数字ではない。

VAE	RTX 5080 の復号	RTX 5080 のVRAMのピーク	RTX 5060 Ti の復号	RTX 5060 Ti のVRAMのピーク	PSNR (fp16 と比較)	エッジの強さ (fp16=100)
fp16	33.6秒	7,725MiB	74.0秒	6,026MiB	基準	100
int8	12.3秒	5,327MiB	27.6秒	3,560MiB	57.1dB	100
Lynn	9.6秒	4,682MiB	20.2秒	2,920MiB	43.5dB	100
Sol	10.0秒	11,717MiB	21.8秒	9,892MiB	38.8dB	92
Light	4.5秒	3,810MiB	10.0秒	2,022MiB	33.6dB	59

VRAM のピークはカード全体の使用量の最大値で、RTX 5080 は画面出力の分（1回目の開始前で 1,787〜1,859MiB）を含む。RTX 5060 Ti は画面出力に使っていない。「映像VAE別の復号」の表の VRAM のピークは、保存した latent を復号するだけのワークフローで測った値で、生成全体のピーク（1344×768・192フレームで 15,468MiB）とは別のもの。映像VAEを差し替えたときに生成全体のピークがどう動くかは測っていない。PSNR とエッジの強さは RTX 5080 の2回目の出力から出したもので、1本の動画だけの値。

図: 同じ latent を5種の映像VAEで復号した時間。2回目 (VAE は読み込み済み) の VAEDecode ノードの時間

画がどれだけ変わるか

int8 は fp16 との PSNR が 57.1dB、エッジの強さも 100.4 で、5種のうち基準の fp16 を除くと一致がいちばん高いまま、復号の時間は fp16 の約3分の1になった。ComfyUI 0.44.0 の公式テンプレートが使う設定になっているのもこの int8 で、テンプレートのまま使っている場合は、すでに int8 の映像VAEで復号している。

エッジの強さは Lynn が 99.7 と fp16 並み、Sol が 91.6 と約1割低く、どちらも int8 より速く復号できた。ただし PSNR は Lynn が 43.5dB、Sol が 38.8dB まで下がり、fp16 との一致は int8 より低い。目で見て違いが分かるかは確かめていない。Sol は VRAM のピークが5種で最も大きく、fp16 より大きかった。この値は 192フレームの動画のもので、Sol の配布元は、復号に要る VRAM は動画が長いほど増えると書いている。

Light は5種のうちで復号の時間がいちばん短い一方、エッジの強さが fp16 の約6割（59.2）になった。2つのコマの部分を等倍で並べると、顔の陰影や傘の雨粒が平らになって見えた。

復号を縮めても、測った差は直接生成全体のうち復号の数十秒の中に収まる。RTX 5080 では int8 と Lynn・Sol の復号の差は2〜3秒ほど（RTX 5060 Ti では約6〜7秒）で、RTX 5080 の直接生成全体の 1169.0秒から見ればごく小さい。この1本の比較からは、fp16 との一致を優先するなら int8、一致が下がっても復号を最も短くしたいなら Light、という選び方になる。

Sol の配布元が書いている値

Sol-H3-VAE の配布元は、RTX 5090 で768pの5秒の動画を復号する時間を、H3 の VAE の 12.5秒に対して 5.0秒としている。生成した768pの動画での H3 の VAE との PSNR は 38.2dB だという。GPU・動画の長さ・解像度がこの記事の測定と違ううえ、配布元のコードは Diffusers の上で動き、既定のエンジンは Triton や FlashAttention-4 を使う。ComfyUI のノードで復号したこの記事とは実行の仕組みも違うので、「映像VAE別の復号」の表の値とは並べて示すだけにとどめる。

配布元はまた、Sol はほかのデコーダと違って動画全体を一度に復号するので、latent を少しずつ流しながら復号することはできないとも書いている。

RTX 5060 Ti での復号

RTX 5060 Ti でも5種の速さの順は RTX 5080 と同じで、どれも RTX 5080 の約2倍の時間がかかった（2回目の値どうしの比較）。RTX 5060 Ti は画面出力に使っていないカードで、OCuLink で接続している。

latent upscalerで8秒の動画は何秒になるか

latent upscaler を挟んだ2段の手順（低い解像度で20ステップ、拡大、高い解像度で8または4ステップ）にすると、8秒の動画の時間は直接生成（20ステップ）の約半分（8ステップ仕上げ）から約3分の1（4ステップ仕上げ）になった。ただし、できあがった動画は直接生成とは別の構図だった。縮んだのは手順全体の効果で、直接生成のステップ数を同じように減らした場合とは比べていない。

組んだ2段の手順

配布元の例のワークフローは専用のカスタムノードと4ステップの LoRA を使うが、この記事では ComfyUI 0.44.0 の標準のノードだけで、次の2段を組んだ。カスタムノードは入れていない。

1段目は、672×384・192フレームを20ステップで生成する。
ComfyUI の models/latent_upscale_models フォルダに置いた upscaler を LatentUpscaleModelLoader で読み込み、その出力を MiniMaxH3LatentUpscaleWithModel で 1344×768 に拡大する。
2段目は、1344×768 の条件付けで作った20ステップのスケジュールを SplitSigmas で前後に分ける。分ける位置の step は、8ステップ仕上げで 12、4ステップ仕上げで 16。後ろの8ステップ（または4ステップ）だけで、拡大した latent を仕上げる。2段目の開始の sigma は、8ステップで 0.8889、4ステップで 0.75 だった。

サンプラーは res_multistep、スケジューラは simple。ノイズは RandomNoise の noise_seed で決め、各条件の1本目は 12345、2本目まで回した 864×480・56フレームの生成だけ2本目を 12346 にした。2段の手順では、2段目の SamplerCustomAdvanced にも1段目と同じ RandomNoise を渡している。guider はどの段も BasicGuider（モデルとその段の条件付けだけを受け取る）で、スケジュールは BasicScheduler の denoise 1 で作った。

かかった時間

直接生成と2段の手順の時間を、処理ごとに分けて「latent upscaler の時間」の表に並べた。

手順	全体	1段目のサンプラー	拡大	2段目のサンプラー	映像の復号
直接 1344×768 を生成 (20ステップ)	1169.0秒	1125.9秒	なし	なし	32.6秒
672×384 で生成 → upscaler で拡大 → 8ステップで仕上げ	616.1秒	126.8秒	1.4秒	437.2秒	32.2秒
672×384 で生成 → upscaler で拡大 → 4ステップで仕上げ	396.7秒	126.6秒	1.4秒	219.0秒	32.0秒
672×384 で生成 → 素の LatentUpscale で拡大	エラーで停止	126.5秒	エラー	なし	なし

RTX 5080 で各1回、モデルの読み込みを含む1本目の値。VRAM のピークはどれも 15,460〜15,468MiB、メインメモリの作業セットのピークは 24.0〜24.1GiB で、手順による差は無かった。

低い解像度で回す1段目は短く、時間の多くは 1344×768 で回す2段目のサンプラーに移っている。拡大そのものはほとんど時間を取らない。全体の時間は、1段目と復号などの決まった分（約180秒）に、2段目の1ステップあたり約55秒をステップ数だけ足した形になり、8ステップ仕上げと4ステップ仕上げの差（約220秒）は2段目のステップ数の差でほぼ説明できる。

直接生成とは構図が変わる

latent upscaler で作った動画は、同じプロンプト・同じ seed で直接 1344×768 を生成した動画とは構図が違った。カメラの位置が低く、人物が遠い。テキストから動画を作る今回の手順では、直接生成した動画を速く作り直すことはできなかった。この手順は、最初のノイズの大きさ（672×384）も、高い解像度で回すステップ数も直接生成と違い、どれが構図を変えたのかは切り分けていない。参照画像を使うなど、ほかの手順は試していない。

latent upscaler は、直接作った動画を速く作り直す機能というより、低い解像度で作った動画を大きくする手順になる。画の中身は1段目の低い解像度の段階で決まっている可能性があるが、1段目の 672×384 の出力と最終の動画を並べて確かめてはいない。

仕上げを4ステップにすると、8ステップより約220秒短くなる代わりに、2つの時刻のコマを見た範囲では細部がやや甘かった。見たコマには、どちらの仕上げにも崩れは無かった。動画を通して見たときのちらつきや一時的な崩れは確かめていない。同じ時刻のコマのエッジの強さ（ラプラシアンの分散）を2つの時刻で比べると、直接生成が 208.8 / 178.4、8ステップ仕上げが 207.3 / 188.3、4ステップ仕上げが 177.4 / 166.4 で、4ステップ仕上げのほうが8ステップ仕上げより小さかった。直接生成とは構図が違う動画どうしの値なので、目安として見るにとどめる。

束ねた latent は素の LatentUpscale に渡せない

比べるために、拡大を ComfyUI の素の LatentUpscale（bilinear）に替えると、拡大のノードで 'NestedTensor' object has no attribute 'reshape' というエラーになり、動画は出なかった（ComfyUI 0.44.0・RTX 5080・1回）。MiniMax H3 のサンプラーの出力は映像と音声を束ねた latent で、それをそのまま渡すと素の LatentUpscale は受けられない。映像の latent だけを取り出して拡大する手順は試していない。

配布元の README は、専用のカスタムノード（Comfyui_Minimax_h3_latent_Upscaler）を入れて使う手順を案内している。この記事は ComfyUI 0.44.0 の標準のノードで動かしたので、カスタムノードでの時間や出来は測っていない。

context windowsで15秒・30秒の動画を作る

context windows は、モデルとサンプリングのあいだにノードを1つ挟むだけで使える。15秒の動画では窓ありのほうが窓なしより短い時間で終わり、30秒の動画も窓ありで最後まで生成できた。

ノードの挟み方と設定

UNETLoader の出力を MiniMaxH3ContextWindows に通し、その出力をスケジューラとガイダーの model に渡して使った。設定はノードの既定値のままで、窓1つの長さ（context_length）は124フレーム、隣り合う窓の重なり（context_overlap）は39フレーム、窓どうしを混ぜる方法（fuse_method）は pyramid、窓のつなぎ目をなじませるノイズの並べ替え（freenoise）は有効。窓の長さと重なりは 17の倍数+5 フレームで指定する。

時間とメモリ

窓の有無で時間とメモリがどう変わったかを「context windows の時間とメモリ」の表にまとめた。362フレームは約15秒、719フレームは約30秒（24fps）。

解像度とフレーム数	窓	全体	うちサンプラー	メインメモリのピーク	共有GPUメモリのピーク
864×480・362フレーム	なし	774.1秒	724.2秒	21.2GiB	14,255MiB
864×480・362フレーム	あり	566.5秒	518.1秒	16.6GiB	9,451MiB
864×480・719フレーム	あり	1150.3秒	1060.6秒	18.5GiB	9,651MiB
1344×768・362フレーム	なし	3571.9秒	3493.0秒	29.8GiB	24,172MiB
1344×768・362フレーム	あり	2262.6秒	2182.7秒	23.2GiB	13,356MiB

RTX 5080 で各1回、モデルの読み込みを含む1本目の値（20ステップ・seed 12345）。VRAM のピークはどれも 15,486〜15,653MiB で、画面出力の分を含む。メインメモリは ComfyUI のプロセスの作業セットのピーク、共有GPUメモリは Windows のパフォーマンスカウンタのピーク。864×480・719フレームの窓なしは測っていない。

窓ありにすると、全体の時間は 864×480 で約4分の3、1344×768 で約3分の2になり、メインメモリと共有GPUメモリの使用量も減った。30秒の 719フレームも、窓ありで最後まで生成できた（窓なしの30秒は測っていない）。ComfyUI 0.44.0 で動画の長さを指定するノード（MiniMaxH3ImageToVideo）の length の説明は、学習した長さの範囲を約124〜362フレーム（約5〜15秒）とし、それより長い指定は未検証としている。30秒はこの範囲の外で、最後まで生成できたことと、中身が保たれることは別の話になる。なお、0.37.1 との比較に使った 56フレームの短い動画も、この範囲より短い側に外れている。

VRAM のピークは窓の有無にかかわらず、どの条件も 15,486〜15,653MiB（約15.1〜15.3GiB）で、16GB のカードの上限近くに張りついていた。差が出たのはメインメモリ（ComfyUI のプロセスの作業セット）と共有GPUメモリのほうだ。共有GPUメモリは、GPU がメインメモリ側に置いて使う分の量で（画面出力など ComfyUI 以外の分も含む、GPU 1枚ごとの値）、Windows のタスクマネージャーにも同じ名前の項目がある。1344×768・362フレームの窓なしは、共有GPUメモリが 24,172MiB と、カードの VRAM を超える量まで増えていた。窓ありは 13,356MiB で、作業セットのピークも 29.8GiB から 23.2GiB に下がった。

窓なしの作業セットのピーク 29.8GiB は、メインメモリ 96GB の PC で ComfyUI のプロセスが物理メモリに置いていた量の最大値になる。メインメモリが少ない PC で同じ条件が遅くなるか止まるかは、OS やほかのプロセスが使う分やページングにも左右される。窓ありで使用量が減ることは、メインメモリが少ない PC ほど助けになると考えられる。ただし、96GB より少ないメインメモリでは測っていない。

動画の中身が変わる

この1組では、窓の有無で動画の中身が変わった。864×480・362フレームでは、窓なしはプロンプトどおり傘を持った人物が遠くからカメラへ近づいてきたが、窓ありでは人物は遠くを歩いたままで、看板や屋台の細部が数秒ごとに入れ替わった。

30秒の動画も同じ傾向で、通りの並びは保たれたまま、看板や人物の位置が少しずつ変わり続けた。コマは間をあけて見たので、窓の継ぎ目でコマが飛んだり、ちらついたりしていないかは確かめていない。

どれも各条件1本（seed 12345）の映像を3秒おきのコマで見た範囲の話で、音声は聴いていない。窓ありでは、窓に分けることに加えて、初期ノイズの並べ替え（freenoise）も有効になっている。1本ずつの比較なので、窓に分けたことによる差か、ノイズが変わって別のサンプルになったことによる差かは切り分けていない。プロンプトで指定した動きや場面のつながりが窓なしと同じになるとは限らない、という前提で使うことになる。

測っていないこと

各節の主張の範囲を変える条件はそれぞれの節に書いた。ここでは、この記事で測っていないものを一覧にする。

latent upscaler と context windows を RTX 5060 Ti で使った場合
latent upscaler と context windows と映像VAEの差し替えを組み合わせた場合
画像から動画（i2v）と参照つきの生成
Turbo LoRA と組み合わせた場合
Comfy-Org が配る fp16 / int8 の Sol-H3-VAE
配布元が案内する latent upscaler のカスタムノード
窓なしの 30秒
窓の長さや重なりを変えた場合
音声の出来
メインメモリが 96GB より少ない PC
VRAM 12GB 以下のカード
192フレームより長い動画での、fp16 以外の映像VAE（int8・Lynn・Sol・Light）の復号（Sol は、長い動画ほど要る VRAM が増えると配布元が書いている）
1344×768 の窓ありの映像の中身（中身を見たのは 864×480 の2本だけ）

検証環境と測り方

測定は ComfyUI 0.44.0・PyTorch 2.14.0+cu130 で、RTX 5080（画面出力にも使っているカード）と、OCuLink（PCIe 4.0 x4）で接続した RTX 5060 Ti を1枚ずつ使った。条件ごとの ComfyUI の起動ログで、実行に使う GPU が指定したカードであることと、動的な VRAM の読み込み（DynamicVRAM）が有効なことを確かめている。CPU は Core i7-14700F、メインメモリは 96GB、OS は Windows。モデルは親記事と同じ構成（拡散モデル FP8、テキストエンコーダ NVFP4、映像VAE fp16、音声VAE fp32）で、サンプラーは res_multistep・スケジューラ simple・20ステップ・24fps。測定機の構成の詳細は検証環境のページに載せている。

2枚目の GPU である RTX 5060 Ti で ComfyUI を動かす手順は、ComfyUIで使うGPUを指定する｜v0.34以降のWindowsは既定で1枚しか使わないに書いた。

時間は ComfyUI の実行開始の通知（execution_start）から完了の通知（execution_success）までで、モデルの読み込みを含む1本目と、読み込み済みの2本目を分けて記録した。条件ごとに ComfyUI を起動し直している。

プロンプトは2種類で、864×480・56フレームは窓辺の猫、それ以外は雨の夜の繁華街を傘を持った人物が歩いてくる場面（環境音つき）。全文は英語で、次のとおり。

窓辺の猫

A calico cat sits on a wooden windowsill in soft morning light, slowly turning its head toward the camera, a gentle breeze moves the lace curtain, birds chirping outside, shallow depth of field, cinematic

雨の夜の繁華街

Rain-soaked Tokyo backstreet at night, glowing neon signs reflected in puddles, a person holding a transparent umbrella walks slowly toward the camera, steam rising from a ramen stall on the left, shallow depth of field, anamorphic lens flares, subtle film grain, cinematic color grading. Ambient sound: steady rainfall, distant city traffic, sizzling from the stall.

1344×768・362フレームの窓ありは、最初の1回が同じ PC の別の負荷（大きなファイルのダウンロードなど）と重なったので使わず、測り直した1回を載せた。

単位は、手元で見る表示のままにしてある。ファイルの大きさは配布元の表示に合わせた10進の GB、VRAM は nvidia-smi の表示の MiB、共有GPUメモリも MiB、メインメモリは GiB で載せた。ピークは、VRAM を 0.5秒おき、メインメモリを 0.25秒おき、共有GPUメモリを1秒おきに取った値の最大で、そのあいだの一瞬だけの増加は捉えていない可能性がある。

本文の実測値は2026年11月5日〜6日に測定したもの。ComfyUI 0.44.0・PyTorch 2.14.0+cu130 で、ComfyUI やモデルの更新で変わりうる。2026年11月7日の時点では ComfyUI 0.44.1・0.44.2 も出ているが、0.44.0 からの変更は、コミットの題と変更したファイルを見るかぎりパートナーノードの追加とワークフローテンプレートの更新が中心で、この記事で測った映像VAE・latent upscaler・context windows に関わるものは見当たらなかった。テンプレートが int8 の映像VAEを使う設定であることを確かめたのは、0.44.0 に同梱のものだけになる。

まとめ

latent upscaler と context windows の結果は RTX 5080 で各条件1回ずつ測ったもの。映像VAEの復号は、1本の動画の latent を RTX 5080 と RTX 5060 Ti で各2回復号した2回目の値を使った。比べる相手は同じ ComfyUI 0.44.0 での直接生成と窓なし。新しい機能を使わない ComfyUI 0.44.0 の生成時間は、親記事の 0.37.1 での値と大きくは違わなかった。測定日も回数も違うので、更新だけの効果を切り分けたものではない。

時間を縮めたい場合、効果が大きかったのは latent upscaler と context windows だった。latent upscaler を挟んだ2段の手順は、8秒の動画を直接生成の約半分〜3分の1の時間で作れたが、直接生成とは別の構図になった。仕上げを4ステップまで減らすと、2つの時刻のコマを見た範囲では細部がやや甘かった。

この記事の3つのうち、サンプリングに手を入れないのは映像VAEの差し替えで、測ったのは最後の復号の部分の短縮になる。読み込みを含む生成全体では測っていない。ただし差し替えると、出力は fp16 と画素の単位では一致しなくなる。今回の1本では、int8 が fp16 との一致がいちばん高いまま復号を縮め、ComfyUI 0.44.0 の公式テンプレートもこれを使う設定になっている。Lynn と Sol は int8 より速いが、PSNR では fp16 との一致が下がり、Sol はエッジの強さも約1割低かった。Light は復号の時間がいちばん短い代わりに、等倍で見ると細部が平らになった。

長い動画を作りたい場合、context windows は15秒の動画の時間を約3分の2〜4分の3に縮め、メインメモリと共有GPUメモリの使用量も減らした。30秒の動画も、長さの指定の説明が未検証とする長さだが、最後まで生成できた。ただし 864×480・362フレームの窓ありの1本では、窓なしで出た人物の近づく動きが出ず、看板や屋台が入れ替わり続けた。窓に分けたことによる差か、freenoise でノイズが変わって別のサンプルになったことによる差かは切り分けていない。

生成そのものを速くしたい場合は、ステップ数を減らす方法もある。ただし、ステップを減らしたときの出力が元と同じになるかは、次の2本の記事でも構図や動きまでは見ていない。MiniMax H3 Turbo LoRA（step600 EMA）とは｜ComfyUIの置き場所・推奨ステップ数と速さをRTX 5080/5060 Tiで実測は元の MiniMax H3 のステップ数を減らす方法を、FastH3 OmniをVRAM 16GBで動かす｜元のMiniMax H3のTurbo LoRAとどちらを使うかは8ステップに縮めた別のモデルを比べている。