Introducción

El deep learning está de moda. Hoy, más que nunca. Basta con ver el cartel del Big Data Spain 2017: Alrededor de un 40% de las ponencias hablaban de Machine learning, Deep learning o algún sinónimo de estos. Pero, ¿qué es Deep Learning?, ¿Por qué necesitamos integrarlo en el entorno Big Data?, ¿Por qué es tan dificil hacerlo? y, sobre todo, ¿Qué ofrece el mercado al respecto?.
Lo primero: ¿Qué es Deep Learning? (abrev. DL). Supongo que a día de hoy muchos tendrán una noción al menos intuitiva de qué es, aún así vamos a explicarlo. Como no quiero que esto se convierta en una serie continua de tecnicismos, vamos a adoptar una visión más funcional, profundizando sólo lo necesario.

¿Qué es Deep learning?

Para no entrar en detalle, vamos a definir un modelo de DL como un algoritmo por capas. En la primera capa le pasaremos nuestros datos, y la última capa nos dará un resultado. Entre medias, cada una de las capas puede verse como una función que toma un input de la capa anterior, lo transforma y le pasa el output a la siguiente capa. El gran truco es que cada capa consta de una serie de parámetros (muchisimos parámetros) que van optimizándose durante el proceso de aprendizaje usando tres conceptos fundamentales (perdón por los tecnicismos): propagaciónretropropagación y gradiente de descenso estocástico. FP, BP y SGD respectivamente por sus siglas en inglés. Más adelante veremos por qué son importantes. De momento, quedémonos con el nombre.
Por poner un ejemplo concreto: Supongamos que queremos que nuestra máquina reconozca entre perros y gatos. Para ello la proveemos de miles (o millones) de imagenes de perros y gatos etiquetadas manualmente. Estas imagenes se la pasamos a un modelo de DL de 5 capas: 1 de entrada, 3 intermedias y 1 de salida como muestra el siguiente esquema:

Por mantener el texto lo más simple posible, el esquema de arriba es una sobre-simplificación del modelo real

¿Por qué es necesario integrar el DL en el entorno Big Data?

El Big Data tiene mucho bombo. Es moderno, novedoso y eficaz, pero sabemos que muchas veces tiene más de marketing que de valor añadido. A pesar de esto, en el caso del deep learning sí existe la necesidad real de usar un entorno Big data. El modelo que sirve arriba de ejemplo es extremadamente simple (5 capas), pero no es raro ver arquitecturas de DL con 50 o 100 capas, cada una de ellas con millones de parámetros. Tales arquitecturas son muy eficaces, pero muy dificiles de entrenar. Hacen falta decenas de millones de datos y muchas repeticiones de FP, BP y SGD para que aprendan con precisión la tarea para las que fueron diseñadas.
Como puede observarse, el problema es muy big. Los procesos FP, BP se basan en cálculos matriciales que no son extremadamente costosos cuando hay pocos parámetros, pero que pueden consumir muchos recursos a los niveles que estamos hablando. Por tanto, se hace necesario utilizar un entorno distribuido para realizar estos cálculos y no quedarnos sin memoria.

¿Por qué es tan dificil la integración?

Como se ha dicho antes, una arquitectura DL es un modelo basado en capas. Cada una de las partes del entrenamiento se realiza capa a capa de manera secuencial. Esto es, primero se realiza la propagación en la primera capa, luego en la segunda, la tercera, y así hasta la última. Cuando la propagación termina, se realiza la retropropagación en sentido inverso: La última capa, la penultima, etc… hasta la primera. Al terminar la BP, podemos actualizar los parámetros usando el SGD. Esta última parte no se realiza capa a capa. Este proceso FP  →  BP  →  SGD se repite cientos de veces de forma cíclica hasta que los parámetros están optimizados (puede llegar a tardar semanas).
Este esquema de entrenamiento presenta el grave inconveniente de que es muy secuencial, y por tanto, poco paralelizable. Necesitamos que termine el paso previo para empezar el siguiente. La mayoría de los frameworks actuales presentan dos formas de paralelismo: Model parallelism Data parallelism. Vamos a centrarnos en el segundo modelo al ser el más común (más info aquí [5]). El Data parallelism consiste en que cada worker (llamado learner en nuestro entorno) de nuestro cluster entrene una parte de los datos. En esencia, cada uno realiza un ciclo completo FP  →  BP  →  SGD, luego se comunican entre ellos para compartir el gradiente, sintetizarlo en un gradiente común y actualizar los parámetros. Parece sencillo, pero…

Es un problema de comunicación

El proceso descrito arriba requiere mucho intercambio de datos entre workers, tanto en el cálculo del gradiente como en la actualización de los parámetros dando lugar a un gasto de comunicación, que prácticamente se come la mejora obtenida por la distribución del cálculo. En palabras más simples, nuestros workers gastan muchos recursos comunicándose entre ellos y esperando a que otros terminen.
Como corolario tenemos la paradoja de la velocidad: Usar unidades de procesamiento más rápido, aumenta el número de comunicaciones que tiene que hacer cada learners, penalizando aún más el proceso. Lo mismo ocurre si aumentamos el número de learners [7].

¿Qué ofrece el mercado?

Llegados a este punto, tenemos que preguntarnos ¿Qué framework es mejor para un entorno big data?. Como suele ocurrir en este mundo, no existe respuesta única. Cada caso es distinto y según nuestras necesidades nos convendrá más un framework u otro. Por supuesto, en el mundo DL TensorFlow es la palabra clave, como demuestra el gráfico de Google Trends de abajo. TensorFlow es rápido, es pythónico, es de Google y tiene un nombre con mucho marketing, pero no es ni el más rápido ni el más escalable.

 

Sí. La línea azul es Tensor Flow…

Así lo demuestra el benchmark independiente de la Universidad Baptista de Hong Kong, [11] que compara 5 frameworks distintos valorando su rapidez y capacidad de escalar tanto en CPU (procesadores) como en GPU (tarjetas gráficas) y en distintas arquitecturas. Eso sí, este benchmark no mide la performance de cada producto en entorno distribuido si no en un entorno con múltiples unidades de procesamiento. En roman paladino: Mide la performance en una sóla computadora con varias CPUs y GPUs pero no en varias computadoras comunicadas entre sí. Aún así, del estudio podemos sacar bastantes conclusiones.

Pros y Contras de TensorFlow

Obviamente TF es un gran framework de DL. Tiene el soporte de Google y eso es siempre motivo de confianza. Además, su popularidad se traduce en toneladas de código abierto con multitud de arquitecturas ya implementadas y modelos pre-entrenados que facilitan enormemente la tarea de los programadores e ingenieros, aumentando su productividad. En el citado estudio, TF no sale mal parado. Si procesamos en CPU, TensorFlow tiene la ventaja de ser super escalable. Mientras otros frameworks empeoran su desempeño cuando aumentamos el paralalelismo del procesador, TF sigue mejorando tiempos incluso con 32 hilos corriendo en paralelo.
El problema de este enfoque es que el entrenamiento en CPU no es (o no debería ser) la opción cuando tenemos nuestro modelo en producción. En general todos los frameworks mejoran el desempeño entre 10 y 15 veces si entrenamos sobre la tarjeta gráfica (GPU). Aquí es donde TF no da la talla. De las 7 arquitecturas analizadas, TF queda último o penúltimo en 6 de ellas en única tarjeta gráfica. Acaso pueda agurmentarse que TF será escalable sobre la GPU del mismo modo que lo es sobre CPU, pero no. Por ejemplo, para una arquitectura simple (fully connected) CNTK (Microsoft) y Apache MXNet mejoran un 35% sobre 2 GPUs, TensorFlow apenas logra una mejora del 10%. Parece ser que el problema es que TF actualiza los parámetros en la CPU, resultando un coste mayor al tener que traspasar el gradiente de la GPU a la CPU.
Por supuesto el problema de la performance en una máquina es importante, pero en el mundo Big Data es fundamental saber como se desempeña cada producto en un entorno distribuido. En este caso TensorFlow ofrece una solución basada en un cluster con una arquitectura parameter server  worker [8]El principal problema es que al ser un producto independiente hay que integrarlo a nuestro cluster de Big Data como una herramienta aparte. Otra opción es usar TensorflowOnSpark, una librería que está desarrollando Yahoo! que integra TF en nuestro cluster Apache Spark o Apache Hadoop. Al ser una librería muy nueva es complicado saber el estado actual de la misma. En esta conferencia [1] de 2016 se advierte de que sólo debe ser utilizada en caso de que tu problema no quepa en una sola máquina, ya que sufre severas penalizaciones en el rendimiento.
 

Más allá de TensorFlow: Dos alternativas (y muchas más).

Por razones de tiempo y espacio aquí solo comentaremos las propuestas de Microsoft e Intel: CNTK y BigDL respectivamente. Otras alternativas dignas de mención son: Apache MXnet, CaffeOnSpark, Deeplearning4j, elephas, etc… Dado que carecemos de un benchmark fiable que compare estas tecnologías en un entorno Big Data, la información que proporcionamos aquí es la que ofrecen los fabricantes salvo en el caso de CNTK que sí disponemos de cierta información gracias al estudio de la HKBU citado previamente.

 

CNTK
son las siglas de Computational Network Toolkit. Actualmente ha cambiado su nombre por Microsoft Cognitive Toolkit (MCT?) pero dado que todas las referencias son por el antiguo nombre (incluso la página oficial de MS) hemos decidido mantenerlo. Según los resultados del estudio [11], CNTK tiene gran escalabilidad sobre GPUs y es con diferencia la que mejor desempeño muestra en arquitecturas recurrentes (diseñadas para analizar patrones secuenciales: Series temporales, lenguaje predictivo, etc…), si bien su rendimiento se ve afectado en redes convolucionales muy grandes (Para el procesamiento de imagenes).
Su secreto consiste en dos algoritmos denominados 1bit-SGD y Block-Momentum SGD que permiten el envío del gradiente entre learners de manera más eficiente. Según afirma MS, por supuesto, la escalabilidad que ofrecen estos algoritmos no sólo es válida en una máquina con multiples GPUs (algo acreditado por la univ. de Hong Kong) si no también en múltiples máquinas. Eso sí, ambos algoritmos tienen licencia propietaria no comercial. Es decir, hay que pagar por su uso. CNTK también se ofrece en una versión con licencia más laxa que incluye otra clase de algoritmos de paralelización.

Otra de las ventajas que ofrece CNTK es que puede integrarse en nuestro cluster a traves de una librería (mmlspark) para Spark desarrollada por la propia Microsoft y no por un tercero. Ofrece una API en python y otra en scala en dos formas: una versión por grafo y otra porcapas (habrá que ver como funcionan…)Sin entrar en detalles, las API por grafo son más flexibles y customizables mientras que una API basada en capas permite un desarrollo más rápido y productivo a costa de menor flexibilidad. Eso es una ventaja con respecto a TF, ya que éste sólo ofrece una API por grafo en python. La API por capas de TF se llama Keras y es third party.

 

BigDL
por su parte, esta desarrollado por Intel y, como no, usa la librería Intel MKL para cálculo multi-hilo. La principal diferencia con los anteriores frameworks es que está escrita como una librería nativa de Spark, extendiendo la actual MLlib, resultando a priori, una mejor integración en nuestro cluster Big Data. Al igual que CNTK, BigDL ofrece API’s tanto por grafo como por capas en python y escala. Otra de las ventajas de BigDL es que puede importar/exportar modelos ya existentes de Caffe, Torch y TensorFlow, aprovechando así todo el trabajo y modelos pre-entrenados de estos frameworks tan populares.
Su arquitectura usa el driver de Spark como gestor de parámetros pero a través de un procotolo P2P que evita el cuello de botella que se produce cuando los workers mandan información muy pesada o hay muchos de ellos. Según Intel, esta arquitectura es mejor que la basada en un servidor de parámetros común que usan tanto TF como CNTK.
El principal defecto es que BigDL no admite el procesamiento en GPU (!). Este es sin duda un grandisimo defecto, aunque según el benchmark de la propia Intel, BigDL es “Ordenes de magnitud” más rápido que sus competidores en una CPU (minuto 19:45 en [12]. Intel no ofrece la referencia completa al benchmark). A pesar de esto, Cloudera parece estar dando bastante soporte a este framework [10]. Ellos argumentan (y con razón) que BigDL puede integrarse rápidamente en un cluster Cloudera sin necesidad de un conocimiento profundo de la configuración, y que distribuir otros frameworks como TF, CNTK o Caffe requiere, en general, una fuerte inversión en granjas de tarjetas gráficas muy potentes, mientras que el hardware intel es de uso común en la mayoria de entornos existentes.

¿IBM al rescate?: PowerAI DDL

No quería desaprovechar esta oportunidad para hablar de la última novedad de IBM llamada PowerAI DDL. Como hemos comentado, el problema de la distribución del Deep Learning se debe principalmente a la dificultad de compartir información de manera eficiente entre learners. Pues bien, hace 4 meses (Agosto 2017) IBM publicó una solución combinada Hardware – Software que, según dicen, permite escalar casi linealmente en velocidad con respecto al número de learners. Es decir, que multiplicando por n el número de learners, la velocidad se divide por n también. Toda la info en el Blog [4] y en el paper [7]

 

Luis Morillo Najarro

BI Software Developer at Indizen
 


References

[1Christopher Nguyen, Chris Smith, Ushnish De Vu Pham, Nanda KishoreDistributed Tensor Flow on Spark: Scaling Google’s Deep Learning Library2016. URL https://www.youtube.com/watch?v=-QtcP3yRqyM.

[2Clemens MarschnerMicrosoft Cognitive Toolkit: fast and furious2017. URL https://www.youtube.com/watch?v=Rb9K10JwR2g.

[3Derek MurrayDistributed TensorFlow2017. URL https://www.youtube.com/watch?v=la_M6bCV91M.

[4Hillery HunterIBM Research achieves record deep learning performance with new software technology2017. URL https://www.ibm.com/blogs/research/2017/08/distributed-deep-learning.

[5Jeffrey Dean, Greg S. Corrado, Rajat Monga, Kai Chen, Matthieu Devin, Quoc V. Le, Mark Z. Mao, MarcAurelio Ranzato, Andrew Senior, Paul Tucker, Ke Yang, Andrew Y. Ng: “Large Scale Distributed Deep Networks”, NIPS2012.

[6Microsoft News CenterAWS and Microsoft announce Gluon, making deep learning accessible to all developers2017. URL https://news.microsoft.com/2017/10/12/aws-and-microsoft-announce-gluon-making-deep-learning-accessible-to-all-developers/.

[7Minsik Cho, Ulrich Finkler, Sameer Kumar, David S. Kung, Vaibhav Saxena, Dheeraj Sreedhar: “PowerAI DDL”, CoRR2017. URL http://arxiv.org/abs/1708.02188.

[8Mu Li, David G. Anderson, Jun Woo Park, Alexander J. Smola, Amr Ahmed, Vanja Josifovski, James Long, Eugene J. Shekita, Bor-Yiing Su: “Scaling Distributed Machine Learning with the Parameter Server”, Operating Systems Design and Implementation (OSDI), pp. 583—5982014.

[9Petar ZecevicDeep Learning in Spark with BigDL2017. URL https://www.youtube.com/watch?v=c2VrudAcMPo.

[10Sergey Ermolin, Jiao (Jennie) Wang, Vartika SinghBigDL on CDH and Cloudera Data Science Workbench2017. URL https://blog.cloudera.com/blog/2017/04/bigdl-on-cdh-and-cloudera-data-science-workbench/.

[11Shaohuai Shi, Qiang Wang, Pengfei Xu, Xiaowen Chu: “Benchmarking State-of-the-Art Deep Learning Software Tools”, CoRR2016. URL http://arxiv.org/abs/1608.07249.

[12Yiheng WangBigDL: A Distributed Deep Learning Library on Spark: Spark Summit East2017. URL https://www.youtube.com/watch?v=j0ewLYecTsY.