Tips och knep för att optimera arbetsflödet med TF och Horovod i grafikprocessorer

Artikeln skrevs av Rakshith Vasudev och John Lockman på HPC AI Innovation Lab i oktober 2019


Introduktion

Horovod är ett distribuerat djupinlärningsramverk som påskyndar inlärningen i olika djupinlärningsramverk som Tensorflow, Keras, Pytorch och MXNet. Det utvecklades för att göra det enklare att etablera distribuerade djupinlärningsprojekt och snabba upp dem med TensorFlow. Horovod har stöd för parallellisering av inlärningsprocesser. Den har stöd för både dataparallellism och modellparallellism. När ett jobb för inlärning i neurala nätverk som använder horovod körs kan dessa vanliga tips användas för att felsöka och se förbättring av prestanda.

Beskrivning

I den här artikeln används CheXNet som ett exempel att referera till. CheXNet är en AI-modell för radiologiassistent som använder DenseNet för att identifiera upp till 14 pathologier från en given x-ray-bild.

1. Med rätt konfiguration av miljön kan du spara mycket tid när du försöker felsöka prestandaproblem. Se till att djupinlärningsramverkets GPU-version används. I det här exemplet används tensorflow-gpu som paketeras av anaconda.
   
    

2. Om du använder horovodrun eller mpirun med bindningsparametrar kan det ge prestandavinster. Vi rekommenderar att processen som styr grafikprocessorn är kopplad till närmaste processorsockel. På Dell EMC PowerEdge C4140 är det optimala alternativet en --map-by-sockel. Du behöver inte ange något bindningsalternativ.

   Det kommer att se ut ungefär så här: 

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

3. Jobbet ska konfigureras så att en MPI-process fungerar på en GPU. Om det finns fler processer än antalet grafikprocessorer konkurrerar processerna om beräkningsresurserna och jobbet kan inte köras med höga prestanda. I ovanstående exempel ska x vara lika med antalet grafikprocessorer som ska användas.
   
    

4. Om du vill ställa in en process per grafikprocessor använder du tensorflow ConfigProto() så här:

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

5. Om du vill kontrollera antalet processer som använder grafikprocessorn kan du använda grafikprocessorns minnesförbrukning för "watch nvidia-smi". Det gör att du även kan se strömförbrukningen.

   
   Bild 1: Skärmbild av utdata för nvidia-smi-kommando som visar minnes-, ström- och GPU-användning.
   
   
    
6. Om data pipelinen är korrekt konfigurerad och mpirun-parametrarna är korrekta bör GPU-användningen konsekvent överstiga 90 % när modellutbildningen påbörjas. Tillfälliga nedgångar till 10–25 % användning är acceptabelt, men de ska vara sällsynta.
   
   
    
7. Ställ in batchstorleken så att grafikprocessorminnet är nästan fullt men begränsat så att minneskraven inte överskrids. Det är viktigt att överväga hur skalning av inlärningsfrekvens uppnås. Skalning av inlärningsfrekvensen är det begrepp enligt vilket inlärningshastigheten måste multipliceras med en faktor som är proportionerlig med antalet grafikprocessorer när antalet grafikprocessorer ökar. Det gör att modellen kan konvergera effektivt. På så sätt minskas antalet i/o-åtgärder genom att högsta antal möjliga bilder förs in i en grafikprocessor utan att modellkonvergensen skadas. Observera att skalning av inlärningsfrekvensen inte alltid är det bästa sättet att förbättra modellkonvergensen i en miljö med distribuerad arbetsbelastning.
   Så här kontrollerar du om skalning av inlärningsfrekvensen behövs:
   
   
   a) Träna modellen med och utan skalning av inlärningsfrekvensen i distribuerat läge.
   b) Om modellen utan skalning av inlärningsfrekvens fungerar bättre än modellen med skalning av inlärningsfrekvens behövs ingen skalning av inlärningsfrekvensen. 
   
   
   Vid konvergensinlärning är det inte alltid obligatoriskt att få in högsta möjliga antal avbildningar per batch. Det innebär ofta kompromisser mellan batchstorlek och konvergens (oavsett om skalning av inlärningsfrekvens används eller inte) som datateknikern måste kunna fastställa utifrån användningsfallet.
   Du kan återigen titta på användningen av grafikprocessorminnet med hjälp av "watch nvidia-smi".  I den här fallstudien användes inte skalning av inlärningsfrekvens eftersom den gav en bättre modell med AUC-värden och den lokala miniskalningen var 64. Uppvärmningsperioder är vanligt förekommande när skalning av inlärningsfrekvens används, vilket beskrivs i detta dokument.
   
    

8. Profilera dina jobb med hjälp av horovod tidslinje och nvprof för att se eventuella flaskhalsar som kan uppstå.  Flaskhalsar beror vanligen på något av följande:

   a) Tf-datapipeline är inte rätt konfigurerad och därför läggs mycket tid på att förbereda data medan acceleratorn är inaktiv. För att åtgärda detta måste tf pipeline korrigeras. 
   Läs artikeln om du vill ha information om hur du ställer in en tf data pipeline. 
   
   b) Kommunikationen kanske inte använder rätt struktur – kontrollera att du använder InfiniBand,så att infrastrukturanvändningen innefattar –x NCCL_DEBUG=INFO när du kör mpirun så här:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/kexnet.py --batch_size=128 --epochs=15
           eller använd horovodrun som innehåller bindningen –x.
   
   
    
9. Om distributionen ska implementeras korrekt måste grafikprocessorerna kommunicera effektivt med varandra. Om de inte kommunicerar på ett effektivt sätt orsakar det en flaskhals i kommunikationen. Du kontrollerar om de kommunicerar optimalt genom att använda följande process:
   
   Börja med att kontrollera hur grafikprocessorerna pratar med hjälp av bindningen -x enligt beskrivningen ovan i punkt 8b
   
   Om grafikprocessorerna pratar:
   1) i noden på ett optimalt sätt ser det ut ungefär så här:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00: 0[0] -> 1[1] via P2P/IPC
    
   2) utanför noden på ett optimalt sätt ser det ut ungefär så här:
   gpu028:149460:149495 [0] NCCL INFO Ring 01: 16 -> 0 [skicka] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01: 12 -> 8 [ta emot] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01: 4 –> 8 [ta emot] via NET/IB/0

• rätt bindningsalternativ finns
• utvärdering av flera processer som inte slösar mot GPU-minnet
• användning av en modern planeringsmetod
• profilering för att se att grafikprocessorerna används minst 80 % av tiden när jobbet körs
• med de senaste CUDA-relaterade biblioteken