ComfyUI Low-VRAM Optimization: Run SDXL, FLUX, and Video Workflows on 6–8GB GPUs

The terminal prints torch.cuda.OutOfMemoryError: CUDA out of memory. The ComfyUI console says regular VAE encoding, retrying with tiled VAE encoding, yet the 1024×1024 image still fails. Your RTX 3060 with 8GB of VRAM can generate one SDXL image, but adding Hires Fix, FaceDetailer, and ControlNet pushes memory use past 12GB. Dropping to 768×768 and disabling ControlNet makes it run, but the result is no longer what you wanted.

On a 6–8GB consumer GPU, Apple Silicon, or AMD hardware, the real task is to make ComfyUI run SDXL, FLUX, and lightweight video workflows as reliably as possible while understanding which adjustments trade away speed, quality, or compatibility.

---

Start by Identifying Your GPU Tier

A VRAM budget is not guesswork. Your GPU tier determines which workflows are realistic and which strategy should come first.

Hardware tier table: VRAM, viable workflows, and a practical starting point

VRAM tier	Viable workflows	Limits and risks	Recommended approach
6GB	Lower-resolution SDXL (512–768) Heavily compressed FLUX (Q2_K/Q3_K_S + GGUF + —lowvram/—novram) Video: 8 frames at 480p as an edge case	Limited resolution Extra nodes easily trigger OOM Slow because of RAM offload	Use aggressive quantization such as Q3_K_S Keep resolution at 512–768 Disable ControlNet and post-processing branches Keep video at 8 frames or fewer
8GB	Single-image SDXL at 1024×1024 FLUX fp8/GGUF Q4_K_S, without a stability guarantee Video: 8 frames at 480p comfortably, or 24 frames at 720p as an edge case	ControlNet or Hires Fix combinations can trigger OOM T5 needs fp8/GGUF Keep resolution at or below 1024×1024 FLUX.1 GGUF Q5_K_S is an edge case	Prefer FLUX.2 Klein 4B GGUF Use T5 fp8/GGUF Use tiled VAE Set batch size to 1
12GB	SDXL + ControlNet + simple upscaling FLUX Q5_K_S/Q6_K comfortably Video: 24 frames at 720p comfortably, or 60 frames at 1080p as an edge case	Multiple ControlNet branches still need care Video frames × resolution still matters Post-processing peaks remain finite	Use FLUX Q5_K_S/Q6_K T5 fp8 is optional Tiled VAE is optional Try batch size 2–3
16GB+	FLUX full fp16 or near-lossless Q8_0 More room for ControlNet and LoRA combinations Video: 60 frames at 1080p comfortably	The full FLUX file is about 23GB Video frames × resolution still matters Post-processing still creates peaks	Use FLUX Q8_0 or fp16 T5 fp16 is practical Tiled VAE is optional Try batch size 4–8

Typical peak contributors, from highest to lowest:

1. Model weights: an SDXL checkpoint is about 6.5GB; FLUX fp16 is about 23GB
2. T5 encoder: fp16 is about 9GB and exceeds an 8GB card; fp8 is about 4–5GB; GGUF offers Q3/Q4/Q5 variants
3. Latent resolution: a 2048×2048 latent can approach 8GB
4. VAE encode/decode: 2048×2048 can peak around 8GB
5. Batch size: concurrent inference creates the largest peak
6. ControlNet/Detailer: each can add roughly 2–3GB
7. Video frames: frame count × resolution × VideoVAE
8. Cache and previews: roughly 0.5–1GB

Actual usage depends on resolution, precision, model version, batch size, post-processing nodes, frame count, PyTorch and driver versions, and custom node implementations. Your workflow may vary by 1–2GB. Treat the table as a starting budget, then measure the real workflow.

---

ComfyUI Low-VRAM Launch Flags

ComfyUI exposes several launch flags for VRAM and system-memory behavior. These flags change over time. The list below reflects ComfyUI v0.18.0+ around March 2026; always verify it with python main.py --help and the current official documentation.

Launch flags: purpose, GPU tier, performance impact, and use case

Flag	Purpose	GPU tier	Performance impact	Use case
--lowvram	Splits model loading and streams parts from RAM	4–8GB	20–40% slower	Has no effect when Dynamic VRAM is enabled Use manually after disabling Dynamic VRAM with —normalvram
--novram	Keeps weights in CPU/RAM and moves only active computation to the GPU	Below 4GB	50–70% slower	Last resort Very slow, but may run
--normalvram	Forces standard mode and disables Dynamic VRAM	12GB+	No expected impact	Use when manually testing —lowvram Or when Dynamic VRAM fragmentation causes OOM
--reserve-vram N	Reserves N GB of VRAM for the OS	All tiers	No expected impact	Helps avoid system instability Often reserve 2–4GB
--async-offload	Offloads weights asynchronously	All tiers	5–10% faster	Can reduce CPU–GPU waiting when RAM is plentiful, usually 32GB+
--fp8_e4m3fn-unet	Forces the UNet to fp8	8–12GB	About neutral	Often ignored by FLUX, which may use its own compute dtype
--fp8_e4m3fn-text-enc	Runs the text encoder in fp8	8GB	About neutral	Reduces T5 from about 9GB to 4–5GB Useful for low-VRAM FLUX
--fp8_e5m2fn-text-enc	Uses another fp8 format for the text encoder	8GB	About neutral	Alternative to fp8_e4m3fn
--preview-method none	Disables image previews	All tiers	Slightly faster	Saves roughly 0.5–1GB A good first OOM test
--cache-none	Disables caching	RAM-constrained systems	Slower	Saves RAM at the cost of recomputation
--cache-lru 10	Keeps 10 results in an LRU cache	RAM-rich systems	Faster	Balanced cache behavior Try 10–20
--cache-classic	Uses the older aggressive cache	RAM-rich systems	Faster	May use more RAM
--force-fp16	Forces global fp16	All tiers	About neutral	Can save 2–3GB with little speed loss
--use-pytorch-cross-attention	Forces PyTorch SDP attention	All tiers	5–20% faster	ComfyUI often auto-selects xformers or SDP Force only for a specific test
--use-flash-attention	Forces Flash Attention	All tiers	5–20% faster	Requires the flash-attention package Some CUDA combinations are incompatible
--fast	Enables experimental fast mode	All tiers	Uncertain	Advanced experiment May affect quality or stability Not a default 8GB setting

Command examples:

# Basic 8GB VRAM configuration
python main.py --lowvram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none

# Extreme 6GB VRAM configuration
python main.py --novram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none --reserve-vram 2

# Performance configuration when RAM is plentiful
python main.py --async-offload --cache-lru 10 --use-pytorch-cross-attention

Volatile fact: Flags can change. Treat python main.py --help and the current official documentation as authoritative. FLUX may ignore --fp8_e4m3fn-unet because it uses an internal compute dtype; set weight_dtype in the relevant node when required.

---

Why Does VRAM Still Overflow After Adding —lowvram?

ComfyUI v0.18.0+ around March 2026 enables Dynamic VRAM by default to manage offloading. When Dynamic VRAM is active, --lowvram is ignored because Dynamic VRAM already applies a more adaptive low-memory policy.

When to use --lowvram manually:

• After disabling Dynamic VRAM with --normalvram
• When fragmentation causes OOM in a particular workflow, test --disable-dynamic-vram

Alternatives:

• Rely on the default Dynamic VRAM behavior
• Use the more aggressive --novram only as a last resort, accepting a 50–70% slowdown
• Use --reserve-vram 2-4 to leave room for the operating system

Dynamic VRAM advantage: It estimates whether VRAM is sufficient and offloads to RAM automatically.

Dynamic VRAM risk: Some workflows may still hit fragmentation-related OOM. In that case, test --disable-dynamic-vram.

---

Three Ways to Run FLUX on 8GB: fp8, GGUF, and Klein 4B

FLUX is a 12B-parameter model whose original file is around 23GB. On an 8GB GPU, you have three practical routes, each with a cost.

FLUX quantization routes

Route	File size	VRAM use	Quality vs fp16	Target GPU	Speed	Compatibility	Best fit
FLUX full (fp16)	~23GB	~20GB+	100%	24GB+	Fastest	Official	Professional use Plenty of VRAM
FLUX fp8 checkpoint	~12GB	~11GB	~95–98%	12GB comfortably/16GB+	Fairly fast	Official quantization	12GB+ users One-file setup
FLUX GGUF Q8_0	~12.7GB	~11GB	~99%	12GB+/16GB+	Slower with offload	city96 node, WIP	12GB+ users Near-lossless
FLUX GGUF Q5_K_S	~8.5GB	~7.5GB	~94–96%	8GB edge case/12GB comfortably	Slow with offload	city96 node, WIP	8GB users Quality balance
FLUX GGUF Q4_K_S	~6.8GB	~6.5GB	~88–90%	8GB/6GB edge case	Slowest with offload	city96 node, WIP	6–8GB edge case Prioritize running
FLUX.2 Klein 4B GGUF Q4_K_M	~2.6GB	~2.6GB	Its own 4B-model quality level	8GB comfortably	Four steps, fast	Apache 2.0, city96 node	Recommended for 8GB Four-step inference Fast

T5 encoder options

T5 version	File size	VRAM use	Target GPU
T5 fp16	~9GB	~9GB	24GB+, too large for 8GB
T5 fp8_e4m3fn	~4–5GB	~4–5GB	Practical on 8GB
T5 GGUF Q3/Q4/Q5	~2–4GB	~2–4GB	6–8GB edge cases

Installation

For fp8, download the fp8 safetensors file, load it with Load Diffusion Model, and set weight_dtype to fp8_e4m3fn in the node.

For GGUF, install city96’s ComfyUI-GGUF custom node, load the model with Unet Loader (GGUF), and place the file under models/unet/.

Third-party node risk: The GGUF node is marked WIP, and LoRA support is experimental. It changes frequently and is not an official built-in route.

Quality observation from Apatero: Q5_K_S is close to fp16, with differences most visible in rendered text and fine patterns. Q4_K_S loses more detail.

Performance observation from Local AI Master:

• FLUX.1-dev Q4_K_S + —lowvram, 1024×1024, 20 steps, RTX 3060 Ti 8GB: about 90–150 seconds
• FLUX.2 Klein 4B Q4_K_M, 1024×1024, four steps, 8GB VRAM: about 15–30 seconds

Volatile benchmark warning: Hardware, software versions, and workflow details can change these figures substantially. Treat them as reference ranges.

---

VAE Encode or Decode OOM? Use Tiled VAE

High-resolution images such as 2048×2048 and video workflows can exhaust VRAM during VAE encode or decode. Tiled VAE processes the image in smaller regions to reduce the peak.

Nodes

VAEDecodeTiled decodes a latent into an image tile by tile. VAEEncodeTiled encodes an image into a latent the same way.

Parameters

Parameter	Purpose	Starting value	Use case
tile_size	Size of each spatial tile	512 for low VRAM 1024 when comfortable	Smaller tiles use less VRAM but run more slowly 512 is a practical 8GB starting point
overlap	Overlap between tiles	64	Helps prevent tile seams Try 32–128
fast mode	Faster processing mode	true	Usually worth enabling
temporal_size	Temporal chunk size for video VAE only	8 for low VRAM 16 when comfortable	Processes video frames in groups Only meaningful for video VAE
temporal_overlap	Overlap between temporal chunks	2–4	Maintains continuity between frame groups

Peak comparison from SynpixCloud

Resolution	Standard VAE peak	Tiled at 512	Tiled at 1024
1024×1024	~2GB	~0.5GB	~1GB
2048×2048	~8GB	~1GB	~2.5GB

Use tiled VAE when:

• Resolution exceeds 1024×1024
• The GPU has 8–12GB
• The workflow uses a video VAE
• Hires Fix, Upscale, or FaceDetailer fails during post-processing

Documentation caveat: The node documentation is marked as AI-generated. Verify the current UI and parameters in your installed ComfyUI version.

---

OOM Troubleshooting by Peak Source

When CUDA out of memory appears, diagnose peak sources from largest to smallest and attach one concrete downgrade to each.

OOM troubleshooting table

Peak source	Example VRAM use	Downgrade action	Priority
Model weights	SDXL ~6.5GB FLUX fp16 ~23GB	Switch to fp8/GGUF Use —lowvram/—novram	P0
T5 encoder	fp16 ~9GB	Use T5 fp8/GGUF through a compatible loader	P0 for FLUX
Latent resolution	2048×2048 ~8GB	Reduce to 1024×1024 or 512×512	P1
VAE encode/decode	2048×2048 can peak near 8GB	Use tiled VAE with tile_size=512 and overlap=64	P1
Batch size	batch size=4 at 1024×1024 can peak around 8–12GB	Set batch size=1 Use a queued batch count	P2
ControlNet/Detailer	Each can add ~2–3GB	Disable the ControlNet branch Or use a lower-memory ControlNet route	P2
Video frames	Frames × resolution × VideoVAE	Use temporal chunking Reduce frames Use temporal tiled VAE	P2 for video
Cache/previews	~0.5–1GB	Use —preview-method none Use —cache-none	P3

Apply changes in this order:

1. Lower resolution: 2048 → 1024 → 512
2. Disable previews: --preview-method none
3. Switch to an fp8/GGUF model: use FLUX Q4_K_S, Q5_K_S, or Klein 4B
4. Switch T5 to fp8/GGUF: essential for low-VRAM FLUX
5. Use tiled VAE: start with tile_size=512 and overlap=64
6. Lower batch size: set batch size=1 and use a queued batch count
7. Disable ControlNet and post-processing branches: FaceDetailer, Hires Fix, and Upscale
8. For video: reduce frames and use temporal chunking

---

Troubleshoot Slow Generation by Separating Two Kinds of Slow

First decide whether the workflow is slow because low-VRAM offloading makes it slow, or whether a tunable setting is making it slower than necessary.

Speed troubleshooting table

Bottleneck	Symptom	Diagnostic	Adjustment
Expected low-VRAM slowdown
—lowvram/—novram	20–70% slower	Check launch flags	Accept the slowdown Or use a GPU with more VRAM
GGUF offload to RAM	Low GPU utilization	Check GPU utilization in the system monitor	RAM bandwidth controls speed Use fp8/fp16 when VRAM permits
Video workflow with many frames	Slow VAE decode	Calculate frames × resolution	Reduce frames Use temporal tiling
CPU mode with —cpu	Extremely slow	Check launch flags	Use only as a last resort Switch to a GPU
Unexpected slowdown
Too many sampler steps	FLUX dev uses more than 20 steps	Inspect KSampler	About 20 steps may be enough for FLUX dev schnell/Klein 4B may need only four
Attention backend not tuned	High memory use	Inspect launch options	Install xformers when compatible Or test PyTorch SDP attention
Slow VAE decode	Tiled VAE tile_size is too small	Inspect VAEDecodeTiled	Increase tile_size from 512 to 1024 About 1GB more peak VRAM, potentially 10–30% faster
CPU offload stalls	CPU–GPU waiting	Inspect launch options	Enable —async-offload Make sure RAM is sufficient, usually 32GB+
Poor disk or memory caching	Models reload repeatedly	Inspect launch options	Try —cache-lru 10 Cache 10 results
Another process occupies the GPU	Low useful GPU utilization	Check the system monitor	Close browsers, games, or video editors

Try these adjustments in order:

1. Enable xformers or SDP attention: pip install xformers for auto-detection, or test --use-pytorch-cross-attention; reference ranges suggest 20–30% lower VRAM and 5–20% higher speed
2. Use a four-step FLUX model: schnell or Klein 4B instead of dev at 20 steps
3. Increase tiled VAE tile_size: 512 → 1024, accepting roughly 1GB more peak VRAM for a possible 10–30% speedup
4. Enable async offload: --async-offload when RAM is plentiful
5. Close other GPU-heavy processes: browsers, games, and video editors

SynpixCloud observation: xformers or SDP attention used 20–30% less VRAM and ran 5–20% faster in the cited environment.

Local AI Master observation: FLUX.2 Klein 4B Q4_K_M at four steps and 1024×1024 took about 15–30 seconds on an 8GB GPU.

Volatile benchmark warning: Treat all timing and memory ranges as environment-specific references.

---

Why Can a Smaller GGUF File Be Slower?

A smaller GGUF file, such as Q4_K_S at about 6.8GB instead of FLUX fp16 at about 23GB, can still generate more slowly:

• GGUF may offload model weights to system RAM instead of keeping them in VRAM, lowering GPU utilization
• Inference repeatedly moves weights from RAM to VRAM
• RAM bandwidth is much lower than VRAM bandwidth: DDR4/DDR5 is roughly 25–50GB/s, while GDDR6X can reach roughly 500–1000GB/s

Use GGUF when:

• A 6–8GB GPU cannot fit the fp8 route and GGUF is the remaining way to run FLUX
• You accept slower generation in exchange for fitting the model

Avoid GGUF when:

• A 12GB+ GPU can use fp8 or fp16 more efficiently
• Speed matters more than fitting the model at any cost

Apatero observation: Q8_0 with CPU offloading may take 5–10 minutes per generation.

---

Video VRAM Budget: Frames × Resolution × VideoVAE

In a video workflow, frames × resolution × VideoVAE can quickly dominate VRAM. This section covers budgeting and peak reduction, not a complete Wan or AnimateDiff workflow.

Budget principle

Peak VRAM is roughly model weights + T5 + frame count × per-frame latent + the VideoVAE peak.

Example budget based on the cited ComfyUI-Wan2.2 workflow and Local AI Master material

Video setting	VRAM budget	Target GPU	Note
8 frames at 480p (640×360)	~6–8GB	6GB may work	A cited RTX 3050 6GB run generated roughly one second of video within five minutes
24 frames at 720p (1280×720)	~12–16GB	8GB edge case/12GB comfortable	Requires temporal tiling
60 frames at 1080p (1920×1080)	~20–24GB+	16GB+	High-VRAM route

Ways to reduce the peak

Temporal tiling splits video frames into smaller groups, such as eight frames at a time. The relevant controls are temporal_size and temporal_overlap.

Tiled VAE processes each frame’s VAE decode in spatial regions.

Reduce frame count from 60 to 24 to 8, and verify the smallest run first.

Reduce resolution from 1080p to 720p to 480p.

For model choice, the source workflow suggests Wan 2.2 5B for an 8GB target or Wan 2.2 14B GGUF from 6GB.

Volatile benchmark warning: Treat the numbers as environment-specific reference ranges.

---

Avoid OOM in Batch Generation: Batch Size vs Batch Count

Batch size and batch count create very different VRAM peaks. Raising batch size blindly is a common way to trigger OOM.

Batch size vs batch count

Batch size runs multiple images concurrently, so latent, VAE, and other active tensors scale with the number of images. Batch count queues several batches sequentially, keeping each active batch small.

VRAM comparison

Configuration	Resolution	Peak VRAM	OOM risk
batch size=4	1024×1024	~8–12GB	High because the peak is concurrent
batch count=4, batch size=1	1024×1024	~2–3GB	Lower because each image runs sequentially

Recommendation:

• On 6–8GB GPUs, use batch size=1 and batch count=N
• For API batches, use the queue and concurrency controls from the ComfyUI API automation workflow instead of starting several VRAM-heavy requests at once

---

Sudden OOM After an Update? Check Version Changes

If a workflow becomes slower or starts failing after a PyTorch, driver, or ComfyUI update, the environment may have changed even though the prompt and graph did not.

Version changes that affect VRAM

PyTorch CUDA behavior changes across versions, including TF32/FP16 defaults and allocator behavior. TF32 and FP16 are not universally better: PyTorch examples show that TF32 matrix multiplication can be faster with higher numerical error. Driver, ROCm, and CUDA versions also change GPU behavior.

Recommended process:

1. Back up the environment before updating with conda or pip freeze
2. Test the new version in a separate environment
3. Record the stable PyTorch, CUDA, and driver versions
4. Roll back to a pinned version when a regression appears

---

Experimental Speedups vs Stable Starting Points

Separate experimental acceleration options from the settings that make sense as a stable first test.

Advanced experiments, not default requirements for an 8GB GPU

Item	Status	Risk	Note
--fast	Experimental	May affect quality or stability	Marked experimental by ComfyUI
FlashAttention	Requires the flash-attention package	Some CUDA versions are incompatible	Installation can be involved
Sage Attention	Third-party optimization	Experimental and may affect precision	Requires a matching CUDA/PyTorch environment
TensorRT	Requires TensorRT SDK and extra setup	Model conversion is complex	Poor fit for beginners

Stable starting points

Item	Status	Effect	Note
xformers	Stable when compatible	Reference range: 20–30% less VRAM and 5–20% faster	pip install xformers ComfyUI auto-detects it
SDP attention with —use-pytorch-cross-attention	Stable	Reference range: 20–30% less VRAM and 5–20% faster	ComfyUI may already choose the best backend automatically

---

Conclusion

Hardware tier: Start by identifying whether the GPU has 6GB, 8GB, 12GB, or 16GB+ because each tier supports a different baseline workflow.

Core flags: Dynamic VRAM is enabled by default in the cited v0.18.0+ behavior, so --lowvram may do nothing. Flags change; verify them with python main.py --help.

Quantization route: The source measurements favor FLUX.2 Klein 4B GGUF for an 8GB fast route, or FLUX.1 GGUF Q4_K_S when fitting the model matters more than speed. GGUF offloading depends heavily on RAM bandwidth.

Troubleshooting order: Diagnose OOM by model weights → T5 → latent resolution → VAE → batch size → ControlNet → video frames → cache. For speed, distinguish expected offload slowdown from a genuinely tunable bottleneck.

Next steps:

1. Identify the GPU tier: 6GB, 8GB, 12GB, or 16GB+
2. Select a quantization route, such as FLUX.2 Klein 4B or FLUX.1 GGUF Q4_K_S for the cited 8GB cases
3. Use the OOM checklist when memory fails
4. Use the speed checklist when generation is unexpectedly slow
5. Use temporal tiling for video workflows

If the base environment is not running yet, start with the ComfyUI beginner guide. For red nodes, missing models, or failed workflow reproduction, use the ComfyUI workflow reuse troubleshooting checklist. If you have not decided between SDXL, SD 3.5, and FLUX, read the Stable Diffusion model selection guide.