画像生成AIのVAEはなぜ重い？ Qwen-ImageとHunyuanImageのアーキテクチャ比較

Qwen-Image-Editをローカルで動かしていると、VAEの推論フェーズでやたら待たされる。M1 Max 64GBでも体感でわかるくらい止まる。モデル本体の20Bが重いのは当然として、なんでVAEまで重いのか気になって調べた。

ちょうどKohya氏（sd-scripts / musubi-tuner開発者）がVAEのメモリ使用量を32GBから6GBに削減したというツイートをしていたり、Tencent発のHunyuanImage 2.1がVAE設計で面白いアプローチを取っていたりしたので、あわせて整理する。

VAEの役割

画像生成AIの基本的なパイプラインはこうなっている:

テキスト → テキストエンコーダ → DiT（ノイズ除去） → VAEデコード → 画像

VAE（Variational AutoEncoder）は画像とlatent空間の変換を担当する。エンコーダが画像をlatentに圧縮し、デコーダがlatentを画像に復元する。

推論時にVRAMを消費するのはDiT（メインのTransformer）とVAEの2つ。DiTの最適化（fp8量子化、block swap、SageAttentionなど）は進んでいるが、VAE側はあまり注目されてこなかった。

Qwen-Image-EditのVAEが重い理由

Wan-2.1-VAEベースの大きなモデル

Qwen-Image（20B MMDiT）のVAEは Wan-2.1-VAE をベースにしている。構成はsingle-encoder / dual-decoderで、エンコーダはWan-2.1から凍結、画像デコーダをテキストリッチなデータ（PDF、ポスター、合成テキストなど）でfine-tuneしたもの。

テキスト描画品質を上げるためにデコーダを強化した結果、VAE自体のパラメータ数と計算量が増えている。

二重エンコードの負荷

Qwen-Image-Editでは、入力画像を2つの経路で処理する:

Qwen2.5-VL に通して意味理解（セマンティクス）を抽出
VAEエンコーダ に通してビジュアル情報（色、テクスチャ、レイアウト）を抽出

この二重エンコードのおかげで「元画像のキャラを維持しつつポーズだけ変える」といった編集が高精度でできるが、VAE周りの計算量が単純に多い。

Apple Siliconとの相性問題

前回の記事でも書いたが、デフォルトだとVAEが bfloat16 で動作し、Apple SiliconのMPSバックエンドでNaNが出る。--fp16-vae で回避できるとはいえ、VAEの数値精度が問題になるほどデカいモデルだという証拠でもある。

HunyuanImage 2.1の逆張り: 32x高圧縮VAE

Tencent発のHunyuanImage 2.1は、VAE設計で真逆のアプローチを取った。

圧縮率の違い

モデル	VAE圧縮率	備考
Stable Diffusion	8x	定番
FLUX	16x	SD比でlatent半減
HunyuanImage 2.1	32x	超高圧縮

32x spatial compressionということは、2048×2048の画像が64×64のlatentになる。FLUX（16x）なら128×128、SD（8x）なら256×256。latentが小さければDiTが処理するトークン数が激減するため、DiT側の推論が大幅に軽くなる。

DINOv2による品質維持

普通、圧縮率を上げれば画質が落ちる。HunyuanImage 2.1ではVAEの特徴空間を DINOv2（Meta発の自己教師あり学習モデル）の特徴空間にalignすることで、高圧縮でも意味的な情報を保持している。

結果として、2K画像を他のモデルの1K相当のトークン数で処理できる。Kohya氏も「VAEが高圧縮のせいかサイズのわりに推論は軽い」とコメントしている。

17B DiTとの組み合わせ

DiTは17Bパラメータのdual-stream構成。Qwen-Imageの20Bと同クラスだが、VAEの高圧縮によってDiTへの入力トークンが少ないため、実効的な推論コストはかなり低い。

設計思想の比較

	Qwen-Image	HunyuanImage 2.1
VAE圧縮率	低〜中（Wan-2.1準拠）	32x（超高圧縮）
VAEの重さ	重い（dual-decoder + fine-tuned）	軽め（高圧縮で出力を小さく）
DiTの負荷	高い（latentが大きい）	低い（latentが小さい）
編集能力	強い（二重エンコード）	生成特化
テキスト描画	非常に高品質	高品質
VRAM要求	高い	比較的低い

Qwen-Imageは VAEに機能を詰め込んで編集精度を上げる アプローチ、HunyuanImage 2.1は VAEを軽くしてシステム全体を効率化する アプローチ。目的が違うので単純な優劣はないが、VRAM制約のある環境ではHunyuanImageの設計が有利。

Kohya氏のVAEメモリ最適化

musubi-tuner（Kohya氏の学習・推論フレームワーク）では、各モデルのVAEメモリ最適化が進められている。

主な手法

VAEタイリング: 画像を分割してVAEに通すことでピークVRAMを削減。--vae_spatial_tile_sample_min_size で制御
CPU offload: --vae_cache_cpu でVAEの内部キャッシュをメインメモリに退避
FramePack対応: 動画モデル向けに常時VAEタイリングを有効化（PR #583）

32GB → 6GBの話

2026年2月時点で、Kohya氏がVAEメモリ使用量を32GBから6GBに削減したという報告があるが、musubi-tunerのリポジトリにはまだマージされていない（最新コミットは2026年1月29日）。開発中の成果をツイートで先出しして、後からリリースするいつものパターンだと思われる。

Qwen-Image 2.0の方向性

2026年2月10日にリリースされたQwen-Image 2.0は、VAEの重さ問題に対して別のアプローチを取った。

パラメータ数を 20B → 7B に大幅削減（約1/3）
Qwen3-VL（8B）をエンコーダ、7B DiTをデコーダとする構成
生成と編集を 単一モデルに統合（以前は別々だった）
ネイティブ2K解像度対応

モデル全体を軽量化することでVAEの負荷問題を間接的に緩和する方針。ただし2026年2月時点ではAPI提供のみで、ローカル実行用のウェイトは公開されていない。

ローカル勢にとっての現実

現状でQwen-Image-Editをローカルで使う場合の対処法:

RTX 4090以上: fp8量子化 + SageAttentionでDiTを軽くし、VAEタイリングを併用
Apple Silicon 64GB以上: --fp16-vae 必須。生成速度は遅いが動く
VRAM 24GB以下: RunPodなどクラウドGPUが現実的

Kohya氏のVAE最適化がmusubi-tunerにマージされれば、VRAM 24GB環境でもVAEがボトルネックにならなくなる可能性がある。HunyuanImage 2.1のような高圧縮VAEが他のモデルにも波及すれば、さらに状況は改善する。

Qwen-Image 2.0のウェイト公開も待ち遠しい。7Bで編集までできるなら、24GBどころか16GBでもいけるかもしれない。