ComfyUIの低VRAM・高速化実践：6〜8GB GPUでSDXL、FLUX、動画ワークフローを動かす

terminalにtorch.cuda.OutOfMemoryError: CUDA out of memoryと表示されます。ComfyUIのconsoleはregular VAE encoding, retrying with tiled VAE encodingと出していますが、1024×1024の画像はまだ完成しません。RTX 3060 8GBならSDXLを1枚生成できても、Hires Fix、FaceDetailer、ControlNetを同時に有効にするとVRAMが12GB以上へ跳ね上がります。768×768へ下げ、ControlNetを切れば動くものの、期待した品質ではありません。

6〜8GBの一般向けGPU、Apple Silicon、AMD環境で必要なのは、ComfyUIのSDXL、FLUX、軽量動画workflowをできるだけ安定させ、各調整が速度、品質、互換性のどれを犠牲にするか把握することです。

---

まずGPUのVRAM区分を確認する

VRAM予算は勘では決まりません。GPUの区分によって、現実的なworkflowと最初に選ぶ戦略が変わります。

VRAM区分、実行可能なworkflow、起点の一覧

VRAM	実行しやすいworkflow	制約とrisk	推奨する起点
6GB	低解像度SDXL（512〜768） 強く圧縮したFLUX（Q2_K/Q3_K_S + GGUF + —lowvram/—novram） 動画は480p・8 framesが限界例	解像度が限られる 追加nodeでOOMになりやすい RAM offloadで遅い	Q3_K_Sなど強い量子化を使う 512〜768に抑える ControlNetと後処理branchを止める 動画は8 frames以下
8GB	SDXL 1024×1024を1枚 FLUX fp8/GGUF Q4_K_S、安定保証なし 480p・8 framesは比較的容易、720p・24 framesは限界例	ControlNet/Hires Fixの併用でOOMになりやすい T5はfp8/GGUFが必要 1024×1024以下 FLUX.1 GGUF Q5_K_Sは限界	FLUX.2 Klein 4B GGUFを優先 T5 fp8/GGUF Tiled VAE batch size=1
12GB	SDXL + ControlNet + 簡単なupscale FLUX Q5_K_S/Q6_K 720p・24 framesは比較的容易、1080p・60 framesは限界例	複数ControlNetには注意 frames×解像度を計算する 後処理ピークにも上限がある	FLUX Q5_K_S/Q6_K T5 fp8は任意 Tiled VAEは任意 batch size 2〜3を試す
16GB+	FLUX full fp16またはほぼ無損失のQ8_0 ControlNet/LoRA併用の余裕が増える 1080p・60 frames	FLUX full fileは約23GB frames×解像度は引き続き重要 後処理ピークは残る	FLUX Q8_0またはfp16 T5 fp16 Tiled VAEは任意 batch size 4〜8を試す

ピーク要因の目安、大きい順

1. モデル重み：SDXL checkpointは約6.5GB、FLUX fp16は約23GB
2. T5 encoder：fp16は約9GBで8GBを超える、fp8は約4〜5GB、GGUFはQ3/Q4/Q5
3. latent解像度：2048×2048のlatentは約8GBに達する場合がある
4. VAE encode/decode：2048×2048で約8GBのピーク例
5. batch size：同時推論のピークが最も高い
6. ControlNet/Detailer：各約2〜3GBの例
7. 動画frames：frames×解像度×VideoVAE
8. cache/preview：約0.5〜1GB

実使用量は解像度、精度、モデルversion、batch、後処理node、動画frames、PyTorch/driver、custom node実装で変わります。1〜2GBほど前後する場合があります。この表は起点として使い、実際のworkflowを計測してください。

---

ComfyUIの低VRAM起動オプション

ComfyUIにはVRAMとsystem memoryを制御する起動オプションがあります。オプションはversionで変わります。以下は2026年3月前後のComfyUI v0.18.0+を前提にしています。実行時はpython main.py --helpと最新の公式ドキュメントを確認してください。

起動オプション、用途、対象GPU、速度への影響

option	役割	対象GPU	速度への影響	使用場面
--lowvram	モデルを分割しRAMから順次転送	4〜8GB	20〜40%遅い	Dynamic VRAM有効時は無効 —normalvramでDynamic VRAMを無効にした後の手動test
--novram	重みをCPU/RAMに置き、計算中の部分だけGPUへ移動	4GB未満	50〜70%遅い	最後の手段 非常に遅いが動く場合がある
--normalvram	standard modeを強制しDynamic VRAMを無効化	12GB+	ほぼなし	—lowvramを手動testするとき Dynamic VRAMのfragmentationでOOMになるとき
--reserve-vram N	OS用にN GBのVRAMを予約	全区分	ほぼなし	system crashを避ける 2〜4GBを確保する例
--async-offload	重みを非同期offload	全区分	5〜10%高速化の例	RAMが32GB以上など十分な場合にCPU–GPU待ちを減らす
--fp8_e4m3fn-unet	UNetをfp8へ強制	8〜12GB	ほぼなし	FLUXでは無視されることがある 内部compute dtypeに注意
--fp8_e4m3fn-text-enc	text encoderをfp8で実行	8GB	ほぼなし	T5を約9GBから4〜5GBへ削減 低VRAM FLUX向け
--fp8_e5m2fn-text-enc	text encoderに別のfp8形式を使う	8GB	ほぼなし	fp8_e4m3fnの代替
--preview-method none	生成previewを無効化	全区分	わずかに高速	約0.5〜1GB削減 OOM切り分けの最初
--cache-none	cacheを無効化	RAM不足	遅くなる	RAMを節約する代わりに再計算
--cache-lru 10	10件をLRU cacheへ保存	RAM十分	高速化	balanceを取りやすい 10〜20を試す
--cache-classic	旧式の強いcache	RAM十分	高速化	RAM使用量が増える場合がある
--force-fp16	全体をfp16へ強制	全区分	ほぼなし	速度を大きく落とさず2〜3GB削減する例
--use-pytorch-cross-attention	PyTorch SDP attentionを強制	全区分	5〜20%高速化の例	ComfyUIがxformers/SDPを自動選択する場合がある 特定testだけで強制
--use-flash-attention	Flash Attentionを強制	全区分	5〜20%高速化の例	flash-attention packageが必要 CUDA組み合わせによって非互換
--fast	experimental fast mode	全区分	不定	上級者向け実験 品質や安定性に影響する場合 8GBの標準設定にはしない

command例

# 8GB VRAMの基本設定
python main.py --lowvram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none

# 6GB VRAMの限界設定
python main.py --novram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none --reserve-vram 2

# RAMが十分な場合の高速化設定
python main.py --async-offload --cache-lru 10 --use-pytorch-cross-attention

変わりやすい事実：オプションはversionで変わります。python main.py --helpと最新公式ドキュメントを優先してください。FLUXは内部compute dtypeを使うため--fp8_e4m3fn-unetを無視する場合があり、必要に応じてnodeのweight_dtypeを設定します。

---

—lowvramを付けてもVRAMが溢れる理由

2026年3月前後のComfyUI v0.18.0+では、offloadを自動管理するDynamic VRAMが既定で有効です。Dynamic VRAMが有効な場合、より適応的な低VRAM処理がすでに働くため、--lowvramは無視されます。

--lowvramを手動で使う場面

• --normalvramでDynamic VRAMを無効にした後
• 特定workflowでfragmentation OOMが起きる場合に--disable-dynamic-vramをtestする

代替策

• Dynamic VRAMの既定動作に任せる
• より強い--novramは最後の手段にし、50〜70%の速度低下を受け入れる
• --reserve-vram 2-4でOS用の余裕を残す

Dynamic VRAMの利点：VRAMが足りるか判断し、不足時にRAMへ自動offloadします。

Dynamic VRAMのrisk：workflowによってはfragmentation OOMが残ります。その場合は--disable-dynamic-vramをtestします。

---

8GBでFLUXを動かす3ルート：fp8、GGUF、Klein 4B

FLUXは12B parameterのモデルで、元fileは約23GBです。8GB GPUでは三つのルートがあり、それぞれ代価があります。

FLUX量子化ルート

route	file size	VRAM使用量	fp16比の品質	対象GPU	速度	互換性	向く場面
FLUX full (fp16)	~23GB	~20GB+	100%	24GB+	最速	公式	professional用途 VRAM十分
FLUX fp8 checkpoint	~12GB	~11GB	~95〜98%	12GBなら余裕/16GB+	比較的速い	公式量子化	12GB+ 1 fileで導入
FLUX GGUF Q8_0	~12.7GB	~11GB	~99%	12GB+/16GB+	offloadで遅い	city96 node、WIP	12GB+ ほぼ無損失
FLUX GGUF Q5_K_S	~8.5GB	~7.5GB	~94〜96%	8GBは限界/12GBなら余裕	offloadで遅い	city96 node、WIP	8GB 品質とのbalance
FLUX GGUF Q4_K_S	~6.8GB	~6.5GB	~88〜90%	8GB/6GBは限界	最も遅い	city96 node、WIP	6〜8GB まず動かす
FLUX.2 Klein 4B GGUF Q4_K_M	~2.6GB	~2.6GB	4Bモデル固有の品質	8GBなら余裕	4 stepsで速い	Apache 2.0、city96 node	8GB向け 4-step inference 高速

T5 encoderの選択

T5 version	file size	VRAM使用量	対象GPU
T5 fp16	~9GB	~9GB	24GB+、8GBを超える
T5 fp8_e4m3fn	~4〜5GB	~4〜5GB	8GBで実用的
T5 GGUF Q3/Q4/Q5	~2〜4GB	~2〜4GB	6〜8GBの限界構成

導入方法

fp8はsafetensors fileをdownloadし、Load Diffusion Modelで読み込み、nodeのweight_dtypeをfp8_e4m3fnへ設定します。

GGUFはcity96のComfyUI-GGUF custom nodeをinstallし、Unet Loader (GGUF)で読み込み、fileをmodels/unet/へ配置します。

サードパーティーnodeのrisk：GGUF nodeはWIP表記で、LoRA対応もexperimentalです。更新頻度が高く、公式内蔵ルートではありません。

Apateroの品質観測：Q5_K_Sはfp16に近く、rendered textや細かいpatternで差が出やすいとされています。Q4_K_Sはdetail低下が大きくなります。

Local AI Masterの速度観測

• FLUX.1-dev Q4_K_S + —lowvram、1024×1024、20 steps、RTX 3060 Ti 8GB：約90〜150秒
• FLUX.2 Klein 4B Q4_K_M、1024×1024、4 steps、8GB VRAM：約15〜30秒

変わりやすいbenchmark：hardware、software version、workflowで大きく変わるため、参考範囲として扱います。

---

VAE Encode/DecodeのOOMはTiled VAEで下げる

2048×2048の高解像度画像や動画workflowでは、VAE encode/decodeがVRAMを使い切ることがあります。Tiled VAEは画像を小さな領域へ分けて処理し、ピークを下げます。

nodeの使い方

VAEDecodeTiledはlatentをtileごとに画像へdecodeします。VAEEncodeTiledは画像を同じ方式でlatentへencodeします。

parameter

parameter	役割	起点	使用場面
tile_size	空間tileのsize	低VRAMは512 余裕があれば1024	小さいほどVRAMを減らすが遅い 8GBでは512から試す
overlap	tile間の重なり	64	tile seamを防ぐ 32〜128を試す
fast mode	高速処理mode	true	通常は有効化
temporal_size	video VAEだけの時間chunk	低VRAMは8 余裕があれば16	framesをgroup処理 video VAEだけで有効
temporal_overlap	temporal chunk間の重なり	2〜4	frame group間の連続性

SynpixCloudのピーク比較

解像度	standard VAE peak	Tiled 512	Tiled 1024
1024×1024	~2GB	~0.5GB	~1GB
2048×2048	~8GB	~1GB	~2.5GB

Tiled VAEを使う場面

• 1024×1024を超える解像度
• 8〜12GB GPU
• video VAE workflow
• Hires Fix、Upscale、FaceDetailerの後処理でOOMになる場合

ドキュメント上の注意：node documentationはAI-generated表記です。現在のComfyUIでUIとparameterを確認してください。

---

ピーク要因順のOOM切り分け

CUDA out of memoryが出たら、ピークの大きい要因から確認し、それぞれ一つの具体的なdowngradeを適用します。

OOM切り分け表

ピーク要因	VRAM例	downgrade	優先度
モデル重み	SDXL ~6.5GB FLUX fp16 ~23GB	fp8/GGUFへ変更 —lowvram/—novram	P0
T5 encoder	fp16 ~9GB	対応loaderでT5 fp8/GGUFへ変更	P0（FLUX）
latent解像度	2048×2048 ~8GB	1024×1024または512×512へ下げる	P1
VAE encode/decode	2048×2048で約8GB peak	Tiled VAE、tile_size=512、overlap=64	P1
batch size	batch size=4、1024×1024で約8〜12GB	batch size=1 batch countをqueueへ	P2
ControlNet/Detailer	各約2〜3GB	ControlNet branchを無効化 低VRAM ControlNet routeへ	P2
動画frames	frames×解像度×VideoVAE	temporal chunking framesを減らす temporal tiled VAE	P2（動画）
cache/preview	~0.5〜1GB	—preview-method none —cache-none	P3

次の順で変更します

1. 解像度を下げる：2048 → 1024 → 512
2. previewを止める：--preview-method none
3. fp8/GGUFモデルへ替える：FLUX Q4_K_S、Q5_K_S、Klein 4B
4. T5をfp8/GGUFへ替える：低VRAM FLUXでは重要
5. Tiled VAEを使う：tile_size=512、overlap=64から
6. batch sizeを下げる：batch size=1、batch countをqueueへ
7. ControlNetと後処理branchを止める：FaceDetailer、Hires Fix、Upscale
8. 動画では：framesを減らしtemporal chunkingを使う

---

生成が遅い原因を2種類に分ける

低VRAM offloadのため「遅いが正常」なのか、調整できる設定のため「必要以上に遅い」のかを最初に分けます。

速度切り分け表

bottleneck	特徴	確認方法	調整
低VRAMで想定内の遅さ
—lowvram/—novram	20〜70%遅い	起動optionを確認	遅さを受け入れる VRAMの多いGPUへ
GGUFをRAMへoffload	GPU utilizationが低い	system monitorでGPU%を確認	RAM bandwidthが速度を決める VRAMに余裕があればfp8/fp16
framesの多い動画workflow	VAE decodeが遅い	frames×解像度を計算	framesを減らす Temporal Tiling
—cpuのCPU mode	非常に遅い	起動optionを確認	最後の手段だけ GPUへ切り替える
必要以上の遅さ
sampler stepsが多すぎる	FLUX devで20 steps超	KSamplerを確認	FLUX devは20 steps程度で足りる場合 schnell/Klein 4Bは4 steps
attention backend未調整	memory使用量が高い	起動optionを確認	対応環境でxformers またはPyTorch SDP attention
VAE decodeが遅い	Tiled VAEのtile_sizeが小さすぎる	VAEDecodeTiledを確認	512から1024へ peak約1GB増、10〜30%高速化例
CPU offload待ち	CPU–GPU待ち	起動optionを確認	—async-offload 通常32GB+の十分なRAM
disk/memory cache不適切	modelを繰り返しload	起動optionを確認	—cache-lru 10 10 resultsをcache
他processがGPU使用	有効なGPU utilizationが低い	system monitorを確認	browser、game、video editorを閉じる

次の順で試します

1. xformersまたはSDP attention：pip install xformersで自動検出、または--use-pytorch-cross-attentionをtest。参考値はVRAM 20〜30%削減、速度5〜20%向上
2. 4-step FLUXモデル：dev 20 stepsではなくschnell/Klein 4B
3. Tiled VAEのtile_size：512 → 1024。peak約1GB増と引き換えに10〜30%高速化の例
4. async offload：RAMが十分なら--async-offload
5. 他のGPU processを閉じる：browser、game、video editor

SynpixCloudの観測：xformers/SDP attentionでVRAM 20〜30%削減、速度5〜20%向上の例です。

Local AI Masterの観測：FLUX.2 Klein 4B Q4_K_M、4 steps、1024×1024、8GB VRAMで約15〜30秒です。

変わりやすいbenchmark：すべて環境依存の参考範囲です。

---

小さいGGUF fileが遅くなる理由

Q4_K_S約6.8GBのように、FLUX fp16約23GBより小さいGGUF fileでも生成が遅くなる場合があります。

• GGUFはモデル重みをVRAMへ常駐させずsystem RAMへoffloadすることがあり、GPU utilizationが下がる
• inference中にRAMからVRAMへ重みを繰り返し転送する
• RAM bandwidthはVRAMより低い。DDR4/DDR5は約25〜50GB/s、GDDR6Xは約500〜1000GB/sの例

GGUFを使う場面

• 6〜8GB GPUでfp8が収まらず、GGUFがFLUXを動かす残りのルートになる
• 遅さを受け入れて、まず実行可能にしたい

GGUFを避ける場面

• 12GB+でfp8またはfp16を効率よく使える
• とにかく動かすことより速度を優先する

Apateroの観測：Q8_0 with CPU offloading may take 5-10 minutes per generation。

---

動画のVRAM予算：frames×解像度×VideoVAE

動画workflowではframes×解像度×VideoVAEがVRAMを押し上げます。ここでは予算とピーク削減だけを扱い、WanやAnimateDiffの完全なworkflowは扱いません。

予算の考え方

peak VRAM ≈ モデル重み + T5 + frames×1 frameのlatent + VideoVAE peakです。

ComfyUI-Wan2.2 workflowとLocal AI Master資料に基づく例

動画設定	VRAM予算	対象GPU	備考
480p（640×360）・8 frames	~6〜8GB	6GBで動く例	RTX 3050 6GBの引用例では約1秒の動画を5分以内に生成
720p（1280×720）・24 frames	~12〜16GB	8GBは限界/12GBは余裕	Temporal Tilingが必要
1080p（1920×1080）・60 frames	~20〜24GB+	16GB+	高VRAM route

ピークを下げる方法

Temporal Tilingは動画framesを8 framesずつなど小さなgroupに分けます。設定はtemporal_sizeとtemporal_overlapです。

Tiled VAEは各frameのVAE decodeを空間tileに分けます。

frame数を60→24→8と下げ、最小構成を先に確認します。

解像度を1080p→720p→480pと下げます。

モデルは、source workflowでは8GB向けWan 2.2 5B、または6GBから動く例としてWan 2.2 14B GGUFが挙げられています。

変わりやすいbenchmark：環境依存の参考範囲です。

---

batch sizeとbatch countでOOMを避ける

batch sizeとbatch countではVRAMピークが大きく異なります。batch sizeを無闇に増やすとOOMになりやすくなります。

batch sizeとbatch count

batch sizeは複数画像を同時推論するため、latent、VAE、active tensorが画像数に応じて増えます。batch countは複数batchを順番にqueueへ入れるため、active batchを小さく保てます。

VRAM比較

設定	解像度	peak VRAM	OOM risk
batch size=4	1024×1024	~8〜12GB	同時処理なので高い
batch count=4、batch size=1	1024×1024	~2〜3GB	順次処理なので低い

推奨

• 6〜8GB GPUではbatch size=1、batch count=N
• API batchではVRAMの重いrequestを同時開始せず、ComfyUI API自動化workflowのqueueとconcurrency controlを使う

---

更新後に突然OOMになったらversionを確認する

PyTorch、driver、ComfyUI更新後に同じworkflowが遅くなったりOOMになったりする場合、promptやgraphではなく環境が変わった可能性があります。

VRAMに影響するversion変更

PyTorch CUDAの動作はversionで変わり、TF32/FP16のdefaultやallocator strategyも変化します。TF32/FP16は常に良いわけではありません。PyTorchの例では、TF32 matrix multiplicationは高速でもnumerical errorが増えます。driver、ROCm、CUDA versionもGPU動作を変えます。

推奨手順

1. update前にcondaまたはpip freezeでenvironmentを保存
2. 新versionを別environmentでtest
3. 安定したPyTorch、CUDA、driver versionを記録
4. regressionが出たら固定versionへ戻す

---

実験的な高速化と安定した起点を分ける

高速化optionは、上級者向けの実験と、安定した最初のtestを分けて考えます。

上級者向け実験、8GB GPUのdefault要件ではないもの

item	status	risk	備考
--fast	experimental	品質や安定性に影響する場合	ComfyUI公式でexperimental
FlashAttention	flash-attention packageが必要	CUDA versionによって非互換	installが複雑
Sage Attention	サードパーティー最適化	experimental、精度に影響する場合	CUDA/PyTorchの一致が必要
TensorRT	TensorRT SDKと追加設定が必要	model変換が複雑	初心者には不向き

安定した起点

item	status	効果	備考
xformers	対応環境では安定	参考値はVRAM 20〜30%削減、速度5〜20%向上	pip install xformers ComfyUIが自動検出
SDP attention（—use-pytorch-cross-attention）	安定	参考値はVRAM 20〜30%削減、速度5〜20%向上	ComfyUIが最適backendを自動選択する場合あり

---

まとめ

GPU区分：6GB、8GB、12GB、16GB+のどこに当たるかを最初に確認し、区分に合う基準workflowから始めます。

主要オプション：引用したv0.18.0+の動作ではDynamic VRAMが既定で有効なため、--lowvramが効かない場合があります。起動optionはpython main.py --helpで確認します。

量子化ルート：引用された測定では、8GBで速度を優先する場合はFLUX.2 Klein 4B GGUF、収めることを優先する場合はFLUX.1 GGUF Q4_K_Sが候補です。GGUF offloadの速度はRAM bandwidthに強く依存します。

切り分け順：OOMはモデル重み→T5→latent解像度→VAE→batch size→ControlNet→動画frames→cacheの順で確認します。速度はoffloadによる想定内の遅さと、調整可能なbottleneckを分けます。

次の手順

1. 6GB、8GB、12GB、16GB+のGPU区分を確認
2. 8GBの引用例ならFLUX.2 Klein 4BまたはFLUX.1 GGUF Q4_K_Sなど量子化routeを選ぶ
3. OOM時はmemory checklistで切り分ける
4. 想定外に遅い場合はspeed checklistで調整する
5. 動画workflowではTemporal Tilingを使う

基本環境がまだ動いていない場合はComfyUI入門ガイドから始めてください。red node、missing model、workflow再現の失敗はComfyUI workflow再利用の切り分けを確認します。SDXL、SD 3.5、FLUXをまだ決めていない場合はStable Diffusionモデル選択ガイドを先に読みます。