• 목록

모델을 실행하다 메모리 부족 오류를 만나면 컴퓨터에 남은 RAM부터 확인하기 쉽습니다. 그런데 시스템 RAM이 넉넉해 보여도 GPU에서 새로운 텐서를 만들지 못할 수 있습니다.

서로 다른 위치의 메모리를 사용하기 때문입니다. 반대로 GPU 메모리가 비어 있어도 데이터를 읽고 준비하는 과정에서 시스템 메모리가 부족해질 수 있습니다.

여기서는 별도의 메모리를 가진 외장 GPU와 CPU를 사용하는 일반적인 실행 환경을 기준으로 설명합니다. 통합 메모리 구조나 특별한 오프로딩 설정까지 모두 같은 방식으로 동작한다고 보지는 않습니다.

메모리 용량을 합산하기 전에 어떤 데이터가 어디에 있고 어느 단계에서 증가하는지 이해하는 것이 출발점입니다.

AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.

핵심 정리
시스템 RAM과 GPU 메모리는 사용 위치를 나누어 봅니다. 모델 파일 크기, 실행 중 텐서, 학습용 정보, 할당기의 예약 공간은 서로 다른 항목이므로 한 숫자로 판단하지 않습니다.

1. 데이터가 있는 위치와 계산하는 장치를 나눕니다

CPU가 다루는 일반적인 시스템 메모리와 GPU 연산에 사용하는 장치 메모리는 별도 공간으로 생각하면 이해하기 쉽습니다. 파일을 읽어 CPU 쪽 배열로 만들었다고 해서 GPU에서 바로 같은 위치를 사용하는 것은 아닙니다.

필요한 데이터가 장치로 이동하는 과정이 있으며 이동 비용도 실행 시간에 영향을 줍니다. NVIDIA의 가이드는 호스트와 장치 사이의 전송을 줄이는 중요성을 설명합니다.

그러므로 RAM과 GPU 메모리를 단순히 더해 모델이 쓸 수 있는 하나의 공간으로 계산하면 실제 동작을 놓칠 수 있습니다. 통합 메모리나 오프로딩은 별도의 기능과 실행 방식이 개입하므로 지원 여부와 비용을 함께 확인해야 합니다.

자신의 코드가 어느 장치에 데이터를 두는지 먼저 확인하고 메모리 그래프의 이름도 그 위치와 맞추어 읽습니다.

관련 공식 문서

2. 모델 파일 크기와 실행 메모리는 다릅니다

디스크에 저장된 모델 파일은 실행 과정에서 필요한 모든 임시 데이터를 나타내지 않습니다. 모델의 가중치 외에도 입력과 중간 결과, 연산 과정의 작업 공간이 필요할 수 있습니다.

간단한 계산 예시로 원소가 백만 개인 배열을 원소당 4바이트로 저장하면 원소 데이터만 4백만 바이트입니다. 같은 원소 수라도 자료형이 달라지면 이 값은 바뀝니다.

이 계산에는 객체 관리 비용이나 연산 중 새로 만드는 배열이 포함되지 않습니다. 따라서 이 숫자는 실제 프로그램의 총 사용량이 아니라 데이터 크기를 이해하기 위한 예시입니다.

입력 길이나 이미지 크기를 늘렸을 때 중간 결과의 크기가 어떻게 바뀌는지는 모델 구조에 따라 달라집니다. 파일 하나가 장치 용량보다 작다는 조건만으로 모든 입력이 처리된다고 결론 내릴 수는 없습니다.

3. 텐서 이동은 결과의 장치도 확인합니다

PyTorch의 Tensor.to는 장치나 자료형 변환에 사용합니다. 요청한 장치와 자료형이 이미 같으면 같은 텐서를 반환할 수 있고, 다른 경우에는 변환된 텐서를 반환합니다.

따라서 원래 변수만 보고 이동됐다고 생각하지 말고 반환값을 어떻게 사용하는지 확인해야 합니다. 모델과 입력이 계산에 맞는 장치에 있는지도 살펴봅니다.

예를 들어 입력을 새 GPU 텐서로 만들면서 CPU 쪽 원본을 계속 보관하면 두 위치에 데이터가 남는 상황을 생각할 수 있습니다. 이는 데이터 흐름을 설명하는 예시이며 모든 호출이 반드시 복사본을 만든다는 뜻은 아닙니다.

장치 이동을 반복문 안에서 불필요하게 되풀이하고 있지 않은지도 확인할 수 있습니다. 코드를 읽을 때는 읽기, 전처리, 장치 이동, 연산, 결과 보관을 순서대로 표시하면 어느 위치에 데이터가 남는지 따라가기 편합니다.

관련 공식 문서

4. 학습과 추론에서 보관하는 정보가 달라집니다

학습에서는 역전파를 위해 필요한 중간 정보가 보관될 수 있습니다. PyTorch 문서는 평가 모드와 기울기 추적을 끄는 기능이 서로 다른 역할임을 설명합니다.

model.eval()을 호출했다는 이유만으로 모든 기울기 기록이 꺼진다고 이해하면 안 됩니다. 추론 목적이라면 no-grad나 inference mode가 해당 코드에 맞는지 확인하고 사용 조건을 살펴봐야 합니다.

이 구분은 메모리 사용량을 해석할 때도 중요합니다. 같은 모델과 입력을 사용하더라도 학습 경로와 추론 경로의 실행 상태를 섞어 비교하면 원인을 잘못 찾을 수 있습니다.

실험 기록에는 모델 모드와 기울기 설정을 따로 적습니다. 추론 결과를 이후 학습 계산에 사용하려는 경우처럼 데이터가 이어지는 상황은 기능의 제약을 함께 확인해야 합니다.

모드를 바꾸는 일은 오류를 숨기기 위한 임의 조치가 아니라 계산 목적에 맞춘 설정이어야 합니다.

관련 공식 문서

5. 사용 중인 텐서와 예약된 공간을 구분합니다

PyTorch의 CUDA 메모리 할당기는 공간을 캐시해 재사용합니다. memory_allocated는 텐서가 차지하는 메모리를, memory_reserved는 할당기가 관리하는 전체 공간을 살펴보는 지표입니다.

두 값이 다르다는 사실만으로 누수라고 단정하지 않습니다. empty_cache는 사용하지 않는 캐시 공간을 돌려주는 기능이며 살아 있는 텐서의 데이터를 지우는 해결책은 아닙니다.

지표를 기록할 때는 모델을 불러온 직후인지 한 번 실행한 뒤인지 같은 조건을 맞춥니다. 반복 실행에서 값이 증가한다면 결과 텐서를 목록 등에 계속 보관하고 있는지도 살펴볼 수 있습니다.

다만 증가 원인은 다양하므로 그래프 한 장만으로 결론을 내리지 않습니다. 실제 오류 메시지와 입력 조건, 실행 단계의 정보를 함께 남겨야 다음 비교가 의미를 갖습니다.

관련 공식 문서

6. 작은 재현 실험으로 어느 쪽이 부족한지 좁힙니다

먼저 오류가 발생한 장치와 시점을 기록합니다. 데이터를 모두 읽는 중인지 모델을 옮기는 중인지, 첫 계산인지 반복 실행 이후인지 나누어 보면 확인할 범위가 달라집니다.

다음에는 입력 크기와 배치 조건을 고정해 한 번에 하나의 조건만 바꾸는 방식으로 비교할 수 있습니다. 실험표에는 시스템 메모리와 장치 메모리 지표를 별도 칸에 적습니다.

예를 들어 배치 조건을 바꾼 실험과 자료형을 바꾼 실험을 동시에 진행하면 어느 변화가 결과에 영향을 줬는지 분리하기 어렵습니다. 이 글의 계산 예시를 실제 장비의 최대 처리량으로 사용하지 말고 자신의 실행 조건에서 측정합니다.

실행에 성공한 조건도 여유가 얼마나 있는지와 함께 남겨야 입력이 달라졌을 때 다시 비교할 수 있습니다. 마지막으로 용량 문제와 전송 시간 문제를 구분합니다.

메모리에 들어가는 것과 원하는 속도로 처리되는 것은 별도 검증 항목입니다. 실험 결과에는 성공 여부뿐 아니라 비교한 입력과 실행 경로를 적어 다른 사람이 같은 조건을 재현할 수 있게 합니다.

7. 자주 묻는 질문

Q1. 시스템 RAM이 남으면 GPU 메모리 부족은 안 생기나요?

별도 메모리를 가진 GPU 환경에서는 그렇게 볼 수 없습니다. 오류가 발생한 장치와 데이터 배치 방식을 확인해야 합니다.

Q2. 모델 파일이 작으면 GPU에서 항상 실행되나요?

실행 중에는 입력과 중간 결과 등 추가 공간이 필요할 수 있습니다. 실제 입력 조건과 실행 방식으로 확인해야 합니다.

Q3. 예약 메모리가 크면 무조건 메모리 누수인가요?

캐시 할당기가 재사용할 공간을 보유할 수 있으므로 숫자 하나로 단정하지 않습니다. 같은 조건의 반복 실행 추이와 살아 있는 텐서를 함께 확인합니다.

Q4. 평가 모드와 기울기 추적 중지는 같은 설정인가요?

서로 다른 역할입니다. 평가 모드는 해당 모듈의 동작을 바꾸며 기울기 기록 여부는 별도 기능으로 확인합니다.

참고 자료

• NVIDIA CUDA 데이터 전송과 메모리
• PyTorch Tensor.to
• PyTorch Autograd mechanics
• PyTorch CUDA 메모리 관리