この記事について（広告・アフィリエイトリンクはありません）
結論：Lite は元の VAE に足す部品です。元の VAE を標準の Load VAE で読み、Lite は Load H3 LightVAE で選びます。エンコーダーは替えず、デコーダーだけ替えるのが無難です。
できること
- エラーの文から、どのファイルで何が起きたかを見分ける
Load H3 LightVAEで Lite を動かす- ノードなしで使える int8 版を選ぶ
難易度：ふつう。所要時間：ファイルが揃っていれば約10分。
H3 そのものの導入は、MiniMax H3の使い方を先に見てください。
ファイル別の結果
標準の VAEを読み込む（Load VAE）で読んだ場合と、Load H3 LightVAE で読んだ場合です。
| ファイル | サイズ | 標準 v0.40.0 | 標準 v0.44.0 | ノード v0.44.0 |
|---|---|---|---|---|
元の minimax_h3_video_vae_int8_convrot | 2.81GB | 通る | 通る | base_vae に使う |
lightvae-lite-h3-decoder | 3.25GB | VAE is invalid | デコードでサイズのエラー | 通る |
lightvae-lite-h3-decoder-comfy | 3.25GB | VAE is invalid | デコードでサイズのエラー | 通る |
lightvae-lite-h3-decoder-int8-convrot | 0.83GB | VAE is invalid | 通る | 通る |
lightvae-lite-h3-encoder | 0.41GB | VAE is invalid | VAE is invalid | 通る |
lynnreal_omni_light_vae_fp16 | 3.86GB | 通る | 通る | 対象外 |
エラーの全文は次のとおりです。
RuntimeError: ERROR: VAE is invalid: None
If the VAE is from a checkpoint loader node your checkpoint does not contain a valid VAE.RuntimeError: Expected size for first two dimensions of batch2 tensor to be: [4, 24] but got: [4, 2048].2つ目の文は、バッチの大きさで最初の数字が変わります（小さい試験では [3, 24]）。
ComfyUI 本体の PR #17049 は、2026年10月15日にマージされました。説明には、LightVAE の対応と、エンコーダーとデコーダーを別々に読み込む対応が書かれています。v0.40.0 はこの変更の前で、v0.44.0 には入っています。
v0.44.0 で decoder と -comfy が標準のノードで止まる理由として考えられるのは、int8 版と中の名前の違いです。decoder には attn.to_k のような名前が入り、int8 版は attn.to_qkv のような名前。これはファイルの中を見た私の推測です。
ノードの入れ方
README の手順で、今回は検証用の ComfyUI に入れました。カスタムノードの基本の入れ方はこちらにまとめています。H3 向けのほかのノードはH3 専用カスタムノード8選で紹介しています。
- リポジトリを
custom_nodesの外に clone する - ComfyUI のフォルダーで、次を実行する
git clone https://github.com/ModelTC/LightVAE.git LightVAE
python LightVAE/comfyui/install.py --comfy-root .- Lite のファイルを
models/vae/LightVAEに置く - ComfyUI を起動し直す
ポータブル版なら、python は python_embeded\python.exe に読み替えます。今回は同梱の Python で install.py を実行しました。追加のパッケージは入りません。
custom_nodes にリポジトリをそのまま置くと、起動ログに次の行が出ました。ルートに __init__.py がないためです。
FileNotFoundError: [Errno 2] No such file or directory: '...\custom_nodes\LightVAE\__init__.py'つなぎ方
VAEを読み込む で元の VAE を選び、Load H3 LightVAE の base_vae につなぎます。Load H3 LightVAE の出力を、動画のノードと VAEデコード につなぎます。
encoder は none のままにします。理由は後で書きます。
- h3_fl2v_lightvae_node.jsonComfyUI にドラッグして読み込みます。入力画像は自分のものに差し替えてください
速さと VRAM
1344×768、124 フレーム（約5秒）のデコードです。同じ生成結果を VAE だけ替えて、各6回測りました。
| VAE | 読み方 | デコード（中央値） | VRAM のピーク |
|---|---|---|---|
| 元の fp16 | 標準 | 11.8秒 | 約7.7GB |
| 元の int8 | 標準 | 5.2秒 | 約5.4GB |
| LynnReal light | 標準 | 8.7秒 | 約6.4GB |
| Lite decoder | ノード | 約4.1秒 | 約4.5GB |
Lite decoder -comfy | ノード | 約4.1秒 | 約4.5GB |
| Lite decoder int8 | ノード | 約2.0秒 | 約3.6GB |
| Lite decoder int8 | 標準 | 約2.0秒 | 約3.7GB |
VRAM には、この PC の他のアプリの約1.9GB が含まれます。
サンプリングの時間は変わりません。今回の1本では、サンプリングに約96秒かかっています。デコードが数秒縮んでも、全体の短縮は数秒です。
画質
元の fp16 との差を、3シードの3フレームずつで比べました。PSNR は大きいほど元に近い値です。
| VAE | 元の fp16 との差（PSNR） |
|---|---|
| 元の int8 | 54.7〜58.6dB |
| LynnReal light | 37.6〜45.3dB |
Lite（decoder、-comfy、int8 のどれも） | 30.8〜37.9dB |
Lite は速い代わりに、元の VAE との差が一番大きくなりました。 下の比較では、木の細かい部分が少し甘くなっています。
Lite の3種類どうしの比較も取りました。
decoderと-comfyは、確かめたフレームで完全に同じでした。両方ダウンロードする必要はありません。decoderと int8 版の差は、画素の平均で 0.1 以下でした。base_vaeを fp16 と int8 で替えても、同じ結果でした。- int8 版は、標準のノードで読んでも、ノードで読んでも同じ結果でした。
今回の結果では、一番小さい int8 版で十分でした。 標準のノードで動くので、ノードを入れなくても使えます。ただし README が案内しているのはノードの方法で、標準のノードで読めるのは今回の版での結果です。
エンコーダーは替えない
画像から動画を作るときは、入力の画像を VAE でエンコードします。同じ入力とシードで、3通り試しました。
| 設定 | 結果 | 元の VAE だけとの差 |
|---|---|---|
| 元の VAE だけ | 通る | 基準 |
| デコーダーだけ Lite | 通る | 35.7〜38.2dB |
| エンコーダーも Lite | 通る | 18.5〜28.7dB |
エンコーダーも Lite にすると、絵が崩れるわけではなく、キツネの位置や動きが別のものになりました。 README でも、最初と最後のフレームから作る場合はデコーダーだけを替える案内です。
速さの利点も小さく、1枚のエンコードは 0.3秒が 0.2秒になった程度でした。
なお、int8 版を標準のノードで読んで、そのままエンコードに使うと止まります。
'MiniMaxH3VideoVAE' object has no attribute 'quant_conv'ノードなしで使うなら、VAEを読み込む を2つ置き、エンコードには元の VAE、VAEデコード には Lite をつなぎます。これも3シードで通りました。
- h3_fl2v_lightvae_decoder.jsonComfyUI にドラッグして読み込みます。入力画像は自分のものに差し替えてください
混ぜやすい3つの話
- LynnReal の light VAE：デコーダーとエンコーダーの両方が入ったファイルで、標準のノードで読みました。v0.40.0 でも通っています。
- lightx2v の Lite：この記事の中心です。デコーダーとエンコーダーが別のファイルです。
- TLR と
-comfy：配布元の議論には、-comfyにLoad LightVAE (TLR)が要るという古い案内があります。今の README では H3 に TLR はいらないと書かれていて、今回も TLR なしで-comfyが通りました。
つまずいた点
最初は「現行版でも VAE is invalid が再現する」と考えていました。ところが v0.44.0 の decoder は読み込みまで通り、デコードで別の文のエラーが出ます。v0.40.0 を起動して、ようやく報告と同じエラーを decoder で再現できました。
ノードを入れた直後は、decoder の欄が none だけでした。Lite のファイルを普段の models/vae に置いていたためです。このノードは models/vae/LightVAE だけを見ます。 移すと、欄に表示されました。
SaveLatent で生成結果を保存して使い回すつもりでしたが、H3 の結果では 'NestedTensor' object has no attribute 'contiguous' で保存できませんでした。ComfyUI のキャッシュを使って VAE だけ替える形に変えています。
よくある質問（FAQ）
Q. VRAM の少ない PC で効きますか？
デコードのピークは下がりました。ただしサンプリングのピークは別なので、Lite だけで足りるとは言えません。少ない VRAM の実機では試していません。
Q. どれを選べばいいですか？
仕上げには元の VAE を選びます。確認を急ぐときは、Lite の int8 版をデコーダーにする形が今回は無難でした。
Q. 最初の読み込みが遅いのはなぜですか？
ノードで decoder と -comfy を最初に読んだときは約60秒でした。2回目からは約1秒です。ディスクからの読み込みの時間と考えられます。int8 版は約0.3秒でした。
まとめ
VAE is invalidは、Lite を標準のノードで読んだときの代表的なエラーです。- Lite は
models/vae/LightVAEに置き、Load H3 LightVAEで選びます。 - エンコーダーは元のままにして、デコーダーだけ替えます。
検証メモ
- 更新：2026年11月4日に、最初はノードなしで公開し、同じ日のうちにノードの結果を追記しました。
- ファイル別の表：標準のノードは 512×320・25 フレームの空の latent、ノードは下の実際の生成結果で確かめました。
- 速さの表：シード 101、202、303 を各1回、シード 303 をさらに3回測りました。LynnReal だけはノードを入れる前の6回です。ディスクの読み込みが重なった回は、これより遅くなりました（fp16 の初回は 62〜70秒）。VRAM は、モデルを降ろしてからの値で、開始時に VRAM が残っていた回は外しました。元の int8 の VRAM は、外したあと2回分です。
- 画質：各シードの 1、63、124 フレーム目を比べた範囲です。プロンプトは1種類で、動きの多い映像は試していません。
- 画像から動画：FL2V の pruned int8、960×544、8 ステップ、シード 11、22、33 で、差は 63 フレーム目だけの比較です。元の VAE は fp16（ノードあり）と int8（ノードなし）で試しました。ノードなしの2つの VAE の構成でも、デコーダーだけ Lite の差は同じ 35.7〜38.2dB でした。
- エンコードの速さ：1344×768 の1枚で、ノードの
encoderが 0.18〜0.25秒、元の fp16 が 0.29〜0.30秒です（初回の 4.18秒を除く）。動画のリファレンスでの差は試していません。 - ライセンス：LightVAE のカードは Apache-2.0 です。LynnReal は minimax-h3-community です。H3 本体のライセンスは導入の記事を見てください。
- ダウンロード：LightVAE と LynnReal は同意なしで取得できました（2026年11月4日時点）。
- ノード：ModelTC/LightVAE（38b0587）の
comfyuiフォルダーをinstall.pyで入れました。 - 未確認のこと：REF2V、TLR ノード、v0.44.0 より前の版でのノード、少ない VRAM の実機、Comfy Desktop 版。
