5 consejos para entrenamiento multi-GPU con Keras

• Enero 21, 2018
• Vasilis Vryniotis
• . 1 comentario

Deep Learning (la palabra de moda favorita de finales de 2010 junto con blockchain / bitcoin y Data Science / Machine Learning) nos ha permitido hacer algunas cosas realmente geniales en los últimos años. Además de los avances en algoritmos (que ciertamente se basan en ideas ya conocidas desde la década de 1990, también conocida como "era de la minería de datos"), las principales razones de su éxito se pueden atribuir a la disponibilidad de grandes conjuntos de datos gratuitos, la introducción de bibliotecas de código abierto y El uso de GPU. En esta publicación de blog me centraré en los dos últimos y compartiré con ustedes algunos consejos que aprendí de la manera más difícil.

¿Por qué TensorFlow & Keras?

TensorFlow es una biblioteca de aprendizaje profundo muy popular desarrollada por Google que te permite crear prototipos de redes complejas rápidamente. Viene con muchas características interesantes, como la diferenciación automática (que le ahorra estimar / codificar los gradientes de las funciones de costo) y el soporte de GPU (que le permite obtener fácilmente una mejora de velocidad de 200x utilizando hardware decente). Además, ofrece una interfaz Python, lo que significa que puede crear prototipos rápidamente sin necesidad de escribir código C o CUDA. Es cierto que hay muchos otros marcos que se pueden usar en lugar de TensorFlow, como Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK, etc., pero todo se reduce a su caso de uso y su preferencia personal.

Pero ¿por qué Keras? Para mí, usar TF directamente es como hacer Machine Learning con Numpy. Sí, es factible y de vez en cuando debe hacerlo (especialmente si escribe capas personalizadas / funciones de pérdida), pero ¿realmente desea escribir código que describa las redes complejas como una serie de operaciones vectoriales (sí, lo sé Hay métodos de nivel superior en TF pero no son tan geniales como Keras)? Además, ¿qué pasa si desea pasar a una biblioteca diferente? Bueno, entonces probablemente necesites reescribir el código, lo cual apesta. Ta ta taaa, Keras al rescate! Keras le permite describir sus redes utilizando conceptos de alto nivel y escribir código que es independiente del backend, lo que significa que puede ejecutar las redes en diferentes bibliotecas de aprendizaje profundo. Pocas cosas que amo de Keras es que está bien escrito, tiene una arquitectura orientada a objetos, es fácil de contribuir y tiene una comunidad amigable. Si te gusta, da las gracias a François Chollet para desarrollarlo y abrirlo de fuente abierta.

Consejos y trucos para la capacitación en múltiples GPU

Sin más preámbulos, pasemos a algunos consejos sobre cómo aprovechar al máximo el entrenamiento de GPU en Keras y un par de trucos que debe tener en cuenta:

1. El entrenamiento multi-GPU no es automático

El entrenamiento de modelos en GPU con Keras y Tensorflow es perfecto. Si tiene una tarjeta NVIDIA y ha instalado CUDA, las bibliotecas la detectarán automáticamente y la usarán para entrenamiento. ¡Muy guay! Pero, ¿qué pasa si eres un mocoso mimado y tienes varias GPU? Bueno, desafortunadamente, tendrás que trabajar un poco para lograr el entrenamiento de múltiples GPU.

Existen múltiples formas de paralelizar una red dependiendo de lo que desea lograr, pero los dos enfoques principales son la paralelización de modelo y datos. El primero puede ayudarlo si su modelo es demasiado complejo para caber en una sola GPU, mientras que el segundo lo ayuda cuando desea acelerar la ejecución. Por lo general, cuando las personas hablan sobre entrenamiento multi-GPU se refieren a lo último. Solía ​​ser más difícil de lograr, pero afortunadamente Keras ha incluido recientemente un método de utilidad llamado mutli_gpu_modelo lo que facilita el entrenamiento / predicciones paralelas (actualmente solo está disponible con TF back-end). La idea principal es que pase su modelo a través del método y se copie en diferentes GPU. La entrada original se divide en fragmentos que se alimentan a las distintas GPU y luego se agregan como una sola salida. Este método se puede utilizar para lograr predicciones y entrenamiento paralelo, sin embargo, tenga en cuenta que para el entrenamiento no se escala linealmente con la cantidad de GPU debido a la sincronización requerida.

2. Presta atención al tamaño del lote

Cuando realice un entrenamiento con múltiples GPU, preste atención al tamaño del lote, ya que tiene múltiples efectos sobre la velocidad / memoria, la convergencia de su modelo y, si no tiene cuidado, ¡podría corromper los pesos de su modelo!

Velocidad / memoria: Obviamente, cuanto mayor sea el lote, más rápido será el entrenamiento / predicción. Esto se debe a que hay una sobrecarga al introducir y extraer datos de las GPU, por lo que los lotes pequeños tienen más sobrecarga. Por otro lado, cuanto mayor sea el lote, más memoria necesitará en la GPU. Especialmente durante el entrenamiento, las entradas de cada capa se guardan en la memoria, ya que se requieren en el paso de propagación hacia atrás, por lo que aumentar demasiado el tamaño del lote puede provocar errores de falta de memoria.

Convergencia: Si utiliza el Decente degradado estocástico (SGD) o algunas de sus variantes para entrenar su modelo, debe tener en cuenta que el tamaño del lote puede afectar la capacidad de su red para converger y generalizarse. Los tamaños de lote típicos en muchos problemas de visión por computadora están entre 32-512 ejemplos. Como Keskar et al. En otras palabras, "se ha observado en la práctica que cuando se usa un lote más grande (que 512) hay una degradación en la calidad del modelo, medida por su capacidad de generalizar". Tenga en cuenta que otros optimizadores diferentes tienen propiedades diferentes y las técnicas especializadas de optimización distribuida pueden ayudar con el problema. Si está interesado en los detalles matemáticos, le recomiendo leer la Tesis de Joeri Hermans "Sobre aprendizaje profundo escalable y descenso de gradiente en paralelo.

Corrompiendo los pesos: Este es un detalle técnico desagradable que puede tener resultados devastadores. Cuando realiza un entrenamiento con múltiples GPU, es importante alimentar a todas las GPU con datos. Puede suceder que el último lote de su época tenga menos datos de los definidos (porque el tamaño de su conjunto de datos no se puede dividir exactamente por el tamaño de su lote). Esto puede hacer que algunas GPU no reciban ningún dato durante el último paso. Desafortunadamente, algunas capas de Keras, sobre todo la capa de normalización de lotes, no pueden hacer frente a eso, lo que lleva a que aparezcan valores nanométricos en los pesos (la media de ejecución y la varianza en la capa BN). Para hacer las cosas aún más desagradables, uno no observará el problema durante el entrenamiento (mientras que la fase de aprendizaje es 1) porque la capa específica usa la media / varianza del lote en las estimaciones. Sin embargo, durante las predicciones (fase de aprendizaje establecida en 0), se utiliza la media / varianza de ejecución, que en nuestro caso puede convertirse en nan y conducir a malos resultados. Así que hazte un favor y siempre asegúrate de que el tamaño de tu lote sea fijo cuando realices un entrenamiento con múltiples GPU. Dos formas simples de lograr esto es rechazando lotes que no coinciden con el tamaño predefinido o repitiendo los registros dentro del lote hasta que alcance el tamaño predefinido. Por último, pero no menos importante, tenga en cuenta que en una configuración de múltiples GPU, el tamaño del lote debe ser un múltiplo de la cantidad de GPU disponibles en su sistema.

3. Falta de datos de GPU, es decir, las CPU no pueden seguir el ritmo de las GPU

Por lo general, la parte más costosa durante el entrenamiento / predicción de redes profundas es la estimación que ocurre en las GPU. Los datos se procesan previamente en las CPU en segundo plano y se envían periódicamente a las GPU. Sin embargo, no se debe subestimar lo rápido que son las GPU; puede suceder que si su red es demasiado superficial o el paso de preprocesamiento es demasiado complejo que sus CPU no pueden seguir el ritmo de sus GPU o, en otras palabras, no las alimentan con datos lo suficientemente rápido. Esto puede conducir a una baja utilización de la GPU que se traduce en dinero / recursos desperdiciados.

Keras generalmente realiza las estimaciones de los lotes en paralelo, sin embargo, debido a GIL (Global Interpreter Lock) de Python, realmente no se puede lograr un verdadero multihilo en Python. Hay dos soluciones para eso: usar múltiples procesos (tenga en cuenta que hay muchas trampas en este que no voy a cubrir aquí) o simplifique su paso de preprocesamiento. En el pasado, envié una solicitud de extracción en Keras para aliviar parte de la tensión innecesaria que estábamos aplicando a las CPU durante el preprocesamiento de imágenes, por lo que la mayoría de los usuarios no deberían verse afectados si usan los generadores estándar. Si tiene generadores personalizados, intente enviar tanta lógica como sea posible a las bibliotecas C como Numpy porque algunos de estos métodos realmente liberar el GIL lo que significa que puede aumentar el grado de paralelización. Una buena manera de detectar si se enfrenta al hambre de datos de GPU es monitorear la utilización de GPU, sin embargo, tenga en cuenta que esta no es la única razón para observar eso (la sincronización que ocurre durante el entrenamiento en las múltiples GPU también es la culpa de la baja utilización ) Por lo general, el hambre de datos de GPU se puede detectar observando ráfagas de GPU seguidas de largas pausas sin utilización. En el pasado, he abierto una extensión para Dstat que puede ayudarlo a medir la utilización de su GPU, así que eche un vistazo al publicación original en el blog.

4. Guardar sus modelos paralelos

Supongamos que usó el método mutli_gpu_model para paralelizar su modelo, la capacitación terminó y ahora desea mantener sus pesos. La mala noticia es que no puedes llamar a save () en él. Actualmente, Keras tiene una limitación que no le permite guardar un modelo paralelo. Hay dos formas de evitar esto: llame a save () en la referencia del modelo original (los pesos se actualizarán automáticamente) o necesita serializar el modelo cortando la versión paralela y limpiando todas las conexiones innecesarias. La primera opción es mucho más fácil, pero en el futuro planeo abrir un método serialize () que realice el último.

5. Contar las GPU disponibles tiene un efecto secundario desagradable

Desafortunadamente en este momento, hay un efecto secundario desagradable en el método tensorflow.python.client.device_lib.list_local_devices () que hace que se cree una nueva sesión TensorFlow y la inicialización de todas las GPU disponibles en el sistema. Esto puede conducir a resultados inesperados, como ver más GPU que las especificadas o inicializar nuevas sesiones prematuramente (puede leer todos los detalles sobre esto solicitud de extracción) Para evitar sorpresas similares, se recomienda utilizar el método Keget 'K.get_session (). List_devices (), que le devolverá todas las GPU registradas actualmente en la sesión. Por último, pero no menos importante, tenga en cuenta que llamar al método list_devices () es de alguna manera costoso, por lo que si solo está interesado en la cantidad de GPU disponibles, llame al método una vez y almacene su número en una variable local.

¡Eso es! Espero que hayas encontrado útil esta lista. Si encontró otros trucos / consejos para la capacitación de GPU en Keras, compártalos a continuación en los comentarios. 🙂