내 딥러닝 모델(학습)이 지나치게 느릴 때 점검해야할 사항들
야심차게 모델링 코드를 짜고 훈련을 시작했다! 그런데 1 epoch을 돌리는데 하루 이상이 걸린다..?
가장 먼저, 원인 파악을 위해 GPU 사용 현황을 모니터링하러 가보자. 각 훈련 환경마다 GPU 모니터링 방법이 다를 수 있다.
Ubuntu에서 GPU 모니터링하는 방법은 여기에 잘 소개되어 있다. 나는 회사에서 nvidia-smi로 항상 확인해주고 있다. nvidia-smi 결과를 잘 살펴보는 방법은 여기를 참조하면 된다. 즉, GPU-Util 같은 지표를 통해 GPU의 가용 성능 중 현재 얼마만큼 사용하고 있는지 확인해주면 된다. 100%인데 느리다? 그럼 모델의 문제일 것이고, 이 비율이 50% 정도 미만으로 확연히 낮다? 그럼 모델 외의 문제일 것이다.
1. 모델이 너무 크고 무겁진 않은가?
GPU를 만땅으로 사용하고 있는데도 느리다면, 모델이 너무 크고 무거울 확률이 높다. 당연히 layer가 깊어지고 파라미터가 많아질 수록 훈련 속도가 느려질 수 밖에 없다.
tensorflow로 구현했다면 model.summary를, pytorch로 구현했다면 from torchsummary import summary; summary(model, input_size)를 통해 전체 구조와 trainable parameter의 수를 확인해보자. 너무 많다고 파악되면, parameter수를 줄여가면서 실제로 학습 속도가 감소하는지 확인해보자.
GPU 사용 비율이 이상하게 낮거나, 모델 크기를 줄였음에도 속도가 나아지지 않으면 다른 문제일 확률이 높다. 여러 원인이 있을 수 있는데, 다른 요인에 의해 현재 컴퓨터/서버가 너-무 바빠서 병목이 생기거나, DataLoader 쪽에서 데이터 로드 혹은 전처리에서 병목이 생겼을 수 있다.
2. 현재 서버가 너무 바쁘지 않은지?
각 컴퓨터마다 리소스 확인 방법이 다르지만 리눅스는 htop을 통해 확인할 수 있다.
만약 현재 Core나 RAM의 사용량이 100%에 육박한다면, 다른 프로세스들 때문에 데이터 로딩, 배치 구성 등이 느려져서 병목이 생긴 것일 수 있다. 불필요한 프로세스를 적절하게 없애주는게 필요할 것이다.
3. DataLoader에서 병목이 생기진 않는지?
컴퓨터가 딱히 바쁘지도 않은데 너무 느리다면, 데이터 로더에서 병목이 생기는 것일 수 있다.
우선 전처리 과정을 확인해보자. 전처리 부분만 따로 떼어내어, 한 데이터 혹은 한 batch 구성시 시간이 얼마나 걸리는지 측정해보자. 그럼 한 epoch을 돌릴 때 데이터 로딩만 얼마나 걸릴지 추정해볼 수 있다. 이것 자체만으로 너무 오래걸린다면, 이 부분을 개선해주어야 한다. 전처리 과정을 최적화하거나, 데이터를 몽땅 전처리해서 저장해두거나, 도저히 최적화할 수도, 저장할 수도 없다면 멀티 프로세싱을 잘 이용해볼 수 있다.
개인적으로는 어떤 오픈소스 패키지를 이용한 전처리 단계에서 병목이 발생한 바 있어, 아예 패키지를 해체해서 필요한 부분만 꺼내어 전처리 과정을 최적화한 적이 있었다. 중간에 불필요한 프로세스가 너무 많이 껴있었다.
4. 어디서 데이터를 불러오는지?
전처리 과정에도 문제가 없다면, 최최최종으로 데이터를 어디에서 불러오는지 확인해야한다. 데이터 read 시간 자체도 테스트해보자. 데이터가 SSD에 저장되어 있지 않다면? 그냥 읽는 것 자체만으로 한평생 걸릴 수 있다. HDD disk 에 저장되어 있지는 않은지 확인해보자. 특히 딥러닝 모델을 돌릴 때는 데이터를 매번 Random하게 읽기 때문에, HDD에서는 특히 성능이 매우 저하될 수 있다. HDD는 그냥 저장 순서대로 읽는게 가장 빠르다고 한다. 데이터가 HDD에 저장되어 있는 경우, SSD로 옮기거나, SSD 자리가 없다면, 미리 HDD 에 randomized 된 데이터를 몽땅 (중복되게) 저장하는 방법이 있을 수 있다.... 여기까지는 보통 아니길..
이 부분 역시 개인적으로 용량 문제로 데이터를 HDD에 저장했다가 낭패를 봤던 케이스이다. 리소스가 중요하다 리소스가,,
HDD disk와 관련된 병목 현상은 여기서 상세하게 확인할 수 있다.