前回、ROCm 10 を Windows の RX 9070 XT に入れた。FLUX.1 が3倍速くなったので、次に気になるのは当然これである。
16GBのRadeonで、動画生成は動くのか。
当ブログのRadeon記事は、画像生成とローカルLLMで止まっていた。動画は1本も無い。理由は単純で、動画生成モデルは大きいからだ。いま主流の Wan 2.2 は 14B、LTX-2.3 は 22B。fp8 にしても 14〜30GB で、16GB の VRAM には物理的に入らない。
だから「入らないものを無理に動かすとどうなるか」まで含めて、6モデル・10条件を全部同じマシンで回した。
結論を先に言う。速度の話と、見た目の話は別だった。
【結論】速いのは3つ。見るに耐えるのは1つ
1280×704・5秒（Wan は 81〜121フレーム、LTX は 126フレーム）で揃えた。合計時間はモデルのロードを除いた、テキストエンコード〜動画書き出しまでの実時間である。
| モデル | 合計 | VRAM最大 | 見た目 |
|---|---|---|---|
| Wan 2.2 14B fp8 + 4step LoRA | 6分30秒 | 14.2GB | 見るに耐える。これだけ |
| LTX-2.3 22B distilled fp8（音声付き） | 3分33秒 | 15.6GB | 映画的だがのっぺり。指示が効かない |
| Wan 2.2 5B fp16 | 7分52秒 | 15.9GB | のっぺり |
| HunyuanVideo 1.5 480p fp8 + 4step LoRA | 4分12秒（848×480） | — | 眠い |
| Wan 2.2 14B fp8（素・20step） | 54分16秒 | 14.2GB | 良いが待てない |
| HunyuanVideo 1.5 720p fp16 | 73分見込み・中断 | 12.2GB | — |
- 動くかどうかで言えば、全部動く。16GBに入らない 14B も 22B も、メインメモリ64GBに逃がして完走した
- 使えるかどうかで言えば、Wan 2.2 14B に蒸留LoRAを足した構成だけが、時間と見た目の両方で合格だった
- 速さで選ぶと失敗する。LTX-2.3 は最速の3分半だが、出てきた動画は綺麗な壁紙が揺れているだけだった
そして、この記事でいちばん伝えたいのは次の2つである。
- 16GBの壁は、サンプリングではなくVAEデコードに出る。ノードを1つ差し替えるだけで 258秒が28秒になった
- 14Bは素だと54分、LoRAで6分半。「16GBで14Bは無理」は、もう古い
【環境】前回のROCm 10環境をそのまま使った
| GPU | Radeon RX 9070 XT 16GB（gfx1201） |
| CPU / メモリ | Ryzen 9 7900X / DDR5 64GB |
| OS | Windows 11 |
| ComfyUI | 0.35.0（Python 3.14.4） |
| PyTorch | 2.13.0+rocm10.0.0 |
| 起動 | python main.py --cuda-device 1（起動オプションなし・環境変数なし） |
前回の記事で組んだ環境に、何も足していない。MIOpen の環境変数も、--use-pytorch-cross-attention も入れていない。
ワークフローはすべて ComfyUI 公式テンプレートの設定値をそのまま使い、API 経由で投げた。時間はノードごとの開始イベントの差分で取っているので、「サンプリングに何秒、VAEに何秒」が分かる。VRAM は Windows のパフォーマンスカウンタを1秒ごとに読んだ最大値である。
プロンプトは全条件で同じ。「夕日の海岸道路を走る赤いバイク、カメラが追従するトラッキングショット」。
注意点が1つ。 Ryzen のデスクトップは、何もしないと内蔵GPUを掴む。前回の記事に書いた --cuda-device 1 は今回も必須だった。
【モデル】どれを落としたか
全部で 約110GB 落とした。
モデルを何本も置くなら、置き場所は先に確保しておいたほうがいい。
ポチップ
ポチップ
| モデル | ファイル | 容量 |
|---|---|---|
| Wan 2.2 TI2V-5B | wan2.2_ti2v_5B_fp16.safetensors | 10.0GB |
| Wan 2.2 T2V-14B fp8 | wan2.2_t2v_high_noise_14B_fp8_scaled ＋ low_noise | 14.3GB × 2 |
| └ 4step LoRA | wan2.2_t2v_lightx2v_4steps_lora_v1.1_high/low_noise | 1.2GB × 2 |
| └ テキストエンコーダ / VAE | umt5_xxl_fp8_e4m3fn_scaled / wan2.2_vae wan_2.1_vae | 6.7GB / 1.4GB / 0.25GB |
| LTX-2.3 22B distilled fp8 | ltx-2.3-22b-distilled-fp8.safetensors（VAE同梱） | 29.5GB |
| └ テキストエンコーダ / アップスケーラ | gemma_3_12B_it_fp4_mixed / ltx-2.3-spatial-upscaler-x2-1.1 | 9.4GB / 1.0GB |
| HunyuanVideo 1.5 | hunyuanvideo1.5_480p_t2v_cfg_distilled_fp8_scaled / 720p_t2v_fp16 | 8.3GB / 16.7GB |
| └ テキストエンコーダ / VAE | qwen_2.5_vl_7b_fp8_scaled ＋ byt5_small_glyphxl_fp16 / hunyuanvideo15_vae_fp16 | 9.4GB ＋ 0.4GB / 2.5GB |
| LTX-Video 2B distilled | ltxv-2b-0.9.8-distilled.safetensors | 6.3GB |
Wan と Hunyuan は Comfy-Org のリポジトリ（Wan_2.2_ComfyUI_Repackaged / HunyuanVideo_1.5_repackaged）、LTX-2.3 は Lightricks 公式の fp8 リポジトリから。LTX 2.5 は公式リポジトリが全部ゲート付き（ライセンス同意が要る）だったので今回は外した。
Hugging Face からの直接ダウンロードは、大きいファイルだと途中で切れる。curl -C - で再開する前提で落とすとよい。
ちなみに Hunyuan のテキストエンコーダ qwen_2.5_vl_7b_fp8_scaled は、Qwen-Image 用に持っていたものがそのまま使えた。
【本題1】16GBの壁は、VAEデコードに出る
最初に Wan 2.2 5B を、公式テンプレートの既定値（1280×704・121フレーム・30step）で回した。
完走した。14分15秒。VRAM の最大は 15,904MB で、16,304MB の枠にぎりぎり収まっている。
だが内訳を見ると、おかしい。
| 工程 | 時間 |
|---|---|
| サンプリング（30step） | 433秒 |
| VAEデコード | 約420秒 |
動画を「作る」時間と、潜在表現を「絵に戻す」時間が同じである。画像生成ならVAEデコードは1秒で終わる工程だ。
条件を軽くして（1280×704・49フレーム・20step）ノード別に測り直すと、もっとはっきりした。
| 工程 | 時間 |
|---|---|
| サンプリング（20step） | 89秒 |
VAEデコード（VAEDecode） | 258秒 |
サンプリングの3倍。832×480 では VAE デコードは25秒程度で済んでいたので、解像度を上げた瞬間に VRAM から溢れ、遅い経路に落ちている。
VAEDecodeTiled に差し替えるだけで9倍速い
ComfyUI には、VAEデコードをタイル分割して行う VAEDecodeTiled ノードがある。テンプレートの VAEDecode をこれに差し替えた。設定は tile_size 512 / overlap 64 / temporal_size 64 / temporal_overlap 8。
| VAEデコード | 時間 |
|---|---|
VAEDecode（テンプレート既定） | 258秒 |
VAEDecodeTiled（512） | 28秒 |
9.2倍速くなった。同じシードで、サンプリング結果はキャッシュされたままVAEだけ再実行しているので、条件は揃っている。出力は目視で区別がつかず、中央フレームの画素差は平均 1.6/255 だった。
公式既定の 121フレームでも同じで、VAE は 420秒 → 83秒。5秒動画の合計が 14分15秒から 7分52秒になった。
2モデル目で、理由がログに出た
HunyuanVideo 1.5 でも同じことが起きた。こちらはログが理由を言ってくれている。
memory allocation failed with OOM on device 0 while trying to allocate 22508732416 bytes
Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding.22.5GB を確保しようとして失敗し、タイル分割で再試行している。つまり VAEDecode は、16GB の環境では「一度失敗してからタイルに落ちる」動きをしている。最初から VAEDecodeTiled を置けば、失敗のぶんが消える。
公式テンプレートは通常の VAEDecode のままなので、16GB の Radeon で動画を回す人は、まずここを差し替えるべきである。
【本題2】14Bは素だと54分、LoRAで6分半
Wan 2.2 の本命は 14B のほうだ。fp8 でも 14.3GB × 2（high noise / low noise の2段構成）で、16GB には入らない。
それでも動く。ComfyUI が VRAM に入らない分をメインメモリに置いて、必要な層だけ往復させる。ログには 13628MB Staged と出て、VRAM の最大は 14,202MB。5B より少ないのは、収まらない前提で動いているからである。
公式テンプレートの既定値（1280×704・81フレーム・20step・cfg 3.5）で回した結果がこれだ。
| 工程 | 時間 |
|---|---|
| high noise 10step | 1,611秒（160秒/step） |
| low noise 10step | 1,607秒 |
| VAEデコード（Tiled） | 36秒 |
| 合計 | 54分16秒 |
5B は同じ解像度の 121フレームで 12.9秒/step だった。14B は 81フレームでこの数字なので、フレーム数を揃えれば差は12倍どころではない。
蒸留LoRAを足すと6分30秒
ここで効くのが、Comfy-Org が配っている lightx2v の 4step 蒸留LoRA である。high / low それぞれに LoraLoaderModelOnly で当て、steps 4（high 0→2 / low 2→4）・cfg 1.0・shift 5.0 にする。
| 工程 | 時間 |
|---|---|
| high noise 2step | 176秒 |
| low noise 2step | 178秒 |
| VAEデコード（Tiled） | 33秒 |
| 合計 | 6分30秒 |
54分が6分半になった。1stepあたりの重さは変わらないので、単純に step 数が 20 → 4 になった分である。
そして出てきた動画は、今回試した中で唯一「見るに耐える」ものだった。赤いバイクの造形、路面の照り返し、海の描写のどれもが 5B とは別物で、20step の素の 14B と比べても落ちていない。レンズフレア風の緑の玉が出る、タイヤの影が少し不自然、という小さな癖はあるが、ここは許容範囲だった。
「16GBで14Bは無理」は、LoRA前提なら過去の話である。ただし、これはメインメモリが64GBあるから成立している。VRAM から溢れた 14GB × 2 の行き先が要る。
なお、この構成を組むならGPUとメモリはここを参考にしてほしい。今回はメモリが効いた。
ポチップ
ポチップ
【本題3】速いモデルは、のっぺりしていた
ここからは、表で「のっぺり」「眠い」と書いたものの話である。数字だけ見ると良さそうなモデルが、実際に再生すると弱かった。
LTX-2.3 22B：3分半で音まで付くが、指示が効かない
LTX-2.3 は 22B で、fp8 でも 29.5GB。今回の最大サイズである。だが公式テンプレートの設計が賢く、**640×360 で 8step 回してから潜在表現を2倍にアップスケールし、1280×720 で 3step だけ回す。**しかも音声を同時に生成する。
| 工程 | 時間 |
|---|---|
| 1段目 8step（640×360） | 56秒 |
| 2段目 3step（1280×720） | 50秒 |
| VAEデコード ＋ 音声デコード | 68秒 |
| 合計 | 3分33秒 |
VRAM 最大 15,638MB。今回の全モデルで最速で、出力には AAC の音声が付いている。夕日と海岸の描写は最も映画的だった。
だが、バイクが画面の隅に小さい。「追従するトラッキングショット」と書いたのに、出てきたのはドローンで撮った俯瞰である。綺麗な壁紙が5秒揺れている、という印象で、主役を動かす道具にはならなかった。プロンプトへの追従は Wan のほうがずっと素直だ。
余談だが、LTX-2.3 を動かすには extra_model_paths.yaml に latent_upscale_models: の行を足す必要があった。既定の設定ファイルにこのフォルダが無い。
Wan 2.2 5B：8分で完走するが、のっぺり
5B は「民生GPU向け」として ComfyUI が最初に推しているモデルで、16GB に丸ごと入る唯一の Wan である。VAE を Tiled にすれば 5秒動画が 7分52秒で出る。
ただし絵が平坦だった。バイクも背景も形は合っているのに、質感が乗らない。14B + LoRA が 6分半で出るようになった今、時間で選んでも5Bを選ぶ理由が無くなった。
HunyuanVideo 1.5：Wanより遅く、眠い
Tencent の 8.3B。「24GB VRAM の民生GPU向け」とされている。480p の fp8 版に 4step LoRA を当てて 4分12秒だが、848×480 でこの時間は、1280×704 の Wan より遅い。
原因は2つ見えている。fp8 の重みが fp16 にキャストされて計算されること（Wan 14B fp8 のログに manual cast: torch.float16 と出ており、同じ fp8 scaled 形式の Hunyuan も同様と考えている）、そして Hunyuan の VAE が重く、Tiled でも 141秒かかることだ。720p の fp16 版は 220秒/step まで落ちたので、5/20 step で中断した。
絵はツアラー風の赤いバイクで破綻は無いが、全体に眠い。
LTX-Video 2B：4秒動画が15秒
古い世代の軽量モデル。768×512・97フレームが 14.5秒（サンプリング 2.5秒・VAE 10.6秒）。桁が違う。
品質は今回の中でいちばん低く、バイクの形が崩れる瞬間がある。ただ構図やプロンプトの当たりを付けるだけならこれで十分で、本番を 14B に投げる前の下書きとしては使い道がある。
【I2V】自分のバイクの写真を動かしてみた
テキストからではなく、手元の写真を起点に動かすのも試した。Wan 2.2 5B は TI2V モデルなので、Wan22ImageToVideoLatent の start_image に画像を挿すだけでよい。
使った写真は、以前の記事に載せた CB250R である。960×704・81フレーム（3.4秒）・20step・Tiled。プロンプトは「カメラがゆっくり回り込む、草木が揺れる、雲が流れる」。
| 工程 | 時間 |
|---|---|
| サンプリング | 116秒 |
| VAEデコード（Tiled） | 56秒 |
| 合計 | 3分13秒 |
バイクの形、ガードレール、路面は元の写真のまま保たれ、カメラがわずかに回り込む。動画として破綻はしていない。
ただ、正直に言うと微妙である。回り込みは小さく、揺れる草も控えめで、「写真がちょっと動いた」の域を出ない。14B の I2V モデル（wan2.2_i2v_*_14B_fp8_scaled）と LoRA の組み合わせなら変わる可能性はあるが、今回は未検証だ。
【手順】結局どう組めばいいか
上の結果から、16GB の Radeon で動画をやるなら Wan 2.2 14B fp8 + 4step LoRA + VAEDecodeTiled に絞ってよい。公式テンプレート「Wan 2.2 14B T2V」からの変更点だけ書く。
LoraLoaderModelOnlyを2つ足す。high noise 側にwan2.2_t2v_lightx2v_4steps_lora_v1.1_high_noise、low noise 側に..._low_noise。強度は 1.0ModelSamplingSD3の shift を 8.0 → 5.0KSamplerAdvancedを2つとも steps 4・cfg 1.0。high は start 0 / end 2、low は start 2 / end 4VAEDecodeをVAEDecodeTiledに差し替え。tile_size 512 / overlap 64 / temporal_size 64 / temporal_overlap 8- 解像度は公式既定の 1280×704・81フレームのままでよい
これで 1本 6分30秒、VRAM 14.2GB。メインメモリの使用量は今回測っていないが、VRAM に入らない重み（14.3GB × 2）の行き先として確実に要る。32GB のマシンでは厳しいと思う。
VAE デコードの差し替えは、他のどのモデルでも同じように効く。Wan 5B でも Hunyuan でも、VAEDecode のままにしておく理由は無い。
モデルは全部で 110GB あった。SSD の空きは先に確認したほうがいい。
ポチップ
ポチップ
【限界】この記事で測れていないこと
- ROCm 7.x との比較が無い。同じ計測を 7.x でしていないので、「ROCm 10 で動画生成が速くなった」とは書けない。前回の FLUX.1 の結果（3.23倍）から「大きいモデルほど効く」推定はできるが、推定は推定である
- 各条件は1〜2回の計測。画像生成の記事のような8ラン平均ではない。ただし VAE の 258秒 → 28秒だけは、同一シード・サンプラーキャッシュ済みでデコードだけ再実行した差なので、条件は揃っている
- 見た目の評価は筆者の目視。「のっぺり」「眠い」は主観で、プロンプトを変えれば印象が変わる可能性はある。プロンプトは1種類しか試していない
- fp8 が fp16 にキャストされる理由は未調査。gfx1201 側の制約なのか ComfyUI の判定なのか分かっていない。fp8 のまま計算できれば 14B と Hunyuan はもっと速いはずである
- 14B の I2V は未検証。5B の I2V が微妙だった、という結果しか無い
まとめ
- 16GB の Radeon で、Wan 2.2 14B も LTX-2.3 22B も動く。入らない分はメインメモリ64GBに逃げる
- 壁はサンプリングではなく VAE デコードに出る。
VAEDecodeTiledに差し替えるだけで 258秒 → 28秒。Wan と Hunyuan の両方で OOM → 再試行の動きを確認した - Wan 2.2 14B は素だと 54分、4step LoRA で 6分30秒。「16GBで14Bは無理」は LoRA 前提なら過去の話
- 速さと見た目は別。最速の LTX-2.3（3分33秒・音声付き）は指示が効かず、5B は平坦、Hunyuan は眠い
- 見るに耐えたのは 14B + LoRA だけだった
- I2V は動くが微妙。5B では「写真がちょっと動いた」止まり
- モデルは 110GB。メインメモリ 64GB と SSD の空きが前提
「動くか」の答えは「全部動く」で、「使えるか」の答えは「1つ」だった。16GB の Radeon で動画をやるなら、Wan 2.2 14B に LoRA を当てて、VAE をタイルにする。それ以外は、今のところ回す理由が見つからなかった。
コメント