Introducción a la implementación de modelos en tiempo real en Amazon SageMaker

Amazon SageMaker es un servicio completamente administrado que brinda a cada desarrollador y científico de datos la capacidad de crear, entrenar e implementar rápidamente modelos de aprendizaje automático (ML) a escala. ML se realiza en la inferencia. SageMaker ofrece cuatro opciones de inferencia:

1. Inferencia en tiempo real
2. Inferencia sin servidor
3. Inferencia asíncrona
4. Transformación por lotes

Estas cuatro opciones se pueden clasificar en términos generales en opciones de inferencia en línea y por lotes. En Online Inference, se espera que las solicitudes se procesen a medida que llegan, y la aplicación consumidora espera una respuesta después de que se procese cada solicitud. Esto puede ocurrir de forma síncrona (inferencia en tiempo real, sin servidor) o asíncrona (inferencia asíncrona). En un patrón síncrono, la aplicación consumidora se bloquea y no puede continuar hasta que recibe una respuesta. Estas cargas de trabajo tienden a ser aplicaciones en tiempo real, como la detección de fraudes con tarjetas de crédito en línea, donde se esperan respuestas en el orden de milisegundos a segundos y las cargas útiles de solicitud son pequeñas (unos pocos MB). En el patrón asincrónico, la experiencia de la aplicación no está bloqueada (por ejemplo, enviar un reclamo de seguro a través de una aplicación móvil) y, por lo general, requiere tamaños de carga útil más grandes y/o tiempos de procesamiento más prolongados. En la inferencia sin conexión, una agregación (lote) de solicitudes de inferencia se procesan juntas y las respuestas se proporcionan solo después de que se haya procesado todo el lote. Por lo general, estas cargas de trabajo no son sensibles a la latencia, involucran grandes volúmenes (varios GB) de datos y se programan con una cadencia regular (por ejemplo, ejecutar la detección de objetos en las imágenes de la cámara de seguridad al final del día o procesar los datos de nómina al final del día). final de mes).

En los huesos desnudos, Inferencia en tiempo real de SageMaker consiste en un modelo(s), el marco/contenedor con el que está trabajando y la infraestructura/instancias que respaldan su punto final implementado. En esta publicación, exploraremos cómo puede crear e invocar un punto final de modelo único.

Elección de la opción de implementación del modelo

Elegir el tipo de inferencia correcto puede ser difícil, y la siguiente guía simple puede ayudarlo. No es un diagrama de flujo estricto, por lo que si encuentra que otra opción funciona mejor para usted, no dude en usarla. En particular, Real-Time Inference es una excelente opción para hospedar sus modelos cuando tiene una latencia baja y constante (del orden de milisegundos o segundos) y cargas de trabajo sensibles al rendimiento. Puede controlar el tipo de instancia y contar detrás de su punto final mientras también configura Autoescalado política para manejar el tráfico. Hay otras dos opciones de inferencia de SageMaker que también puede usar para crear un punto final. La inferencia asíncrona es cuando tiene grandes tamaños de carga útil y un ancho de banda de latencia casi en tiempo real. Esta es una buena opción, especialmente para los modelos NLP y Computer Vision que tienen tiempos de preprocesamiento más largos. La inferencia sin servidor es una excelente opción cuando tiene tráfico intermitente y no desea administrar el escalado de la infraestructura. La receta para crear un punto final sigue siendo la misma, independientemente del tipo de inferencia que elija. En esta publicación, nos centraremos en crear un punto final basado en instancias en tiempo real, pero puede adaptarlo fácilmente a cualquiera de las otras opciones de inferencia según su caso de uso. Por último, la inferencia por lotes se lleva a cabo sin conexión, por lo que puede proporcionar un conjunto de datos de los que desea obtener la inferencia y lo ejecutaremos. Esto también se basa en instancias, por lo que puede seleccionar la instancia óptima para su carga de trabajo. Como no hay un punto final en funcionamiento, solo paga por la duración del trabajo. Es bueno para procesar gigabytes de datos y la duración del trabajo puede ser de días. Hay funciones integradas para facilitar el trabajo con datos estructurados y optimizaciones para distribuir automáticamente los datos estructurados. Algunos ejemplos de casos de uso son el modelado de propensión, el mantenimiento predictivo y la predicción de rotación. Todo esto puede tener lugar fuera de línea de forma masiva porque no tiene que reaccionar a un evento específico.

Alojar un modelo en SageMaker Endpoints

En esencia, SageMaker Real-Time Endpoints consiste en un modelo y la infraestructura con la que elige respaldar el Endpoint. SageMaker usa contenedores para hospedar modelos, lo que significa que necesita un contenedor que configure correctamente el entorno para el marco que usa para cada modelo que proporciona. Por ejemplo, si está trabajando con un modelo de Sklearn, debe pasar los scripts/datos de su modelo dentro de un contenedor que configure correctamente Sklearn. Afortunadamente, SageMaker proporciona imágenes administradas para marcos populares, como TensorFlow, PyTorch, Sklearn y HuggingFace. Puede recuperar y utilizar estas imágenes utilizando el alto nivel SDK de SageMaker Python e inyecte los scripts y datos de su modelo en estos contenedores. En el caso de que SageMaker no tenga un contenedor compatible, también puede Construya su propio contenedor e inserte su propia imagen personalizada, instalando las dependencias que son necesarias para su modelo.

SageMaker admite modelos entrenados y previamente entrenados. En el párrafo anterior, cuando hablamos de secuencias de comandos/datos del modelo, nos referimos a este asunto. Puede montar una secuencia de comandos en su contenedor o, si tiene un artefacto de modelo previamente entrenado (por ejemplo, `modelo.joblib` para SKLearn), luego puede proporcionar esto junto con su imagen a SageMaker. Para entender SageMaker Inference, hay tres entidades principales que creará en el proceso de creación de Endpoint:

1. Entidad de modelo de SageMaker: aquí puede pasar los datos de su modelo entrenado/secuencia de comandos de modelo y la imagen con la que está trabajando, ya sea que sea propiedad de AWS o la haya creado usted.
2. Creación de configuración de punto final: aquí define su infraestructura, lo que significa que selecciona el tipo de instancia, el recuento, etc.
3. Creación de punto final: este es el punto final REST que aloja su modelo que está invocando para obtener una respuesta. Veamos cómo puede utilizar una imagen de SageMaker administrada y su propia imagen personalizada para implementar un punto final.

Requisitos de terminales en tiempo real

1. Antes de crear un punto final, debe comprender qué tipo de modelo desea alojar. Si es un modelo de Framework, como TensorFlow, PyTorch o MXNet, puede utilizar uno de los Imágenes preconstruidas de Framework.
   Si se trata de un modelo personalizado, o si desea total flexibilidad para crear el contenedor que SageMaker ejecutará para la inferencia, entonces puede crear su propio contenedor.

Puntos finales de SageMaker están formados por un Modelo de SageMaker y Configuración de punto final.
Si está utilizando Boto3, entonces crearía ambos objetos. De lo contrario, si está utilizando SageMaker Python SDK, la configuración de punto final se crea en su nombre cuando usa el .deploy(..) función.

Entidades de SageMaker:

• Modelo de SageMaker:
  • Contiene los detalles de la imagen de inferencia, la ubicación de los artefactos del modelo en Servicio de almacenamiento simple de Amazon (Amazon S3), configuración de la red, y Administración de acceso e identidad de AWS (IAM) Rol que utilizará el punto final.
    • SageMaker requiere que los artefactos de su modelo se compriman en un .tar.gz expediente. SageMaker extrae automáticamente este .tar.gz archivo en el /opt/ml/model/ directorio en su contenedor. Si está utilizando uno de los contenedores del marco, como TensorFlow, PyTorch o MXNet, entonces el contenedor espera que su estructura TAR sea la siguiente:
      • TensorFlow
        

        model.tar.gz/
        |--[model_version_number]/
        |--variables
        |--saved_model.pb
        code/
        |--inference.py
        |--requirements.txt

      • PyTorch
        

        model.tar.gz/
        |- model.pth
        |- code/
        |- inference.py
        |- requirements.txt # only for versions 1.3.1 and higher

      • MXNet
        

        model.tar.gz/
        |- model-symbol.json
        |- model-shapes.json
        |- model-0000.params
        |- code/
            |- inference.py
            |- requirements.txt # only for versions 1.6.0 and higher

      • aprender
        

        model.tar.gz/
        |- model.joblib
        | code/ 
        |- inference.py

    • Al utilizar una imagen de Framework, podemos proporcionar un script de punto de entrada personalizado, donde podemos implementar nuestro propio procesamiento previo y posterior. En nuestro caso, el script de inferencia está empaquetado en model.tar.gz en el directorio /code.

• • Configuración de punto final
    • Contiene la información de infraestructura necesaria para implementar SageMaker Model en el punto final.
    • Por ejemplo, aquí se especifica el modelo de SageMaker que creamos, así como el tipo de instancia y el recuento inicial de instancias.

Marcos y BYOC

• • Recuperación de imágenes de SageMaker
    • Esta parte no siempre es necesaria y el SDK de Python de SageMaker la abstrae a través de estimadores. Sin embargo, si desea poder recuperar una imagen administrada por SageMaker para extenderla, puede obtener las imágenes que están disponibles a través del SDK. El siguiente es un ejemplo de recuperación de una imagen TF 2.2 para inferencia.

      import sagemaker
      tf_image = sagemaker.image_uris.retreive(framework="tensorflow", region="us-east-1",
      image_scope = "inference", version = "2.2", instance_type = "ml.c5.xlarge)
      print(tf_image)

  • Marcos
    • En el caso de que desee implementar un modelo de marco, como TensorFlow, PyTorch o MXNet, todo lo que necesita son los artefactos del modelo.
    • Consulte la documentación para implementar modelos directamente desde artefactos de modelo para TensorFlow, PyTorcho MXNet.

• • Elegir entre 1P y BYOC
    • El SDK de SageMaker también abstrae el manejo de la imagen, como vio en la sección Marcos anterior. Tiene estimadores listos para usar para Sklearn, TensorFlow y PyTorch que seleccionan automáticamente la imagen para usted en función de la versión que ha seleccionado. Luego puede pasar un script de entrenamiento/inferencia a través de Modo de secuencia de comandos en estos estimadores.

      from sagemaker.pytorch import PyTorch #PyTorch Estimator within SageMaker SDK
      estimator_parameters = {"entry_point": "train_deploy_pytorch_without_dependencies.py",
      "source_dir": "pytorch_script","instance_type": train_instance_type,
      "instance_count": 1,"hyperparameters": hyperparameters,
      "role": role,"base_job_name": "pytorch-model","framework_version": "1.5",
      "py_version": "py3",}
      
      ## Model Training
      estimator = PyTorch(**estimator_parameters)estimator.fit(inputs)
      
      ## Deploy Trained model
      pytorch_predictor = estimator.deploy(initial_instance_count=1, instance_type="ml.m5.xlarge", endpoint_name=pytorch_endpoint_name)

    • No todos los paquetes e imágenes son compatibles con SageMaker y, en este caso, debe traiga su propio contenedor (BYOC). Esto significa crear un Dockerfile que configurará el entorno adecuado para el servicio de su modelo. Un ejemplo de esto es el módulo Spacy NLP, y no hay contenedores administrados de SageMaker para este marco. Por lo tanto, debe proporcionar un Dockerfile que instale Spacy. Dentro del contenedor, también monta los scripts de inferencia de su modelo. Analicemos rápidamente los componentes que proporciona en un formato Traiga su propio contenedor, ya que estos se mantienen consistentes para la mayoría de los ejemplos.
      • "nginx.conf" es el archivo de configuración para el front-end de nginx. No tendrá que editar este archivo, a menos que desee afinar estas partes.
      • "predictor.py" es el programa que realmente implementa el servidor web Flask y el código modelo para su aplicación. Puede tener más archivos o funciones de Python en su contenedor a los que puede llamar en este archivo.
      • "atender" es el programa iniciado cuando se inicia el contenedor para el alojamiento. Simplemente inicia el servidor gunicorn, que ejecuta varias instancias de la aplicación Flask definida en predictor.py. Al igual que nginx.conf, no es necesario que edite este archivo a menos que desee realizar más ajustes.
      • "tren" es el programa que se invoca cuando se ejecuta el contenedor para el entrenamiento. Modificará este programa para implementar su algoritmo de entrenamiento. Si trae un modelo o marco previamente entrenado como Spacy, entonces no necesita este archivo.
      • “wsgi.py“ es un pequeño contenedor que se usa para invocar la aplicación Flask. Debería poder tomar este archivo tal cual, a menos que haya cambiado el nombre de su archivo predictor.py. En ese caso, asegúrese de que se mapee correctamente aquí.

• • Guión de inferencia personalizado
    • Los contenedores de SageMaker Framework le brindan la flexibilidad de manejar el procesamiento previo y posterior de la solicitud y la carga del modelo mediante un script/inference.py de punto de entrada personalizado.
    • Consulte la documentación para crear un script inference.py personalizado para TensorFlow, PyTorch y MXNet.
  • Contenedor personalizado

Diferentes formas de interactuar con SageMaker Endpoints

Hay muchas opciones para usar SageMaker mediante programación, de modo que pueda llamar a sus modelos implementados para obtener inferencias. los Interfaz de línea de comandos de AWS (AWS CLI), API REST, Formación en la nube de AWS, Kit de desarrollo de la nube de AWS (CDK de AWS), y los SDK de AWS son herramientas comunes ofrecidas por AWS y ampliamente compatibles con otros servicios de AWS. Para SageMaker, también tenemos un SDK de SageMaker Python. Ahora, comparemos las diferentes opciones para crear, invocar y administrar SageMaker Endpoints.

Además de nuestras localidaded en CLI de SageMaker, hay dos formas programáticas de interactuar con Endpoints en SageMaker a través de los SDK. Veamos algunas diferencias entre SDK de SageMaker Python y SDK de Python para Boto3:

1. SDK "Python" de SageMaker de alto nivel: este SDK es una biblioteca de código abierto que proporciona una abstracción de mayor nivel diseñada específicamente para llamar a las API de SageMaker mediante programación mediante Python. La parte buena de este SDK es que es muy fácil llamar a las API de sagemaker, ya se ha hecho mucho trabajo pesado, como llamar a las API en modo síncrono/asincrónico (ayuda a evitar el sondeo), esquema de solicitud/respuesta más simple, mucho menos código y mucho código más simple. SageMaker Python SDK proporciona varias abstracciones de alto nivel para trabajar con SageMaker. El paquete está destinado a simplificar diferentes procesos de ML en SageMaker.
2. SDK de AWS de bajo nivel (SDK de Boto3): este SDK funciona en el nivel inferior al permitir que el usuario elija entre los lenguajes de programación admitidos y llame a cualquier servicio de AWS mediante programación. Esto no es solo específico de SageMaker, sino que se puede usar en general para todos los servicios de AWS. Los SDK de AWS de bajo nivel están disponibles en varios lenguajes de programación, como .NET, Python, Java, Node.js, etc. Uno de los SDK populares que se utilizan es boto3 python SDK, que es popular en la comunidad de científicos de datos para ML. Lo bueno de este SDK es que es muy liviano y está disponible por defecto instalado en AWS Lambda tiempo de ejecución. Además, puede utilizar este SDK para interactuar con cualquier servicio de AWS fuera de SageMaker.

Ambos SDK se pueden utilizar para las mismas tareas, pero en algunos casos es más intuitivo usar uno más que el otro. SageMaker Python SDK se recomienda para pruebas sencillas, mientras que AWS SDK/Boto3 se recomienda para casos de uso de producción para un mejor control del rendimiento. Por ejemplo, SageMaker como servicio proporciona imágenes prediseñadas y mantenidas para marcos populares, como Sklearn, PyTorch y TensorFlow. Puede ser particularmente útil usar SageMaker SDK para recuperar imágenes de aprendizaje profundo, entrenar modelos usando Estimadorese implemente fácilmente el modelo mediante una simple llamada a la API. Se puede encontrar un ejemplo para mostrar esto en acción esta página.

Por otro lado, a veces tiene modelos pre-entrenados o diferentes marcos que puede estar usando. Esto requiere una mayor cantidad de personalización y SageMaker SDK no siempre ofrece eso. Tenemos tres pasos importantes y las correspondientes llamadas a la API de boto3 que debemos ejecutar para implementar un punto final: Creación de modelos, Creación de configuración de punto finaly Creación de punto final. Las dos primeras entidades se abstrajeron con el SDK de SageMaker con nuestros marcos compatibles, pero vemos esos detalles con el SDK de Boto3. Se puede encontrar un ejemplo extenso para mostrar los pasos involucrados en el uso de un SDK de Boto3 para crear y administrar un punto final esta página.

Consideraciones del alojamiento de SageMaker

SageMaker Real-Time Inference tiene dos optimizaciones principales que puede considerar: 1/ Optimización del rendimiento y 2/ Optimización de costos. Veamos primero optimización de rendimiento, ya que cuando se trata de cargas de trabajo sensibles a la latencia, cada milisegundo es crucial. Hay diferentes perillas que puede ajustar para optimizar su latencia y rendimiento. A nivel de instancia, puede utilizar Recomendador de inferencia, nuestra herramienta de prueba de carga integrada, para ayudarlo a seleccionar el tipo de instancia correcto y contar para su carga de trabajo. Utilizar la combinación adecuada de cómputo lo ayudará con el rendimiento y el costo. También puede ajustar a nivel de contenedor y marco.
Las preguntas que debe hacerse incluyen:

1. ¿Qué marco estás usando?
2. ¿Hay alguna variable de entorno que pueda ajustar dentro de su contenedor?

Un ejemplo de esto es maximizar Rendimiento de TensorFlow con contenedores de SageMaker. Otro ejemplo de optimizaciones a nivel de contenedor es utilizando gRPC en lugar de REST detrás de su punto final. Por último, también puede optimizar a nivel de secuencia de comandos. ¿Tu código de inferencia está tomando más tiempo en ciertos bloques? La sincronización de todas y cada una de las líneas de su secuencia de comandos lo ayudará a capturar cualquier cuello de botella dentro de su código.

Hay tres formas de mirar mejorar la utilización de su terminal en tiempo real:

1. Endpoints multimodelo (MME)
   • Puede alojar miles de modelos detrás de un único punto final. Esto es perfecto para casos de uso en los que no necesita un punto final dedicado para cada uno de sus modelos. MME funciona mejor cuando los modelos tienen un tamaño y una latencia similares y pertenecen al mismo marco de ML. Por lo general, se pueden usar cuando no necesita llamar al mismo modelo en todo momento. Puede cargar dinámicamente el modelo respectivo en SageMaker Endpoint para atender su solicitud. Se puede encontrar un ejemplo que muestra MME en acción esta página. Si desea obtener más información sobre las diferentes advertencias y mejores prácticas para alojar modelos en MME, consulte la publicación esta página.
2. Puntos finales de varios contenedores (MCE)
   • En lugar de utilizar varios puntos finales para alojar varios contenedores, puede alojar hasta 15 contenedores en un solo punto final. Cada uno de estos contenedores puede ser invocado directamente. Por lo tanto, puede buscar hospedar modelos dispares de diferentes marcos, todo en un único punto final. Esta opción es mejor cuando los contenedores exhiben características de uso y rendimiento similares. Se puede encontrar un ejemplo que muestra MCE esta página. Si desea obtener más información sobre las diferentes advertencias y mejores prácticas para alojar modelos en MCE, consulte la publicación esta página.
3. Canalización de inferencia en serie (SIP)
   • Si tiene una canalización de pasos en su lógica de inferencia, puede utilizar la canalización de inferencia en serie (SIP). SIP le permite encadenar de 2 a 15 contenedores juntos detrás de un único punto final. SIP funciona bien cuando tiene pasos de preprocesamiento y posprocesamiento. Si desea obtener más información sobre los patrones de diseño para canalizaciones de inferencia en serie, consulte la publicación esta página.

La segunda optimización principal a tener en cuenta es el costo. La inferencia en tiempo real es una de las tres opciones dentro de la creación de puntos finales de SageMaker. SageMaker Endpoints se ejecuta en todo momento a menos que se elimine. Por lo tanto, debe buscar mejorar la utilización del punto final, lo que a su vez proporciona una relación costo-beneficio.

SageMaker también ofrece Planes de Ahorro. Los Planes de Ahorro pueden reducir sus costos hasta en un 64%. Este es un compromiso de 1 o 3 años a una cantidad constante de uso ($/hora). Mira esto liga para más información. y mira esto liga para optimizar los costos de Inference en Amazon SageMaker.

Conclusión

En esta publicación, le mostramos algunas de las mejores prácticas para elegir entre diferentes opciones de hospedaje de modelos en SageMaker. Discutimos los requisitos de SageMaker Endpoint y también contrastamos los requisitos y la funcionalidad de Framework y BYOC. Además, hablamos sobre las diferentes formas en que puede aprovechar los puntos finales en tiempo real para alojar sus modelos ML en producción. de una manera rentable, y tienen un alto rendimiento.

Ver el correspondiente Repositorio GitHub y prueba los ejemplos.

---

Sobre los autores

Raghu Ramesha es Arquitecto de soluciones de aprendizaje automático en el equipo de servicios de Amazon SageMaker. Se enfoca en ayudar a los clientes a crear, implementar y migrar cargas de trabajo de producción de ML a SageMaker a escala. Se especializa en dominios de aprendizaje automático, IA y visión por computadora, y tiene una maestría en Ciencias de la Computación de UT Dallas. En su tiempo libre le gusta viajar y la fotografía.

Ram Vegiraju es un arquitecto de ML en el equipo de servicio Sagemaker. Se enfoca en ayudar a los clientes a construir y optimizar sus soluciones AI/ML en Amazon Sagemaker. En su tiempo libre, le encanta viajar y escribir.

marc karp es un Arquitecto de ML con el equipo de Servicio de SageMaker. Se enfoca en ayudar a los clientes a diseñar, implementar y administrar cargas de trabajo de ML a escala. En su tiempo libre le gusta viajar y explorar nuevos lugares.

Patel Dhawal es Arquitecto Principal de Aprendizaje Automático en AWS. Ha trabajado con organizaciones que van desde grandes empresas hasta empresas emergentes medianas en problemas relacionados con la computación distribuida y la inteligencia artificial. Se enfoca en el aprendizaje profundo, incluidos los dominios de PNL y visión por computadora. Ayuda a los clientes a lograr una inferencia de modelos de alto rendimiento en Amazon SageMaker.

Saurabh Trikande es gerente sénior de productos para Amazon SageMaker Inference. Le apasiona trabajar con clientes y está motivado por el objetivo de democratizar el aprendizaje automático. Se enfoca en los desafíos principales relacionados con la implementación de aplicaciones de ML complejas, modelos de ML de múltiples inquilinos, optimizaciones de costos y hacer que la implementación de modelos de aprendizaje profundo sea más accesible. En su tiempo libre, a Saurabh le gusta caminar, aprender sobre tecnologías innovadoras, seguir TechCrunch y pasar tiempo con su familia.