中国アリババが公開した「Wan2.2」モデルで、快適に動画を生成できるグラフィックボードを実際に検証します。今回はとりあえず20枚のグラボで性能比較です。
定番GeForceシリーズは直近3世代、マニア向けのRadeonシリーズは直近2世代を取り上げます。

(公開:2025/8/10 | 更新:2025/8/12)
動画生成AI(Wan2.2)におすすめなグラボを検証
検証方法:動画の生成時間をテストする
実際に動画生成させる |
---|
(指示内容:被写体のまわりを一周して)
動画生成AI(Wan2.2)に適したグラフィックボードをテストする方法はシンプルです。
実際に動画を作らせて、処理にかかった時間を記録します。短時間で動画を生成できればできるほど、動画生成AIに適したグラボです。
なお、生成速度(Iterations per Second)は指標に使いません。「20 it/s」などの数値に、VAEデコード時間が含まれておらず、実態以上の性能に誤認させるリスクが高いです。

最終VAEデコードが終わって、完成品が表示されるまでにかかった時間(Prompt executed seconds)を評価します。

動画生成に使うソフトは「ComfyUI」です。
- Download for ComfyUI(comfy.org)
Wan2.2がリリースされた初日からネイティブ対応済み。イラスト生成時代に定番だった「A1111」や「Forge」は、動画生成AI界から存在感が消えています。

ComfyUIに導入する拡張プラグインは基本中の基本となる「ComfyUI-Manager」に加え、「ComfyUI-GGUF」と「ComfyUI_essentials」を導入します。
- ComfyUI-Manager(github.com)
- ComfyUI-GGUF(github.com)
- ComfyUI_essentials(github.com)
「git clone」がよく分からない方は、ComfyUI-Managerだけ入れて、Managerから各種プラグインをインストールすると楽です。

(ベンチマーク用に自作)
ベンチマーク用のワークフロー(Workflow)は、筆者が自作したテンプレートを使います。ベンチマークに不要な機能を取り除いた、シンプルなテンプレートです。
ダウンロードした.zipファイルを展開して、中に入っている.jsonファイルをComfyUI画面に放り込むだけでテンプレが開きます。

テスト環境:使用したグラボとPCスペックを紹介

テスト環境 「ちもろぐ専用ベンチ機(2025)」 | ||
---|---|---|
スペック | NVIDIA GeForce | AMD Radeon |
CPU | Ryzen 7 9800X3D(レビュー) | |
マザーボード | ASUS TUF GAMING X670E-PLUS WIFI | |
メモリ | DDR5-5600 128GB(64GB 2枚組) → Crucial Pro DDR5-5600 | |
グラボ |
|
|
SSD | WD Black SN850X 8TB → 8 TB版レビューはこちら | |
OS | Windows 11 Pro (24H2) | |
生成ソフト | ComfyUI v0.3.49 pytorch 2.7.1 + cu128 | |
ドライバ | Game Ready 572.83 WHQL | Adrenalin 25.6.3 WHQL |
ライブラリ | NVIDIA CUDA | AMD ROCm Pytorch wheels based ROCm 6.5.0rc |
今回のWan2.2ベンチマークで使用するテスト機のPCスペックです。
CPUにRyzen 7 9800X3D(8コア16スレッド)、メモリにDDR5-5600(JEDEC準拠)を容量128 GBたっぷり搭載しました。
Wan2.2本体のVRAM使用量は使用する量子化モデルに依存しますが、生成する解像度を大きくしたり、後処理にアップスケーリングを入れるとメモリ使用量が急増します。

(共有メモリに漏れるとSSDの寿命を無駄に浪費するし生成速度も・・・)
最低でも64 GB以上、予算に余裕があれば96~128 GBを検討したいです(比較データは後ほど紹介)。
テストに使用したグラフィックボードは全部で20枚(GeForce:16枚 + Radeon:4枚)です。
筆者のお財布事情と時間の都合で、すべてのグラフィックボードが揃っているわけではないものの、ベンチマークとして性能を比較するのに不足しない量を揃えています。
【グラボ別】動画生成AI(Wan2.2)の生成速度

ベンチマーク内容は「HD画質(480 x 704)」を5秒(81フレーム)生成させて、動画が完成するまでにかかった時間(Prompt executed seconds)をテストします。
なお、アップスケーリングやフレーム補間など、グラボよりメモリ容量で勝負が決まりやすい後処理のベンチマークは省略します。
あくまでも、VRAMが足りている範囲でグラフィックボードが出せるネイティブ生成性能に注目した検証です。
Wan2.2は巨大なモデルを半分に分割して、2つのモデルを前後で入れ替える「MoE」方式を採用します。
VRAMに収納するモデルサイズを実質50%に削減できるため、モデル容量の割に少なめのVRAM使用量で済む傾向です。
しかし、それでもなおWan2.2は大きな生成モデルです。オリジナル版(27B_fp16)だと、2つに分けても約53.3 GBを要求し、RTX 5090(32 GB)ですら門前払いを受けます。
使用した量子化モデル(一覧) | |
---|---|
VRAM:32 GB以下 (24 ~ 32 GB) |
|
VRAM:24 GB以下 (16 ~ 24 GB) |
|
VRAM:16 GB以下 (12 ~ 16 GB) |
|
VRAM:12 GB以下 (8 ~ 12 GB) |
|
使用した高速化LoRAモデル | |
VRAM:すべて (8 ~ 32 GB) |
|
幸い、ComfyUIをはじめとした有志ユーザーによって、オリジナルの性能をなるべく維持しつつサイズを軽量化した「量子化モデル」が充実しています。
Comfy-Orgチームが作成した「14B_fp16」版なら、モデル片方あたり26.6 GBほど、VRAM容量32 GBあれば足りる計算です。
QuantStackチームが作成した「Q6_K」や、Zuntan氏が作成したEasyWan22でも使われる「Q3_K_M」版は、片方あたり6.7 GBだからVRAM容量8 GBでも(理論上)動作します。
ただし、モデルサイズがVRAM容量をいくら小さくできても、VRAMに余剰がなければ実際に生成できる動画の長さや解像度に制約がかかります。
今回の記事では、互換性を重視して作られているEasyWan22の思想を参考に、あえて小さめの量子化モデルを使ってベンチマークを行います。
なお、GeForceシリーズに対してRadeonシリーズは、モデルサイズから予想も出来ないほどVRAM使用量が極端に肥大化するため「Q2_K」版を使います。
処理速度を高速化するLoRAモデルは、Kijai氏が作成した「Lightx2v(I2V用)」を適用しています。モーション量がやや犠牲になる代わりに、必要なステップ数を3~5分の1まで削減可能です。
480×704:神里綾華(I2V)ベンチマーク
開始 | 終了 |
---|---|
![]() | ![]() |
イラスト(Image)から動画(Video)に変換する、I2V(Image to Video)ベンチマークです。
完成 |
---|
ベースとなるイラストのアスペクト比に合わせて解像度を「480 x 704」に設定し、高速化LoRA「Lightx2v」を導入してステップ数を合計6(High側で3 + Low側も3)ステップに削減します。
生成する動画の長さは「5秒」です。Wan2.2は16 FPSで動画が生成されるため、最初のフレーム + 5秒 x 16枚 = 81枚の生成に相当します。

(※クリックでグラフ拡大)
ほとんどの生成AIユーザーが予想していたとおり、GeForceシリーズが圧倒的な成績を収めます。
Radeonシリーズはむしろ動いただけでも驚きです。TheRock版ROCm(Windowsネイティブ版)が登場したおかげで、最新版ComfyUIでそのまま動画を生成できます。

しかし、軽量版モデル(Q2_K版)ですらVRAM容量をあるだけすべて湯水のように浪費し、最後の仕上げ工程(VAEデコード)で深刻な目詰まりを起こして大きく時間が伸びます。
ROCmの最適化が遅れているRX 9070 XTはさらに酷く、そもそも最終VAEデコードが通らないです。苦肉の策として「–cpu-vae」オプションを使って、CPU処理でなんとか通しました。


(※クリックでグラフ拡大)
次に、GeForceだけに焦点をあてた拡大グラフをチェック。
すべてVRAM容量がギリギリ足りている範囲で動いているから、グラボ本来のネイティブ生成性能を比較できました。
生成AIユーザーの新規獲得に大きく貢献した名作RTX 3060 12GBも未だにけっこう強いです。RTX 4060に速度で負けますが、VRAM容量が多いから少し高品質なモデルを使えます。
同様にRTX 5060 Ti 16GBも速度こそRTX 4070に届かないものの、サイズの大きなモデルをロードでき、生成品質で優位性があります。
RTX 5070以上は順当に性能が伸びています。イラスト生成で伸びがイマイチだったRTX 50シリーズですが、なぜか動画生成なら意外と性能アップ。
CUDA性能の割に生成速度が伸びているため、改良されたVRAM帯域幅に加えて、Gen5世代のPCIeスロット(最大16 GT/s → 32 GT/s)も効いている可能性が高いです。

メインメモリ容量ごとに生成時間を比較

Wan2.2の前世代モデル「Wan2.1」が登場したころ、動画生成AIには大量のメインメモリが必要だと話題になっていました。
本当にメインメモリ容量が大量に必要なのか、「RTX 5090」を使ってメモリ容量ごとに生成時間を比較します。生成する内容や各種設定は同じままです。

(※クリックでグラフ拡大)
4パターンで比較した結果、たしかにメインメモリ容量が多いほど生成時間が短縮されています。
- メモリ容量128 GB:約2.3倍
- メモリ容量64 GB:約2.3倍
- メモリ容量48 GB:約1.8倍
- メモリ容量32 GB:-
容量32 GBに対する性能の向上幅を計算すると、容量64 GB以上がおすすめです。メモリ容量を増やしただけで、生成時間が半減します。

メモリ容量を増やすと劇的に生成時間を減らせる理由は「スワップ現象」です。
VRAMに入り切らないデータは、PCIeバスを経由してメインメモリに移動し、メインメモリでも足りなければ共有メモリ(システムSSD)に移動します。
それぞれの移動速度は以下のとおりです。
エリア | 具体例 | 帯域幅 (移動速度) |
---|---|---|
PCIeバス | PCIe 5.0 x16 | 64.0 GB/s |
PCIe 4.0 x16 | 32.0 GB/s | |
PCIe 4.0 x8 | 16.0 GB/s | |
メインメモリ | DDR5-5600 | 69.2 GB/s |
DDR4-3200 | 33.6 GB/s | |
共有メモリ | NVMe SSD(Gen5) | 14.8 GB/s |
NVMe SSD(Gen4) | 7.4 GB/s | |
SATA SSD | 0.5 GB/s |
一見するとぶっ飛んだ速度に見えます。
GPU | VRAM | 帯域幅 |
---|---|---|
RTX 5090 | GDDR7 | 1792 GB/s |
RTX 4090 | GDDR6X | 1008 GB/s |
RTX 5070 | GDDR7 | 672 GB/s |
RTX 4070 | GDDR6X | 504 GB/s |
RTX 3060 12GB | GDDR6 | 360 GB/s |
一方で、VRAM帯域幅は文字どおり桁違いの帯域幅です。
PCIeバスやメインメモリの約5~30倍以上も速く、ましてや共有メモリ(NVMe SSD)と比較してまうと約50~250倍も速いです。
VRAMと比較してメモリの帯域幅が遅すぎるから、メインメモリに漏れると生成時間が一気に低速化します。
メインメモリにすら入り切らず、共有メモリ(NVMe SSD)に漏れた場合は、SSDの寿命(TBW:書き込み保証値)を無駄に浪費するペナルティまで付いてきます。

「量子化モデル」ごとの生成時間を比較

(※クリックでグラフ拡大)
読み込む量子化モデルごとに、生成時間が変化するか比較ベンチマーク。
軽量なHD解像度(480 x 704)なら、片方あたり約13~15 GBにもなる「14B_fp8_scaled」や「Q8_0」モデルがすっぽり収納でき、生成時間のペナルティもわずかです。
しかし、片方あたり26.6 GBにもなる「14B_fp16」モデルは初回プリロードの時点で本当に26.6 GBを消費し、生成中にOOM(out of memory)エラーでComfyUIが停止します。
メモリ容量を64 GBから128 GBに増設して、モデルを入れ替えたときメインメモリだけで処理できるように仕向ければ、約50%のペナルティを受けつつ動作成功です。

(※クリックでグラフ拡大)
解像度をフルHD相当(960 x 1408)まで引き上げて、同じテストをした比較グラフです。
片方あたり約15 GBで済む「Q8_0」モデルまでなら、ほとんどペナルティを受けずに安定動作を確認できました。「14B_fp8_scaled」以上から共有メモリを使い出して、生成時間が伸びます。
メモリ容量を64 GBから128 GBに増設すると、モデル入れ替え時に共有メモリをほとんど使わなくなり、ペナルティを大幅に削減して生成時間が短縮されます。

(ComfyUIのワークフローから推測)
つまり、Wan2.2の安定した生成には「2つの関門」が立ちはだかります。
- 初回プリロード
= High側モデルをVRAMに収納 - モデル入れ替え
= High側をメモリに戻してからLow側を収納
1つめの関門は言うまでもなくVRAM容量で勝負がほぼ決まる状況です。モデルサイズがVRAM容量より大きい場合、基本的に安定動作しないです。
High側モデルがVRAMに入りきったら、次はLow側モデルの入れ替えが関門です。使い終わったHigh側モデルをメインメモリに戻して、Low側モデルをVRAMに収納します。
メモリ容量が不足すると、共有メモリ(SSD)を使って耐えようとしますが・・・ 共有メモリは遅すぎて動作が不安定になりがち。
OOM(out of memory)エラーが頻発したり、大幅なペナルティ(速度低下)を受ける可能性が高いです。

「動画の解像度」ごとの生成時間を比較

(※クリックでグラフ拡大)
EasyWan22で使われている「Q3_K_M」モデルを使って、生成する動画サイズ(解像度)ごとの生成時間を比較します。
解像度が大きいほど、生成時間がほとんど線形に増えていきます。VRAM容量とメインメモリ容量が足りている限り、生成時間はほぼ線形です。
しかし、フルHD以上(1280 x 1877など)から非線形に生成時間が大幅に増加します。

フルHD以上になるとVRAM使用量が大幅に増え、メインメモリ容量が足りず、仕方なく共有メモリ(SSD)を使っているからです(※濃いオレンジ色が共有メモリ使用量)。
メインメモリと比較して共有メモリ(SSD)は途方もなく遅い領域で、大幅なペナルティ(速度低下)を受けます。
ペナルティを受けると大量の待ち時間が発生し、グラボが効率よく仕事できません。結果的にGPU使用率(消費電力)も25~33%程度まで下がっていました。

1フレームレートあたりの処理時間(効率)をチェックします。
元画像サイズ(480 x 704)と同じ解像度がもっとも効率よく生成できます。小さすぎると逆に効率は悪化するし、大きすぎると共有メモリのせいで大幅に悪化します。
個人的に、720p前後(720 x 1056)あたりが効率いいです。ほどよく解像度が高いし、モーション量も維持可能です。

「動画の長さ」ごとの生成時間を比較

(※クリックでグラフ拡大)
先ほどの検証に引き続き、「Q3_K_M」モデルを使って生成する動画の長さ(フレーム数)ごとの生成時間を比較します。
フレーム数も解像度と同じく、VRAMとメインメモリが足りている限り、生成時間が線形に伸びます。

VRAM使用量はかなり興味深いです。
9~57フレーム(0.5~3.5秒)まで、VRAM使用量は約3.3 GB前後からまったく変化せず、73フレーム(4.5秒)から線形にVRAM使用量が増加します。
ただし、Wan2.2の推奨設定は「3~5秒(49~81フレーム)」です。49フレーム未満、81フレーム超過時のVRAM使用量を気にする必要はほとんどないでしょう。
HD相当(480 x 704)なら49フレーム時で約3.3 GB、81フレーム時で約4.7 GB、約1.65倍に増加するとだけ覚えておけば十分です。

1フレームレートあたりの処理時間(効率)をチェックします。
Wan2.2公式が推奨する「3~5秒(49~81フレーム)」がもっとも効率が高いです。
「CFGスケール」ごとの生成時間を比較

(※クリックでグラフ拡大)
先ほどの検証に引き続き、「Q3_K_M」モデルを使ってCFGスケール(指示強度)ごとの生成時間を比較します。
Wan2.2のCFGスケールに対する挙動はとても不思議です。初期設定「CFG:1.0」だけ高速に動作でき、少しでも1.0をズレると一律2倍に鈍化します。
CFG:1.1や0.9ですら2倍に伸びます。なぜかCFG:1.0に限って動作が速いです。

CFGスケールごとのVRAM使用量に変化なし。CFGスケールを変えても、VRAM使用量は増えも減りもしないです。

1フレームレートあたりの処理時間(効率)をチェックします。
初期設定「CFG:1.0」が最高効率で、1.0以外だと半減します。速度を重視するならCFG:1.0以外を使わないほうが良いです。
しかし、CFG:1.8~2.2の方が激しく荒ぶる動きを再現しやすく、格段にモーション量が好みです。
High側モデルだけCFG:2.0前後に設定して、Low側モデルをCFG:1.0のまま生成すれば、合計1.5倍の生成時間でモーション量の多い映像を出力できます。

【おまけ】VRAMとメインメモリの関係性

(※詳細な拡大グラフはこちらから)
Wan2.2とComfyUIによる、華麗なメモリ管理システムをグラフで確認します。
グラフの左から右に向かうにつれて、モデルサイズが大きいです。最軽量の「Q2_K」からテストを開始して、最後に「14B_fp16」を読み込んでいます。
モデルサイズが巨大になればなるほど、VRAM使用量がじわじわと増加し、メインメモリ使用量も増加する傾向が明らかです。
「Q6_K」版までなら共有メモリをまったく使わず、VRAMとメインメモリだけでほぼやり繰りできています。
しかし「Q8_0」版から最終VAEデコードで目詰まりを起こして、ついに共有メモリ(SSD)を一時的に使い始めます。
「14B_fp8_sacled」と「14B_fp16」も当然ながら目詰まりを起こし、共有メモリ(SSD)を一時的に使っています。
「14B_fp16」に至っては、最終VAEデコードが終わるまでずっと共有メモリに頼りっきりです。VRAMもメインメモリも枯渇したとき、共有メモリがまさに最後の砦です。

共有メモリを使い続けるデメリットは2点あります。
- 大幅なペナルティ(速度低下)
- SSD書き込み保証値(TBW)の消費
メインメモリに入り切らないデータを、一時的に共有メモリ(SSD)に移すわけで、当然ながらSSDの保証値(TBW)を消費します。
14B級モデルの場合、動画の生成1回あたり約30~50 GBほど消費していました。生成100回なら約3000~4000 GB程度を消費できる計算です。

最近のNVMe SSDなら、容量1 TBモデルで300~600 TBW(= 300,000~600,000 GB相当)です。
1日あたり100生成で約3000~4000 GBを消費するペースであれば、ざっくり150日(5ヶ月)で保証値を使い切れる試算になってしまいます。

では、メモリ容量を64 GBから128 GBに増設して、巨大モデル(14B_fp8_sacled)を再度テストします。
64 GBなら生成1回あたり約30~50 GBも共有メモリ(SSD)を使っていたのに、128 GBに増設すると、まったく共有メモリを使わずに済みます。

もちろん、SSDの書き込みも一切検出されないです。
SSDは書き込み寿命がありますが、メインメモリ(DRAM)に寿命の概念はほとんど存在しないため、やはりメモリの増設がおすすめです。
Wan2.2は、巨大なモデルをHigh側とLow側に分割して、途中で入れ替える挙動をします。「MoE」方式と呼ばれる設計のおかげで、必要なVRAM容量を50%にカットできる賢い設計です。
しかし、モデルを入れ替えるとき、使い終わったHigh側モデルをメインメモリに送りつけます。グラボからメインメモリに移動する経路は「PCIeスロット」です。
- RTX 50:PCIe 5.0 x16(最大32 GT/s)
- RTX 30~40:PCIe 4.0 x16(最大16 GT/s)
RTX 50シリーズからPCIe Gen5規格に更新され、転送レートが最大16 → 32 GT/sに倍増します。
メインメモリとVRAMを行き来するWan2.2(MoE方式)だから、Gen5規格対応のRTX 50がCUDAコアの比率以上の伸び幅を見せた理由かもしれないです。
【おまけ】モデルサイズと生成品質の違い
Q2_K版 (VRAM:~ 12 GB) | Q3_K_M版 (VRAM:~ 16 GB) | 14B_Fp8版 (VRAM:~ 32 GB) |
---|---|---|
同じワークフロー、まったく同じ設定のまま、量子化モデルだけを変更して動画を生成させました。
モデルサイズが小さいほどVRAM使用量を減らせますが、やはり生成品質が犠牲になる様子が明らかです。
映像のアーティファクト(ガビガビ)度合いや解像度の細かさだけでなく、入力したプロンプト(指示内容)に対する追従性も大きく変わってきます。
Wan2.2で指摘が相次ぐ「口パク現象」の発生率も、体感ですがモデルサイズに比例する気がします。
まとめ:動画生成AIにおすすめなグラボ【3選】

今回のWan2.2ベンチマーク調査で、「動画生成AIにおすすめなグラボ」がざっくりと判明しました。
RTX 5060 Ti 16GB:動画生成AI向け入門グラボ

動画生成AIをとりあえず導入してみたい方に、おすすめなグラフィックボードが「RTX 5060 Ti 16GB」です。
生成速度はRTX 4070にやや劣る程度ですが、GDDR7メモリ(448 GB/s)を16 GBも搭載します。そこそこ品質が高い「Q4_0」版や「Q3_K_M」版を収納できるVRAM容量です。
予算10万円未満で買えるグラボの中で、もっとも動画生成AIに適性があるグラフィックボードと評価してます。
なお、RTX 5060 Tiの問題点はゲーム性能の低さです。対応ドライバ「566.xx」以降、ゲームによる性能のバラツキが拡大していて取り扱いが難しいです。
動画生成AI用におすすめできますが、生成AI以外の用途で推奨しづらい惜しいグラボです。革ジャンが早期にドライバの安定化を推し進めてくれるといいのですが。

RTX 5070 Ti 16GB:速度と容量のバランスならこれ

RTX 4080 SUPERに迫る生成性能と、容量16 GB(896 GB/s)を両立するグラボが「RTX 5070 Ti」です。
在庫がかなり安定してきて、今なら約12~13万円台で落ち着いています。それでも価格だけを見るとけっこういい値段してますが、性能とコスパは負けてないです。

RTX 5060 Tiに対して約1.8倍の生成速度があり、一方で価格差は約1.6~1.7倍だから意外とコスパが良い(1.8 / 1.6~1.7 = +6~13%)です。
VRAM容量もRTX 5060 Tiと同じく16 GBを備え、VRAM帯域幅は約2倍近い896 GB/sまで跳ね上がり、なんとRTX 4080 SUPERに迫る生成速度を出せています。

RTX 5090 32GB:動きのある高解像度な動画生成に

「RTX 5090」は筆者がもっとも気に入っている動画生成AIグラボです。
生成速度あたりのコストパフォーマンスで、正直なところ割高と言わざるを得ないです。今回の検証でも、RTX 5070 Tiに速度比コスパでかなり劣っています。
しかし、RTX 5090に搭載された容量32 GBもの巨大なVRAMに「14B_fp8_scaled」版モデルを収納できます。
そもそもコスパがやや悪いだけで、生成速度はちゃんと最強です。凄まじい速度を叩き出せるから、あえて高速化LoRA(Lightx2v)を無効化して、ネイティブ生成で躍動感のある映像も出せます。
高速化を使うと品質だけでなく、映像そのもののモーション量も大きく低減してしまい、ローカル版AIを導入する強い動機となる “特定のニーズ※” にうまく応えられません。
爆速かつ大容量VRAMを誇るRTX 5090なら、品質の高い巨大モデルを使って、高速化LoRA無しに動画生成が可能です。
もちろんアップスケーリングに頼らないネイティブ高解像度(例:960 x 1408など)も対応可能です。
ネイティブ高解像度かつモーション量の多い動画生成なら、現時点でRTX 5090をおすすめします。次点で「Q8_0」版を扱えるRTX 4090でしょうか。
※紳士向けコンテンツ(俗にいうNSFW用途)において、映像のモーション量はとても重要です。

以上「【Wan2.2】動画生成AIにおすすめなグラボをゆるく検証【GPU別の生成速度】」でした。
AIイラスト生成におすすめなグラボ
2025年現在も定番の「SDXL」モデルにおすすめなグラボ解説です。
RTX 5000搭載のおすすめゲーミングPC【解説】
これからAIイラスト用にパソコンを用意するなら、基本的にBTOパソコンを推奨します。手っ取り早く完成済みかつプロが組み立てたパソコンを入手できます。
すでにパソコンを持っている方は、「グラフィックボードの増設・交換ガイド」を参考に、新しく買ってきたグラボを増設・交換するだけでOKです。
- 2025/08/10:Wan2.2のGPUベンチマーク結果をアップ
- 2025/08/12:パラメータ別のベンチマーク結果を追加(UPDATE !!)
あまり詳しくないけどやっぱりそのままcudaで動かせるnvidiaと互換機能を使って動かすAMDでは超えられない壁があるのかな?windows版ROCmでもまるで勝負になってない。
中身がまだROCM 6.5.0rcだから、最適化不足かも?
ROCm 7.x版がリリースされたら性能が上がるかも。RDNA4は静止画なら約3倍(+200%)を出せているらしいです。動画はVAE処理がダメダメすぎるから、あまり伸びない可能性はありますが・・・。
Intel Arcはやらなかったんです?
最近だとIPEX無しでも動かせたりしますが
購入の参考になる素晴らしい検証ありがとうございます
5090に電力制限(70~80%くらい)かけた場合どのくらいの性能になるかわかりますでしょうか?
買おうかすごい迷っているんですが600Wで動かすのが怖くて踏ん切りが付かなくて
【TGP:575W(100%)】
33.1~35.7秒
【TGP:430W(75%)】
36.1~37.2秒
電力を25%カットしても、わずか4%の鈍化でした。
Wan2.2の構造的にメインメモリとやり取りする頻度が高いため、おそらくPCIe 5.0 x16帯域(32 GT/s)が想像以上に効いている様子です。
それと約18000 CUDAコアの暴力ですね。
検証ありがとうございます。
5090買うことに決めました!
RTX5090を買ってしまったので、もう何も悩まなくて済むぜぇ!あとはComfyUI覚えるだけだな!(最難関)
ComfyUIは慣れると最高です。
筆者はRTX 50早期対応のためにA1111 web UIからComfyUIに乗り換えてからドハマリしてしまい、もう二度とWeb UI系列に戻れそうにないです。
昔 弾けもしないのに買って遊んだアナログシンセサイザー思い出しますw 今はまだ公式のWFとか個人が公開してくれてるWFから弄ってるところですが、あの「画像をポイッとな!」でWF再現してくれる機能考えた人天才だと思う。
この検証、動画生成に興味ある人にはめちゃめちゃ需要あると思いますよ!
私は5070tiユーザーですが、他グラボとの比較が各種AIコミュニティの伝聞しかなかったので、非常に参考になりました!
万一、DGX Sparkもご購入予定がありましたら比較検討に加えていただけると幸いです!
結局NVIDIAの独擅場ですね
しかしIntelもAIに関しては結構優秀という噂も聞きますので
B580とその後に噂されているVRAM48GBバージョンも気になってしまいます。
VRAM大幅増量版の「Arc B60」を出すらしいですね。
B60は当然持ってないので、手持ちのB580で検証してみます。
横から失礼します
せっかくArc B580を買っていらっしゃるのですから、B580の総合レビュー記事も見てみたいです
文中の「共有メモリ」は、「仮想メモリ」の誤りかと思われます。
共有メモリは、例えば複数の同じプログラムを動かす時に同じメモリ領域を使い回すとか、プログラム間でデータをやり取りする等に使う物ですね。
タスクマネージャだと「共有ワーキングセット」で表示されます。
リソースモニタで、ハード フォールト/秒ってのが有りますが、ソレがSSDやHDD上のスワップorページファイル関連の数値になります。
タスクマネージャだと、ページ フォールト(差分の同デルタ)です。
タスクマネージャのパフォーマンスタブのメモリだと、「コミット済み」の分子側が急激に増える状態がRAM不足になってページアウトしている状態です。
※アプリ起動後のアイドル時にゆっくり増える事も有りますが、
RAM不足時に備えて、予めページファイルに書き出しておく機能(※※)が原因で、実際はRAM不足ではない場合も有ります。
※※予めページファイルに書き出しておけば、不足してから実際に書き出してRAMを確保するよりも快適になる事が多い。
大幅なペナルティが発生したとき、急増していたパラメータ名称をそのまま使っています。
タスクマネージャーなら「共有GPUメモリ」、HWINFO64なら「GPU D3D Memory Dynamic [MB]」ですね。ここが少しでも増えると、めちゃくちゃ速度が鈍化するから、とりあえずここを共有メモリと呼んでいます。
仮想メモリは「Virtual Memory Committed [MB]」で確認できるのですが、ぼくにとって理解が難しいパラメータだったので無視してます。
ぼくが見てるのは、
1. 共有メモリの増加
2. 生成時間の鈍化
以上2点だけです。
>共有GPUメモリ
GPUを略されていたのですね。
共有メモリと共有GPUメモリは、アイホンとアイフォーン位別物なので当方が勘違いしてしまいました。
申し訳ございません。
タスクマネージャのGPUだと、専用GPUメモリがVRAMの事で、共有GPUメモリがRAMの事になります。
また、Windows10/11の共有GPUメモリは最大でRAM搭載量の半分という制限が有ります。
その為、搭載RAM量がそもそも動くか動かないかの境界線になりえます。
また、共有GPUメモリをどう使うかはドライバー次第で、GeForceならNVIDIAコントロールパネルのCUDA – システムメモリーフォールバックポリシーで変更可能です。
デフォルトは多分共有GPUメモリを使うフォールバックを優先する設定のはず。
フォールバックして共有GPUメモリを使うという事はVRAMが不足しており、ドライバーがVRAM不足を検知してVRAMからRAMへ内容を転送し、必要な部分をRAMからVRAMへ転送する必要が有ります。
このコストが結構高めなので性能は結構落ちます。
特に計算に必要なメモリが連続しておらず分散してると転送が頻発するので滅茶苦茶遅くなります。
※故にフォールバックをオフにしてメモリ不足で止まっても良いから、性能優先させる設定が有る訳ですし、
CUDAプログラムやモデル、ドライバーの最適化等で上手くVRAMとRAM間の転送回数を減らせれば劇的に高速化します。
そして、共有GPUメモリは、使えば使うほどプログラムやOSが自身の実行やキャッシュ等として使えるRAMが減ります。
つまり、VRAM大量使用時に起きる現象としては、
VRAMが不足(タスクマネージャのGPUの専用GPUメモリの使用量が増え満タンに)
→ドライバーがVRAMから共有GPUメモリ(RAM)へ退避(共有GPUメモリの使用量が増える)
→OSやプログラム実行用に使える物理RAM空間が減少(タスクマネージャのメモリの使用量が増える)
ここまでで済めばSSDへのページアウト等はほぼ起きず極めて極端な性能低下はしないで済むかもしれません。
しかし、そのまま状況が悪化すると、
→プログラム実行用のRAMが不足(タスクマネージャのメモリ使用量が満タン)
→ファイルキャッシュの破棄やSSD等へ強制退避が頻発(タスクマネージャのメモリのコミット済みの分子側が増えたり、SSDの読み書きが増加)
という流れになります。
極端にプログラム実行用のRAMが減ればそもそもGPUへ命令を送り込む、生成AIプログラムの実行がそもそもスムーズに出来なくなり、GPUに食わせる入力と出力が一時的に止まり、GPUが完全に遊ぶ現象が起きます。
生成AIのプログラム自身もモデルのキャッシュの為にプログラム実行用のRAMを消費していると思いますが、その領域がSSD等にページアウトされてしまうと致命的な性能低下になります。
タスクマネージャのGPUの項目で「共有GPUメモリ」と記載されているからでは?
3Dゲームには興味ないけどAIのためにグラボ買おうか考えてるので、今後もこういう記事を期待してます
画像生成の比較と違って使用するモデルがVRAM量で違っているのに注意ですね。
32Gと8Gでモデルの大きさを合わせるのは実用からかけ離れるので納得ですが、
VRAM量が違えば単純な性能比較表にはならない。
それでも4年前の3060にはるかに及ばないRadeonはインパクトありますね
モデルサイズの違いをけっこう突っ込まれたので、モデルサイズ別のベンチを追加してみました。
結局のところ、VAE処理含めてVRAM + DRAMに収納できるなら、モデルによる顕著な性能変化は確認できないです。EasyWan22を参考にして、あえて余裕のあるモデルサイズを選ぶ判断は、そこまで間違ってなかったかな?・・・と個人的に思ってます。
噂される5070ti superだとVRAM24GBになるので新たな決定版になりそうですね
現状ではGPUの処理性能よりメモリスワップによるボトルネックの方が重大なので
結局VRAMが大事だそうよ、5080ちゃん…
毎回80番台は不遇ですよね。あとから「80 Ti」や「80 SUPER」を出す余裕を残すために、最初から本気を出せない大人の事情でいつも不遇です。
4080と4080superはほとんど変わらなかったですけどね。
80と70tiの差が一番少ないことが4070tisからの80微妙感の元ですが、速度差はキッチリ開いてます。
ですから5070tisuper16GB据え置きとかやめてね革ジャン
3080や5070にてVRAM容量を超えた時にどう変化するのか、ギリギリ可能な範囲がどんなものか。
ここらへんが知りたく思います。
特に5070がゲーミングで実用的であり5060Tiの16GBが何故か執拗に勧められる所ですね。
初回プリロード(Highモデルの読み込み)に耐えられれば、あとはメモリ容量の大盛りでけっこうスムーズに動くと分かりました。
VRAM:12 GBなら
・Q4_K_M.gguf:480 x 704程度
・Q3_K_M.gguf:640 x 939程度
あたりが、VRAM容量から逆算できる目安となります(5秒 = 81 frameを想定)。
※メモリ容量は64 ~ 96 GBを推奨
Thank you for your test
この128GBメモリってX670Eでも動くんですね
crucialの互換性チェックでは 、殆どのX670Eマザーボードは互換性無し的な表示をされてるから驚きです
Asrockのx670e steel legendでも動く場合があるんでしょうか?
CPUが9000番台じゃないとダメとかあるんですかね?
メモリを交換して、一番最初の起動時のみ、約10~15分くらい待たされます。
2回目以降はスムーズに起動できますし、動作も非常に安定しています。ただ、他のコメントにあるとおりRyzen 9000シリーズ推奨です。7000シリーズよりCPU内蔵メモコンの出来が良いです。
少し前までX670E STEEL LEGEND使ってました。Ryzen7900でTEAMってブランド?の32GBx4が動いてましたが、5600Mhzを4000まで落とす必要がありました。ちょっと綱渡り感ですね。因みに32GBx2なら6000まで上げても平気でした。
まず貴重なベンチマーク結果ありがとうございました。
ただ、VRAM容量ごとにアウトプット品質が異なるモデルを使用して比較するのは、
画像生成で異なる解像度で生成した結果を比較するような違和感を感じます。
(実際使う場合を考慮した条件というのも理解できます。)
例えばBlockToSwapを使えば低VRAMでも高容量モデルを動かせるので、
共通のモデルを使用して、VRAM容量ごと最速になるBlockToSwapを設定することで、
アウトプット品質は同じで、VRAM容量による影響も含めた生成時間を比較できる
ベンチマーク結果が得られるのではないかと思います。
次回ベンチマークする機会がありましたら、ご検討いただけると幸いです。
一応、ベンチマークの検討にあたって、EasyWan22でBlockToSwapを使ってみたのですが。数値に関係なく、VRAM使用量と生成時間がまったく変化しなかったです。
今ならちゃんと動くのかな・・・
売れ筋のRTX 5070あたりを使って、BlockToSwap追試してみます。
【8/13 04:00】
追試しました。
メモリ容量64 GBなら、Q8_0.gguf以上でBlockToSwapに一定の優位性があります。共有メモリの使用量を見ながら、ギリギリ共有メモリに漏れない比率(0~40)を見つけ出す手間はありますが、確かに動きますね。
一方でメモリ容量128 GBなら、14B_fp8ですらBlockToSwapに目立った優位性はありません。ComfyUI公式ワークフローですんなりVAEも通ってしまい、拍子抜けです。ざっくり74 GBもメモリを消費していたから、VRAM 12GBならメモリ96 GB以上で大型モデルを動かせます。
ベンチマーク結果はグラフ整理中です。記事の内容が肥大化してしまったので、たぶん別記事にあらためてアップします。
小生の戯言にお付き合いいただき、早々の追試の実施ありがとございました。
ベンチマーク結果を楽しみに待たせていただきます。
自分のPCでベンチマークの再現しようとしまして用意されていたjsonファイルを開いてみました。
開いたテンプレートに対するVAE,lora,modelがダウンロードされずエラーが排出されて、足りない部分を手動でダウンロードをしなければならない状態なんですがこれってどういう状況なんですかね?
ComfyUI-Managerが導入されていれば足りないモデルなどはComfyUI-Managerが持ってきてくれるはずですが・・・
> 足りないモデルなどはComfyUI-Managerが持ってきてくれるはずですが・・・
そのような仕様があるとは、知らなかったです。
Managerは足りないカスタムノードやモデルを教えてくれるだけで、自動ダウンロード機能はもともと無かった気がします。
ベンチマークで使っている各種モデルのURLをまとめました。
【量子化モデル】
・https://huggingface.co/QuantStack/Wan2.2-I2V-A14B-GGUF/tree/main
・https://huggingface.co/QuantStack/Wan2.2-T2V-A14B-GGUF/tree/main
※I2V = 画像から動画 / T2V = テキストから動画
【テキストエンコーダー】
・https://huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/tree/main/split_files/text_encoders
※fp8版を使ってます
【VAE】
・https://huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/tree/main/split_files/vae
※Wan2.2は2.1用VAEでOK
【高速化LoRA】
・https://huggingface.co/Kijai/WanVideo_comfy/tree/main/Wan22-Lightning
※I2V = 画像から動画 / T2V = テキストから動画
>Managerは足りないカスタムノードやモデルを教えてくれるだけで・・・
jsonファイルを開いたときに足りないモデルなどがあれば、Managerがこのモデルなんかが足りないけどダウンロードする?的な画面を出してそのままダウンロードできます。
その画面が出なかったのはおそらくModel Manager上に対象のモデルが存在していなかったことが原因だと思います。
jsonファイル上のVAEとコメントに添付されたVAEが異なったので以下のURLから同名のVAEを持ってきました。
https://huggingface.co/Kijai/WanVideo_comfy/tree/main
ダウンロードできるファイルが多いので対象のVAEが埋もれています。
ページ下部のLoad more filesをクリックして展開してください。
“Wan2_1_VAE_bf16.safetensors”をページ内検索するのが早いです。
各種モデルのURLをまとめていただきありがとうございます。
自分はカジュアル層なのでbilibiliなどでまとめてパッケージで持ってくる方法が主流なんですよね。
直接必要なモデルを探してくるのは得意ではないので助かりました。
記事と同じ動画が作成できたのでおそらくあっていると思われますが、上記のVAEがベンチマークで使用したVAEであっていますかね?
この記事を見てメインメモリを32GBにしたのを後悔…動画生成じゃなくても32GBだとキツイですかね?
普通の静止画(SDXLモデル)はメモリ32 GBで大丈夫です。動画(Wan2.2)は少なくとも64 GB以上欲しいですね。
求めていた検証です!当方感激しております( ;∀;)
メインメモリ64GBもあれば良いと思っていたのですが、生成時間とSSDの寿命を鑑みるに128GBは積んだ方が賢明なんですね
そこでお尋ねしたいのですが、動画生成AI用にRTX5090かRTX4090を買うかで迷っております
正確にはRTX5090か、RTX4090もしくはVRAM24GB以上になるらしいRTX5080S or 5070TiS で悩んでいる状態です。
なぜ最高性能の5090にしないか?なのですが、やはりかなりの頻度で報告される溶解問題(燃焼問題?)が心配で購入に踏み切れません。
ケーブルの熱問題であれば電源ユニット、ASRockのPhantom GamingやTAICHI TC-1300Tで一応は対策できると考えて購入に踏み切ろうとしていた矢先
下記URLのような、VRM周りから火の手が挙がったとの悪い知らせが届いてしまい、立ち往生しております。
https://g-pc.info/archives/42113/
ただ、省電力と安定動作のためにアンダーボルト設定で動作させていた・・・・というユーザー側の運用方法も気になるところではあります。
つきましてはRTX5090を2台以上所持しているやかもち様にRTX5090の所感をお聞きしたいのです。
RTX4090に戻れないほど快適なのかなと…。
店頭で中古ではありますが30万円を切っていて動作期間が半年もないMSI製RTX4090を目撃してしまい、こちらにしようかとかなり、とても迷っております。
長文失礼いたしました。
「かなりの頻度で報告される」のは欲しいけど買えない人たちの妬みで増幅されてる面もあるとは思う。ただ今回はケーブルじゃなくグラボ基板上の電源回路からって言うのがちょっと怖いかも。私のもZOTACだもんよ。あとグラボの設計ってメーカによって大きく違うものなのかな?
【5090の溶融リスクについて】
溶融の原因は、おそらく設計マージンの少なさだと推測されています。
改良版の12V-2×6コネクタですと、定格660 Wを前提に設計されていますが、RTX 5090の定格は575 Wです。マージンが約13%しかないため、経年劣化の考慮が甘いとの指摘が多いです。
というわけで、溶融リスクを抑えるならTGP制限(Power Limit)が手っ取り早いです。
・Windowsタスクスケジューラを用いたGPUの電力制限
バッチファイルにnvidia-smiコマンドを入れて、タスクスケジューラでPC起動時に自動適用できます。「set UPPER_LIMIT_W=450」なら、450Wに制限されます。
動画生成の場合
・PL 100%:速度100%
・PL 80%:速度97%(-3%)
・PL 75%:速度96%(-4%)
制限をかけても、速度劣化はわずかです。RTX 4090(450W)より速いです。
ぼくはソフト経由の制限に若干の不信感があるので、このように接続して、物理的に450W制限をかけています(5090搭載メイン機の実機写真です)。
【5090の動画生成における使用感】
とにかく生成が速いです。RTX 4090比で約1.5~1.6倍ほどの速度が出るため、体感できるレベルで待ち時間が短く感じます。
しかし、待ち時間の捉え方は運用次第ですね。
ぼくは画面の前で次から次へと手作業で動画のつづきを生成して繋げていく地味なワークフローを採用している都合上、生成時間の速さが重要です。
VRAMに余裕があるから、Wan2.2 → SDXL → Wan2.2 →・・・を行き来するマルチタスクも1台でこなせて便利です。
逆に、自動化できるワークフローなら、RTX 4090でも特に不便しないと思います。
今までSDXLで作ってきた静止画たちを、まとめて動画化する使い方であれば、「EasyWan22」の自動化プラグインに任せる方法もあります。
自動化だから寝ている間に終わってしまい、5090の速度に価値を見いだせないと思います。
・手動、手作業タイプ → RTX 5090
・自動化が多いかも → RTX 4090
こんな感じですね。
大変参考になる検証をありがとうございます。
1点、CFG scale と生成時間についてですが、これは CFG scale の仕様によるものだと思います。
– Conditioning: Positive Prompt で生成される画像
– Unconditioning: Negative Prompt で生成される画像
実際の生成画像 = Unconditioning + (Conditioning − Unconditioning) × CFG scale
CFG scale が 1 の場合は、Unconditioning が打ち消されて無くなるので、生成時間は単純に半分になります。この場合、 Negative Prompt は効かなくなります。
https://note.com/ai_image_journey/n/n752bf830b745
5090は欲しいけど(経年劣化で)溶けるリスクが怖い・・・5080、5070のSuperが出てきたら値段次第で・・・でもやっぱ5090なんだろうね、何やるにしてもVRAMはやっぱり20GB以上欲しいよなぁ
有益記事すぎる ありがたい
生成AI向けRTX5090搭載btoでもしおすすめがありましたら教えて頂きたいです
こんにちは!お忙しいところ失礼します。TCL 27R73Q モニターをレビューするご予定はありますでしょうか?とても良いミニLEDのようですが、まだほとんどレビューがないようです。
追伸:文法の間違いがあればすみません。日本語が話せないため、自動翻訳を使っています。