# Windows에서 ComfyUI 메모리 부족: VRAM, RAM, 디스크 중 무엇인가?

ComfyUI가 Windows에서 `CUDA out of memory`을 보고하면 먼저 GPU 메모리와 실패한 워크플로를 조사하세요. 생성된 이미지를 삭제하면 디스크 공간은 확보되지만 전용 VRAM이 늘어나지는 않습니다. 일반적인 메모리 부족 메시지에 시스템 RAM이 관련될 수도 있으므로, 모든 실패를 같은 문제로 취급하지 말고 실제 오류 텍스트를 보관하세요.

## 실패한 워크플로를 보관하고 단계를 찾기

워크플로를 저장하고 모델, 해상도, 배치 크기, 실행이 중단되는 노드를 기록하세요. 오류 보고서와 터미널 로그를 사용해 모델 로드, 샘플링, 이미지 디코딩, 사용자 정의 노드 실행을 구분하세요. 각 단계는 필요로 하는 메모리 양이 다를 수 있으므로 어느 단계인지가 중요합니다.

ComfyUI의 [문제 해결 안내서](https://docs.comfy.org/troubleshooting/overview)는 보고서 확인, 이미지 크기나 배치 크기 줄이기, 사용자 정의 노드 문제 배제를 권장합니다. 이를 통제된 비교로 다루세요. 모든 노드를 업데이트하고 Python을 바꾸며 모델까지 동시에 바꾸지 마세요. 다시 실행에 성공해도 어떤 변경이 중요했는지 더는 알 수 없게 됩니다.

## GPU 메모리와 시스템 메모리를 따로 읽기

실패를 재현하는 동안 **작업 관리자 › 성능**을 열어 GPU의 전용 메모리를 메모리 페이지와 함께 확인하세요. GPU가 여러 개인 PC에서는 워크플로에 실제로 사용되는 GPU를 보고 있는지 확인하세요.

| 리소스 | 부족할 때 달라지는 것 |
| --- | --- |
| 전용 GPU 메모리 | 모델과 중간 텐서가 GPU에 들어가는지 여부 |
| 시스템 RAM과 커밋 | Windows와 CPU 측 작업에 여유가 있는지 여부 |
| 디스크 공간 | 모델, 출력물, 페이징 파일이 커질 수 있는지 여부 |

공유 GPU 메모리는 그래픽 카드의 추가 물리 VRAM이 아닙니다. SSD 여유 공간이 크다고 해서 큰 모델이 그 카드에 들어가는 것은 아닙니다. Microsoft의 [작업 관리자 GPU 설명](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/)에 서로 다른 수치가 설명되어 있습니다.

## 첫 번째 실험을 실패한 노드에 맞추기

메모리 부족 보고서에는 보통 빨간색 노드만보다 더 유용한 정보가 담겨 있습니다. 첫 번째 할당 오류와 이를 일으킨 노드를 기록하세요. 이후의 예외는 그 첫 실패의 결과일 수 있습니다. 그래프를 변경하기 전에 워크플로의 사본을 저장하세요.

| 실패 단계 | 첫 번째 통제 비교 | 결과로 확인할 수 있는 것 |
| --- | --- | --- |
| 체크포인트 또는 텍스트 인코더 로딩 | 동일한 최소 작업으로 실행하는 호환되는 더 작은 모델 하나 | 로딩 요구량이 장애물인지 여부 |
| 샘플링 | 배치 1, 그다음 별도 실행에서 지원되는 더 낮은 이미지 크기 | 중간 작업 부하가 더 작은 크기에서 맞는지 여부 |
| 샘플링 후 VAE 디코드 | 호환되는 타일 VAE 디코드 | 디코딩이 실패한 최대 지점이었는지 여부 |
| 업스케일링 또는 비디오 처리 | 지원되는 경우 더 작은 입력 하나 또는 더 적은 프레임 | 해당 단계의 입력 크기가 실패를 유발하는지 여부 |
| 사용자 정의 노드 | 가장 작은 지원 내장 동등 노드 | 실패가 해당 노드 경로에 특정된 것인지 여부 |

이는 실험이며 보장이 아닙니다. 더 작은 체크포인트는 모델 계열, 필요한 노드 또는 출력 품질을 바꿀 수 있으므로 이를 지원하는 워크플로를 사용하세요. 첫 번째 오류가 가중치 로딩에 관한 것이라면 최종 JPEG 품질을 낮추는 것으로는 필요한 모델 메모리 양이 바뀌지 않습니다.

모델, 시드, 해상도, 배치, 변경한 노드와 결과를 간단히 기록하세요. 워크플로가 지원하면 동일한 시드를 유지해 시각적 비교를 더 쉽게 하되, 정밀도나 노드를 바꾸면 이미지가 여전히 달라질 수 있음을 인지하세요. 작은 구성이 완료되면 제한 단계가 분명해질 때까지 요구 사항을 하나씩 복원하세요.

## 한 번에 한 가지 요구량 줄이기

배치 크기를 1로, 지원되는 더 작은 해상도로 시작하세요. 그때 워크플로가 완료되면 한 가지 차원만 늘리고 반복하세요. 이미지 너비와 높이를 모두 두 배로 하면 픽셀은 네 배가 되지만, 모델과 여러 노드에 각자의 비용이 있으므로 총 VRAM이 정확히 네 배가 된다는 뜻은 아닙니다.

샘플링이 아니라 디코딩에서 실패하면 워크플로가 지원할 때 호환되는 타일형 VAE 디코드 노드를 시도해 보세요. 출력에서 이음새나 다른 차이를 확인하세요. 단일 모델을 로드할 수 없다면 출력 크기를 줄이는 것만으로는 문제가 해결되지 않을 수 있습니다. 해당 워크플로와 하드웨어가 지원하는 모델이나 정밀도를 테스트하세요.

다시 실행하기 전에 다른 GPU 집약적 작업을 저장하고 종료하세요. 실패한 작업 후에도 메모리가 점유된 상태로 남으면 워크플로를 저장한 뒤 ComfyUI를 정상적으로 재시작하세요. 재시작은 버려진 작업 부하를 해제할 수 있지만, 지나치게 큰 워크플로가 안정적으로 들어가게 만들어 주지는 않습니다.

## 전체 워크플로를 다시 만들지 않고 VAE 디코딩 변경하기

ComfyUI의 [VAE Decode Tiled 문서](https://docs.comfy.org/built-in-nodes/VAEDecodeTiled)는 잠재 샘플을 더 작은 타일로 디코딩하는 방법을 설명합니다. 호환되는 이미지 워크플로의 저장된 사본에서 동일한 잠재 샘플과 VAE를 타일 디코드 노드에 연결한 다음, 그 이미지 출력을 기존 저장 또는 미리보기 노드에 연결하세요. 변경을 되돌릴 수 있도록 원본 워크플로를 유지하세요.

다른 모델에서 여러 타일 및 오버랩 값을 복사하기보다 노드의 사용 가능한 기본값으로 시작하세요. 더 작은 타일이 필요하면 해당 값만 변경하고 메모리 사용량과 결과 이미지를 모두 확인하세요. 작은 조각은 작업 집합을 줄일 수 있지만 처리 오버헤드를 늘립니다. 결과를 수용하기 전에 부드러운 그라데이션, 경계와 세부 디테일을 검사하세요.

디코드 시 타일링은 모델을 로드하거나 샘플러를 실행하기 위해 앞서 필요한 메모리를 줄이지 않습니다. 실행이 디코드에 도달하지 못하면 조사를 실패 단계로 되돌리세요. 비디오 VAE 또는 특수 모델은 자체 호환 노드가 필요할 수 있으므로 이름에 “tiled”가 포함된다는 이유만으로 이미지 디코더를 대체하지 마세요.

## 설치 환경에 맞는 최적화 경로 사용하기

공식 안내서는 수동 설치용 `--lowvram`을 설명합니다. 자체 환경에서 실행되는 수동 설치의 경우 형식은 다음과 같습니다.

```
python main.py --lowvram
```

이것은 ComfyUI Desktop, 포터블 번들, 타사 런처에 그대로 붙여 넣는 범용 명령이 아닙니다. 해당 설치가 지원하는 실행 설정을 사용하고 기존 인수를 유지하세요. 작업을 GPU 메모리에서 옮기면 속도와 시스템 RAM을 대가로 VRAM 요구량을 낮출 수 있습니다.

사용자 정의 노드와 관련된 실패는 내장 워크플로와 비교하고 ComfyUI의 [사용자 정의 노드 문제 해결](https://docs.comfy.org/troubleshooting/custom-node-issues)을 따르세요. 원본 워크플로를 보존하고 어떤 노드를 비활성화했는지 기록하세요. 사용자 정의 노드가 없으면 워크플로가 달라지므로 재현할 수 있는 가장 작은 동등 작업과 비교하세요.

## 비교 후 실행 설정 복원하기

메모리 옵션을 시도하기 전에 런처의 사본이나 인수 기록을 보관하세요. 수동 Python 환경, Windows 포터블 패키지와 데스크톱 앱은 반드시 같은 방식으로 시작되지는 않습니다. 실제로 이 설치를 시작하는 메커니즘을 통해서만 옵션을 추가하세요. 두 번째 Python 환경을 만들면 다른 문제가 생길 수 있습니다.

ComfyUI의 [시작 플래그 참조](https://docs.comfy.org/development/comfyui-server/startup-flags)는 여러 독립적인 메모리 및 캐시 제어를 설명합니다. 이들은 함께 활성화하는 스위치 모음이 아닙니다. 예를 들어 결과 캐싱을 줄이면 보유 메모리를 낮출 수 있지만 더 많은 노드가 다시 실행될 수 있습니다. CPU 오프로딩은 추가 시스템 RAM이 필요하고 워크플로를 느리게 할 수 있습니다.

성공적인 실행 후 출력이 완전하고 사용 가능한지 확인한 다음 일반 작업을 반복하세요. 변경으로 작은 테스트만 통과하고 필요한 워크플로가 여전히 실패하면 그 경계를 기록하세요. 원본 런처에서 도움이 되지 않는 테스트 인수를 제거하고 다음 실험 전에 마지막으로 작동한 구성으로 돌아가세요.

시스템 커밋이 병목이라면 GPU 메모리와 함께 Windows 메모리를 검사하고 작동하는 페이징 파일 구성을 유지하세요. 디스크 용량 늘리기, 페이징 파일 한도 늘리기와 전용 VRAM 수요 줄이기는 서로 다른 개입이며, 어느 것도 다른 개입에 대한 보편적 해결책으로 제시해서는 안 됩니다.

## 출력 정리는 별도 작업으로 유지하기

생성된 이미지와 비디오는 상당한 디스크 공간을 차지할 수 있습니다. 프로젝트별로 검토하고 가치 있는 결과를 재현하는 데 필요한 워크플로와 자산은 보관하세요. 유일한 사본을 삭제하기 전에 보관하려는 것은 백업하세요.

오류가 Windows 커밋 부족이라면 [Windows 메모리 안내서](/ko/windows/blog/windows-high-memory-usage)에 그것이 VRAM과 어떻게 다른지 설명되어 있습니다. 드라이브가 더 깨끗해 보이게 하려고 페이징 파일을 삭제하지 마세요. 지속되는 실패를 보고할 때는 정확한 오류, GPU와 드라이버, 설치 유형, 실패하는 가장 작은 워크플로를 포함하고 비공개 프롬프트와 경로는 제거하세요.


Canonical: https://mole.fit/ko/windows/blog/comfyui-out-of-memory-windows