Suggerimenti e trucchi per ottimizzare il flusso di lavoro con TF e Horovod su GPU

Questo articolo è stato scritto da Rakshith Vasudev e John Lockman - HPC AI Innovation Lab, nell'ottobre 2019


Introduzione

Horovod è un framework di apprendimento approfondito distribuito per accelerare l'addestramento su diversi framework di apprendimento approfondito, come Tensorflow, Keras, Pytorch e MXNet. È stato sviluppato per semplificare la definizione di progetti di apprendimento approfondito distribuiti e accelerarli con TensorFlow. Horovod supporta la parallelizzazione del processo di addestramento. Supporta sia il parallelismo dei dati che il parallelismo dei modelli. Quando è in esecuzione un processo di addestramento di una rete neurale che utilizza horovod, è possibile utilizzare i seguenti suggerimenti generali per eseguire il debug e vedere miglioramenti nelle prestazioni.

Descrizione

Questo articolo utilizza CheXNet come esempio da cui fare riferimento. CheXNet è un modello di assistente radilogo di intelligenza artificiale che utilizza DenseNet per identificare fino a 14 patologie da una data immagine x-ray toracica.

1. La corretta configurazione dell'ambiente operativo consente di risparmiare molto tempo quando si tenta di eseguire il debug dei problemi di prestazioni. Assicurarsi di utilizzare la versione GPU del framework di deep learning. In questo esempio, viene utilizzato tensorflow-gpu in pacchetto da anaconda.
   
    

2. L'utilizzo di horovodrun o mpirun con parametri binding può generare miglioramenti delle prestazioni. Idealmente, il processo che controlla una GPU dovrebbe essere associato al socket CPU più vicino. Su Dell EMC PowerEdge C4140, l'opzione ottimale è --map-by socket. Non è necessario specificare alcuna opzione di binding.

   Il comando sarà simile a quanto segue: 

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

3. Il processo deve essere configurato in modo che un processo MPI funzioni su una GPU. Se il numero di processi è superiore al numero di GPU disponibili, i processi competono per le risorse di calcolo disponibili e non sono in grado di eseguire l'operazione con prestazioni ottimali. Nell'esempio precedente, x dovrebbe essere uguale al numero di GPU da utilizzare.
   
    

4. Per impostare un processo per GPU, utilizzare ConfigProto() di tensorflow() come segue:

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

5. Per controllare il numero di processi che utilizzano la GPU, è possibile utilizzare il consumo di memoria della GPU "watch nvidia-smi". Ciò consente anche di visualizzare il consumo energetico.

   
   Figura 1. Schermata dell'output del comando nvidia-smi che mostra l'utilizzo della memoria, dell'alimentazione e della GPU.
   
   
    
6. Se la pipeline di dati è configurata correttamente e i parametri mpirun sono corretti, l'utilizzo della GPU deve superare costantemente il 90% una volta avviato l'addestramento del modello. Sono accettabili cali occasionali al 10-25% di utilizzo, ma tuttavia non dovrebbero essere frequenti.
   
   
    
7. Impostare le dimensioni batch in modo che la memoria della GPU sia quasi piena, ma limitata in modo che i requisiti di memoria non vengano superati. È importante tenere in considerazione il modo in cui viene eseguito il ridimensionamento della learning rate (velocità di apprendimento). Il ridimensionamento della learning rate è il concetto per cui, con l'aumentare del numero di GPU disponibili, la learning rate deve essere anch'essa moltiplicata per un fattore proporzionale al numero di GPU. Ciò consente al modello di convergere efficacemente. In questo modo, il numero di operazioni I/O viene ridotto regolando il numero massimo di immagini su una GPU senza compromettere la convergenza del modello. Tenere presente che il ridimensionamento della learning rate non sempre è la soluzione ottimale per migliorare la convergenza del modello in una configurazione distribuita del carico di lavoro.
   Per verificare se è necessario il ridimensionamento della learning rate:
   
   
   a) Addestrare il modello con e senza ridimensionamento della learning rate in modalità distribuita.
   b) Se il modello senza ridimensionamento della learning rate offre prestazioni migliori rispetto a quello con ridimensionamento della learning rate, non è necessario il ridimensionamento della learning rate. 
   
   
   Quando si esegue l'addestramento per la convergenza nello specifico, non è sempre obbligatorio seguire la regola di fornire il più alto numero possibile di immagini per batch. Generalmente, esiste una soluzione di un compromesso tra dimensioni batch e convergenza (se il ridimensionamento della learning rate viene utilizzato o meno) che l'ingegnere dei dati deve trovare sulla base del proprio caso di utilizzo.
   Anche in questo caso, è possibile osservare l'utilizzo della memoria GPU utilizzando "watch nvidia-smi".  In questo caso di studio, il dimensionamento della learning rate non è stato utilizzato in quanto ha prodotto un modello migliore con valori AUC e la dimensione minibatch locale era 64. Come viene descritto in questo studio, è tipico avere "momenti di surriscaldamento" quando si utilizza il ridimensionamento della learning rate.
   
    

8. Profilare i job utilizzando la tempistica horovod e nvprof per visualizzare eventuali colli di bottiglia che possono verificarsi.  È molto probabile che questi colli di bottiglia siano dovuti a una delle seguenti cause:

   a) La pipeline di dati non è configurata correttamente e quindi viene speso molto tempo per preparare i dati mentre l'acceleratore è inattivo. Per risolvere questo problema, è necessario correggere la pipeline. 
   Leggere questo articolo per informazioni su come configurare "tf data pipeline". 
   
   b) La comunicazione potrebbe non utilizzare il fabric corretto: accertarsi di utilizzare InfiniBand, per visualizzare l'utilizzo della fabric includere –x NCCL_DEBUG=INFO durante l'esecuzione di mpirun come segue:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py --batch_size=128 --epocas=15
           o utilizzare horovodrun che include l'associazione –x.
   
   
    
9. Per implementare correttamente la distribuzione, le GPU devono comunicare efficacemente tra loro. Se non comunicano in modo efficace, si viene a creare un collo di bottiglia. Per verificare se le GPU comunicano in modo ottimale, utilizzare il seguente processo:
   
   In primo luogo, vedere in che modo le GPU parlano utilizzando l'associazione -x, come mostrato sopra nel punto 8b
   
   Se le GPU parlano:
   1) All'interno del nodo la situazione ottimale apparirà come segue:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00: 0[0] -> 1[1] tramite P2P/IPC
    
   2) All'esterno del nodo la situazione ottimale apparirà come segue:
   gpu028:149460:149495 [0] NCCL INFO Ring 01 : 16 -> 0 [send] tramite NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01 : 12 -> 8 [receive] tramite NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01 : 4 -> 8 [receive] tramite NET/IB/0

• Corretta impostazione delle opzioni di binding
• Valutazione di più processi che non sprechino la memoria della GPU
• Utilizzo di un approccio di pipelining moderno
• Esecuzione di profiling per vedere se le GPU vengono utilizzate per almeno l'80% del tempo in cui il processo viene eseguito
• utilizzando le librerie CUDA più recenti correlate