VRAM 최적화 가이드: 저사양 GPU에서 최대 성능 끄어내기

VRAM은 그래픽카드에 붙어 있는 전용 메모리입니다. 시스템 RAM과는 다릅니다. RAM이 32GB여도 그래픽카드가 6GB라면 이미지 생성에서 쓸 수 있는 것은 6GB입니다. 이미지를 만드는 동안 VRAM에는 다음이 함께 올라가 있어야 합니다. • 모델 가중치 — SD1.5는 2GB 남짓, SDXL은 6GB 안팎, Flux는 12GB 이상 • 작업 중인 잠재 데이터 — 해상도와 장수에 비례해 커집니다 • 중간 계산 버퍼 — 샘플링 과정에서 일시적으로 쓰는 공간 • 화면 출력 등 시스템이 이미 쓰고 있는 몫 마지막 항목이 의외로 큽니다. 브라우저 탭이 여러 개 열려 있거나 동영상을 재생 중이면 그것만으로 1~2GB가 나갑니다. "어제는 됐는데 오늘은 안 된다"의 가장 흔한 원인입니다. ■ CUDA out of memory가 뜨는 순간 이 오류는 대부분 두 지점에서 납니다. 하나는 모델을 처음 올릴 때, 다른 하나는 마지막 VAE 디코딩 단계입니다. 샘플링은 잘 끝났는데 마지막에 터진다면 뒤에 나오는 타일 디코딩으로 해결되는 경우가 많습니다. ■ 확인 방법 윈도우는 작업 관리자의 성능 탭에서 전용 GPU 메모리를 볼 수 있습니다. 터미널에서는 nvidia-smi 명령으로 확인합니다. 생성 중에 이 값을 지켜보면 어느 단계에서 한계에 닿는지 알 수 있습니다.

ComfyUI는 실행할 때 붙이는 옵션으로 메모리 전략을 바꿉니다. 위에서부터 순서대로 시도하세요. python main.py --lowvram 모델을 필요한 부분만 GPU에 올리고 나머지는 시스템 RAM에 둡니다. 속도는 다소 느려지지만 대부분의 부족 상황이 해결됩니다. 8GB 이하 카드에서 SDXL을 쓸 때 사실상 필수입니다. python main.py --novram 거의 모든 것을 시스템 RAM에 두고 필요할 때만 옮깁니다. 매우 느리지만 4GB 카드에서도 동작할 여지가 생깁니다. 최후의 수단입니다. python main.py --highvram 반대로 여유가 많을 때 씁니다. 모델을 계속 GPU에 올려둬 반복 생성이 빨라집니다. 16GB 이상에서 같은 모델을 계속 쓴다면 켜볼 만합니다. python main.py --cpu GPU를 쓰지 않습니다. 확인용으로만 쓰고 실사용은 어렵습니다. 윈도우 포터블 버전은 실행 배치 파일 안에 이 옵션을 적어두면 됩니다. 파일을 편집기로 열어 main.py 뒤에 옵션을 추가하고 저장하세요. ■ 시스템 RAM도 중요합니다 --lowvram과 --novram은 모자란 부분을 시스템 RAM으로 메웁니다. 그래서 RAM이 8GB뿐이면 이 옵션을 써도 한계가 있습니다. RAM 증설이 그래픽카드 교체보다 훨씬 저렴하니 먼저 고려해보세요.

옵션을 건드리기 전에 워크플로우 자체에서 줄일 수 있는 것들이 있습니다. 효과가 큰 순서대로 정리했습니다. ■ 1. 해상도 (효과 가장 큼) 잠재 데이터의 크기는 가로와 세로에 함께 비례합니다. 1024×1024를 768×768로 바꾸면 픽셀 수가 약 44% 줄어듭니다. 512×512로 내리면 4분의 1이 됩니다. 무엇을 조정해야 할지 모르겠다면 여기부터입니다. ■ 2. batch_size 한 번에 4장을 만들면 잠재 데이터도 네 배입니다. 1로 낮추고 여러 번 실행하세요. 총 시간은 비슷하지만 순간 사용량이 크게 줄어듭니다. ■ 3. VAE 디코딩을 타일로 VAEDecode 대신 VAEDecodeTiled를 쓰면 이미지를 조각내어 순차 처리합니다. 마지막 단계에서 터지는 문제가 대부분 여기서 해결됩니다. 속도는 조금 느려지지만 큰 이미지를 다룰 때 필수에 가깝습니다. ■ 4. 업스케일을 나눠서 한 번에 4배로 키우려 하지 말고 2배씩 두 번 하세요. 순간 메모리 사용량이 절반 이하로 떨어집니다. ■ 5. 모델 계열 낮추기 SDXL이 버겁다면 SD1.5로 내리는 것이 현실적입니다. 512에서 만든 뒤 업스케일하면 결과가 크게 나쁘지 않으면서 메모리 부담은 3분의 1 수준입니다. ■ 6. 안 쓰는 노드 지우기 연결되지 않은 노드는 실행되지 않지만, LoRA를 여러 개 연결해두고 강도만 0으로 둔 경우에는 여전히 메모리를 씁니다. 안 쓸 거라면 연결을 끊으세요.

자신의 카드가 어느 구간인지 보고 그에 맞춰 시작하세요. ■ 4GB SD1.5, 512×512, batch 1, --lowvram 또는 --novram. 업스케일은 반드시 별도 단계로 나눠서. SDXL은 권장하지 않습니다. 브라우저를 닫고 실행하세요. ■ 6GB SD1.5는 512~768에서 편안합니다. SDXL은 --lowvram으로 1024가 가능하지만 여유가 없습니다. ControlNet을 함께 쓰면 부족해질 수 있으니 해상도를 낮춰 대비하세요. ■ 8GB SDXL 1024×1024가 --lowvram으로 안정적으로 돌아갑니다. batch는 1~2. Hires fix(두 번 샘플링)까지 무리 없이 씁니다. 가장 흔한 구간이며 대부분의 작업이 가능합니다. ■ 12GB SDXL을 옵션 없이 씁니다. batch 4까지 여유롭고 ControlNet을 두 개 겹쳐도 됩니다. 양자화된 Flux 경량 버전을 시도해볼 수 있습니다. ■ 16GB Flux를 실용적으로 쓸 수 있는 최소 구간입니다. 짧은 영상 생성도 시도 가능합니다. --highvram으로 반복 생성 속도를 올릴 수 있습니다. ■ 24GB 이상 대부분의 워크플로우를 제약 없이 돌립니다. 영상 생성과 고해상도 작업이 편안합니다. ■ 그래도 안 될 때 클라우드 GPU를 시간 단위로 빌리는 방법이 있습니다. 무거운 작업만 잠깐 빌려 처리하고, 일상적인 실험은 로컬에서 하는 조합이 비용 대비 효율이 좋습니다.

메모리를 아끼면 보통 느려집니다. 둘의 균형을 잡는 방법입니다. ■ 실험은 가볍게, 마무리는 무겁게 구도를 탐색하는 단계에서는 steps 12~15, 낮은 해상도로 빠르게 여러 장을 봅니다. 마음에 드는 시드를 찾은 뒤에만 steps를 올리고 업스케일을 붙입니다. 처음부터 최고 설정으로 뽑으면 시간의 대부분을 버리는 결과에 씁니다. ■ 모델을 바꾸지 마세요 ComfyUI는 같은 모델을 계속 쓰면 메모리에 올려둔 것을 재사용합니다. 실험 중에 모델을 계속 바꾸면 매번 로드하느라 시간이 나갑니다. ■ steps를 무작정 올리지 않기 20에서 40으로 올려도 눈에 띄는 차이가 없는 경우가 많습니다. 같은 시드로 20과 30을 비교해보고, 차이가 없다면 낮은 쪽을 쓰세요. ■ 샘플러 선택 dpmpp_2m 계열은 적은 steps에서도 안정적입니다. ancestral이 붙은 샘플러는 steps마다 결과가 달라져 재현이 어렵습니다. ■ 백그라운드 정리 게임 런처, 화상회의 프로그램, 여러 개의 브라우저 창은 생각보다 많은 VRAM을 씁니다. 무거운 작업 전에는 닫아두세요. 이것만으로 1~2GB가 확보되어 옵션을 바꾸지 않아도 되는 경우가 있습니다.