Porady i wskazówki pozwalające zoptymalizować przepływ pracy przy użyciu TF i Horovod w procesorach GPU

Artykuł został napisany przez Rakshitha Vasudeva i Johna Lockmana z HPC AI Innovation Lab w październiku 2019 r.


Wprowadzenie

Horovod to rozproszona struktura głębokiego uczenia, umożliwiająca przyspieszenie szkoleń w ramach różnych struktur głębokiego uczenia, takich jak Tensorflow, Keras, Pytorch i MXNet. Została opracowana, aby ułatwić ustanowienie rozproszonych projektów głębokiego uczenia i przyspieszenie ich z użyciem TensorFlow. Horovod obsługuje paralelizację procesu uczenia. Obsługuje paralelizację zarówno danych, jak i modelu. Kiedy jest uruchomione zadanie uczenia sieci neuronowej korzystające z Horovod, te typowe porady mogą pomóc w jego debugowaniu i poprawie wydajności.

Opis

W tym artykule jako przykład referencyjny przytoczono CheXNet. CheXNet jest modelem opartego na sztucznej inteligencji asystenta radiologicznego, który z użyciem DenseNet identyfikuje do 14 zmian patologicznych w danym obrazie rentgenowskim klatki piersiowej.

1. Poprawna konfiguracja środowiska pozwala zaoszczędzić dużo czasu podczas próby debugowania problemów z wydajnością. Upewnij się, że jest używana wersja procesora GPU odpowiednia dla systemu głębokiego uczenia. W tym przykładzie zastosowano tensorflow-gpu po spakowaniu przez anaconda.
   
    

2. Użycie horovodrun lub mpirun z parametrami powiązania może spowodować wzrost wydajności. W idealnym przypadku proces sterujący procesorem GPU powinien być powiązany z najbliższym gniazdem procesora. W przypadku serwerów Dell EMC PowerEdge C4140 optymalną opcją jest --map-by socket. Nie ma potrzeby określania jakiejkolwiek opcji powiązania.

   Będzie wyglądać podobnie do tego: 

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

3. Zadanie powinno być skonfigurowane w taki sposób, by jeden proces MPI działał na jednym procesorze GPU. W przypadku liczby procesów większej niż liczba procesorów GPU procesy te będą się konkurować z zasobami obliczeniowymi i nie będzie można uruchomić tego zadania z dobrą wydajnością. W powyższym przykładzie wartość x powinna być równa liczbie używanych procesorów GPU.
   
    

4. Aby ustawić jeden proces na jeden GPU, użyj protokołu ConfigProto() tensorflow w następujący sposób:

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

5. W celu sprawdzenia liczby procesów korzystających z GPU, można posłużyć się zużyciem pamięci przez polecenie ‘watch nvidia-smi’ procesora graficznego. Umożliwia to także sprawdzenie zużycia energii.

   
   Rysunek 1: zrzut ekranu ukazujący działanie polecenia nvidia-smi z danymi pamięci, zasilania oraz wykorzystania GPU.
   
   
    
6. Jeśli konfiguracja kanału przepływu danych jest poprawna i parametry mpirun są prawidłowe, po rozpoczęciu szkolenia modelu wykorzystanie GPU powinno być zawsze większe niż 90%. Sporadyczne spadki do 10–25% wykorzystania są dopuszczalne, ale nie powinny być częste.
   
   
    
7. Należy ustawić rozmiar wsadu w taki sposób, aby pamięć GPU była prawie pełna, ale ograniczyć go tak, aby nie przekroczyć wymagań pamięci. Ważne jest, aby uważać, w jaki sposób uzyskuje się skalowanie szybkości uczenia. Skalowanie szybkości uczenia jest koncepcją, zgodnie z którą przy zwiększającej się liczbie procesorów graficznych szybkość uczenia również musi być pomnożona przez współczynnik proporcjonalny do liczby procesorów GPU. Umożliwia to efektywną konwergencję modelu. W ten sposób liczba operacji wejścia/wyjścia jest zmniejszana poprzez przekazanie do procesora GPU maksymalnej możliwej liczby obrazów bez naruszenia konwergencji modelu. Należy zwrócić uwagę na fakt, że skalowanie szybkości uczenia nie zawsze jest najlepszym rozwiązaniem, gdy celem jest poprawienie konwergencji modelu w ramach rozproszonej konfiguracji roboczej.
   Aby sprawdzić, czy skalowanie szybkości uczenia jest wymagane:
   
   
   a) Wyszkolić model ze skalowaniem szybkości uczenia w trybie rozproszonym i bez skalowania.
   b) Jeśli model bez skalowania szybkości uczenia działa lepiej niż model ze skalowaniem szybkości uczenia, skalowanie szybkości uczenia nie jest potrzebne. 
   
   
   W przypadku uczenia, a w szczególności pod kątem konwergencji, umieszczanie największej możliwej liczby obrazów w partii nie zawsze jest obowiązującą regułą. Zazwyczaj występuje kompromis między rozmiarem partii i konwergencją (bez względu na to, czy zastosowano skalowanie szybkości uczenia), który analityk danych musi być w stanie ustalić, opierając się na konkretnym przypadku użycia.
   W tym przypadku także można sprawdzić zużycie pamięci GPU za pomocą polecenia „watch nvidia-smi”.  W tym przypadku nie skalowano szybkości uczenia, ponieważ użyto lepszego modelu z wartościami AUC, a rozmiar lokalny minibatch wynosił 64. Gdy stosowane jest skalowanie szybkości uczenia, typowym przykładem jest użycie epok przygotowawczych zgodnie z opisem w tym dokumencie.
   
    

8. Profiluj zadania za pomocą osi czasu horovod i nvprof, aby wyświetlić ewentualne wąskie gardła.  W większości przypadków wąskie gardło może być spowodowane jedną z następujących przyczyn:

   a)    Zła konfiguracja kanału przepływu danych tf, a zatem dużo czasu poświęca się na przygotowanie danych, kiedy akcelerator jest bezczynny. Aby rozwiązać ten problem, należy skorygować kanał przepływu danych tf. 
   Aby uzyskać informacje na temat konfigurowania potoku danych tf, przeczytaj ten artykuł. 
   
   b)    Komunikacja może nie używać poprawnej sieci szkieletowej — upewnij się, że korzystasz z InfiniBand. W tym celu przy uruchomionym mpirun użyj opcji –x NCCL_DEBUG=INFO w następujący sposób:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py  --batch_size=128   --epochs=15
           lub użyj horovodrun, który zawiera powiązanie –x.
   
   
    
9. Aby dystrybucja była prawidłowa, procesory GPU muszą efektywnie komunikować się ze sobą. Jeśli nie komunikują się efektywnie, powoduje to wąskie gardło komunikacji. Aby sprawdzić, czy komunikacja odbywa się optymalnie, należy wykonać następujące czynności:
   
   Po pierwsze, zapoznaj się z komunikacją procesorów GPU przy użyciu powiązania -x, jak podano powyżej w punkcie 8b
   
   Jeśli procesory GPU komunikują:
   1) w węźle w sposób optymalny, będą wyglądać następująco:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00 : 0[0] -> 1[1] via P2P/IPC
    
   2) poza węzłem w sposób optymalny, będą wyglądać następująco:
   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

• zastosowano prawidłowe opcje powiązań,
• oceniono wiele procesów pod kątem marnowania pamięci GPU,
• używane jest nowoczesne podejście do przetwarzania potokowego,
• zastosowano profilowanie, aby podczas wykonywania zadania uzyskać wykorzystanie procesorów GPU na poziomie co najmniej 80%,
• skorzystano z najnowszych bibliotek powiązanych CUDA