Tipps und Tricks zum Optimieren des Workflows mit TF und Horovod auf GPUs

Der Artikel wurde von Rakshith Vasudev & John Lockman, HPC AI Innovation Lab, im Oktober 2019 verfasst.


Einführung

Horovod ist ein verteiltes Deep-Learning-Framework, das zur Beschleunigung des Trainings verschiedener Deep-Learning-Frameworks wie Tensorflow, Keras, Pytorch und MXNet eingesetzt wird. Es wurde entwickelt, um die Einrichtung verteilter Deep-Learning-Projekte zu vereinfachen und sie mit TensorFlow zu beschleunigen. Horovod unterstützt die Parallelisierung des Trainingsprozesses. Es unterstützt sowohl Datenparallelität als auch Modellparallelität. Bei der Ausführung eines Trainingsjobs für neuronale Netzwerke mit Horovod können diese gängigen Tipps zum Debuggen und zur Verbesserung der Performance verwendet werden.

Beschreibung

In diesem Artikel wird CheXNet als Referenzbeispiel verwendet. Bei CheXNet handelt es sich um ein KI-Assistentenmodell für Radiologen, das DenseNet verwendet, um bis zu 14 Pathologien auf einem Thorax-Röntgenbild zu identifizieren.

1. Das richtige Umgebungs-Setup kann viel Zeit beim Debuggen von Performanceproblemen sparen, Stellen Sie sicher, dass Sie die GPU-Version des Deep Learning Frameworks verwenden. In diesem Beispiel wird die Tensorflow-GPU im Paket von Anaconda verwendet.
   
    

2. Die Verwendung von horovodrun oder mpirun mit Bindungsparametern kann zu Performancesteigerungen führen. Idealerweise sollte der Prozess zur Steuerung einer GPU an den nächstgelegenen CPU-Sockel gebunden sein. Auf einem Dell EMC PowerEdge C4140 wäre die optimale Option „--map-by socket“. Es ist nicht erforderlich, eine Bindungsoption anzugeben.

   Der Befehl ähnelt dem nachfolgenden Beispiel: 

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

3. Der Job sollte so eingerichtet werden, dass ein MPI-Prozess pro GPU ausgeführt wird. Wenn mehr Prozesse als GPUs vorhanden sind, konkurrieren die Prozesse um Rechenressourcen und können den Job nicht mit einer guten Performance ausführen. Im obigen Beispiel sollte x der Anzahl der zu verwendenden GPUs entsprechen.
   
    

4. Um einen Prozess pro GPU festzulegen, verwenden Sie ConfigProto() von Tensorflow wie folgt:

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

5. Um die Anzahl der ausgeführten Prozesse auf der GPU zu überprüfen, kann der Speicherverbrauch der GPU über watch nvidia-smi überprüft werden. Hiermit kann auch der Stromverbrauch abgerufen werden.

   
   Abbildung 1: Screenshot der nvidia-smi-Befehlsausgabe mit Anzeige der Speicher-, Strom- und GPU-Auslastung
   
   
    
6. Wenn die Daten-Pipeline ordnungsgemäß eingerichtet ist und die mpirun-Parameter korrekt sind, sollte die GPU-Auslastung konsistent über 90 % liegen, sobald das Modelltraining beginnt. Gelegentliche Einbrüche auf 10 bis 25 % Auslastung sind akzeptabel, sollten aber selten auftreten.
   
   
    
7. Legen Sie die Batch-Größe so fest, dass der GPU-Speicher fast voll ist, aber die Speicheranforderungen nicht überschritten werden. Es ist wichtig, zu berücksichtigen, wie die Skalierung der Lernrate erreicht wird. Der Skalierung der Lernrate liegt das Konzept zugrunde, dass bei steigender Anzahl von GPUs auch die Lernrate mit einem Faktor multipliziert werden muss, der proportional zur Anzahl der GPUs ist. Auf diese Weise kann das Modell effektiv konvergieren. Dabei wird die Anzahl der E/A-Vorgänge reduziert, indem die maximale Anzahl möglicher Bilder auf einer GPU untergebracht wird, ohne die Konvergenz des Modells zu beeinträchtigen. Es ist zu beachten, dass die Skalierung der Lernrate nicht immer die beste Lösung ist, um die Modellkonvergenz in einer Umgebung mit verteilten Workloads zu verbessern.
   So überprüfen Sie, ob eine Skalierung der Lernrate erforderlich ist:
   
   
   a) Trainieren Sie das Modell mit und ohne Skalierung der Lernrate in einem verteilten Modus.
   b) Wenn das Modell ohne Skalierung der Lernrate besser als das Modell mit Skalierung der Lernrate abschneidet, ist eine Skalierung der Lernrate nicht erforderlich. 
   
   
   Insbesondere beim Training für Konvergenz ist es nicht immer eine zwingende Regel, die höchstmögliche Anzahl von Bildern pro Batch unterzubringen. In der Regel muss ein Kompromiss zwischen Batch-Größe und Konvergenz (mit oder ohne Skalierung der Lernrate) eingegangen werden, was je nach Anwendungsfall entschieden werden muss.
   Wie bereits erwähnt, kann der Speicherverbrauch der GPUs über watch nvidia-smi angezeigt werden.  In dieser Fallstudie wurde die Skalierung der Lernrate nicht verwendet, da mit AUC-Werten und einer lokalen Minibatch-Größe von 64 ein besseres Modell erzielt wurde. Wenn die Skalierung der Lernrate verwendet wird, gibt es typischerweise Aufwärmzeiträume, wie in diesem Whitepaper beschrieben.
   
    

8. Erstellen Sie Profile Ihre Jobs mithilfe einer Horovod-Zeitachse und verwenden Sie nvprof, um mögliche Engpässe aufzudecken.  Ein möglicher Engpass wird wahrscheinlich aus einem der folgenden Gründe auftreten:

   a) Die TF-Daten-Pipeline ist nicht gut eingerichtet und daher wird viel Zeit für die Vorbereitung der Daten aufgewendet, während sich der Accelerator im Leerlauf befindet. Um dies zu beheben, muss die TF-Pipeline korrigiert werden. 
   In diesem Artikel finden Sie Informationen zum Einrichten einer TF-Daten-Pipeline. 
   
   b) Für die Kommunikation wird möglicherweise nicht der richtige Fabric verwendet – Stellen Sie sicher, dass Sie InfiniBand nutzen. Um Informationen zur Fabric-Nutzung zu erhalten, schließen Sie -x NCCL_DEBUG=INFO ein, wenn Sie mpirun ausführen, z. B.:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py  --batch_size=128   --epochs=15
           oder verwenden Sie horovodrun, wo die „-x“-Bindung bereits enthalten ist.
   
   
    
9. Um die Verteilung richtig zu implementieren, müssen die GPUs effektiv miteinander kommunizieren. Wenn sie nicht effektiv kommunizieren, führt dies zu einem Kommunikationsengpass. Verwenden Sie den folgenden Prozess, um zu überprüfen, ob die GPUs optimal kommunizieren:
   
   Überprüfen Sie zunächst, wie die GPUs kommunizieren, indem Sie die oben in Punkt 8b genannte -x-Bindung verwenden.
   
   Wenn die GPUs kommunizieren:
   1) Innerhalb des Nodes sieht eine optimale Kommunikation ähnlich wie folgt aus:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00 : 0[0] -> 1[1] via P2P/IPC
    
   2) Außerhalb des Nodes sieht eine optimale Kommunikation ähnlich wie folgt aus:
   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

• Verwendung der richtigen Bindungsoptionen
• Beurteilung mehrerer Prozesse, die keinen GPU-Speicher verschwenden
• Verwendung eines modernen Pipelining-Ansatzes
• Profilerstellung, um zu überprüfen, dass die GPUs mindestens 80 % der Zeit, in der der Job ausgeführt wird, verwendet werden
• Einsatz der neuesten CUDA-bezogenen Bibliotheken