El Despliegue en el Machine Learning (MLOps)
En este segundo artículo de la serie Machine Learning Operations veremos en detalle en qué consiste el despliegue (o deployment) de un modelo de Machine Learning.
¡Así que listo, comencemos!
Tabla de contenido
Video
Como siempre, en el canal de YouTube se encuentra el video de este post:
Introducción
El despliegue de un modelo de Machine Learning consiste en llevarlo de la etapa de desarrollo a la etapa de producción, para que esté a disposición del usuario final.
Y este aspecto ha cobrado mucha importancia en los últimos años en el desarrollo de aplicaciones a nivel industrial. Así que en este video nos enfocaremos en este despliegue y en particular veremos los aspectos a tener en cuenta cuando queremos llevar nuestro modelo a producción así como las principales herramientas existentes en la actualidad.
¿Qué es el despliegue o deployment?
Comencemos viendo una definición más formal de lo que es el despliegue y algunos conceptos asociados.
En un artículo anterior hablamos del Machine Learning Engineering o Machine Learning Operations (o simplemente MLOps) y vimos que en esencia es un conjunto de prácticas que busca lograr el despliegue y mantenimiento de modelos de Machine Learning de manera confiable y eficiente.
Y el despliegue es una parte central de este proceso, que consiste en tomar el modelo entrenado y hacerlo accesible a un usuario final.
Por ejemplo, en la etapa de desarrollo lo que hacemos usualmente es crear un primer prototipo del modelo y generalmente esto lo hacemos en un computador local (a través de algunos scripts de Python o usando notebooks de Jupyter) o en la nube usando por ejemplo servicios como Google Colab.
Con el modelo ya entrenado, y bien sea que se trate de un proyecto personal, académico o que estemos trabajando para una empresa, lo ideal es llevarlo a un entorno de producción para que sea accesible a un usuario final. ¡Y esto es precisamente el despliegue!
Requerimientos de diseño
Y la elección del tipo de despliegue dependerá no sólo del uso que queramos dar al modelo sino de varios requerimientos de diseño. Así que hablemos en detalle de estos requerimientos.
Predicción (o inferencia): ¿en tiempo real o por lotes?
El primer requerimiento a tener en cuenta es el tipo de predicción que queremos realizar, que puede ser en tiempo real o por lotes.
En tiempo real las predicciones son generadas y devueltas al usuario en el menor tiempo posible después de recibida la solicitud. Un ejemplo es Google Translate: el usuario introduce el texto en el idioma original y casi de inmediato recibirá el texto traducido.
Por su parte, en las predicciones por lotes se procesa una gran cantidad de datos de entrada y el modelo genera las predicciones pero de forma asíncrona, es decir que la predicción no es inmediata. Un ejemplo es el sistema de recomendación de Netflix, que toma el historial de contenido visto por el usuario y aproximadamente cada 4 horas genera nuevas sugerencias de contenido .
Latencia y rendimiento
Otros dos criterios a tener en cuenta para definir el tipo de despliegue son la latencia y el rendimiento.
La latencia es simplemente el tiempo de respuesta requerido desde que se envía la solicitud al modelo en producción hasta que se recibe la predicción. Y la idea es que esta latencia sea lo más pequeña posible (máximo de unos pocos cientos de milisegundos). Por ejemplo, si estamos usando un modelo de reconocimiento facial para permitir el ingreso a los trabajadores de una empresa, queremos que las predicciones se generen lo más pronto posible.
Y el rendimiento es el número de solicitudes por segundo que puede soportar el sistema donde está alojado el modelo y es un aspecto importante al hacer predicciones por lotes. Volviendo al ejemplo de Netflix, que genera por cada usuario predicciones cada 4 horas, lo que buscaríamos sería un rendimiento alto teniendo en cuenta que el servicio tiene varios cientos de millones de usuarios.
Complejidad del modelo
Y por último, el tipo de despliegue a realizar dependerá de qué tan complejo sea el modelo que queramos llevar a producción.
No es lo mismo un modelo del tamaño de GPT-3 que un pequeño modelo como MobileNet. El primero requiere más capacidad de cómputo y de almacenamiento, mientras que el segundo podría incluso correr en un dispositivo móvil.
Alternativas de despliegue
Bien, teniendo claros estos requerimientos ahora sí podemos enfocarnos en las alternativas de despliegue, que son esencialmente dos: en la nube y lo que se conoce como on the edge.
Despliegue en la nube
En la nube quiere decir que el cómputo requerido para las predicciones se realizará en servidores remotos, alojados en la nube, por lo cual los datos y las predicciones se transfieren a través de Internet.
Esta es la alternativa a usar cuando se requieren muchos recursos computacionales (es decir cuando usamos modelos complejos) o cuando la latencia no es un problema (porque podemos aceptar retardos en el envío de los datos y la recepción de las predicciones) o cuando las predicciones se hacen por lotes.
Al desplegar en la nube usualmente podemos acceder al modelo de dos maneras:
- Una es almacenando los datos de entrada al modelo en una base de datos y programando el sistema para que cada cierto tiempo tome esos datos y genere las predicciones. Las predicciones resultantes son también almacenadas en una base de datos y periódicamente son entregadas a la aplicación cliente encargada de llevarlas al usuario final.
- Otra forma muy usada es “empaquetando” nuestro modelo en una API (Application Programming Interface) que le permitirá recibir solicitudes hechas por el usuario final así como entregarle el resultado de la predicción. Esta última forma es usada cuando queremos hacer predicciones con baja latencia y cuando no son por lotes (como por ejemplo el servicio de Google Translate)
Despliegue “on the edge”
Y la otra forma de despliegue es la que se conoce como on the edge. Esto quiere decir que el modelo no estará alojado en la nube sino en el mismo dispositivo encargado de recibir las solicitudes (que generalmente es un dispositivo con limitadas capacidades de cómputo, como un teléfono móvil, un smartwatch, una tablet, etc.)
En este caso la totalidad del cómputo se realiza en el dispositivo local (on the edge), así que esta alternativa se usa cuando no se requieren muchos recursos computacionales (es decir cuando no se usan modelos muy complejos), cuando se requieren bajos niveles de latencia (como en los vehículos autónomos donde nos interesa recibir las predicciones casi que de inmediato) o cuando por temas de seguridad no resulta conveniente enviar información a través de Internet (como por ejemplo en los sistemas de reconocimiento biométrico).
En este tipo de despliegue la predicción sólo puede ser en tiempo real, ya que en dispositivos móviles tenemos recursos limitados que dificultan el procesamiento por lotes.
Algunas de las herramientas de despliegue más usadas
Muy bien, teniendo claros los tipos de despliegue que existen, ahora vamos a ver un poco más en detalle las herramientas usadas en cada caso.
Aunque vale la pena aclarar que no es un listado exhaustivo sino más bien las que considero son las más usadas en la actualidad.
Además, veremos estas herramientas organizadas por nivel de dificultad al momento de la implementación, yendo de las más sencillas a las más complejas.
Herramientas de despliegue local
En primer lugar están las herramientas de despliegue local, que aunque rigurosamente no permiten como tal llevar el modelo a producción, sí permiten desplegarlo en nuestros propios computadores (es decir localmente), sin llegar aún a la nube o a un dispositivo edge (aunque pueden ser un primer paso para luego llevarlas a la etapa de producción).
Dos de las más usadas son Flask y FastAPI, que son librerías de Python que permiten empaquetar el modelo como una API y acceder a este localmente desde nuestro navegador de Internet. La ventaja es que el modelo puede haber sido creado con cualquiera de las librerías usadas comúnmente en Machine Learning.
También tenemos Tensorflow serving y Torchserve, que están optimizadas para tomar modelos entrenados con TensorFlow o Pytorch, respectivamente, y con muy pocas líneas de código desplegarlos localmente. Ambas permiten hacer inferencias (es decir predicciones) en tiempo real o por lotes.
Y finalmente, si queremos hacer despliegue on the edge podemos usar TensorFlow Lite o Pytorch Mobile para desplegar modelos de TensorFlow o Pytorch.
Herramientas out-of-the-box (o listas para usar)
Luego tenemos las que he llamado herramientas out-of-the-box, con las que podemos desplegar modelos como aplicativos web y sin necesidad de muchos recursos computacionales, e incluso muchas de ellas son gratuitas.
La más usada es tal vez Streamlit, que tiene un servicio gratuito en la nube para alojar nuestra aplicación y donde en unos pocos pasos podemos pasar de nuestro código en Python a alojar el aplicativo en los servidores de Streamlit.
Este enfoque lo recomiendo para quienes estén interesados en desplegar en la nube proyectos personales de Machine Learning y que no necesiten predicción por lotes, sobre todo porque la curva de aprendizaje es baja y en pocos minutos podemos tener el modelo disponible.
La gran desventaja es que no funcionan cuando queremos desplegar modelos complejos bien sea para hacer inferencia en tiempo real o por lotes. Esto debido a que por ser gratuitos tendremos nuestro modelo alojado en servidores con restricciones de memoria y de capacidad de cómputo.
Herramientas en la nube
Y finalmente tenemos los servicios en la nube, útiles en los casos en los cuales se requiera mayor capacidad de cómputo o la posibilidad de inferencia tanto en tiempo real como por lotes, así como la posibilidad de llevar nuestro modelo a múltiples usuarios finales.
En la nube quiere decir que el cómputo de las predicciones se hace totalmente en servidores remotos, donde los principales competidores son Amazon Web Services (AWS), Google Cloud o Microsoft Azure.
Este enfoque es útil cuando tenemos modelos complejos que requieren muchos recursos computacionales o cuando la latencia no es un problema.
Para este despliegue podemos incluso aprovechar las herramientas que habíamos usado para el despliegue local para así alojar estos aplicativos en cualquiera de estos servicios en la nube, usando la misma lógica de empaquetamiento y acceso a través de solicitudes en la nube.
La gran ventaja es que estos servicios permiten no sólo el despliegue del modelo sino la implementación de todo el ciclo del MLOps, incluyendo el entrenamiento y el monitoreo. Las desventajas son una curva de aprendizaje muy alta y obviamente el costo de estos servicios.
Conclusión
Muy bien, con lo visto en este artículo ya tenemos un panorama completo de lo que es y de los elementos a tener en cuenta para realizar el despliegue de un modelo de Machine Learning, así como las principales herramientas usadas en la actualidad y que permiten llevar a cabo esta tarea.
En el tercer artículo de esta serie hablaremos en detalle de otro elemento fundamental en el MLOPs, el monitoreo de un modelo de Machine Learning.
Si tienes alguna duda de este artículo o tienes alguna sugerencia no dudes en contactarme diligenciando el siguiente formulario: