beautifulsoups.dev
Published on

ComfyUI 느릴 때 - CUDA VRAM·타일링 최적화

Authors

ComfyUI로 Stable Diffusion을 돌리다 보면, 같은 프롬프트·같은 체크포인트인데도 어느 순간부터 워크플로우가 눈에 띄게 느려지거나, GPU 사용률이 들쭉날쭉해지고, VRAM이 꽉 차면서 스왑처럼 버벅이는 상황을 자주 만납니다. 특히 고해상도, 업스케일, ControlNet, 여러 LoRA, 디테일러(ADetailer 계열)까지 얹으면 “느림”의 원인이 하나가 아니라 여러 병목이 연쇄적으로 발생합니다.

이 글은 ComfyUI 워크플로우가 느릴 때를 다음 3가지 축으로 나눠 접근합니다.

  • CUDA 및 VRAM 관점: VRAM이 부족해지는 순간부터 속도는 급격히 무너집니다.
  • 타일링 관점: 타일링은 만능이 아니라, 설정에 따라 오히려 더 느려질 수 있습니다.
  • 워크플로우 관점: 노드 구성과 배치 전략이 병목을 만들기도 합니다.

1) 먼저 “느림”을 분류하자: 증상별 원인 맵

ComfyUI 성능 이슈는 대체로 아래 증상 중 하나로 나타납니다.

GPU 사용률이 0~100%로 요동친다

  • GPU가 계산을 못 해서가 아니라, CPU 준비 작업(전처리, 디코딩, VAE, ControlNet 입력 생성) 또는 메모리 할당/해제에 발목 잡히는 경우가 많습니다.
  • VRAM이 꽉 차서 프레임워크가 메모리 재배치를 반복하면 사용률이 출렁입니다.

특정 단계에서만 유독 느리다

  • 샘플링은 빠른데 VAE Decode에서 멈춘다: VAE가 CPU로 떨어졌거나, 타일 VAE 설정이 과합니다.
  • 업스케일에서만 느리다: 타일 크기/오버랩이 과도하거나, 업스케일 모델이 VRAM을 과점유합니다.

처음 몇 장은 빠른데, 점점 느려진다

  • 캐시가 쌓이거나, 그래프가 커지면서 메모리 파편화가 생길 수 있습니다.
  • 장시간 실행 시 다른 프로세스(브라우저, 게임, 캡처 툴)가 VRAM을 잠식하는 경우도 흔합니다.

서버 운영 관점에서 보면, 이 현상은 “메모리 부족으로 인한 성능 붕괴”와 매우 유사합니다. 쿠버네티스에서도 메모리가 임계치를 넘으면 OOMKilled로 터지기 전에 먼저 지연이 커지는데, 비슷한 패턴으로 이해하면 진단이 빨라집니다. 필요하면 K8s CrashLoopBackOff - OOMKilled·Probe 실패 진단처럼 증상 기반으로 원인을 좁히는 방식을 참고해도 좋습니다.

2) VRAM 병목: “해상도·배치·모델 조합”이 전부를 결정한다

Stable Diffusion에서 VRAM을 가장 크게 잡아먹는 요소는 보통 다음입니다.

  • Latent 해상도(즉, 최종 이미지 해상도)
  • 배치 크기(batch size)
  • ControlNet 개수 및 입력 해상도
  • LoRA/텍스트 인코더 부하(조합이 많을수록)
  • 업스케일 모델(특히 4x 계열)과 타일 처리

2-1) 해상도는 “면적”으로 VRAM을 먹는다

예를 들어 1024x1024는 512x512 대비 픽셀 수가 4배입니다. 단순히 2배 느려지는 정도가 아니라, 중간 텐서가 커지면서 VRAM 압박으로 속도가 급락할 수 있습니다.

권장 전략은 다음과 같습니다.

  • 베이스 생성은 768 또는 832 같은 중간 해상도에서 안정적으로 뽑고
  • 업스케일은 별 단계로 분리하며
  • 업스케일 단계는 타일로 안전장치를 건다

2-2) 배치 크기는 “속도”가 아니라 “리스크”다

배치 크기를 올리면 GPU가 잘 차서 빨라질 것 같지만, VRAM 임계치를 살짝만 넘어도 전체가 느려집니다.

  • batch size 1에서 안정적으로 빠른지 확인
  • 그 다음 2로 올려보고
  • VRAM이 90% 이상 상시 점유되면 다시 내리는 식으로 접근하세요.

2-3) ControlNet 입력 해상도를 낮추면 체감이 크다

ControlNet은 입력 전처리와 추가 U-Net 경로로 비용이 큽니다.

  • Canny, Depth 같은 전처리를 고해상도로 넣으면 CPU/GPU 모두 부담
  • 입력 해상도를 베이스 생성 해상도에 맞추되, 필요 이상으로 높이지 않기

3) CUDA/파이토치 설정: “VRAM 절약”과 “속도”의 균형

ComfyUI는 내부적으로 PyTorch 기반이고, CUDA 커널 선택과 정밀도 설정에 따라 성능이 크게 달라집니다.

3-1) FP16, BF16, TF32의 의미

  • FP16: VRAM 절약과 속도에 유리하지만, 일부 조합에서 품질/안정성 이슈 가능
  • BF16: 지원 GPU에서 안정성이 좋고 속도도 준수
  • TF32: Ampere 이후에서 행렬 연산을 빠르게(정밀도는 FP32보다 낮음)

체감 상, VRAM이 빡빡할수록 FP16 계열이 유리합니다. 다만 “속도가 느린데 VRAM은 남는다”면, 오히려 커널/정밀도 조합이 최적이 아닐 수 있습니다.

3-2) xFormers / SDP(Scaled Dot Product Attention)

Attention 최적화는 SD 성능에 직결됩니다.

  • xFormers가 잘 잡히면 VRAM과 속도 모두 개선되는 경우가 많음
  • PyTorch 2.x의 SDP가 더 안정적인 환경도 있음

환경마다 다르니, 동일 워크플로우로 아래처럼 A/B 테스트하는 것이 가장 확실합니다.

# 예시: 실행 시 플래그/환경변수로 attention 구현을 바꿔가며 테스트
# (실제 옵션은 설치/런처에 따라 다를 수 있음)

# 케이스 1: 기본
python main.py

# 케이스 2: xFormers 사용(환경에 따라)
export XFORMERS_FORCE_DISABLE=0
python main.py

# 케이스 3: xFormers 비활성화
export XFORMERS_FORCE_DISABLE=1
python main.py

중요한 건 “무조건 xFormers가 빠르다”가 아니라, 당신의 GPU·드라이버·PyTorch 조합에서 어떤 경로가 빠른지 확인하는 것입니다.

3-3) VRAM 여유가 없으면 “할당 스파이크”가 제일 위험하다

SD는 스텝 진행 중에도 순간적으로 메모리가 튈 수 있습니다. 이때 VRAM이 임계치면,

  • 커널이 느려지거나
  • CPU 오프로딩이 발생하거나
  • 최악에는 OOM으로 작업이 중단됩니다.

따라서 “평균 VRAM”이 아니라 피크 VRAM을 줄이는 방향(해상도/타일/배치 조정)이 효과적입니다.

4) 타일링: 느릴 때의 구명줄이지만, 과하면 독이다

타일링은 업스케일, VAE Decode, 일부 후처리에서 VRAM을 나눠 쓰는 대표적인 기법입니다. 하지만 다음 이유로 느려질 수 있습니다.

  • 타일 개수가 늘면 오버헤드가 선형으로 증가
  • 오버랩이 크면 같은 영역을 여러 번 계산
  • 타일 경계 블렌딩 비용 증가

4-1) 타일 크기와 오버랩의 실전 감각

  • 타일 크기: 클수록 빠르지만 VRAM을 더 먹음
  • 오버랩: 경계 아티팩트를 줄이지만 느려짐

권장 접근:

  1. VRAM이 터지지 않는 선에서 타일 크기를 최대한 키우기
  2. 오버랩은 최소부터 시작해서, 경계가 보일 때만 조금씩 올리기

예시로 4x 업스케일에서 다음처럼 단계적으로 시험합니다.

타일 512 / 오버랩 32  -> 경계 괜찮고 빠르면 유지
타일 384 / 오버랩 32  -> VRAM 부족하면 타일만 내림
타일 384 / 오버랩 64  -> 경계가 보이면 오버랩만 올림

4-2) “타일 VAE”는 마지막 수단으로

VAE Decode가 VRAM을 크게 먹어서 타일 VAE를 켜는 경우가 있는데,

  • VRAM은 확실히 절약되지만
  • 속도는 눈에 띄게 느려지는 경우가 많습니다.

가능하면 아래 우선순위로 처리하세요.

  1. 최종 해상도를 낮추고 업스케일로 분리
  2. 업스케일 단계만 타일링
  3. 정말 안 되면 VAE 타일링

5) 워크플로우 구조 최적화: “같은 계산을 반복”하지 않게 만들기

ComfyUI는 노드 그래프 기반이라, 구성에 따라 동일한 작업을 여러 번 수행할 수 있습니다.

5-1) 업스케일·디테일러를 “필요한 것만” 적용

흔한 실수:

  • 전체 이미지를 업스케일한 뒤, 다시 전체에 디테일러를 돌림
  • 디테일러가 마스크/크롭을 만들기 위해 또 전처리를 반복

개선 방향:

  • 디테일이 필요한 영역만 인페인트/디테일러
  • 업스케일은 최종 단계로 미루기

5-2) 프롬프트/시드 탐색과 고해상도 렌더를 분리

탐색 단계에서 고해상도로 돌리면 시간 낭비가 큽니다.

  • 512~768에서 시드/구도/프롬프트 확정
  • 확정된 조합만 1024 이상으로 렌더
  • 필요 시 업스케일로 품질 끌어올림

5-3) 반복 실행에는 “캐시” 관점이 필요하다

ComfyUI 자체 캐시뿐 아니라, 모델 로딩/디스크 IO가 병목이 되는 경우도 있습니다.

  • 체크포인트를 계속 바꿔 끼우면 로딩이 반복
  • 네트워크 드라이브에 모델이 있으면 IO 지연

CI에서 캐시가 안 먹으면 빌드가 매번 느려지듯, 모델 파일도 로컬 SSD에 두고 로딩 경로를 단순화하는 것만으로도 체감이 큽니다. 캐시 관점은 GitHub Actions 캐시가 안 먹을 때 키·경로·권한에서 다루는 “경로·키·권한” 같은 사고방식이 은근히 그대로 적용됩니다.

6) “정말 느릴 때” 체크리스트: 10분 안에 원인 좁히기

아래 순서대로 보면 대부분 원인을 잡습니다.

6-1) VRAM 점유 프로세스부터 정리

  • 브라우저(특히 GPU 가속), 게임 런처, 녹화 프로그램이 VRAM을 먹습니다.
  • Windows라면 작업 관리자 GPU 메모리, Linux라면 nvidia-smi로 확인합니다.
# Linux에서 GPU 상태 확인
nvidia-smi

# 1초 간격으로 보기
nvidia-smi -l 1

6-2) 워크플로우를 반으로 쪼개서 범인 찾기

  • 베이스 생성만 실행: 빠르면 업스케일/후처리 쪽 문제
  • 업스케일만 실행: 타일링/업스케일 모델 문제
  • ControlNet을 하나씩 끄기: 특정 전처리/컨트롤이 병목인지 확인

6-3) 해상도와 배치를 “내렸다가 올리기”

  • 해상도를 20%만 내려도 VRAM 피크가 크게 줄어드는 경우가 많습니다.
  • batch size는 반드시 1부터 안정화 후 올립니다.

7) 예시: 느린 업스케일 워크플로우를 빠르게 만드는 리팩터링

상황:

  • 1024로 생성 후 4x 업스케일
  • 업스케일에서만 GPU 사용률이 출렁이고 시간 폭증

개선안:

  1. 베이스 생성 해상도를 768로 낮춤
  2. 업스케일을 2x + 2x로 나눠 중간 결과를 확인
  3. 타일 크기를 가능한 크게, 오버랩을 최소로

개념 워크플로우(의사 구성):

KSampler(768) -> VAE Decode -> 2x Upscale(타일 512, overlap 32)
-> 2x Upscale(타일 384, overlap 32) -> 최종 샤프닝(필요 시)

이렇게 하면 “한 번에 4x”보다 중간 단계에서 실패를 줄이고, 타일 파라미터 튜닝도 쉬워집니다.

8) 결론: ComfyUI 최적화의 핵심은 “피크 VRAM” 관리

ComfyUI가 느릴 때 가장 흔한 본질은 GPU가 약해서가 아니라, VRAM 피크를 넘나들며 메모리 경로가 꼬이는 것입니다. 따라서 최적화는 다음 우선순위로 접근하는 게 효율적입니다.

  1. 해상도·배치·ControlNet 개수로 피크 VRAM을 먼저 낮추기
  2. 업스케일/후처리는 분리하고, 타일링은 “필요 최소”로 적용하기
  3. attention 최적화(xFormers 또는 SDP)를 A/B 테스트로 확정하기
  4. 워크플로우에서 동일 계산 반복을 제거하기

이 과정을 거치면, 같은 GPU에서도 “안정적으로 빠른” 워크플로우로 수렴합니다. 만약 현재 워크플로우의 노드 구성(스크린샷 또는 JSON)과 GPU 모델, 목표 해상도, ControlNet/LoRA 사용 개수를 알려주면, 병목 지점을 기준으로 더 구체적인 튜닝 지점을 짚어 최적화안을 제안할 수 있습니다.

Discuss on Twitter • View on GitHub