Tip og trick til optimering af arbejdsgang med TF og Horovod på GPU'er

Artiklen er skrevet af Rakshith Vasudev og John Lockman - HPC AI Innovation Lab i oktober 2019


Indledning

Horovod er en distribueret, dyb læringsstruktur, der fremskynder indlæring på forskellige, dybe læringsrammer som f.eks. Tensorflow, Keras, Pytorch og MXNet. Det blev udviklet for at gøre det nemmere at oprette distribuerede, dybe læringsopgaver og fremskynde dem med TensorFlow. Horovod understøtter parallelisering af indlæringsprocessen. Den understøtter både dataparallelitet og modelparallelitet. Når et neuralt netværksindlæringsjob, der bruger Horovod, kører, kan disse almindelige tip bruges til at foretage fejlfinding og opnå forbedringer af ydeevnen.

Beskrivelse

Denne artikel bruger CheXNet som eksempel at referere til fra. CheXNet er en AI-radiologassistentmodel, der anvender DenseNet til at identificere op til 14 patologier ud fra et givent x-ray-patologibillede af patologien.

1. Den korrekte miljøkonfiguration kan spare en masse tid, når man forsøger at foretage fejlfinding af problemer med ydeevnen. Sørg for at anvende den dybe læringsstrukturs GPU-version. I dette eksempel bruges tensorflow-gpu, der er pakket af anaconda.
   
    

2. Brug af horovodrun eller mpirun med bindingsparametre kan give forbedringer af ydeevnen. Ideelt set skal processen, der styrer en GPU, bindes til den nærmeste CPU-sokkel. På Dell EMC PowerEdge C4140 er den optimale indstilling --map-by-socket. Det er ikke nødvendigt at angive en bindingsindstilling.

   Det ser nogenlunde sådan ud: 

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

3. Jobbet skal konfigureres således, at én MPI-proces fungerer på én GPU. Hvis der er flere processer end antallet af GPU'er, konkurrerer processerne om databehandlingsressourcerne og vil ikke kunne køre jobbet med en god ydeevne. I eksemplet ovenfor skal x være lig med antallet af GPU'er, der skal bruges.
   
    

4. For at indstille én proces pr. GPU skal du bruge tensorflow's ConfigProto() som følger:

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

5. For at kontrollere antallet af processer, der bruger GPU'en, kan GPU'ens hukommelsesforbrug "watch nvidia-smi" anvendes. Dette giver samtidig mulighed for at se strømforbruget.

   
   Figur 1: Skærmbillede af nvidia-smi-kommandooutput, der viser hukommelses-, strøm- og GPU-udnyttelse.
   
   
    
6. Hvis datapipeline er konfigureret korrekt, og mpirun-parametre er korrekte, bør GPU-udnyttelsen konstant overstige 90 %, når modeluddannelse begynder. Lejlighedsvise fald til 10-25 % udnyttelse er acceptable, men de bør ikke forekomme hyppigt.
   
   
    
7. Angiv batchstørrelsen, så GPU-hukommelsen er næsten fuld, men begrænset til ikke at overskride hukommelseskravene. Det er vigtigt at overveje, hvordan skaleringen af læringshastigheden udføres. Skaleringen af læringshastigheden er det koncept, efterhånden som antallet af GPU'er øges, hvormed læringshastigheden også skal multipliceres med en faktor, der er proportional med antallet af GPU'er. Dette gør modellen i stand til at konvergere effektivt. På denne måde reduceres antallet af i/o-handlinger ved at indsætte det maksimale antal mulige billeder på en GPU uden at gå på kompromis med modelkonvergensen. Det skal bemærkes, at en skalering af læringshastigheden ikke altid er den bedste løsning til at forbedre modelkonvergensen i en distribueret arbejdsbelastningsmiljø.
   Sådan kontrolleres det, om der er behov for en skalering af læringshastigheden:
   
   
   a) Træn modellen med og uden skalering af læringshastigheden i en distribueret tilstand.
   b) Hvis modellen uden skalering af læringshastigheden yder bedre end modellen med skalering af læringshastigheden, er der ikke behov for skalering af læringshastigheden. 
   
   
   Ved indlæring specifikt til konvergens er det ikke altid obligatorisk at indsætte det højest mulige antal billeder pr. batch. Det er som regel en afvejning mellem batchstørrelse og konvergens (hvad enten skalering af læringshastigheden bruges eller ej), at dataforskeren skal kunne træffe afgørelse baseret på deres brugssituation.
   Du kan igen se forbruget af GPU-hukommelse ved hjælp af "watch nvidia-smi".  I dette kundeeksempel blev skalering af læringshastighed ikke brugt, da det gav en bedre model med AUC-værdier & den lokale minibatch-størrelse var 64. Det er typisk at have opvarmningsepoker som beskrevet i denne artikel, når der anvendes skalering af læringshastigheden.
   
    

8. Lav en profil af dine job ved hjælp af en horovod-tidslinje og nvprof for at se eventuelle flaskehalse, der måtte opstå.  Flaskehalsen skyldes højst sandsynligt et af følgende:

   a) Tf-datapipeline er ikke konfigureret korrekt, og derfor bruges der meget tid på at forberede dataene, mens acceleratoren er inaktiv. For at løse dette skal tf pipeline rettes. 
   Læs denne artikel for at få oplysninger om, hvordan man konfigurerer en tf-datapipeline. 
   
   b) Kommunikationen anvender muligvis ikke den korrekte struktur – sørg for at bruge InfiniBandtil at se strukturforbruget omfatte –x NCCL_DEBUG=INFO, når du kører mpirun på følgende vis:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py --batch_size=128 --epochs=15
           eller bruge horovodrun, som indeholder –x-bindingen.
   
   
    
9. For at kunne implementere distributionen korrekt skal GPU'erne kommunikere effektivt med hinanden. Hvis de ikke kommunikerer effektivt, opstår der en kommunikationsflaskehals. For at kontrollere, om de kommunikerer optimalt, anvendes følgende fremgangsmåde:
   
   Se først, hvordan GPU'erne taler sammen ved at bruge -x-bindingen som vist ovenfor i punkt 8b,
   
   hvis GPU'erne taler:
   1) I knudepunktet på en optimal måde vil se nogenlunde således ud:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00: 0[0] - > 1 [1] via P2P/IPC
    
   2) uden for knudepunktet på en optimal måde vil se nogenlunde således ud:
   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 [modtag] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01: 4 -> 8 [modtag] via NET/IB/0

• de korrekte bindingsindstillinger er konfigureret,
• ved at vurdere flere processer, der ikke spilder GPU-hukommelse,
• ved at anvende en moderne pipelinetilgang
• ved at opstille en profil for at se, om GPU'erne anvendes mindst 80 % af den tid, jobbet kører.
• ved hjælp af de nyeste CUDA-relaterede biblioteker