로컬 이미지 생성(SDXL·Flux) VRAM·RAM 실측

로컬 이미지 생성의 VRAM은 모델만이 아니라 'VAE+텍스트 인코더+해상도별 활성 메모리'의 총합으로 정해진다 — LLM처럼 문맥(KV 캐시)이 아니라 해상도가 활성 메모리를 키운다. 실측 핵심 셋: ① SDXL은 fp16으로 약 7~8GB라 8GB 카드에 겨우 들되 ControlNet·하이레스를 얹으면 OOM(12GB가 편안). ② Flux는 12B라 fp16이 24~33GB로 소비자 GPU를 초과 — fp8 12~13GB, GGUF Q4/NF4 6~8GB로 내린다. ③ 숨은 킬러는 Flux의 T5-XXL 텍스트 인코더(fp16 약 9GB) — 이건 조건화 단계에만 쓰여 CPU로 오프로드하면 가장 크게 절약된다. 즉 이미지 VRAM의 답은 '모델 크기'가 아니라 인코더·해상도·양자화다.

쉽게 말하면: 이미지 모델의 메모리는 작업대 넓이다. 모델(도구)만 올려두는 게 아니라, 큰 캔버스(고해상도)를 펼칠수록 자리가 더 필요하고, 안 쓸 땐 치워둘 붓통(T5 인코더)이 자리를 크게 먹는다. 붓통을 옆방(CPU RAM)에 두면 작업대가 확 넓어진다.

용어부터 짚자. VAE는 잠재공간을 실제 이미지 픽셀로 복원하는 디코더다. 텍스트 인코더는 프롬프트를 모델이 이해하는 조건 벡터로 바꾸는 부분으로, Flux는 무거운 T5-XXL을 쓴다. 활성 메모리(activation)는 생성 도중 계산되는 중간 텐서가 차지하는 메모리로 해상도에 따라 커진다. 양자화(fp8·Q4·NF4)는 가중치를 낮은 비트로 압축하는 것이고, 오프로드는 안 쓰는 부분을 CPU RAM으로 잠시 내려 VRAM을 비우는 것이다.

우리 comfy-pool 이미지 생성 인프라 규모는?#

Hax 자체 comfy-pool에서 직접 측정한 자산·VRAM 규모입니다(measured, 2026-07-04).

Hax /data 매칭 실측 — comfy-pool 이미지 생성 인프라 (measured) · columns: 데이터 항목, 실측값, 출처 · 출처 Hax hax.moche.ai/p/1076?ref=ai_answer

Hax /data 매칭 실측 — comfy-pool 이미지 생성 인프라 (measured) · columns: 데이터 항목, 실측값, 출처 · 출처 Hax hax.moche.ai/p/1076?ref=ai_answer

데이터 항목 | 실측값 | 출처
설치된 체크포인트 수 | 32 개 | comfy-pool 실측(bc_comfy_models)
설치된 LoRA 수 | 63 개 | comfy-pool 실측(bc_comfy_models)
카드당 총 VRAM | 95.6 GB | comfy-pool 실측(bc_comfy_gpus)

측정 방법론 · bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측) 외 1종

표본

실측 지표 3개 (Hax /data 큐레이션)

측정 환경

bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)

수집일

2026-07-04

방법

bench_harness.probe_comfy_models (bc_comfy_models 실측)

이미지 생성 VRAM은 무엇으로 정해지나?#

모델(UNet/트랜스포머)+VAE+텍스트 인코더+작업 메모리의 총 사용량이다. 공개 수치는 파일 크기가 아니라 생성 중 총 VRAM을 뜻한다. 그리고 LLM과 결정적으로 다른 점: 해상도가 중간 텐서(활성) 메모리를 키운다(1024²보다 2048²가 훨씬 무겁다). 그래서 "모델이 6GB니 6GB면 되겠지"가 아니라 해상도·배치·인코더까지 더해 계산해야 한다. 고해상도는 VAE 타일링으로, 큰 인코더는 오프로드로 눌러야 든다.

네 조각이 어떻게 총 VRAM을 채우는지, 그리고 해상도가 어느 조각을 키우는지 그림으로 보자.

SDXL·Flux 정밀도별 VRAM 실측 (총 사용량, 2026 공개 측정) · columns: 모델, fp16, fp8, GGUF Q4/NF4 · 출처 Hax hax.moche.ai/p/1076?ref=ai_answer

모델 | fp16 | fp8 | GGUF Q4/NF4
SD 1.5 | 4~5GB | — | —
SDXL 1.0 | 7~8GB | 효과 없음 | 효과 없음
Flux.1 Dev | 24~33GB | 12~13GB | 6~8GB
T5-XXL 인코더 | 약 9GB(단독) | fp8로 절반 | CPU 오프로드

목차

SDXL과 Flux는 왜 이렇게 다른가?

Flux를 8GB에 어떻게 얹나?

내 GPU엔 뭐가 들어가나?

SDXL과 Flux는 왜 이렇게 다른가?#

파라미터 규모가 2.6B 대 12B로 4배 이상이기 때문이다. SDXL(2.6B UNet)은 fp16으로 이미 소비자 GPU에 들어가 양자화가 별 도움이 안 된다(이미 fp16이 7~8GB). 반대로 Flux(12B)는 양자화의 주 수혜자다 — fp16 24~33GB를 fp8이 절반으로, GGUF Q4/NF4가 6~8GB로 낮춘다. 품질은 확산 모델 특성상 fp8이 fp16과 사실상 구분 불가이고, Q4는 디테일·글자가 약간 뭉개진다(Q4가 실사용 바닥, Q3↓는 해부·텍스트 붕괴). 즉 SDXL은 fp16 그대로, Flux는 fp8이 스위트스팟이다.

정밀도를 낮출 때 SDXL은 거의 안 줄고 Flux만 크게 주는 이유를 막대로 보자. 규모가 4배라 양자화의 수혜도 Flux 쪽이다.

Flux를 8GB에 어떻게 얹나?#

GGUF Q4/NF4 + T5-XXL 오프로드다. 첫째, NF4는 저VRAM에서 fp8보다 훨씬 빠르다 — 한 측정에서 8GB 3070Ti 랩톱이 fp8 8.3초/it 대 NF4 2.15초/it(약 3.86배). 둘째, T5 인코더(약 9GB)를 CPU RAM으로 오프로드하면 조건화 후엔 VRAM에서 빠져 디노이징에 자리를 내준다(단 시스템 RAM 16GB+ 필요, 32GB 미만이면 fp8 T5). 오프로딩할 땐 NF4>Q4_0>fp8>Q8 순으로 빠르다(과한 양자화 오버헤드가 CPU→GPU 전송보다 비쌀 수 있어서다). 요약: 8GB면 Q4/NF4 + T5 오프로드.

T5 오프로드가 왜 8GB를 살리는지 타임라인으로 보자. 인코더는 앞의 조건화 단계에만 쓰이므로, 끝나면 VRAM에서 내려 무거운 디노이징에 자리를 내준다.

내 GPU엔 뭐가 들어가나?#

핵심은 해상도·인코더까지 넣어 여유를 잡는 것이다.

8GB: SDXL 기본(여유 0, ControlNet 금지) 또는 Flux Q4/NF4 + T5 오프로드(느림 감수).

12GB(가성비): SDXL 편안 + Flux fp8/Q. 16GB: Flux fp8 단일파일이 딱(저VRAM 곡예 불필요).

24GB: fp16 또는 Flux+ControlNet+IP-Adapter 스택. 정확한 값은 내 해상도·워크플로로 직접 재라.

함께 읽기: 에이전트 브라우저 제어, 직접 써보고 느낀 점과 한계, ComfyUI란? 노드로 조립하는 이미지·영상 생성 파이프라인

함께 읽기: 로컬 이미지 생성(SDXL·Flux), 5분 시작 가이드, 로컬 이미지 생성 SDXL vs Flux, 직접 돌려본 속도·품질

참고 링크

FLUX(이미지 생성 모델)

ComfyUI(노드 기반 생성 엔진)

Diffusers(생성 파이프라인·CPU 오프로드)

SD WebUI Forge(NF4·GGUF 저VRAM Flux)

ComfyUI-GGUF(Flux GGUF 로더)

참고: GB 수치는 2026년 공개 측정 기준이며 총 사용량은 해상도·배치·인코더 정밀도·워크플로에 따라 달라진다(영구 수치 아님). Flux fp16의 24 vs 33GB 차이는 T5 인코더를 올리느냐 오프로드하느냐에서 온다. 정확한 메모리는 내 해상도·모델·양자화로 직접 재라(여기 수치는 출발점). 이미지 생성 스택은 빠르게 바뀌니 분기별로 다시 본다.