Tips en trucs voor het optimaliseren van de workflow met TF en Horovod op GPU's

Dit artikel is geschreven door Rakshith Vasudev en John Lockman - HPC AI Innovation Lab in oktober 2019


Inleiding

Horovod is een gedistribueerd deeplearning-framework om training over verschillende deeplearning-frameworks zoals Tensorflow, Keras, Pytorch en MXNet te versnellen. Het is ontwikkeld om het gemakkelijker te maken gedistribueerde deep learning-projecten op te zetten en deze te versnellen met TensorFlow. Horovod ondersteunt parallelle uitvoering van het trainingsproces. Het ondersteunt zowel dataparallellisme als modelparallellisme. Wanneer een trainingstaak van een neuraal netwerk die gebruikmaakt van horovod wordt uitgevoerd, kunnen deze veelvoorkomende tips worden gebruikt om fouten op te sporen en de prestaties te verbeteren.

Beschrijving

Dit artikel gebruikt CheXNet als voorbeeld om naar te verwijzen. CheXNet is een AI-radioloogassistent model dat gebruikmaakt van DenseNet om maximaal 14 ziektebeelden te identificeren van een bepaalde röntgenfoto op de borst.

1. De juiste omgevingsinstellingen kunnen veel tijd besparen bij het opsporen van prestatieproblemen. Zorg ervoor dat de GPU-versie van het deeplearing-framework wordt gebruikt. In dit voorbeeld wordt tensorflow-gpu verpakt door annda gebruikt.
   
    

2. Het gebruik van horovodrun of mpirun met bindingsparameters kan prestatiewinst opleveren. Idealiter moet het proces dat een GPU stuurt, gebonden zijn aan de dichtstbijzijnde CPU-socket. Op de Dell EMC PowerEdge C4140 zou de optimale optie --map-by socket zijn. Het is niet nodig om een bindingsoptie op te geven.

   Dit ziet er ongeveer zo uit: 

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

3. De taak moet zodanig worden ingesteld dat één MPI-proces op één GPU werkt. Als er meer processen zijn dan het aantal GPU's, zullen de processen concurreren om rekenbronnen en zal de uitvoering van de taak niet optimaal zijn. In het bovenstaand voorbeeld moet x gelijk zijn aan het aantal te gebruiken GPU's.
   
    

4. Als u één proces per GPU wilt instellen, gebruikt u de ConfigProto() van tensorflow als:

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

5. Om het aantal processen met behulp van de GPU te controleren, kan het geheugenverbruik van GPU 'watch nvidia-smi' worden gebruikt. Hiermee kunt u ook het energieverbruik zien.

   
   Afbeelding 1: Schermafbeelding van nvidia-smi-opdrachtuitvoer met geheugen, voeding en GPU-gebruik.
   
   
    
6. Als de datapijplijn correct is ingesteld en de mpirun-parameters correct zijn, moet het GPU-gebruik consistent hoger zijn dan 90% zodra de modeltraining begint. Af en toe een daling tot 10-25% in het gebruik is acceptabel, maar dit mag niet te vaak voorkomen.
   
   
    
7. Stel de batchgrootte zodanig in dat het GPU-geheugen bijna vol maar wel beperkt is, zodat de geheugenvereisten niet worden overschreden. Het is belangrijk om rekening te houden met de wijze waarop de schaal van het leertempo wordt verwezenlijkt. Het schalen van het leertempo is het concept dat zegt dat naarmate het aantal GPU's stijgt, het leertempo ook moet worden vermenigvuldigd met een factor evenredig met het aantal GPU's. Hierdoor kan het model effectief worden geconvergeerd. Op deze manier wordt het aantal i/o-bewerkingen gereduceerd door het maximale aantal mogelijke afbeeldingen per GPU aan te passen zonder de modelconvergentie in gevaar te brengen. Er moet worden opgemerkt dat het schalen van het leertempo niet altijd de beste oplossing is om de modelconvergentie te verbeteren in het geval van een gedistribueerde werklast.
   U kunt als volgt controleren of schaling van het leertempo nodig is:
   
   
   a) Train het model met en zonder leertempo-schaling in een gedistribueerde modus.
   b) Als het model zonder leertempo-schaling beter presteert dan het model met leertempo-schaling, is leertempo-schaling niet nodig. 
   
   
   Bij het trainen van met name convergentie is het niet altijd een verplichte regel om het hoogst mogelijke aantal afbeeldingen per batch te kiezen. Er is meestal een balans tussen batchgrootte en convergentie (of leertempo-schaling nu wel of niet wordt gebruikt) waarover de data-scientist moeten kunnen beslissen op basis van hun scenario.
   Nogmaals, u kunt het gebruik van GPU-geheugen bekijken met behulp van 'watch nvidia-smi'.  In dit casestudy werd schaling van het leertempo niet gebruikt omdat het een beter model met AUC-waarden opleverde en de lokale minibatch-grootte 64 was. Het is gebruikelijk om een opwarmperiode te hanteren, zoals beschreven in dit artikel, bij gebruik van leertempo-schaling.
   
    

8. Profileer uw taken met behulp van de horovod-tijdlijn en nvprof om eventuele knelpunten te bekijken die kunnen optreden.  Meer dan waarschijnlijk is het knelpunt te wijten aan een van de volgende punten:

   a) De TF-datapijplijn is niet goed ingesteld en daarom wordt veel tijd besteed aan het voorbereiden van de data terwijl de accelerator inactief is. Om dit op te lossen, moet de tf-pipeline worden gecorrigeerd. 
   Lees dit artikel voor informatie over het instellen van een tf data pipeline. 
   
   b) De communicatie gebruikt mogelijk niet de juiste fabric – zorg ervoor dat u InfiniBandgebruikt, om te zien dat het fabric-gebruik –x NCCL_DEBUG=INFO is tijdens het uitvoeren van mpirun zoals:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py --batch_size=128 --epochs=15
           of gebruik horovodrun die de –x-binding bevat.
   
   
    
9. Voor een juiste implementatie van distributie moeten de GPU's effectief met elkaar communiceren. Als ze niet effectief communiceren, leidt dit tot een knelpunt in de communicatie. Met het volgende proces kunt u controleren of ze optimaal communiceren:
   
   Zie eerst hoe GPU's praten met behulp van de -x-binding zoals hierboven weergegeven in punt 8b
   
   Als GPU's praten:
   1) Binnen het knooppunt op een optimale manier, ziet dit er ongeveer zo uit:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00: 0[0] -> 1[1] via P2P/IPC
    
   2) Buiten het knooppunt op een optimale manier, ziet dit er ongeveer zo uit:
   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 [ontvangen] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01: 4 -> 8 [ontvangen] via NET/IB/0

• de juiste bindingsopties zijn aanwezig;
• het beoordelen van meerdere processen verspilt geen GPU-geheugen;
• gebruik van een moderne pipeline-benadering;
• profilering om ervoor te zorgen dat GPU's ten minste 80% van de tijd worden gebruikt wanneer de taak wordt uitgevoerd;
• met behulp van de nieuwste CUDA-gerelateerde bibliotheken