ComfyUIのDynamic VRAMとは？ROCm 7.14でAMD GPUは何が変わる？

ComfyUIで大きな画像・動画モデルを使うとき、「Dynamic VRAMを使えばVRAM不足を気にしなくてよい」と考えるのは危険だ。

ComfyUI v0.34.0では、ROCm 7.14以降でDynamic VRAMを既定で有効にする変更が入った。AMD GPUユーザーにとって重要な変更だが、これはRadeonの物理VRAMが増えるという意味ではない。

Dynamic VRAMは、モデルや中間データをどこへ残し、どこを退避させるかというメモリ管理の改善として捉えた方が分かりやすい。使えるワークフローが増える可能性がある一方で、システムRAM、モデルの再読み込み、生成時間などとのトレードオフが残る。

Dynamic VRAMは「VRAMを増やす機能」ではない

まず整理しておきたい。

Dynamic VRAMを有効にしても、16GB GPUが24GB GPUになるわけではない。GPU上へ同時に置ける物理メモリの上限は変わらない。

変わるのは、ComfyUIがGPUメモリとシステムRAMをどう使い分け、どのデータを残し、どのデータを追い出すかという部分だ。

そのため、Dynamic VRAMで大きなモデルが動くようになったとしても、次のような条件が同じとは限らない。

• 生成速度
• モデル切り替え速度
• システムRAM使用量
• ディスクからの再読み込み回数
• 複数ワークフローを連続実行したときの挙動

「動くか」と「快適に動くか」は分けて考える必要がある。

ComfyUI v0.34.0でROCm 7.14以降は既定で有効に

ComfyUI v0.34.0の公式リリース説明には、ROCm 7.14 and 以上でDynamic VRAMを既定で有効化する変更が明記されている。

これはAMD GPU環境では大きい。これまでメモリ管理の挙動を意識して設定していたユーザーだけでなく、対応するROCm環境では既定値そのものが変わるからだ。

ただし、「ROCm 7.14ならすべてのAMD GPU・すべてのOSで同じ動作」という意味ではない。

ROCmの対応範囲はGPU型番とOSによって異なるため、まずAMD GPUでROCmを使えるか確認する手順で自分の構成を確認した方がよい。

Dynamic VRAMでは何をしているのか

ComfyUIのDynamic VRAM周辺では、GPUだけでなくRAM側へ何を保持するかも重要になる。

ComfyUIの実装PRでは、RAMへ残す対象について、現在のワークフローで使う中間データ、現在のモデル、同じワークフロー内のほかのモデル、過去ワークフローの中間データなどに優先順位を付ける考え方が示されている。

つまり、単純に「VRAMからRAMへ全部逃がす」という仕組みではない。

現在使っているものをできるだけ再利用しながら、メモリ圧迫時には不要度の高いものから退避させる方向へ管理を改善している。

このため、VRAMだけでなくシステムRAMの容量も実用性へ影響する。

RAMが多ければ必ず速くなるわけではない

Dynamic VRAMやRAM キャッシュを使うと、GPUから外したデータをRAMへ保持できる場合がある。

しかしRAMはVRAMの代用品ではない。GPUが直接高速に使うメモリとは帯域や経路が異なるため、退避や読み戻しが増えれば待ち時間も発生する。

ComfyUIの実装PRにはRTX 5060やRTX 5090を使った開発者側のテスト例があるが、それは特定ワークフロー・特定条件の結果だ。独自実測でもなく、すべてのPCへそのまま当てはめられる数字でもない。

したがって自分の環境では、次を同じワークフローで測るのがよい。

ComfyUI version:
GPU / VRAM:
ROCm version:
System RAM:
Model:
Resolution / frames:
Dynamic VRAMの状態:
Peak VRAM:
Peak RAM:
Generation time:

設定変更前後でこの条件を揃えれば、「動くようになったが極端に遅くなった」「RAM不足へ移った」といった違いも見つけやすい。

OOMが出たらDynamic VRAMだけを疑わない

Dynamic VRAMが有効でも、OOMは起こり得る。

解像度、バッチ数、VAE、ControlNet、LoRA、動画フレーム、複数モデルの同時利用などで必要メモリは変わるためだ。

OOMが起きた場合はDynamic VRAMのON/OFFだけを何度も変えるのではなく、ComfyUIのCUDA out of memoryを直す確認順と同じように条件を一つずつ切り分ける。

特に動画生成では、モデル本体以外の潜在表現やVAE処理も大きくなりやすいため、「チェックポイントがVRAMより小さいから動く」とは判断できない。

Radeonを選ぶ理由は少し増えたが、購入判断は別

ROCm 7.14以降でDynamic VRAMが既定化されたことは、ComfyUIでRadeonを使う際のメモリ管理面ではプラス材料になる。

ただし、これだけを理由にGeForceよりRadeonを選ぶのは早い。

購入前には少なくとも次を確認したい。

1. 自分のGPU候補がROCmの対象か
2. WindowsかLinuxか
3. ComfyUIの導入方法
4. 使いたい画像・動画モデルが対応しているか
5. 必要なカスタムノードが同じバックエンドで動くか
6. VRAM容量
7. システムRAM容量
8. 同価格帯のGeForceとの価格差

ブランド全体で判断する場合は、ComfyUI用GPUはGeForceとRadeonのどちらを選ぶかも合わせて確認したい。

Windowsの複数GPUも同じ話ではない

v0.34.0にはWindowsの複数GPU 認識範囲を制限する変更も含まれている。

注意点は、Dynamic VRAMと複数GPUは別の仕組みだということだ。

Dynamic VRAMが有効だから複数GPUのVRAMが自動的に一つへ合算されるわけではない。2枚のGPUを挿せば32GB+16GB=48GBとして一つのモデルを自由に載せられる、という意味でもない。

複数GPUを使う場合は、モデルや処理をどう分割する実装なのかを個別に確認する必要がある。

速度低下が大きいときはボトルネックを分ける

Dynamic VRAM利用後に生成が遅くなった場合も、原因がメモリオフロードだけとは限らない。

GPU使用率、CPU使用率、RAM、ディスク I/O、モデル読み込み時間、VAE処理などを分けて確認する。確認順はComfyUIの生成が遅いときのボトルネック確認が使える。

特にモデルを頻繁に切り替えるワークフローでは、メモリ節約と再読み込み待ちのバランスが重要になる。

いま使っているRadeonユーザーがやること

ROCm 7.14以降とComfyUI v0.34.0以降の組み合わせを使っているなら、まず既定動作が変わっていることを把握しておけばよい。

そのうえで以前と同じワークフローを使い、VRAM、システムRAM、生成時間を比較する。

以前OOMだったワークフローが通るようになった場合も、そこで「必要VRAMが減った」と固定値化しない。Dynamic VRAMによるメモリ配置、RAM容量、モデル構成まで含めた結果だからだ。

逆に16GBや24GBの物理VRAMで余裕を持って処理できるワークフローなら、Dynamic VRAMの効果を無理に追う必要もない。

Dynamic VRAMはRadeonを突然大容量VRAM GPUへ変える機能ではないが、ComfyUIが限られたGPUメモリを扱う方法を改善する重要な仕組みとして見るのが適切だ。