Fuente de la imagen: Pixabay (Imagen libre)

¿Está buscando "ciencia de datos impulsada por GPU"?

 
 
Imagínese que es un científico de datos, un analista de negocios o un investigador académico en Física / Economía / Neurociencia ...

Haces mucho disputa de datos, limpieza, pruebas estadísticas, visualizaciones sobre una base regular. También juegas con muchos modelos lineales ajustar datos y ocasionalmente aventurarse en Bosque aleatorio. Tu tambien estas en clustering grandes conjuntos de datos. ¿Suena lo suficientemente familiar?

Sin embargo, dada la naturaleza de los conjuntos de datos en los que trabaja (en su mayoría tabulares y estructurados), no se aventura tanto en el aprendizaje profundo. Preferiría poner todos los recursos de hardware que tiene en las cosas que realmente hace a diario, en lugar de gastar en un modelo elegante de aprendizaje profundo. ¿Otra vez familiar?

Escuchas sobre el asombroso poder y la destreza de cómputo ultrarrápida de Sistemas GPU como los de NVidia para todo tipo de aplicaciones industriales y científicas.

Y sigues pensando: "¿Qué hay para mí? ¿Cómo puedo aprovechar estas poderosas piezas de semiconductores en mi flujo de trabajo específico?? "

Está buscando ciencia de datos impulsada por GPU.

Una de sus mejores (y más rápidas) opciones para evaluar este enfoque es utilizar la combinación de Nube de Saturno + RÁPIDOS. Déjame explicarte en detalle ...

Las GPU en el folclore AI / ML han sido principalmente para el aprendizaje profundo

 
 
Si bien el uso de GPU y computación distribuida se discute ampliamente en los círculos académicos y comerciales para tareas centrales de AI / ML (por ejemplo, ejecutar un Red neuronal profunda de 1000 capas para clasificación de imágenes o BERT de mil millones de parámetros modelo de síntesis de voz), han encontrado menos cobertura en lo que respecta a su utilidad para las tareas habituales de ciencia de datos e ingeniería de datos.

Sin embargo, Las tareas relacionadas con los datos son el precursor esencial de cualquier carga de trabajo de AA en una canalización de IA y a menudo constituyen un porcentaje mayoritario del tiempo y esfuerzo intelectual gastado por un científico de datos o incluso un ingeniero de ML. Recientemente, el famoso pionero de la IA
Andrew Ng habló sobre pasar de un enfoque centrado en el modelo a uno centrado en los datos para la IA desarrollo de herramientas. Esto significa pasar mucho más tiempo con los datos sin procesar y preprocesarlos antes de que se ejecute una carga de trabajo de IA real en su canalización.

Entonces, la pregunta importante es: ¿Podemos aprovechar el poder de la GPU y la computación distribuida para trabajos regulares de procesamiento de datos??

Fuente de la imagen: Collage creado por el autor a partir de imágenes gratuitas (Pixabay)

 

Si bien el uso de GPU y la computación distribuida se discute ampliamente en los círculos académicos y comerciales para las tareas centrales de AI / ML, han encontrado menos cobertura en su utilidad para las tareas habituales de ciencia de datos e ingeniería de datos.

El fantástico ecosistema de RAPIDS

 
 
La Conjunto de API y bibliotecas de software RAPIDS brindarle, a un científico de datos habitual (y no necesariamente a un profesional del aprendizaje profundo), la opción y la flexibilidad para ejecutar Canalizaciones de análisis y ciencia de datos de extremo a extremo completamente en GPU.

Este proyecto de código abierto fue incubado por Nvidia mediante la creación de herramientas para aprovechar las primitivas de CUDA. Se centra específicamente en exponer el paralelismo de la GPU y las características de velocidad de memoria de alto ancho de banda a través del lenguaje Python compatible con la ciencia de datos.

Tareas comunes de preparación y negociación de datos son muy valorados en el ecosistema RAPIDS. También presta una cantidad significativa de soporte para implementación de múltiples nodos, múltiples GPU y procesamiento distribuido. Siempre que sea posible, se integra con otras bibliotecas que hacen sin memoria (es decir, un tamaño de conjunto de datos mayor que la RAM de una computadora individual) procesamiento de datos fácil y accesible para los científicos de datos individuales.

Fuente de la imagen: Collage creado por el autor

 

Los tres componentes más destacados (y Pythonic), que son de particular interés para los científicos de datos comunes, son,

• cupy: Una biblioteca de arreglos impulsada por CUDA que se ve y se siente como Numpy, mientras usa varias bibliotecas CUDA, por ejemplo, cuBLAS, cuDNN, cuRand, cuSolver, cuSPARSE, cuFFT y NCCL para aprovechar al máximo la arquitectura GPU subyacente.
• CuDF: Esta es una biblioteca de GPU DataFrame para cargar, agregar, unir, filtrar y manipular datos con un API similar a pandas. Los ingenieros de datos y los científicos de datos pueden usarlo para acelerar fácilmente sus flujos de tareas utilizando potentes GPU sin tener que aprender los detalles de la programación CUDA.
• CUML: Esta biblioteca permite a los científicos de datos, analistas e investigadores ejecutar algoritmos ML tradicionales / clásicos y tareas de procesamiento asociadas aprovechando al máximo la potencia de una GPU. Naturalmente, esto se usa principalmente con conjuntos de datos tabulares. ¡Piense en Scikit-learn y lo que podría hacer con todos esos cientos de Cuda y Tensor Cores en su tarjeta GPU! En respuesta a eso, en la mayoría de los casos, la API de Python de cuML coincide con la de Scikit-learn. Además, intenta ofrecer Compatibilidad con GPU de varios nodos y múltiples GPU by integrándose elegantemente con Tablero, donde sea posible, para aprovechar el verdadero procesamiento distribuido / computación en clúster.

¿Podemos aprovechar el poder de la GPU y la computación distribuida para trabajos de procesamiento de datos regulares y aprendizaje automático con datos estructurados?

¿Es diferente de usar Apache Spark?

 
 
Puede preguntar en qué se diferencia este procesamiento de datos impulsado por GPU al uso de Apache Spark. En realidad, existen algunas diferencias sutiles y, solo recientemente, con Spark 3.0, las GPU son un recurso principal para las cargas de trabajo de Spark.

Acelerando Apache Spark 3.0 con GPU y RAPIDS | Blog para desarrolladores de NVIDIA
 

No tenemos tiempo ni espacio para discutir las diferencias únicas de este enfoque de ciencia de datos impulsado por GPU frente a las tareas de Big Data que son particularmente adecuadas para Apache Spark. Pero hágase estas preguntas y probablemente comprenderá la sutil diferencia,

"Como científico de datos que modela transacciones económicas y gestión de carteras, quiero resolver un sistema lineal de ecuaciones con 100,000 variables. ¿Utilizo una biblioteca de álgebra lineal pura o Apache Spark?? "

"Como parte de una canalización de compresión de imágenes, quiero usar Valor singular de descomposición en una gran matriz de millones de entradas. ¿Apache Spark es una buena opción para eso?? "

El gran tamaño del problema no siempre significa Apache Spark o el ecosistema Hadoop. Big Computation no es equivalente a Big Data. Como científico de datos completo, necesita conocer ambos para abordar todo tipo de problemas.

RAPIDS se centra específicamente en exponer el paralelismo de la GPU y las características de velocidad de memoria de alto ancho de banda a través de las API de Python.

¿Qué mostramos en este artículo?

 
 

Ejemplos nítidos de CuPy y CuML solamente

 
Entonces, en este artículo, solo demostraremos ejemplos nítidos de CuPy y CuML,

• cómo se comparan (en velocidad) con las funciones / estimadores correspondientes de Numpy y Scikit-learn
• cómo importa el tamaño de los datos / problemas en esta comparación de velocidad.

Ejemplos de CuDF en un artículo posterior

 
Aunque los ejemplos de ingeniería de datos similares al procesamiento de datos de Pandas son de gran interés para muchos científicos de datos, cubriremos los ejemplos de CuDF en un artículo posterior.

¿Cuál es mi plataforma de hardware basada en GPU?

 
Estoy usando un Nube de Saturno Instancia de GPU Tesla T4, ya que son literalmente 5 minutos de trabajo para hacer girar un recurso informático completo y cargado (con bibliotecas DS y AI) en la nube por todo mi trabajo de ciencia de datos con su servicio. Siempre que no exceda las 10 horas de uso de Jupyter Notebook por mes, es gratis! Si desea leer más sobre su servicio,

Lanzamiento de Saturn Cloud Hosted: ¡Ciencia de datos de GPU para todos!

La informática con GPU es el futuro de la ciencia de datos. Paquetes como RAPIDS, TensorFlow y PyTorch permiten la velocidad del rayo ...

Aparte de tener el GPU Tesla T4, es una máquina Intel (R) Xeon (R) Platinum 4CL CPU de 8259 núcleos a 2.50 GHz con 16 GB de RAM y 10 GB de disco persistente. Por lo tanto, esta es una configuración bastante normal desde el punto de vista de la configuración del hardware (disco duro limitado debido al nivel gratuito), es decir, cualquier científico de datos puede tener este tipo de hardware en su poder. El único factor distintivo es la presencia de la GPU y la configuración de todas las bibliotecas CUDA y Python de manera adecuada para que la suite RAPIDS funcione sin ningún problema.

El gran tamaño del problema no siempre significa Apache Spark o el ecosistema Hadoop. Big Computation no es equivalente a Big Data. Como científico de datos completo, necesita conocer ambos para abordar todo tipo de problemas.

Resolver un sistema lineal de ecuaciones

 
Creamos sistemas lineales de ecuaciones de diferentes tamaños y usamos Numpy (y CuPy) linalg.solverutina para resolver eso con el siguiente código,

¡Y el código cambia con una sola letra (en múltiples invocaciones) para la implementación de CuPy!

También tenga en cuenta cómo podemos crear matrices CuPy a partir de matrices Numpy como argumentos.

Sin embargo, el resultado es dramático. CuPy comienza lento o a un ritmo similar al de Numpy, pero lo supera de lleno en problemas de gran tamaño (número de ecuaciones).

Valor singular de descomposición

 
A continuación, abordamos el problema de la descomposición de valores singulares utilizando una matriz cuadrada generada aleatoriamente (extraída de una distribución normal) de diferentes tamaños. No repetimos el bloque de código aquí, solo mostramos el resultado por brevedad.

Es importante señalar que el algoritmo CuPy no muestra un rendimiento notablemente superior al del algoritmo Numpy en esta clase de problemas. Quizás, esto es algo que los desarrolladores de CuPy deben abordar para mejorar.

Volviendo a lo básico: inversión matricial

 
Por último, volvemos a lo básico y consideramos el problema fundamental de la inversión de matrices (utilizado en casi todos los algoritmos de aprendizaje automático). El resultado nuevamente muestra una ganancia de rendimiento muy favorable por parte del algoritmo CuPy sobre el del paquete Numpy.

Abordar un problema de agrupamiento de K-medias

 
A continuación, consideramos un problema de aprendizaje no supervisado de agrupamiento utilizando el algoritmo de k-medias demasiado familiar. Aquí, comparamos una función CuML con un estimador equivalente del paquete Scikit-learn.

Solo como referencia, aquí está la comparación API entre estos dos estimadores.

Fuente de la imagen: Scikit-learn y Sitio web de CuML (Proyectos de código abierto)

 

Este es el resultado de un conjunto de datos con 10 características / dimensiones.

Y aquí está el resultado de otro experimento con un conjunto de datos de 100 características.

Claramente, tanto el tamaño de la muestra (número de filas) como la dimensionalidad (número de columnas) importaban en el desempeño superior de la aceleración basada en GPU.

Problema de regresión lineal demasiado familiar

 
¿Quién puede ignorar un problema de regresión lineal para la comparación de velocidades al tratar con conjuntos de datos tabulares? Siguiendo la cadencia como antes, variamos el tamaño del problema, esta vez tanto el número de muestras como las dimensiones simultáneamente, y comparamos el rendimiento de CuML LinearRegression estimador al obtenido del estable de Scikit-learn.

El eje X en la siguiente figura representa el tamaño del problema, desde 1,000 muestras / 50 características hasta 20,000 muestras / 1000 características.

Una vez más, el estimador CuML funciona mucho mejor a medida que aumenta la complejidad del problema (tamaño de la muestra y dimensionalidad).

Resumen

 
 
Nos centramos en dos de los componentes más fundamentales del marco de RAPIDS, cuyo objetivo es llevar el poder de la GPU a las tareas diarias de análisis de datos y aprendizaje automático, incluso cuando el científico de datos no realiza ninguna tarea de aprendizaje profundo.

Fuente de la imagen: Realizado por el autor con imágenes gratuitas de Pixabay (Link-1, Link-2, Link-3)

 

Usamos un Nube de Saturno Instancia basada en Tesla T4 para configuración fácil, gratuita y rápida y mostró algunas características de las bibliotecas CuPy y CuML y comparaciones de rendimiento de algoritmos ampliamente utilizados.

• No todos los algoritmos de las bibliotecas de RAPIDS son muy superiores, pero la mayoría lo son.
• En general, la ganancia de rendimiento aumenta rápidamente a medida que aumenta la complejidad del problema (tamaño de la muestra y dimensionalidad).
• Si tiene una GPU, pruebe siempre RAPIDS, compare y pruebe si está obteniendo algún rendimiento y conviértalo en un caballo de batalla confiable de su canal de ciencia de datos.
• El cambio de código es mínimo, casi inexistente para el cambio.

Deje que el poder de la GPU impulse su flujo de trabajo de análisis y ciencia de datos.

Puedes consultar el autor GitHub repositorios para código, ideas y recursos en aprendizaje automático y ciencia de datos. Si, como yo, te apasiona la inteligencia artificial / aprendizaje automático / ciencia de datos, no dudes en agrégame a LinkedIn or Sigueme en Twitter.

Gracias a Mel.

 
Original. Publicado de nuevo con permiso.

Relacionado:

• Cómo utilizar las bibliotecas aceleradas por GPU de NVIDIA
• ¿Por qué y cómo debería aprender "Ciencia de datos productiva"?
• No solo para el aprendizaje profundo: cómo las GPU aceleran la ciencia y el análisis de datos