Vuelta de tuerca al despliegue de modelos: Llega el Edge AI

No hace tanto tiempo se asociaba el despliegue del un modelo de machine learning o deep learning (en adelante me referiré a ellos como modelo IA) a su puesta en productivo y los vendedores de herramientas, consultores y otros recién llegados solían decir aquello de “pulsas un botón y pones el modelo en producción” (quien esté libre de culpa…). Sin embargo, creo que todos hemos madurado y tenemos claro que el despliegue del modelo – o, mejor dicho, la intención de desplegar un modelo – tan solo es el inicio del proceso de operacionalización del modelo que, tal como comenté en mi anterior entrada del blog, aún está pendiente de industrialización en la mayoría de las empresas.

El despliegue del modelo es, ciertamente, un factor de complejidad fundamental en aquellos proyectos cuyo objetivo incluye la necesidad de operacionalizar el modelo IA en una aplicación, sea cual sea la naturaleza de ésta. En el libro detallo cuatro modalidades de despliegue de los modelos:

1.- Como módulo embebido dentro del código de la aplicación, donde la aplicación utiliza la librería del framework con el que ha sido entrenado el modelo para invocar la correspondiente operación de predicción con los nuevos datos. El resultado es una aplicación que contiene el modelo, es autónoma y puede desplegarse, por ejemplo, en dispositivos móviles – cada día más potentes – sin la necesidad de que éstos deban estar conectados a un servidor externo que realice la inferencia.

2.- Como servicio web, probablemente la modalidad más frecuente y visible gracias al API economy y a los servicios AI as a Service de los diversos cloud públicos. Es la modalidad más flexible y sus ventajas superan de largo a sus inconvenientes.

3.- Como programa para el tratamiento batch y masivo de datos sobre infraestructuras típicas de BigData. Son escenarios de uso donde el modelo se aplica de forma masiva sobre grandes grupos de registros, como pueden ser la base de datos de clientes, de forma que se leen los datos, se aplica el modelo y se actualiza el registro con el resultado del modelo (por ejemplo, el grado de propensión del cliente para adquirir un producto ante una determinada campaña de cross-selling)

4.- Como operador en una secuencia de procesado de datos en streaming, para aplicar modelos sobre flujos de datos, cualesquiera que sean estos. Por supuesto, es necesario disponer de una plataforma de análisis de datos en streaming, y es fácil pensar en aplicaciones en el ámbito del análisis de datos de sensores, monitorización con detección de anomalías en series de datos, etc. todo muy de la órbita del Internet of Things.

Las cuatro modalidades – salvo, quizás, la primera – tienen algo en común: Son despliegues en el centro de datos o, al menos, en el cloud, donde los recursos de computación y almacenamiento abundan y donde muchas herramientas que nos ayudan con el entrenamiento de los modelos pueden perfectamente encargarse del despliegue del modelo y de albergarlo en una infraestructura de servicio (aplicación web exponiendo el api de inferencia, cluster Spark o solución de streaming). Es decir, todo muy a mano, conocido y controlado, y aun así inherentemente complejo.

Y ahora llega la nueva movida: EDGE AI

Sí, el Edge Computing está de moda y aunque su propuesta de valor es amplia y diversa, parece que uno de los principales drivers de este patrón de computación – y de todo el ecosistema tecnológico que arrastra – es la posibilidad de ejecutar la inferencia del modelo en el lugar (edge) donde se capturan los datos que deben ser tratados y que, casualmente, está lejos del lugar donde se entrenan los modelos (cloud o centro de datos). Esta distancia y el hecho de que en el edge las condiciones operativas habituales no sean precisamente de abundancia de recursos eleva el reto del despliegue de los modelos a una nueva dimensión de complejidad.

¿Por qué el despliegue de modelos IA en edge adquiere un nivel superior de complejidad?

En primer lugar, el sacar la inferencia del centro de datos y los requerimientos de bajo consumo y tamaño reducido que suelen imponerse en el edge, ha potenciado la proliferación de los llamados Systems On Chip (SOC), que incorporan GPUs o nuevo hardware acelerador de las operaciones de inferencia de los modelos IA. Este hardware, que poco o nada tienen que ver con las GPUs utilizadas para el entrenamiento del modelo, optimiza las condiciones operativas de la inferencia, maximizando el factor [capacidad de computación / consumo energético]. Esta disparidad de hardware entre entrenamiento e inferencia obliga, la mayoría de las veces, a optimizar los modelos entrenados para que puedan ser ejecutados eficientemente en el hardware de inferencia, lo que añade tareas adicionales al proceso de despliegue del modelo entrenado.

Así, por ejemplo, NVIDIA, el gran fabricante de GPUs tanto para aplicaciones gráficas como para deep learning, tiene en el mercado la familia NVIDIA Jetson claramente orientada a la inferencia en edge y su SDK JetPack incluye TensorRT una librería para optimizar modelos entrenados previamente con prácticamente cualquiera de los frameworks deep learning más populares. TensorRT proporciona optimizaciones específicas para cada tipo de chip de inferencia, siempre que, eso sí, sea compatible con CUDA. Algunas de estas optimizaciones consisten en convertir los parámetros calculados en coma flotante de 32 bits (FP32) a coma flotante de 16 bits (FP16) o incluso a enteros de 8 bits (INT8), tratando de minimizar el impacto en la precisión del modelo a cambio de aumentar la velocidad de la inferencia. Desde el punto de vista del proceso de despliegue, esto sólo ya añade dos nuevas tareas: optimizar y validar con unas pruebas de regresión el resultado obtenido.

Esquema TensorRT donde se ilustran las diversas técnicas de optimización

Del mismo modo, Google ha lanzado al mercado su familia de TPUs para el mercado edge, llamada coral.ai. De todos ellos es destacable su USB Accelerator, que puede “vitaminizar” la inferencia de placas tan populares como discretas en cuanto a capacidad computacional para inferencia de modelos IA como son los sistemas Raspberry Pi. En el caso de coral.ai, la optimización se lleva a cabo mediante Tensorflow Lite, que conceptualmente efectúa la misma misión que TensorRT: optimizar modelos entrenados con Tensorflow. Tensorflow Lite no solo está diseñado para optimizar y ejecutar modelos IA en dispositivos Android y iOS, sino que también abarca la optimización para arquitecturas basadas en ARM de 32 y 64 bits y, con limitaciones, el mundo de los microcontroladores de 32 bits, como por ejemplo Arduino. De nuevo, como mínimo, dos tareas más: optimizar y más pruebas.

El USB Accelerator de Coral.ai añade potencia de inferencia a cualquier dispositivo

Y por finalizar los ejemplos, el fabricante de SOCs y chips FPGA Xilinx también ofrece al mercado toda una familia de sistemas especializados en inferencia con baja latencia para modelos con arquitectura de redes neuronales convolutivas (CNNs) y su entorno de desarrollo VITIS AI sigue el mismo esquema de optimizar y adaptar modelos entrenados mediante los frameworks Tensorflow o Caffe para sus DPUs (Deeplearning Processing Units).

Dejando de lado la optimización de los modelos, el edge computing, en general, añade la dificultad de la gestión del inventario y la distribución de las aplicaciones y configuraciones a las decenas, los centenares o incluso miles de dispositivos edge repartidos por el mundo que pueden estar ejecutando una misma aplicación. Y es aquí cuando subimos la apuesta con el re-entrenamiento de los modelos. Y es que si el escenario de uso exige un re-entrenamiento más o menos frecuente del modelo, posiblemente haya que arquitecturizar la aplicación edge en componentes que puedan ser actualizados de forma independiente, sin excesivos problemas de integración, como bien podrían ser contenedores integrados mediante servicios web conformando una única aplicación. Este tipo de cuestiones deben ser contempladas por las nuevas herramientas que se van lanzando al mercado, como es el caso del IBM Edge Application Manager, cuyo objetivo principal es distribuir aplicaciones contenerizadas al edge, pero que ya incorpora un módulo llamado “Model Management System” que justamente busca poder desplegar en el edge modelos entrenados en el cloud sin que ello obligue a una distribución completa de la aplicación. Recordemos que una aplicación IA puede estar utilizando uno o más modelos, tanto en cloud como en edge. Es de esperar que este tipo de herramientas ayuden en la gestión de la distribución de aplicaciones y modelos de forma independiente pero coordinada.

Y la historia no acaba aquí, pero si este artículo. Quedará pendiente hablar de entrenamiento o aprendizaje federado que busca que diversos dispositivos edge contribuyan al entrenamiento de un modelo común llevando a cabo un entrenamiento parcial con sus datos locales e intercambiando los parámetros calculados para conformar el modelo final unificado. Complejidad, y más complejidad.

¡Y solo hemos hablado del despliegue del modelo!

¡Si te ha interesado este artículo, valora comprar el libro!

Buy from Amazon
Buy from Amazon Kindle
Buy from Google Play
Buy from Apple Books
guest
1 Comment
Inline Feedbacks
View all comments
Ian Gardner
Ian Gardner
1 year ago

Thanks for this Jaume.

I really like this. Google did a good job of translating the article without too much confusion.
One of the challenges around Edge is with the management of multiple devices etc. This is nothing new and takes us back in time to older architecture. Difference now is with multi-cloud