Sugerencias y trucos para optimizar el flujo de trabajo con TF y Horovod en las GPU

Artículo escrito por Rakshith Vasudev y John Lockman: Laboratorio de innovación de IA de HPC en octubre del 2019


Introducción

Horovod es una infraestructura de aprendizaje profundo distribuido para acelerar la capacitación en diferentes infraestructuras de aprendizaje profundo, como Tensorflow, Keras, Pytorch y MXNet. Se desarrolló para que sea más fácil establecer proyectos de aprendizaje profundo distribuidos y acelerarlos con TensorFlow. Horovod admite la paralelización del proceso de capacitación. Admite el paralelismo de datos y el paralelismo de modelos. Cuando se ejecuta un trabajo de capacitación de red neuronal que utiliza horovod, se pueden usar estas sugerencias comunes para depurar y ver mejoras en el rendimiento.

Descripción

En este artículo, se utiliza CheXNet como un ejemplo de referencia. CheXNet es un modelo de asistente de radiología de IA que utiliza DenseNet para identificar hasta 14 patologías desde una imagen determinada de rayos X de tórax.

1. La configuración correcta del entorno puede ahorrar una gran cantidad de tiempo cuando se intenta depurar problemas de rendimiento. Asegúrese de que se esté utilizando la versión de GPU del marco de aprendizaje profundo. En este ejemplo, se utiliza tensorflow-gpu empaquetado por anaconda.
   
    

2. Mediante horovodrun o mpirun con parámetros de vinculación, se pueden obtener ganancias de rendimiento. Idealmente, el proceso para controlar una GPU se debe vincular al conector de CPU más cercano. En Dell EMC PowerEdge C4140, la opción óptima sería --map-by socket. No hay necesidad de especificar una opción de vinculación.

   Tendrá un aspecto similar al siguiente: 

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

3. El trabajo se debe configurar de modo que un proceso MPI funcione en una GPU. Si hay más procesos que la cantidad de GPU, los procesos competirán por los recursos de procesamiento y no podrán ejecutar el trabajo con un buen rendimiento. En el ejemplo anterior, x debe ser igual a la cantidad de GPU que se utilizarán.
   
    

4. Para establecer un proceso por GPU, utilice el comando ConfigProto() de tensorflow de la siguiente manera:

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

5. Para comprobar la cantidad de procesos mediante la GPU, se puede usar el comando de consumo de memoria de GPU “watch nvidia-smi”. Esto también permite ver el consumo de energía.

   
   Figura 1: Captura de pantalla de la salida del comando nvidia-smi, en la cual se muestra el consumo de memoria, alimentación y GPU.
   
   
    
6. Si el pipeline de datos está configurado correctamente y los parámetros mpirun son correctos, la utilización de la GPU debe superar el 90 % de forma consistente una vez que comience la capacitación del modelo. Se admiten disminuciones ocasionales del 10 al 25 % de utilización, pero deben ser poco frecuentes.
   
   
    
7. Configure el tamaño del lote para que la memoria GPU esté casi llena, pero limitada, a fin de que no se superen los requisitos de memoria. Es importante tener en cuenta la manera en que se realiza el escalamiento de la tasa de aprendizaje. El escalamiento de la tasa de aprendizaje es el concepto según el cual, a medida que aumenta la cantidad de GPU, la tasa de aprendizaje también se debe multiplicar por un factor proporcional a la cantidad de GPU. Esto permite que el modelo realice una convergencia eficaz. De esta manera, se reduce la cantidad de operaciones de E/S mediante un ajuste en la cantidad máxima de imágenes posibles en una GPU sin comprometer la convergencia del modelo. Se debe tener en cuenta que el escalamiento de tasa de aprendizaje no siempre es la mejor solución para mejorar la convergencia de modelos en una configuración de carga de trabajo distribuida.
   Para comprobar si es necesario un escalamiento de tasa de aprendizaje:
   
   
   a)    Capacite el modelo con y sin escalamiento de tasa de aprendizaje en un modo distribuido.
   b) Si el modelo sin escalamiento de tasa de aprendizaje funciona mejor que el modelo con escalamiento de tasa de aprendizaje, no se necesita el escalamiento de la tasa de aprendizaje. 
   
   
   Cuando se capacita para una convergencia en particular, no siempre es obligación ajustar a la mayor cantidad posible de imágenes por lote. Por lo general, hay un intercambio entre el tamaño del lote y la convergencia (si se utiliza o no el escalamiento de tasa de aprendizaje), el cual el científico de datos debe decidir según su caso de uso.
   Nuevamente, puede observar el consumo de memoria de GPU mediante “watch nvidia-smi”.  En este estudio de caso, el escalamiento de tasa de aprendizaje no se utilizó, ya que generaba un modelo mejor con valores de AUC y el tamaño local de minibatch era de 64. Cuando se utiliza el escalamiento de tasa de aprendizaje, es común tener períodos de preparación, como se describe en este informe.
   
    

8. Cree un perfil de sus trabajos mediante horovod timeline y nvprof para ver los cuellos de botella que puedan ocurrir.  Lo más probable es que el cuello de botella se deba a uno de los siguientes motivos:

   a)    El pipeline de datos de Tf no está bien configurado y, por lo tanto, se dedica una gran cantidad de tiempo a la preparación de los datos mientras el acelerador está inactivo. Para solucionar esto, se debe corregir el pipeline de tf. 
   Lea este artículo para obtener información sobre cómo configurar “Tf data pipeline”. 
   
   b)    Es posible que la comunicación no utilice la red fabric correcta: asegúrese de que utiliza InfiniBand para ver el uso de la red fabric, incluido –x NCCL_DEBUG=INFO mientras ejecuta mpirun de la siguiente manera:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py  --batch_size=128   --epochs=15
           o use horovodrun que incluye la vinculación –x.
   
   
    
9. Para implementar correctamente la distribución, las GPU deben comunicarse entre sí de manera eficaz. Si no se comunican de manera eficaz, esto provoca un cuello de botella de comunicación. Para comprobar si se están comunicando de manera óptima, utilice el siguiente proceso:
   
   En primer lugar, vea cómo se comunican las GPU mediante la vinculación -x, como se muestra anteriormente en el punto 8b
   
   Si las GPU se comunican:
   1) Dentro del nodo de forma óptima, entonces se verá algo similar a lo siguiente:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00 : 0[0] -> 1[1] via P2P/IPC
    
   2) Fuera del nodo de forma óptima, entonces se verá algo similar a lo siguiente:
   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

• se aplican las opciones de vinculación correctas,
• se evalúan varios procesos que no desperdician la memoria de GPU,
• se utiliza un enfoque moderno de canalización,
• se generan perfiles para ver si se utilizan las GPU al menos el 80 % de las veces en las que se ejecuta el trabajo,
• mediante las bibliotecas de CUDA más recientes relacionadas