beautifulsoups.dev
Published on

ComfyUI VRAM 폭발? 타일·VAE로 해결하기

Authors

ComfyUI로 이미지 생성하다가 CUDA out of memory를 한 번이라도 봤다면, 대부분은 “해상도”가 아니라 “어떤 단계에서 무엇을 VRAM에 붙잡아 두는가”가 문제입니다. 특히 SDXL, 고해상도 업스케일, ControlNet 다중 사용, 그리고 디코딩(VAE)까지 한 번에 몰아치면 VRAM이 순간적으로 치솟습니다.

이 글은 ComfyUI에서 흔히 말하는 “VRAM 폭발”을 재현 가능한 형태로 분해하고, 타일링(tile)과 VAE 운용만으로 OOM을 피하는 구성 패턴을 정리합니다. 목표는 단순히 “낮은 해상도로 타협”이 아니라, 품질을 유지하면서 피크 메모리를 낮추는 것입니다.

운영 관점에서의 ‘폭발’은 소프트웨어에서도 비슷합니다. 예를 들어 DB에서 N+1이 터지면 지연과 부하가 순간적으로 폭증하듯, VRAM도 특정 구간에서만 피크가 생깁니다. 문제를 “구간별로 쪼개서” 막는 접근은 Spring Boot 3 JPA N+1 폭발 - 5가지 해결법과도 결이 같습니다.

ComfyUI에서 VRAM이 터지는 대표 구간

ComfyUI 파이프라인을 크게 나누면 다음 순서로 VRAM 압력이 생깁니다.

  1. UNet 디노이징(샘플링) 구간: 스텝 수와 해상도에 비례해 메모리/연산이 증가
  2. ControlNet / IP-Adapter / LoRA 등 추가 조건: 모델/특징맵이 추가로 상주
  3. VAE 디코딩 구간: latent를 RGB로 바꾸는 순간, 고해상도일수록 피크가 크게 튐
  4. 업스케일/후처리 구간: ESRGAN/4x 업스케일 모델이 추가로 VRAM을 먹음

여기서 핵심은 UNet이 아니라 VAE 디코딩에서 터지는 경우가 꽤 많다는 점입니다. 특히 SDXL + 고해상도에서 latent를 한 번에 디코딩하면, “샘플링은 되는데 마지막에 죽는” 케이스가 자주 나옵니다.

진단 체크리스트: 어디서 터지는지 먼저 고정

OOM 대응은 먼저 “어떤 노드에서 죽는지”를 고정해야 합니다.

  • 큐 실행 시 마지막으로 성공한 노드와 첫 실패 노드를 확인
  • 실패가 VAE Decode라면, 우선 타일링 후보는 VAE 쪽
  • 실패가 업스케일 모델이라면, 업스케일을 타일 기반으로 바꾸거나 단계 분리

가능하면 다음처럼 실행 구간을 분리해 실험합니다.

# 예시: 동일 프롬프트에서
# 1) 샘플링까지만 성공하는지
# 2) VAE Decode에서 죽는지
# 3) 업스케일에서 죽는지

ComfyUI는 노드 단위로 원인을 좁히기 쉽기 때문에, “전체를 한 번에 최적화”하기보다 가장 큰 피크를 만드는 노드를 먼저 타일화하는 게 빠릅니다.

해결 전략 1: VAE를 타일로 디코딩하기

왜 VAE 타일링이 효과적인가

VAE Decode는 latent 전체를 한 번에 펼쳐서 RGB로 만들기 때문에, 해상도가 커질수록 중간 텐서가 커지고 VRAM 피크가 크게 튑니다. 타일 디코딩은 이미지를 여러 조각으로 나눠 디코딩하므로, 피크 메모리를 타일 크기 수준으로 제한할 수 있습니다.

ComfyUI에서의 구성 패턴

설치 환경에 따라 노드 이름은 조금 다를 수 있지만, 일반적으로 아래 흐름이 성립합니다.

  • KSampler 출력 latent
  • VAE Decode (Tiled) 또는 타일 디코딩 노드
  • 저장 또는 후처리

예시(개념 흐름):

Checkpoint Loader
  -> CLIP Text Encode (positive/negative)
  -> Empty Latent Image
  -> KSampler
  -> VAE Decode (Tiled)
  -> Save Image

타일 디코딩에서 주로 조정하는 값은 다음입니다.

  • tile_size: 256, 384, 512 등
  • overlap: 16, 32, 64 등

권장 시작점:

  • 8GB VRAM: tile_size 256~384, overlap 32
  • 12GB VRAM: tile_size 384~512, overlap 32

overlap은 타일 경계 아티팩트를 줄이지만 비용이 늘어납니다. 경계가 보이면 overlap을 올리고, VRAM이 빡빡하면 tile_size를 내리는 식으로 튜닝합니다.

타일 디코딩의 품질 이슈와 대응

  • 경계선/밴딩: overlap 증가, 또는 후처리에서 약한 블러/샤픈 조정
  • 디테일 손실: tile_size를 너무 작게 잡으면 미세 디테일이 약해질 수 있어 384 이상을 우선 고려

해결 전략 2: 업스케일을 “샘플링 기반”과 “픽셀 기반”으로 분리

고해상도 결과가 필요할 때 흔한 실수는 처음부터 큰 해상도로 샘플링하는 것입니다. VRAM이 제한적이면 다음 2단계가 더 안정적입니다.

  1. 낮은 해상도에서 샘플링 (UNet 부담 감소)
  2. 업스케일 (타일 업스케일로 피크 제한)

예시 전략:

  • 1024x1024로 한 번에 생성하다 OOM이면
  • 768x768 또는 832x832로 샘플링 후
  • 1.5x~2x 업스케일을 타일로 수행

개념 흐름 예시:

KSampler (768x768 latent)
  -> VAE Decode (Tiled)
  -> Upscale (Tiled)
  -> Save Image

업스케일러도 타일 기반을 쓰면 VRAM이 급격히 안정됩니다. 특히 4x 업스케일 모델은 피크가 커서, 타일이 사실상 필수인 경우가 많습니다.

해결 전략 3: VAE를 바꿔서 디코딩 부담을 낮추기

VAE는 “품질”뿐 아니라 “메모리 패턴”에도 영향

일부 VAE는 디코딩 시 메모리 사용 패턴이 다르고, 특정 조합에서 피크가 더 크게 나타납니다. SDXL 계열은 VAE 선택이 결과 톤에도 영향을 주지만, OOM을 줄이기 위해선 다음을 우선 확인합니다.

  • 현재 워크플로우에서 VAE가 명시적으로 로드되는지
  • 체크포인트 내장 VAE를 쓰는지, 외부 VAE를 덮어쓰는지

ComfyUI에서는 보통 VAE Loader를 명시하거나, 체크포인트 로더에서 함께 가져옵니다.

Checkpoint Loader
  -> (optional) VAE Loader
  -> VAE Decode

실전 팁

  • OOM이 디코딩에서만 난다면, VAE 타일 디코딩을 먼저 적용하고, 그 다음에 VAE 교체를 시도하는 편이 안전합니다.
  • VAE 교체는 색감/디테일이 달라질 수 있어, 품질 기준이 있는 작업에서는 A/B 비교가 필요합니다.

해결 전략 4: 샘플링 단계에서 피크를 낮추는 설정들

타일과 VAE가 “결정타”라면, 아래는 보조적으로 피크를 줄이는 방법입니다.

1) 배치/동시성 줄이기

  • batch_size를 1로 고정
  • 큐에 여러 작업을 동시에 돌리지 않기

2) 해상도와 스텝의 곱을 관리

  • 해상도를 올릴수록 스텝을 조금 줄여도 체감 품질이 유지되는 경우가 많습니다.

3) ControlNet을 다중으로 쓰면 먼저 1개로 축소

ControlNet 2~3개를 동시에 붙이면 특징맵 상주로 VRAM이 증가합니다. 문제가 해결되면 하나씩 다시 추가해 상한을 찾습니다.

추천 워크플로우: “안 터지는” 기본 골격

아래는 VRAM이 빡빡한 환경에서 시작하기 좋은 골격입니다.

  1. 샘플링 해상도는 보수적으로 시작 (예: SDXL이면 768 또는 832)
  2. 디코딩은 기본적으로 타일
  3. 업스케일이 필요하면 타일 업스케일
  4. ControlNet/어댑터는 최소 구성부터

개념 워크플로우(요약):

Load Checkpoint
 -> Encode Prompts
 -> Create Latent (moderate size)
 -> KSampler
 -> VAE Decode (Tiled: tile 384, overlap 32)
 -> (optional) Tiled Upscale
 -> Save

자주 묻는 실패 패턴과 빠른 처방

“샘플링은 되는데 저장 직전에 죽어요”

  • 거의 항상 VAE Decode 또는 후처리 업스케일 피크
  • 처방: VAE Decode (Tiled) 적용, 업스케일 타일화

“해상도 조금만 올려도 바로 OOM”

  • ControlNet/어댑터/LoRA가 누적되어 상주 메모리가 큰 상태
  • 처방: 구성 요소를 하나씩 끄고 상한 확인, 업스케일 2단계로 변경

“타일을 켰는데 경계가 보여요”

  • 처방: overlap 증가(예: 32 -> 64), 타일 크기 상향(가능하면 384 이상)

운영 관점 팁: 캐시/재현성처럼 워크플로우도 고정하라

VRAM 이슈는 “어제는 됐는데 오늘은 안 됨” 형태로도 자주 나타납니다. 노드/확장 업데이트, 모델 교체, 설정 변경이 누적되기 때문입니다. 이럴 때는 워크플로우를 버전처럼 다루는 게 좋습니다.

  • 잘 동작하는 워크플로우는 JSON으로 따로 보관
  • 변경은 한 번에 하나씩만
  • 실패 시 마지막 변경을 되돌릴 수 있게 기록

이런 습관은 CI 캐시가 갑자기 안 먹을 때 원인을 좁히는 방식과 유사합니다. 체크리스트 기반으로 하나씩 배제하면 해결이 빨라집니다. 참고로 캐시 문제 접근법은 GitHub Actions 캐시가 안 먹을 때 키·경로 9분 점검도 같은 방식입니다.

결론: VRAM 폭발은 “피크 노드”를 타일로 자르는 문제

ComfyUI에서 VRAM OOM을 가장 빠르게 안정화하는 루트는 다음 두 가지입니다.

  • VAE 디코딩을 타일로 바꾸기: 마지막에 터지는 케이스에 특히 강력
  • 업스케일/후처리를 타일로 분리: 고해상도 목표를 포기하지 않게 해줌

여기에 VAE 선택, ControlNet 개수, 샘플링 해상도/스텝을 보조적으로 조정하면, 8GB~12GB 같은 현실적인 VRAM에서도 SDXL 워크플로우를 꽤 안정적으로 굴릴 수 있습니다.

원하는 GPU VRAM 용량(예: 8GB, 12GB, 16GB)과 목표 해상도, 사용 중인 모델(SD1.5/SDXL), ControlNet 사용 여부를 알려주면 그 조건에 맞춘 tile_size/overlap 시작값과 워크플로우 분리안을 더 구체적으로 제안할 수 있습니다.

Discuss on Twitter • View on GitHub