ComfyUIのPC要件：VRAM 8・12・16・24GBの選び方

Qwen-Image 2.1ではUnsloth Q4_K_M生成モデルが約4.2GB、Q4 text encoderが約5.15GB、専用VAEが約0.68GBです。いずれもdisk上のファイル容量で、3つを保存するには約10GB必要です。生成時には中間bufferや他のアプリ用メモリも必要で、構成要素を同時に読み込むか段階ごとに切り替えるかは配布方式によって異なります。

sampling bufferが足りないと画像計算中に停止し、sampling完了後もVAEが画像を復元する領域が不足することがあります。logで読み込み・sampling・decodeのどこで止まったか確認すると、モデルの量子化⁶を変えるか、画像サイズや同時作業を減らすか判断しやすくなります。

縦横をそれぞれ2倍にするとpixel面積は4倍になりますが、ピークメモリや生成時間が正確に4倍になるとは限りません。モデル内部の表現、attention⁷実装、tile分割、upscale、decode方式も増加量に影響します。

低解像度の風景は保存できるのに目標のdesktopサイズでsampling中に失敗する場合、同じworkflowを小さいサイズへ戻して実行します。小さい画像は成功し、大きい画像だけ停止するなら、解像度に応じた作業領域がボトルネックの可能性があります。原因を絞るためモデルファイルなど他の設定は変えません。

目標サイズの画像1枚は作れるのに同じ風景を4枚batchで作ると失敗する場合、まずbatchを1に下げます。複数候補を同時に保持すると、4枚を1枚ずつ生成するよりピークメモリが大きくなることがあります。画像1枚の完成と候補4枚の同時生成は別のメモリ条件として考えます。

画像batchは複数候補の中間データを同時に保持します。動画ではフレーム⁸間の時間関係も計算するため、フレーム数・時間圧縮方式・解像度が作業領域に影響します。画像1枚分のメモリに動画フレーム数を掛けるだけでは、モデルがフレームをまとめて処理する方式を見落とすことがあります。

動画では対象モデルの実行経路と対応フレーム条件を先に決め、短く低解像度の処理1件から始めます。その後フレーム数かサイズを一つずつ変え、モデル読み込み・生成中のピーク・保存完了・再生を記録します。ここでは画像1枚の例を扱うため、動画メモリは対象モデルの別の実行記録で判断します。

一部runtime⁹はGPUメモリに収まらない構成要素をhost RAM¹⁰に置き、必要時に転送するoffloadに対応します。大きなモデル構成を実行できる場合がありますが、RAMとCPU-GPU間転送も使います。CPU¹¹で計算するoffloadと、重みをRAMに置いてからGPUへ送る方式は異なるため、設定説明とlogで実際に移動する項目を確認します。

PCのシステムRAMは専用VRAMとは別です。12GB GPUと64GB RAMを足して76GB GPUのように扱うことはできません。Macのユニファイドメモリ¹²はCPUとGPUが共有する物理メモリですが、OSや編集アプリも使います。workflowが読み込めるか、許容速度で繰り返せるかをそれぞれ実際に確認します。

offload後に待ち時間が増えた場合、モデル読み込み・sampling中の反復転送・システムRAM不足によるdisk swapを分けて調べます。同じ風景とprompt¹³を保ち設定を一つだけ変えると、実行できるだけなのか継続利用できる速度なのかを見分けやすくなります。

VRAM容量だけで特定モデルの動作を保証することはできません。モデルファイル、精度、text encoderとVAE、解像度、画像枚数、フレーム数、runtimeもピークメモリを左右します。以下の表は速度や最大使用量の測定結果ではなく、各容量帯で試す作業の出発点です。

8GBでは小型画像モデル・低解像度・画像1枚で読み込みと生成を別々に試します。12GBでは反復生成や軽い編集を試し、画像入力や追加nodeを加えた後の余裕を記録します。16GBではモデルの選択肢を広げつつ1枚から始め、大型モデルの全体読み込みと動画は別途確認します。

24GBでは大型画像モデルの省メモリ経路や動画候補をさらに試せますが、必要な長さとフレームへの対応も確認します。64GB以上でもGPUメモリとRAMを単純に足さず、runtimeの分割・offload方式と必要なhost memoryを確認します。次の選択は表の数字だけでなく、自分のworkflowで繰り返し失敗する段階に合わせます。