6–8GB GPU에서 ComfyUI 저VRAM 최적화: SDXL·FLUX·영상 워크플로 실행

터미널에 torch.cuda.OutOfMemoryError: CUDA out of memory가 표시됩니다. ComfyUI console에는 regular VAE encoding, retrying with tiled VAE encoding이 나오지만 1024×1024 이미지는 끝내 완성되지 않습니다. VRAM 8GB RTX 3060은 SDXL 한 장을 생성할 수 있어도 Hires Fix, FaceDetailer, ControlNet을 함께 켜면 사용량이 12GB를 넘습니다. 768×768로 낮추고 ControlNet을 끄면 겨우 실행되지만 원하는 품질과 달라집니다.

6–8GB 일반 GPU, Apple Silicon, AMD 환경에서는 ComfyUI의 SDXL, FLUX, 가벼운 영상 워크플로를 최대한 안정적으로 실행하면서 각 조정이 속도, 품질, 호환성 중 무엇을 희생하는지 알아야 합니다.

---

먼저 GPU의 VRAM 등급을 확인합니다

VRAM 예산은 감으로 정하지 않습니다. GPU 등급에 따라 현실적인 워크플로와 첫 전략이 달라집니다.

VRAM 등급, 가능한 워크플로, 시작점

VRAM	가능한 workflow	제한과 위험	권장 시작점
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 한 장 안정성 보장 없는 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: 동시 inference가 가장 높은 피크 생성
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 정도 차이가 날 수 있습니다. 이 표는 시작 예산으로 사용하고 실제 워크플로를 측정하세요.

---

ComfyUI 저VRAM 실행 옵션

ComfyUI에는 VRAM과 system memory를 제어하는 실행 옵션이 있습니다. 옵션은 version에 따라 바뀝니다. 아래 내용은 2026년 3월 전후 ComfyUI v0.18.0+ 기준이며 python main.py --help와 최신 공식 문서를 우선합니다.

옵션, 역할, GPU, 속도 영향

옵션	역할	GPU	속도 영향	사용 상황
--lowvram	모델을 나눠 RAM에서 전송	4–8GB	20–40% 느림	Dynamic VRAM 활성화 시 효과 없음 —normalvram 뒤 수동 테스트
--novram	가중치를 CPU/RAM에 두고 활성 계산만 GPU로 이동	4GB 미만	50–70% 느림	마지막 수단 매우 느리지만 실행 가능
--normalvram	표준 mode 강제, Dynamic VRAM 비활성화	12GB+	예상 영향 없음	—lowvram 수동 테스트 fragmentation OOM
--reserve-vram N	OS용 N GB VRAM 예약	모든 등급	예상 영향 없음	system 불안정 방지 보통 2–4GB 예약
--async-offload	가중치 비동기 offload	모든 등급	예시: 5–10% 빠름	RAM이 충분할 때 CPU–GPU 대기 감소, 보통 32GB+
--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	다른 fp8 text encoder 형식	8GB	대체로 중립	fp8_e4m3fn 대안
--preview-method none	preview 비활성화	모든 등급	약간 빠름	약 0.5–1GB 절약 첫 OOM 테스트
--cache-none	cache 비활성화	RAM 부족	느림	RAM 절약, 재계산 증가
--cache-lru 10	10개 결과를 LRU cache에 저장	RAM 충분	빠름	균형 잡힌 cache 10–20 테스트
--cache-classic	예전 aggressive cache	RAM 충분	빠름	RAM 사용 증가 가능
--force-fp16	전체 fp16 강제	모든 등급	대체로 중립	2–3GB 절약 가능
--use-pytorch-cross-attention	PyTorch SDP attention 강제	모든 등급	예시: 5–20% 빠름	ComfyUI가 xformers/SDP 자동 선택 가능 특정 테스트에서만 강제
--use-flash-attention	Flash Attention 강제	모든 등급	예시: 5–20% 빠름	flash-attention 필요 일부 CUDA version 비호환
--fast	실험적 fast mode	모든 등급	불확실	고급 실험 품질/안정성 영향 가능 8GB 기본값 아님

명령 예시

# 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

변경 가능성이 큰 정보: 옵션은 바뀔 수 있습니다. python main.py --help와 최신 문서를 확인하세요. FLUX는 내부 compute dtype 때문에 --fp8_e4m3fn-unet을 무시할 수 있으며 필요할 때 node의 weight_dtype을 설정합니다.

---

—lowvram으로도 OOM이 나는 이유

2026년 3월 전후 ComfyUI v0.18.0+는 Dynamic VRAM을 기본으로 활성화합니다. 이미 적응형 offload가 작동하므로 Dynamic VRAM이 활성화되면 --lowvram이 무시됩니다.

--lowvram을 수동으로 쓸 때

• --normalvram으로 Dynamic VRAM을 끈 뒤
• 특정 workflow에서 fragmentation OOM이 나면 --disable-dynamic-vram 테스트

대안

• Dynamic VRAM 기본 동작 사용
• --novram은 마지막 수단으로 두고 50–70% 속도 저하 감수
• --reserve-vram 2-4로 OS 여유 확보

Dynamic VRAM 장점: 필요한 VRAM을 판단하고 부족하면 RAM으로 자동 offload합니다.

Dynamic VRAM 위험: 일부 workflow는 fragmentation OOM이 남습니다. 이때 --disable-dynamic-vram을 테스트합니다.

---

8GB에서 FLUX를 실행하는 세 가지 경로: fp8, GGUF, Klein 4B

FLUX는 12B parameter 모델이며 원본 file은 약 23GB입니다. 8GB에서는 각각 비용이 다른 세 경로가 있습니다.

FLUX 양자화 경로

경로	File size	VRAM	fp16 대비 품질	GPU	속도	호환성	용도
FLUX full (fp16)	~23GB	~20GB+	100%	24GB+	가장 빠름	공식	professional VRAM 충분
FLUX fp8 checkpoint	~12GB	~11GB	~95–98%	12GB 여유/16GB+	비교적 빠름	공식 양자화	12GB+ 한 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 여유	느림	city96 node, WIP	8GB 품질 균형
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을 내려받아 Load Diffusion Model로 불러오고 node의 weight_dtype을 fp8_e4m3fn으로 설정합니다.

GGUF는 city96의 ComfyUI-GGUF custom node를 설치하고 Unet Loader (GGUF)로 모델을 불러온 뒤 file을 models/unet/에 둡니다.

외부 node 위험: 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: 약 15–30초

변경 가능한 benchmark: hardware, version, workflow에 따라 크게 달라집니다. 참고 범위로만 사용하세요.

---

VAE Encode/Decode OOM은 Tiled VAE로 낮춥니다

2048×2048 또는 영상에서는 VAE Encode/Decode가 VRAM을 소진할 수 있습니다. Tiled VAE는 이미지를 작은 영역으로 나눠 피크를 낮춥니다.

Nodes

VAEDecodeTiled는 latent를 tile별 이미지로 decode합니다. VAEEncodeTiled는 이미지를 같은 방식으로 latent에 encode합니다.

Parameter

Parameter	역할	시작값	용도
tile_size	tile 크기	저VRAM 512 여유 시 1024	작을수록 VRAM은 줄고 느려짐 8GB는 512부터
overlap	tile 사이 겹침	64	seam 방지 32–128 테스트
fast mode	빠른 mode	true	대개 활성화
temporal_size	Video VAE 전용 시간 chunk	저VRAM 8 여유 시 16	frames를 group 처리 Video VAE에서만 의미 있음
temporal_overlap	시간 chunk 사이 겹침	2–4	frame group 연속성

SynpixCloud 피크 비교

해상도	표준 VAE	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 문서는 AI-generated로 표시됩니다. 현재 ComfyUI의 UI와 parameter를 확인하세요.

---

VRAM 피크 원인별 OOM 진단

CUDA out of memory가 나오면 큰 피크부터 확인하고 각 단계에서 하나의 구체적인 절감 조치를 적용합니다.

OOM 표

피크 원인	VRAM 예	절감 조치	우선순위
모델 가중치	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	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 경로	P2
영상 frames	Frames × 해상도 × VideoVAE	Temporal chunking frames 감소 Tiled Video 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과 후처리 끄기: FaceDetailer, Hires Fix, Upscale
8. 영상: frames 감소, temporal chunking

---

느린 생성 원인을 두 종류로 나눕니다

저VRAM offload 때문에 느린 것인지, 조정 가능한 설정 때문에 필요 이상으로 느린 것인지 먼저 구분합니다.

속도 진단 표

Bottleneck	특징	진단	조정
저VRAM에서 정상적인 느림
—lowvram/—novram	20–70% 느림	실행 옵션 확인	느림을 감수 또는 더 많은 VRAM
GGUF RAM offload	GPU utilization 낮음	system monitor 확인	RAM bandwidth가 제한 가능하면 fp8/fp16
많은 frames의 영상	VAE Decode 느림	frames×해상도 계산	frames 감소 Temporal Tiling
CPU mode —cpu	매우 느림	실행 옵션 확인	마지막 수단 GPU 사용
비정상적으로 느림
sampler steps 과다	FLUX dev 20 steps 초과	KSampler 확인	FLUX dev는 20 정도로 충분할 수 있음 schnell/Klein 4B는 4
attention backend 부적절	memory 사용 높음	실행 옵션 확인	호환 xformers 또는 PyTorch SDP
VAE Decode 느림	tile_size가 너무 작음	VAEDecodeTiled 확인	512에서 1024 피크 약 1GB 증가, 10–30% 속도 향상 가능
CPU offload 대기	CPU–GPU 대기	실행 옵션 확인	—async-offload 충분한 RAM, 보통 32GB+
disk/RAM cache 부적절	모델 반복 load	실행 옵션 확인	—cache-lru 10 10개 결과 cache
다른 process가 GPU 사용	유효 활용 낮음	system monitor 확인	browser, game, video editor 종료

조정 순서

1. xformers 또는 SDP attention: pip install xformers로 자동 감지하거나 --use-pytorch-cross-attention 테스트. 참고값은 VRAM 20–30% 감소, 속도 5–20% 향상
2. 4-step FLUX 모델: dev 20 steps 대신 schnell/Klein 4B
3. tile_size 증가: 512 → 1024, 피크 약 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에서 약 15–30초입니다.

변경 가능한 benchmark: 모든 값은 환경 의존 참고치입니다.

---

작은 GGUF 파일이 더 느릴 수 있는 이유

약 6.8GB인 Q4_K_S GGUF가 약 23GB인 FLUX fp16보다 느릴 수 있습니다.

• GGUF가 모델 가중치를 VRAM에 두지 않고 system RAM으로 offload해 GPU utilization이 낮아질 수 있음
• inference 중 RAM에서 VRAM으로 가중치를 반복 전송
• RAM bandwidth가 훨씬 낮음. DDR4/DDR5 약 25–50GB/s, GDDR6X 약 500–1000GB/s 사례

GGUF를 사용할 때

• 6–8GB GPU에 fp8이 들어가지 않고 GGUF가 FLUX를 실행할 남은 경로일 때
• 느린 생성을 감수하고 모델을 실행해야 할 때

GGUF를 피할 때

• 12GB+ GPU에서 fp8 또는 fp16을 더 효율적으로 실행할 수 있을 때
• 어떤 방식으로든 실행하는 것보다 속도가 중요할 때

Apatero 관측: Q8_0 with CPU offloading may take 5-10 minutes per generation.

---

영상 VRAM 예산: frames×해상도×VideoVAE

영상에서는 frames×해상도×VideoVAE가 VRAM을 빠르게 지배합니다. 여기서는 예산과 피크 절감만 다루고 Wan이나 AnimateDiff 전체 workflow는 다루지 않습니다.

예산 원리

피크 VRAM ≈ 모델 가중치 + T5 + frames×frame당 latent + VideoVAE 피크입니다.

인용된 ComfyUI-Wan2.2와 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 경로

피크를 낮추는 방법

Temporal Tiling은 frames를 한 번에 8개 같은 작은 group으로 나눕니다. parameter는 temporal_size와 temporal_overlap입니다.

Tiled VAE는 각 frame의 VAE Decode를 공간 tile로 처리합니다.

frames를 60→24→8로 낮추고 가장 작은 실행부터 검증합니다.

해상도를 1080p→720p→480p로 낮춥니다.

원문 자료는 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는 여러 이미지를 동시에 inference하므로 latent, VAE, 활성 tensor가 증가합니다. batch count는 작은 batch를 순서대로 queue에 넣어 활성 batch를 작게 유지합니다.

VRAM 비교

설정	해상도	피크 VRAM	OOM 위험
batch size=4	1024×1024	~8–12GB	동시 처리로 높음
batch count=4, batch size=1	1024×1024	~2–3GB	순차 처리로 낮음

권장

• 6–8GB: batch size=1, batch count=N
• API batch: 여러 무거운 request를 동시에 시작하지 말고 ComfyUI API 자동화 workflow의 queue와 concurrency control 사용

---

업데이트 후 갑자기 OOM이면 version을 확인합니다

PyTorch, driver, ComfyUI 업데이트 후 같은 workflow가 느려지거나 실패하면 prompt와 graph가 같아도 환경이 바뀌었을 수 있습니다.

VRAM에 영향을 주는 version 변경

PyTorch CUDA 동작은 TF32/FP16 default와 allocator를 포함해 변합니다. TF32와 FP16이 항상 더 좋은 것은 아닙니다. PyTorch 예시는 TF32 matrix multiplication이 빠르지만 numerical error가 커질 수 있음을 보여 줍니다. Driver, ROCm, CUDA version도 GPU 동작을 바꿉니다.

권장 절차

1. update 전 conda 또는 pip freeze로 환경 저장
2. 새 version을 별도 환경에서 테스트
3. 안정적인 PyTorch, CUDA, driver version 기록
4. regression 발생 시 고정 version으로 복귀

---

실험적 가속과 안정적인 시작점을 구분합니다

고급 실험과 첫 안정 테스트에 적합한 설정을 나눕니다.

고급 실험, 8GB 기본 요구 사항 아님

항목	상태	위험	비고
--fast	Experimental	품질/안정성 영향 가능	ComfyUI에서 experimental 표시
FlashAttention	flash-attention 필요	일부 CUDA version 비호환	설치 복잡
Sage Attention	외부 최적화	Experimental, 정밀도 영향 가능	CUDA/PyTorch 일치 필요
TensorRT	TensorRT SDK와 추가 설정 필요	모델 변환 복잡	초보자에게 부적합

안정적인 시작점

항목	상태	효과	비고
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이 효과가 없을 수 있습니다. python main.py --help로 확인합니다.

양자화: 인용된 측정은 8GB의 빠른 경로로 FLUX.2 Klein 4B GGUF를, 모델을 넣는 것이 속도보다 중요할 때 FLUX.1 GGUF Q4_K_S를 제시합니다. GGUF offload는 RAM bandwidth에 크게 좌우됩니다.

진단 순서: 모델 가중치 → T5 → latent 해상도 → VAE → batch size → ControlNet → 영상 frames → cache 순서입니다. 속도는 정상적인 offload 지연과 조정 가능한 bottleneck을 나눕니다.

다음 단계

1. GPU 등급 6GB, 8GB, 12GB, 16GB+ 확인
2. 인용된 8GB 사례에서는 FLUX.2 Klein 4B 또는 FLUX.1 GGUF Q4_K_S 선택
3. OOM이면 메모리 checklist 적용
4. 비정상적으로 느리면 속도 checklist 적용
5. 영상 workflow에 Temporal Tiling 사용

기본 환경이 아직 실행되지 않으면 ComfyUI 입문 가이드부터 시작하세요. red node, missing model, 재현 실패는 ComfyUI workflow 재사용 진단 목록을 확인합니다. SDXL, SD 3.5, FLUX 중 아직 결정하지 않았다면 Stable Diffusion 모델 선택 가이드를 먼저 읽으세요.