beautifulsoups.dev
Published on

Stable Diffusion ComfyUI GPU OOM 8가지 해결

Authors

ComfyUI로 Stable Diffusion 워크플로우를 돌리다 보면 가장 흔하게 마주치는 에러가 GPU OOM(Out Of Memory)입니다. 특히 CUDA out of memory 혹은 RuntimeError: CUDA error: out of memory 같은 메시지는 워크플로우가 조금만 커져도 재현됩니다.

OOM은 단순히 “VRAM이 부족하다”로 끝나지 않습니다. 해상도, 배치, 샘플러/스텝, 모델 종류, VAE, ControlNet, 업스케일러, 캐시/프리뷰, PyTorch 메모리 단편화까지 복합적으로 영향을 줍니다. 이 글에서는 ComfyUI 기준으로 바로 적용 가능한 8가지 해결책을 우선순위대로 정리합니다.

참고: OOM 원인 추적 관점은 인프라에서도 동일합니다. 쿠버네티스에서 OOMKilled를 추적하는 방법론이 궁금하면 K8s CrashLoopBackOff에서 OOMKilled 원인 추적도 함께 보면 도움이 됩니다.

1) 해상도·배치·스텝을 먼저 줄여 “상한선” 찾기

VRAM 사용량에 가장 큰 영향을 주는 3요소는 해상도(픽셀 수), 배치 크기, 동시 처리(특히 업스케일/컨트롤 포함) 입니다.

  • 해상도: 픽셀 수가 2배가 되면 메모리도 대략 그에 비례해 증가합니다.
  • 배치: batch_size를 2로 올리면 거의 2배에 가깝게 증가합니다.
  • 스텝: 스텝 자체가 VRAM을 선형 증가시키진 않지만, 워크플로우에 따라 중간 텐서가 오래 유지되면 피크가 커질 수 있습니다.

ComfyUI에서 가장 빠른 실험은 다음 순서입니다.

  1. Empty Latent Image의 width/height를 낮추기 (예: 1024x1024에서 768x768 혹은 512x512)
  2. KSampler의 batch_size를 1로 고정
  3. 스텝을 줄여 우선 “돌아가는 조합”을 확보 (예: 30에서 20)
권장 탐색 순서
- 1024^2 / batch 1 / steps 20
- 실패하면 768^2로
- 그래도 실패하면 512^2로
- 성공하면 steps를 늘리거나, 후처리(업스케일)로 품질 보완

핵심은 한 번에 고해상도로 끝내려 하지 말고 “저해상도 생성 + 업스케일”로 파이프라인을 재구성하는 것입니다.

2) SDXL은 특히 무겁다: 모델을 바꾸거나 라이트 설정으로

OOM이 잦다면 현재 모델이 SD 1.5인지 SDXL인지부터 확인하세요. SDXL은 기본적으로 더 무겁고, 다음 요소에서 피크가 커집니다.

  • SDXL Base + Refiner를 둘 다 쓰는 구성
  • 큰 해상도(특히 1024x1024 이상)
  • ControlNet 다중 적용

해결책은 선택지로 나뉩니다.

  • VRAM이 8GB 이하라면 SD 1.5 기반으로 전환
  • SDXL을 꼭 써야 한다면
    • Refiner를 끄고 Base만 사용
    • 해상도를 1024 고정이 아니라 832/896 등으로 타협
    • ControlNet 개수를 줄이기

ComfyUI 워크플로우에서는 Checkpoint Loader에서 모델을 바꾼 뒤 동일한 노드 흐름으로 비교해보는 게 가장 빠릅니다.

3) VAE·디코딩 타이밍 최적화: 미리보기(Preview)와 디코드 횟수 줄이기

VRAM 피크는 생각보다 디코딩(잠재공간에서 이미지로 변환) 구간에서 튀는 경우가 많습니다. 특히 다음 조합이 위험합니다.

  • 고해상도 latent를 자주 디코드
  • 중간 결과를 여러 번 Preview
  • 업스케일 단계마다 디코드/인코드를 반복

권장 패턴은 다음입니다.

  • 샘플링 단계에서는 latent 상태로 최대한 유지
  • 최종 단계에서만 VAE Decode 수행
  • 중간 확인이 필요하면 해상도를 낮춘 별도 브랜치로 Preview
좋은 패턴
KSampler (latent) -> (필요한 후처리도 latent 위주) -> VAE Decode -> Save Image

나쁜 패턴
KSampler -> VAE Decode -> Upscale -> VAE Encode -> KSampler -> VAE Decode ...

4) ControlNet·IP-Adapter·LoRA “동시 적용 수”를 줄이고, 해상도도 분리

OOM을 만드는 주범 중 하나가 “조건부 네트워크를 여러 개 얹는 것”입니다.

  • ControlNet을 2~3개 동시에 적용
  • IP-Adapter를 고해상도 입력으로 사용
  • LoRA를 여러 개 중첩

해결 포인트는 두 가지입니다.

  1. 동시 개수 제한: ControlNet은 1개로도 충분한 경우가 많습니다.

  2. 입력 해상도 분리: 예를 들어 포즈/엣지 입력은 원본 고해상도가 아니라, 생성 해상도에 맞춘 다운스케일 버전을 쓰는 편이 안정적입니다.

# (개념 예시) ControlNet 입력은 생성 해상도에 맞추는 것이 안전
# 실제 ComfyUI에서는 Resize/Scale 노드를 사용
controlnet_input = resize(image, width=768, height=768)

5) 업스케일은 “한 번에 크게”가 아니라 “두 번에 나눠”

4x 업스케일을 한 번에 때리면 업스케일러/후처리 노드에서 VRAM 피크가 크게 발생합니다. 특히 ESRGAN 계열이나 타일링 없는 업스케일은 위험합니다.

권장 방식:

  • 2x + 2x로 나누기
  • 또는 타일 기반 업스케일(타일 크기/오버랩 조절)
예시
512 -> (2x) 1024 -> (2x) 2048

타일 업스케일 권장 설정(경험칙)
- tile_size: 256 또는 512
- overlap: 32~64

타일링은 속도는 조금 느려지지만, VRAM 피크를 낮추는 데 매우 효과적입니다.

6) ComfyUI 실행 옵션: VRAM 절약 모드(저VRAM) 활용

환경에 따라 옵션 명칭/지원이 조금씩 다르지만, ComfyUI는 보통 VRAM을 아끼는 실행 플래그를 제공합니다. 대표적으로 많이 쓰는 실행 형태는 아래처럼 “일단 안전한 모드”로 부팅해 보는 것입니다.

# 예시: VRAM 절약에 도움이 되는 실행 형태(환경별로 옵션은 다를 수 있음)
python main.py --lowvram

또한 xFormers/SDP 같은 어텐션 최적화가 켜져 있으면 VRAM/속도에 유리한 경우가 많습니다. 다만 드라이버/CUDA/PyTorch 조합에 따라 오히려 불안정할 수도 있으니, OOM이 잦은 환경에서는 옵션을 하나씩 켜고 끄며 안정 조합을 찾는 것이 좋습니다.

7) PyTorch 메모리 단편화 대응: 캐시 정리·재시작·환경 변수

VRAM이 “총량은 남아 있는데” OOM이 나는 경우가 있습니다. 이는 메모리 단편화(조각난 빈 공간)로 큰 연속 블록을 못 잡는 전형적인 증상입니다.

실전 대응 순서:

  1. 워크플로우를 여러 번 돌리다가 OOM이 나기 시작했다면 ComfyUI 재시작이 가장 확실합니다.
  2. 다른 GPU 프로세스가 VRAM을 잡고 있는지 확인 후 종료
  3. PyTorch 할당 전략을 바꾸는 환경 변수를 적용
# PyTorch CUDA allocator 설정 예시
# (환경에 따라 효과가 다르며, 문제 해결용으로 시도해볼 가치가 큼)
export PYTORCH_CUDA_ALLOC_CONF="max_split_size_mb:128"
python main.py

또한 리눅스라면 다음으로 현재 VRAM 점유를 확인할 수 있습니다.

nvidia-smi

여기서 ComfyUI 외에 브라우저, 다른 파이썬 프로세스, 게임 런처 등이 VRAM을 잡고 있으면 먼저 정리하는 게 좋습니다.

8) 워크플로우 구조 자체를 바꾸기: “2단계 생성”으로 피크 낮추기

마지막은 근본 처방입니다. 한 번의 거대한 그래프에서 모든 걸 해결하려고 하면 피크 VRAM이 계속 올라갑니다. 대신 다음처럼 2단계로 쪼개면 훨씬 안정적으로 동작합니다.

  • 1단계: 저해상도에서 구도/컨셉 확정 (ControlNet, IP-Adapter도 여기서만)
  • 2단계: 업스케일 + 디테일 보강 (타일 업스케일, 디테일러 등)
권장 파이프라인
Step A: 512~768 생성(조건 강하게) -> 베스트 1장 선택
Step B: 선택본만 업스케일/디테일(조건 최소화) -> 최종 저장

이 방식은 OOM을 줄일 뿐 아니라, 실패 비용(시간/전력)도 줄여줍니다.

OOM이 계속 난다면: “어디서 피크가 나는지”부터 로그로 좁히기

OOM 해결의 핵심은 “VRAM을 많이 쓰는 노드/구간이 어디인지”를 아는 것입니다. ComfyUI는 노드 단위로 실행되므로, 다음처럼 접근하면 빠르게 원인을 좁힐 수 있습니다.

  • 워크플로우를 복제한 뒤, 의심 노드(ControlNet, 업스케일, VAE Decode)를 하나씩 끄고 실행
  • 특정 노드에서만 터지면 그 노드의 입력 해상도/타일/배치부터 줄이기
  • 실행 중에는 nvidia-smi를 켜두고 피크를 관찰

장애를 원인-증상-재현-완화로 구조화하는 방식은 다른 분야에서도 그대로 통합니다. 성능/안정성 트러블슈팅 관점은 AWS ALB 502/504 급증 - 타임아웃 7곳 점검처럼 “체크리스트화”가 가장 효과적입니다.

체크리스트: 8가지 해결책 요약

  1. 해상도/배치/스텝을 줄여 안전 조합부터 확보
  2. SDXL이면 Base/Refiner 구조와 해상도를 재검토(필요 시 SD 1.5로)
  3. VAE Decode/Preview 횟수를 줄이고 latent 상태로 오래 유지
  4. ControlNet/IP-Adapter/LoRA 동시 적용 수를 줄이고 입력 해상도 분리
  5. 업스케일은 타일링 또는 2x 두 번으로 나누기
  6. ComfyUI 실행 옵션에서 --lowvram 등 VRAM 절약 모드 시도
  7. PyTorch 단편화 대응: 재시작, 프로세스 정리, PYTORCH_CUDA_ALLOC_CONF 적용
  8. 워크플로우를 2단계로 분리해 피크 VRAM 자체를 낮추기

마무리

ComfyUI의 GPU OOM은 “VRAM이 작아서”만이 아니라, 피크 메모리를 만드는 워크플로우 구조에서 비롯되는 경우가 많습니다. 위 8가지를 적용하면 대부분의 환경에서 최소 한두 단계는 안정화가 됩니다.

그래도 해결이 안 된다면, 사용 중인 GPU VRAM 용량, 모델(SD 1.5/SDXL), 해상도, ControlNet/업스케일 구성, 그리고 OOM이 나는 정확한 노드 위치를 기준으로 워크플로우를 다시 쪼개는 것이 가장 확실한 접근입니다.

Discuss on Twitter • View on GitHub