PyTorch DataLoader 병목 진단 사례: num_workers=0으로 T4 GPU가 51% 유휴였고 세 줄 변경으로 학습 시간이 43% 단축된 실측 보고

작성자는 본인이 도구(TraceML)를 공개 소스로 제공한다고 명시했고 상세 글과 깃허브 링크를 함께 제시해 추가적인 방법론 검토와 재현을 허용했다. 작성자는 댓글에서 방법론을 더 다룰 의사를 표명했으며 게시글 구조상 독자들이 구체적인 튜닝 절차나 측정 방법을 문의할 여지가 남아 있다. 링크와 실측 수치가 제공되어 토론의 출발점이 되는 근거가 충분히 마련되어 있다.

• 학습 중 GPU 이용률과 전체 벽시계 시간을 측정해 입력 바운드 여부를 확인하라; 낮은 GPU 이용률과 긴 벽시계 시간은 데이터 로딩 병목을 시사한다.
• DataLoader에서 num_workers를 0에서 환경에 맞는 값으로 단계적으로 증가시키고 pin_memory와 persistent_workers를 활성화해 호스트→디바이스 전송과 워커 오버헤드를 줄여라.
• 환경(코어 수, 스토리지 성능, 데이터 변환 비용)에 따라 적정 num_workers가 달라지므로 블로그의 고정값을 그대로 복사하지 말고 직접 측정 결과로 튜닝하라.

PyTorch DataLoader

— PyTorch의 DataLoader는 데이터셋에서 배치를 생성하기 위해 샘플을 읽고 전처리하는 파이프라인 역할을 한다. 내부적으로 샘플 인덱스를 기반으로 데이터를 로드하고 선택된 수의 워커 프로세스로 병렬화하여 I/O와 변환 비용을 분산한다. DataLoader 설정(num_workers, pin_memory, persistent_workers)은 입력 파이프라인의 처리량과 GPU 활용률에 직접적인 영향을 준다.

num_workers

— num_workers는 DataLoader가 배치 생성에 사용하는 서브프로세스 수를 지정하는 파라미터로 입력 읽기와 변환을 병렬화한다. num_workers가 0이면 메인 프로세스에서 모든 I/O와 전처리가 수행되어 GPU가 데이터 준비를 기다리는 병목이 발생할 수 있다. 적정값은 CPU 코어 수, 스토리지 성능, 데이터 변환 비용, 배치 크기 등 환경에 따라 달라져 직접 측정으로 튜닝해야 한다.

pin_memory

— pin_memory는 DataLoader가 반환하는 텐서를 페이지 잠금된(host-pinned) 메모리에 올려서 GPU로의 비동기 전송을 가속하는 설정이다. pin_memory=true일 때 CUDA가 호스트->디바이스 전송을 효율적으로 수행하여 전송 대기 시간을 줄일 수 있다. 이 설정은 CPU에서 GPU로 데이터 이동이 병목일 때 전체 학습 지연을 낮추는 데 중요하다.

persistent_workers

— persistent_workers는 에폭 간에 DataLoader의 워커 프로세스를 재사용하여 워커 생성 오버헤드를 제거하는 옵션이다. 워커가 반복해서 생성·종료되는 비용이 큰 워크로드에서 startup 비용을 줄여 입력 처리량을 높인다. 특히 다중 에폭 반복 학습에서 작은 배치 또는 많은 변환을 사용할 때 전체 벽시계 시간을 개선할 수 있다.