GPU에서 TF 및 Horovod로 워크플로를 최적화하는 팁과 요령

이 문서는 2019년 10월 HPC AI Innovation Lab에서 Rakshith Vasudev와 John Lockman이 집필했습니다.


소개

Horovod는 Tensorflow, Keras, Pytorch 및 MXNet과 같은 다양한 딥 러닝 프레임워크에 대한 교육을 신속하게 진행할 수 있는 분산형 딥 러닝 프레임워크입니다. TensorFlow를 사용하여 분산형 딥 러닝 프로젝트를 보다 쉽게 설정하고 시간을 단축할 수 있도록 개발되었습니다. Horovod는 교육 프로세스의 병렬 배치를 지원합니다. 데이터 병렬화와 모델 병렬화를 모두 지원합니다. Horovod를 사용하는 신경망 교육 작업이 실행 중일 때 이러한 공통 팁을 사용하여 디버깅하고 성능 개선을 확인할 수 있습니다.

설명

이 문서에서는 CheXNet를 참조할 수 있는 예로 사용합니다. CheXNet은 DenseNet을 활용하여 제공된 흉부 X선 영상에서 최대 14개의 병변을 식별하는 AI 방사선 기사 보조 모델입니다.

1. 올바른 환경 설정은 성능 문제를 디버깅하려는 경우 많은 시간을 절약할 수 있습니다. 딥 러닝 프레임워크의 GPU 버전이 사용되고 있는지 확인하십시오. 이 예에서는 anaconda가 패키징한 tensorflow-gpu가 사용되고 있습니다.
   
    

2. 바인딩 매개변수와 함께 horovodrun 또는 mpirun을 사용하면 성능이 향상될 수 있습니다. GPU를 제어하는 프로세스는 가장 가까운 CPU 소켓에 바인딩하는 것이 가장 좋습니다. Dell EMC PowerEdge C4140에서 최적의 옵션은 소켓별로 매핑하는 것입니다. 바인딩 옵션을 지정할 필요가 없습니다.

   다음과 유사하게 나타납니다. 

   mpirun --map-by socket -np x python pyfile.py - -pyoptions
   
    

3. 하나의 MPI 프로세스가 하나의 GPU에서 작동하도록 작업을 설정해야 합니다. GPU 수보다 많은 프로세스가 있는 경우 프로세스는 컴퓨팅 리소스를 위해 경쟁하므로 우수한 성능으로 작업을 실행할 수 없습니다. 위 예에서 x는 사용할 GPU의 수와 같아야 합니다.
   
    

4. GPU당 하나의 프로세스를 설정하려면 tensorflow의 ConfigProto()를 다음과 같이 사용하십시오.

   config.gpu_options.visible_device_list=str(hvd.local_size())
   
    

5. GPU를 사용하는 프로세스 수를 확인하기 위해 GPU ‘watch nvidia-smi’의 메모리 소비를 사용할 수 있습니다. 이를 통해 소비 전력도 확인할 수 있습니다.

   
   그림 1: 메모리, 전원 및 GPU 활용도를 보여주는 nvidia-smi 명령 출력의 스크린샷
   
   
    
6. 데이터 파이프라인이 올바르게 설정되고 mpirun 매개변수가 올바른 경우 모델 교육이 시작되면 GPU 활용도가 계속 90%를 초과해야 합니다. 때로 활용도가 10~25%로 낮아질 수도 있지만, 이는 드문 경우여야 합니다.
   
   
    
7. 메모리 요구 사항을 초과하지 않도록 GPU 메모리가 거의 다 찼지만 제한되도록 배치 크기를 설정하십시오. 학습 속도를 확장하는 방법도 고려해야 합니다. 학습 속도 확장은 GPU 수가 증가함에 따라 학습 속도도 GPU 수에 비례하는 계수를 곱하는 수 만큼 증가해야 한다는 개념입니다. 이렇게 하면 모델이 효과적으로 융합됩니다. 이런 방법을 통해 모델 융합의 손상 없이 GPU에 가능한 최대 이미지 수를 맞추면 I/O 작업 수가 줄어듭니다. 학습 속도 확장이 분산형 워크로드 설정에서 항상 모델 융합을 개선하는 가장 적합한 솔루션은 아닙니다.
   학습 속도 확장이 필요한지 확인하려면 다음을 수행하십시오.
   
   
   a)    분산 모드에서 학습 속도 확장을 사용하거나 사용하지 않고 모델을 교육합니다.
   b)    학습 속도 확장을 사용하지 않는 모델이 학습 속도 확장을 사용하는 모델보다 더 나은 경우 학습 속도 확장은 필요하지 않습니다. 
   
   
   특히 융합을 교육할 때 항상 배치당 가능한 최고 개수의 이미지를 맞추는 것이 필수 규칙은 아닙니다. 배치 크기와 융합(학습 속도 확장의 사용 여부에 관계 없이) 사이에 대체로 균형이 유지되므로 데이터 과학자는 사용 사례에 따라 이러한 균형을 파악할 수 있어야 합니다.
   다시 말하면 ‘watch nvidia-smi’를 사용하여 GPU 메모리 소비를 확인할 수 있습니다.  이 사례 연구에서는 AUC 값을 가진 더 나은 모델이 산출되었고 로컬 minibatch 크기가 64로 나타났기 때문에 학습 속도 확장이 사용되지 않았습니다. 이 논문에서 설명한 것처럼 학습 속도 확장을 사용할 때는 워밍업 시간을 갖는 것이 일반적입니다.
   
    

8. horovod timeline 및 nvprof를 사용하여 작업의 프로파일을 작성하여 발생할 수 있는 병목 현상을 확인하십시오.  병목 현상의 원인은 다음 중 하나일 가능성이 높습니다.

   a) TF 데이터 파이프라인이 제대로 설정되지 않은 경우 가속기가 유휴 상태이면 데이터를 준비하는 데 많은 시간이 소요됩니다. 이 문제를 해결하려면 TF 파이프라인을 수정해야 합니다. 
   TF 데이터 파이프라인을 설정하는 방법에 대한 자세한 내용은 이 문서를 참조하십시오. 
   
   b) 통신이 올바른 패브릭을 사용하고 있지 않을 수 있습니다. InfiniBand를 사용 중인지 확인하십시오. 패브릭 사용을 확인하려면 –x NCCL_DEBUG=INFO를 포함하여 mpirun을 실행하거나
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py  --batch_size=128   --epochs=15
   또는 –x 바인딩을 포함하는 horovodrun을 사용합니다.
   
   
    
9. 배포를 올바르게 실행하려면 GPU가 서로 효과적으로 통신해야 합니다. 효과적으로 통신하지 않으면 통신 병목 현상이 발생합니다. 통신 상태가 최적인지 확인하려면 다음 프로세스를 사용하십시오.
   
   먼저 위의 8b 지점에서처럼 GPU가 -x binding을 사용하여 대화하는 방법을 확인하십시오.
   
   GPU를 사용하는 경우
   1)노드 내부에서 최적의 방법은 다음과 유사하게 보입니다.  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00 : 0[0] -> 1[1] via P2P/IPC
    
   2)노드 외부에서 최적의 방법은 다음과 유사하게 보입니다.
   gpu028:149460:149495 [0] NCCL INFO Ring 01 : 16 -> 0 [send] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01 : 12 -> 8 [receive] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01 : 4 -> 8 [receive] via NET/IB/0

• 올바른 바인딩 옵션이 있음
• GPU 메모리를 낭비하지 않는 여러 프로세스 평가
• 최신 파이프라이닝 접근 방식 사용
• GPU를 확인하기 위한 프로파일 작성에 작업 실행 시간의 80% 이상 사용
• 최신 CUDA 관련 라이브러리 사용