Las aplicaciones de aprendizaje automático (ML) son complejas de implementar y, a menudo, requieren la capacidad de hiperescala, y tienen requisitos de latencia ultrabaja y presupuestos de costos estrictos. Los casos de uso, como la detección de fraudes, las recomendaciones de productos y la predicción del tráfico, son ejemplos en los que los milisegundos importan y son fundamentales para el éxito comercial. Se deben cumplir estrictos acuerdos de nivel de servicio (SLA), y una solicitud típica puede requerir varios pasos, como preprocesamiento, transformación de datos, ingeniería de funciones, lógica de selección de modelos, agregación de modelos y posprocesamiento.

La implementación de modelos ML a escala con costos optimizados y eficiencias informáticas puede ser una tarea abrumadora y engorrosa. Cada modelo tiene sus propios méritos y dependencias en función de las fuentes de datos externas, así como del entorno de tiempo de ejecución, como la potencia de CPU/GPU de los recursos informáticos subyacentes. Una aplicación puede requerir múltiples modelos de ML para atender una sola solicitud de inferencia. En ciertos escenarios, una solicitud puede fluir a través de múltiples modelos. No existe un enfoque único para todos, y es importante que los profesionales de ML busquen métodos probados para abordar los desafíos recurrentes de alojamiento de ML. Esto ha llevado a la evolución de los patrones de diseño para el alojamiento de modelos ML.

En esta publicación, exploramos patrones de diseño comunes para crear aplicaciones ML en Amazon SageMaker.

Patrones de diseño para crear aplicaciones de aprendizaje automático

Veamos los siguientes patrones de diseño para usar para hospedar aplicaciones ML.

Aplicaciones de aprendizaje automático basadas en un único modelo

Esta es una excelente opción cuando su caso de uso de ML requiere un solo modelo para atender una solicitud. El modelo se implementa en una infraestructura informática dedicada con la capacidad de escalar en función del tráfico de entrada. Esta opción también es ideal cuando la aplicación cliente tiene un requisito de inferencia de baja latencia (del orden de milisegundos o segundos).

Aplicaciones de ML basadas en modelos múltiples

Para que el hospedaje sea más rentable, este patrón de diseño le permite hospedar varios modelos en la misma infraestructura de inquilino. Múltiples modelos de ML pueden compartir los recursos del host o del contenedor, incluido el almacenamiento en caché de los modelos de ML más utilizados en la memoria, lo que da como resultado una mejor utilización de la memoria y los recursos informáticos. Según los tipos de modelos que elija implementar, el cohospedaje de modelos puede usar los siguientes métodos:

• Alojamiento multimodelo – Esta opción le permite alojar varios modelos utilizando un contenedor de servicio compartido en un solo punto final. Esta característica es ideal cuando tiene una gran cantidad de modelos similares que puede servir a través de un contenedor de servicio compartido y no necesita acceder a todos los modelos al mismo tiempo.
• Alojamiento multicontenedor – Esta opción es ideal cuando tiene varios modelos que se ejecutan en diferentes pilas de servicio con necesidades de recursos similares y cuando los modelos individuales no tienen suficiente tráfico para utilizar la capacidad total de las instancias de punto final. El alojamiento de múltiples contenedores le permite implementar múltiples contenedores que usan diferentes modelos o marcos en un único punto final. Los modelos pueden ser completamente heterogéneos, con su propia pila de servicio independiente.
• Conjuntos de modelos – En muchos casos de uso de producción, a menudo puede haber muchos modelos ascendentes que alimentan entradas a un modelo descendente dado. Aquí es donde los conjuntos son útiles. Los patrones de conjunto implican mezclar la salida de uno o más modelos base para reducir el error de generalización de la predicción. Los modelos base pueden ser diversos y entrenados por diferentes algoritmos. Los conjuntos de modelos pueden superar a los modelos individuales porque el error de predicción del modelo disminuye cuando se utiliza el enfoque de conjunto.

Los siguientes son casos de uso comunes de patrones de conjuntos y sus correspondientes diagramas de patrones de diseño:

• Dispersión-reunión – En un patrón de dispersión y recopilación, una solicitud de inferencia se enruta a una serie de modelos. A continuación, se utiliza un agregador para recopilar las respuestas y destilarlas en una sola respuesta de inferencia. Por ejemplo, un caso de uso de clasificación de imágenes puede usar tres modelos diferentes para realizar la tarea. El patrón de dispersión y recopilación le permite combinar resultados de inferencias ejecutadas en tres modelos diferentes y elegir el modelo de clasificación más probable.

• Modelo agregado – En un patrón de agregación, se promedian los resultados de varios modelos. Para los modelos de clasificación, se evalúan las predicciones de varios modelos para determinar la clase que recibió la mayor cantidad de votos y se trata como el resultado final del conjunto. Por ejemplo, en un problema de clasificación de dos clases para clasificar un conjunto de frutas como naranjas o manzanas, si dos modelos votan por una naranja y un modelo vota por una manzana, la salida agregada será una naranja. La agregación ayuda a combatir la imprecisión en modelos individuales y hace que la salida sea más precisa.

• Selección dinámica – Otro patrón para los modelos de conjunto es realizar dinámicamente la selección del modelo para los atributos de entrada dados. Por ejemplo, en una entrada dada de imágenes de frutas, si la entrada contiene una naranja, se utilizará el modelo A porque está especializado en naranjas. Si la entrada contiene una manzana, se usará el modelo B porque está especializado para manzanas.

• Aplicaciones de ML de inferencia en serie – Con un patrón de inferencia en serie, también conocido como canalización de inferencia, los casos de uso tienen requisitos para preprocesar los datos entrantes antes de invocar un modelo de ML preentrenado para generar inferencias. Además, en algunos casos, es posible que las inferencias generadas deban procesarse aún más, de modo que las aplicaciones posteriores puedan consumirlas fácilmente. Una canalización de inferencia le permite reutilizar el mismo código de preprocesamiento utilizado durante el entrenamiento del modelo para procesar los datos de solicitud de inferencia utilizados para las predicciones.

• Lógica de negocios – La producción de ML siempre involucra la lógica comercial. Los patrones de lógica empresarial involucran todo lo que se necesita para realizar una tarea de ML que no es una inferencia de modelo de ML. Esto incluye cargar el modelo desde Servicio de almacenamiento simple de Amazon (Amazon S3), por ejemplo, búsquedas en la base de datos para validar la entrada, obtener funciones precalculadas del almacén de funciones, etc. Una vez que se completan estos pasos de lógica comercial, las entradas se pasan a los modelos ML.

Opciones de inferencia de ML

Para la implementación del modelo, es importante trabajar hacia atrás desde su caso de uso. ¿Cuál es la frecuencia de la predicción? ¿Espera tráfico en vivo a su aplicación y respuesta en tiempo real a sus clientes? ¿Tiene muchos modelos entrenados para diferentes subconjuntos de datos para el mismo caso de uso? ¿El tráfico de predicción fluctúa? ¿Es la latencia de la inferencia una preocupación? Según estos detalles, todos los patrones de diseño anteriores se pueden implementar mediante las siguientes opciones de implementación:

• Inferencia en tiempo real – La inferencia en tiempo real es ideal para cargas de trabajo de inferencia en las que tiene requisitos de baja latencia, interactivos y en tiempo real. Las cargas de trabajo de inferencia de ML en tiempo real pueden incluir una aplicación de ML basada en un solo modelo, donde una aplicación requiere solo un modelo de ML para atender una sola solicitud, o una aplicación de ML basada en varios modelos, donde una aplicación requiere múltiples modelos de ML para atender una sola solicitud. solicitud.
• Inferencia casi en tiempo real (asincrónica) – Con inferencia casi en tiempo real, puede poner en cola las solicitudes entrantes. Esto se puede utilizar para ejecutar inferencias en entradas que son cientos de MB. Funciona casi en tiempo real y permite a los usuarios usar la entrada para la inferencia y leer la salida desde el punto final desde un depósito S3. Puede ser especialmente útil en casos con NLP y visión por computadora, donde hay grandes cargas útiles que requieren tiempos de preprocesamiento más prolongados.
• Inferencia por lotes – La inferencia por lotes se puede utilizar para ejecutar la inferencia fuera de línea en un gran conjunto de datos. Debido a que se ejecuta sin conexión, la inferencia por lotes no ofrece la latencia más baja. Aquí, la solicitud de inferencia se procesa con un activador programado o basado en eventos de un trabajo de inferencia por lotes.
• Inferencia sin servidor – La inferencia sin servidor es ideal para cargas de trabajo que tienen períodos de inactividad entre picos de tráfico y pueden tolerar algunos segundos adicionales de latencia (inicio en frío) para la primera invocación después de un período de inactividad. Por ejemplo, un servicio de chatbot o una aplicación para procesar formularios o analizar datos de documentos. En este caso, es posible que desee una opción de inferencia en línea que pueda aprovisionar y escalar automáticamente la capacidad informática en función del volumen de solicitudes de inferencia. Y durante el tiempo de inactividad, debería poder apagar completamente la capacidad informática para que no se le cobre. La inferencia sin servidor elimina el trabajo pesado indiferenciado de seleccionar y administrar servidores al iniciar automáticamente los recursos informáticos y escalarlos hacia adentro y hacia afuera según el tráfico.

Use las funciones de fitness para seleccionar la opción de inferencia ML correcta

Decidir cuál es la opción de hospedaje adecuada es importante porque afecta a los usuarios finales representados por sus aplicaciones. Para este propósito, estamos tomando prestado el concepto de funciones de fitness, que fue acuñado por Neal Ford y sus colegas de AWS Partner ThoughtWorks en su trabajo Construcción de arquitecturas evolutivas. Las funciones de aptitud brindan una evaluación prescriptiva de varias opciones de alojamiento en función de los objetivos del cliente. Las funciones de fitness le ayudan a obtener los datos necesarios para permitir la evolución planificada de su arquitectura. Establecen valores medibles para evaluar qué tan cerca está su solución de lograr sus objetivos establecidos. Las funciones de fitness pueden y deben adaptarse a medida que la arquitectura evoluciona para guiar el proceso de cambio deseado. Esto proporciona a los arquitectos una herramienta para guiar a sus equipos mientras mantienen la autonomía del equipo.

Hay cinco funciones principales de aptitud que preocupan a los clientes cuando se trata de seleccionar la opción de inferencia de ML adecuada para alojar sus modelos y aplicaciones de ML.

Implementación de modelos con SageMaker

SageMaker es un servicio de AWS totalmente administrado que brinda a todos los desarrolladores y científicos de datos la capacidad de crear, entrenar e implementar rápidamente modelos de aprendizaje automático a escala. Con la inferencia de SageMaker, puede implementar sus modelos ML en puntos finales alojados y obtener resultados de inferencia. SageMaker ofrece una amplia selección de hardware y funciones para satisfacer sus requisitos de carga de trabajo, lo que le permite seleccionar más de 70 tipos de instancias con aceleración de hardware. SageMaker también puede proporcionar recomendaciones de tipos de instancias de inferencia mediante una nueva característica llamada SageMaker Inference Recommender, en caso de que no esté seguro de cuál sería la más óptima para su carga de trabajo.

Puede elegir las opciones de implementación que mejor se adapten a sus casos de uso, como inferencia en tiempo real, asíncrono, por lotes e incluso puntos finales sin servidor. Además, SageMaker ofrece varias estrategias de implementación como canary, azul / verde, sombra, y pruebas A/B para la implementación de modelos, junto con una implementación rentable con múltiples modelos, puntos finales de múltiples contenedores y escalabilidad elástica. Con la inferencia de SageMaker, puede ver las métricas de rendimiento de sus terminales en Reloj en la nube de Amazon, escalar puntos finales automáticamente en función del tráfico y actualice sus modelos en producción sin perder disponibilidad.

SageMaker ofrece cuatro opciones para implementar su modelo para que pueda comenzar a hacer predicciones:

• Inferencia en tiempo real – Esto es adecuado para cargas de trabajo con requisitos de latencia de milisegundos, tamaños de carga útil de hasta 6 MB y tiempos de procesamiento de hasta 60 segundos.
• Transformación por lotes – Esto es ideal para predicciones fuera de línea en grandes lotes de datos que están disponibles por adelantado.
• inferencia asíncrona – Esto está diseñado para cargas de trabajo que no tienen requisitos de latencia inferiores a un segundo, tamaños de carga útil de hasta 1 GB y tiempos de procesamiento de hasta 15 minutos.
• Inferencia sin servidor – Con la inferencia sin servidor, puede implementar rápidamente modelos ML para la inferencia sin tener que configurar o administrar la infraestructura subyacente. Además, solo paga por la capacidad informática utilizada para procesar solicitudes de inferencia, lo que es ideal para cargas de trabajo intermitentes.

El siguiente diagrama puede ayudarlo a comprender las opciones de implementación del modelo de hospedaje de SageMaker junto con las evaluaciones de funciones de aptitud asociadas.

Exploremos cada una de las opciones de implementación con más detalle.

Inferencia en tiempo real en SageMaker

Se recomienda la inferencia en tiempo real de SageMaker si tiene un tráfico constante y necesita una latencia más baja y constante para sus solicitudes con tamaños de carga útil de hasta 6 MB y tiempos de procesamiento de hasta 60 segundos. Implementa su modelo en los servicios de alojamiento de SageMaker y obtiene un punto final que se puede usar para la inferencia. Estos puntos finales están totalmente administrados y admiten el escalado automático. La inferencia en tiempo real es popular para casos de uso en los que espera una respuesta sincrónica de baja latencia con patrones de tráfico predecibles, como recomendaciones personalizadas para productos y servicios o casos de uso de detección de fraude transaccional.

Por lo general, una aplicación cliente envía solicitudes al extremo HTTPS de SageMaker para obtener inferencias de un modelo implementado. Puede implementar varias variantes de un modelo en el mismo punto final HTTPS de SageMaker. Esto es útil para probar variaciones de un modelo en producción. El escalado automático le permite ajustar dinámicamente la cantidad de instancias aprovisionadas para un modelo en respuesta a los cambios en su carga de trabajo.

La siguiente tabla proporciona orientación sobre cómo evaluar la inferencia en tiempo real de SageMaker en función de las funciones de aptitud.

Inferencia asíncrona en SageMaker

La inferencia asíncrona de SageMaker es una nueva capacidad de SageMaker que pone en cola las solicitudes entrantes y las procesa de forma asíncrona. Esta opción es ideal para solicitudes con grandes tamaños de carga útil (hasta 1 GB), largos tiempos de procesamiento (hasta 15 minutos) y requisitos de latencia casi en tiempo real. Las cargas de trabajo de ejemplo para la inferencia asincrónica incluyen empresas de atención médica que procesan imágenes biomédicas de alta resolución o videos como ecocardiogramas para detectar anomalías. Estas aplicaciones reciben ráfagas de tráfico entrante en diferentes momentos del día y requieren procesamiento casi en tiempo real a bajo costo. Los tiempos de procesamiento de estas solicitudes pueden oscilar en el orden de los minutos, lo que elimina la necesidad de ejecutar inferencias en tiempo real. En su lugar, las cargas útiles de entrada se pueden procesar de forma asíncrona desde un almacén de objetos como Amazon S3 con colas automáticas y un umbral de simultaneidad predefinido. Tras el procesamiento, SageMaker coloca la respuesta de inferencia en la ubicación de Amazon S3 devuelta anteriormente. Opcionalmente, puede optar por recibir notificaciones de éxito o error a través de Servicio de notificación simple de Amazon (red social de Amazon).

La siguiente tabla proporciona orientación sobre cómo evaluar la inferencia asincrónica de SageMaker en función de las funciones de aptitud.

Inferencia por lotes en SageMaker

La transformación por lotes de SageMaker es ideal para predicciones fuera de línea en grandes lotes de datos que están disponibles por adelantado. La característica de transformación por lotes es un método de alto rendimiento y alto rendimiento para transformar datos y generar inferencias. Es ideal para escenarios en los que maneja grandes lotes de datos, no necesita una latencia inferior a un segundo o necesita preprocesar y transformar los datos de entrenamiento. Los clientes en ciertos dominios, como la publicidad y el marketing o la atención médica, a menudo necesitan hacer predicciones fuera de línea en conjuntos de datos de hiperescala donde el alto rendimiento suele ser el objetivo del caso de uso y la latencia no es una preocupación.

Cuando se inicia un trabajo de transformación por lotes, SageMaker inicializa las instancias informáticas y distribuye la carga de trabajo de inferencia entre ellas. Libera los recursos cuando se completan los trabajos, por lo que solo paga por lo que se utilizó durante la ejecución de su trabajo. Cuando se completa el trabajo, SageMaker guarda los resultados de la predicción en un depósito de S3 que usted especifique. Las tareas de inferencia por lotes suelen ser buenas candidatas para el escalado horizontal. Cada trabajador dentro de un clúster puede operar en un subconjunto diferente de datos sin necesidad de intercambiar información con otros trabajadores. AWS ofrece varias opciones de almacenamiento y computación que permiten el escalado horizontal. Las cargas de trabajo de ejemplo para la transformación por lotes de SageMaker incluyen aplicaciones fuera de línea, como aplicaciones bancarias para predecir la rotación de clientes, donde se puede programar un trabajo fuera de línea para que se ejecute periódicamente.

La siguiente tabla proporciona orientación sobre cómo evaluar la transformación por lotes de SageMaker en función de las funciones de aptitud.

Inferencia sin servidor en SageMaker

La inferencia sin servidor de SageMaker le permite implementar modelos ML para la inferencia sin tener que configurar o administrar la infraestructura subyacente. Según el volumen de solicitudes de inferencia que recibe su modelo, la inferencia sin servidor de SageMaker aprovisiona, escala y desactiva automáticamente la capacidad informática. Como resultado, solo paga por el tiempo de cómputo para ejecutar su código de inferencia y la cantidad de datos procesados, no por el tiempo de inactividad. Puede usar los algoritmos integrados de SageMaker y los contenedores de servicio del marco de ML para implementar su modelo en un punto final de inferencia sin servidor o elegir traer su propio contenedor. Si el tráfico se vuelve predecible y estable, puede actualizar fácilmente desde un punto final de inferencia sin servidor a un punto final en tiempo real de SageMaker sin necesidad de realizar cambios en la imagen de su contenedor. Con la inferencia sin servidor, también se beneficia de otras funciones de SageMaker, incluidas las métricas integradas, como el recuento de invocaciones, las fallas, la latencia, las métricas de host y los errores en CloudWatch.

La siguiente tabla proporciona orientación sobre cómo evaluar la inferencia sin servidor de SageMaker en función de las funciones de aptitud.

Patrones de diseño de hospedaje de modelos en SageMaker

Los extremos de inferencia de SageMaker usan contenedores Docker para hospedar modelos de aprendizaje automático. Los contenedores le permiten empaquetar software en unidades estandarizadas que se ejecutan de manera uniforme en cualquier plataforma compatible con Docker. Esto garantiza la portabilidad entre plataformas, implementaciones de infraestructura inmutable y una administración de cambios e implementaciones de CI/CD más sencillas. SageMaker proporciona contenedores administrados preconstruidos para marcos populares como Apache MXNet, TensorFlow, PyTorch, Sklearn y Hugging Face. Para obtener una lista completa de las imágenes de contenedor de SageMaker disponibles, consulte Imágenes de contenedores de aprendizaje profundo disponibles. En el caso de que SageMaker no tenga un contenedor compatible, también puede crear su propio contenedor (BYOC) y enviar su propia imagen personalizada, instalando las dependencias necesarias para su modelo.

Para implementar un modelo en SageMaker, necesita un contenedor (contenedores de marco administrado de SageMaker o BYOC) y una instancia informática para alojar el contenedor. SageMaker admite varias opciones avanzadas para patrones de diseño de hospedaje de modelos de aprendizaje automático comunes en los que los modelos se pueden hospedar en un solo contenedor o cohospedar en un contenedor compartido.

Una aplicación de ML en tiempo real puede usar un solo modelo o varios modelos para atender una sola solicitud de predicción. El siguiente diagrama muestra varios escenarios de inferencia para una aplicación ML.

Exploremos una opción de alojamiento de SageMaker adecuada para cada uno de los escenarios de inferencia anteriores. Puede consultar las funciones de aptitud para evaluar si es la opción correcta para el caso de uso dado.

Hospedaje de una aplicación de aprendizaje automático basada en un solo modelo

Hay varias opciones para hospedar aplicaciones de aprendizaje automático basadas en un solo modelo mediante los servicios de hospedaje de SageMaker, según el escenario de implementación.

Endpoint de modelo único

Los extremos de un solo modelo de SageMaker le permiten alojar un modelo en un contenedor alojado en instancias dedicadas para lograr una baja latencia y un alto rendimiento. Estos puntos finales están totalmente administrados y admiten el escalado automático. Puede configurar el punto final de modelo único como un punto final aprovisionado en el que pasa la configuración de la infraestructura del punto final, como el tipo y el recuento de instancias, o un punto final sin servidor en el que SageMaker inicia automáticamente los recursos informáticos y los escala hacia adentro y hacia afuera según el tráfico, eliminando la necesidad para elegir tipos de instancias o administrar políticas de escalado. Los puntos finales sin servidor son para aplicaciones con tráfico intermitente o impredecible.

El siguiente diagrama muestra escenarios de inferencia de punto final de modelo único.

La siguiente tabla proporciona orientación sobre la evaluación de las funciones de aptitud para un punto final de modelo único aprovisionado. Para las evaluaciones de la función de aptitud de los puntos finales sin servidor, consulte la sección de puntos finales sin servidor en esta publicación.

Co-anfitrión de múltiples modelos

Cuando se trata de una gran cantidad de modelos, implementar cada uno en un punto final individual con un contenedor e instancia dedicados puede generar un aumento significativo en el costo. Además, también se vuelve difícil administrar tantos modelos en producción, específicamente cuando no necesita invocar todos los modelos al mismo tiempo, pero aún necesita que estén disponibles en todo momento. El alojamiento conjunto de varios modelos en los mismos recursos informáticos subyacentes facilita la gestión de las implementaciones de ML a escala y reduce los costos de alojamiento mediante un mayor uso del punto final y sus recursos informáticos subyacentes. SageMaker es compatible con opciones avanzadas de cohospedaje de modelos, como punto final multimodelo (MME) para modelos homogéneos y punto final multicontenedor (MCE) para modelos heterogéneos. Los modelos homogéneos usan el mismo marco de ML en un contenedor de servicio compartido, mientras que los modelos heterogéneos le permiten implementar múltiples contenedores de servicio que usan diferentes modelos o marcos en un único punto final.

El siguiente diagrama muestra las opciones de alojamiento compartido de modelos mediante SageMaker.

Puntos finales de varios modelos de SageMaker

SageMaker MME le permite alojar múltiples modelos utilizando un contenedor de servicio compartido en un solo punto final. Esta es una solución escalable y rentable para implementar una gran cantidad de modelos que se adaptan al mismo caso de uso, marco o lógica de inferencia. Los MME pueden atender solicitudes dinámicamente según el modelo invocado por la persona que llama. También reduce la sobrecarga de implementación porque SageMaker administra la carga de modelos en la memoria y los escala en función de los patrones de tráfico hacia ellos. Esta característica es ideal cuando tiene una gran cantidad de modelos similares que puede servir a través de un contenedor de servicio compartido y no necesita acceder a todos los modelos al mismo tiempo. Los puntos finales de varios modelos también permiten el uso compartido de recursos de memoria en todos sus modelos. Esto funciona mejor cuando los modelos son bastante similares en tamaño y latencia de invocación, lo que permite que las MME utilicen las instancias de manera efectiva en todos los modelos. Los MME de SageMaker admiten el alojamiento de modelos respaldados por CPU y GPU. Mediante el uso de modelos respaldados por GPU, puede reducir los costos de implementación de su modelo a través de un mayor uso del punto final y sus instancias informáticas aceleradas subyacentes. Para un caso de uso real de MME, consulte Cómo escalar la inferencia de aprendizaje automático para casos de uso de SaaS multiinquilino.

La siguiente tabla proporciona orientación sobre la evaluación de las funciones de aptitud para las MME.

Puntos finales de varios contenedores de SageMaker

SageMaker MCE Admite la implementación de hasta 15 contenedores que usan diferentes modelos o marcos en un único punto final, y los invoca de forma independiente o en secuencia para lograr inferencias de baja latencia y ahorrar costos. Los modelos pueden ser completamente heterogéneos, con su propia pila de servicio independiente. Alojar de forma segura varios modelos de diferentes marcos en una sola instancia podría ahorrarle hasta un 90 % en costos.

Los patrones de invocación de MCE son los siguientes:

• Canalizaciones de inferencia – Los contenedores en un MME se pueden invocar en una secuencia lineal, también conocida como canalización de inferencia en serie. Por lo general, se utilizan para separar el preprocesamiento, la inferencia de modelos y el posprocesamiento en contenedores independientes. La salida del contenedor actual se pasa como entrada al siguiente. Se representan como un único modelo de canalización en SageMaker. Una canalización de inferencia se puede implementar como un MME, donde uno de los contenedores de la canalización puede atender solicitudes de forma dinámica en función del modelo que se invoque.
• Invocación directa - Con invocación directa, se puede enviar una solicitud a un contenedor de inferencia específico alojado en un MCE.

La siguiente tabla proporciona orientación sobre la evaluación de las funciones de aptitud para los MCE.

Hospedaje de una aplicación de aprendizaje automático basada en varios modelos

Muchas aplicaciones comerciales necesitan usar múltiples modelos de ML para atender una sola solicitud de predicción a sus consumidores. Por ejemplo, una empresa minorista que quiere brindar recomendaciones a sus usuarios. La aplicación ML en este caso de uso puede querer usar diferentes modelos personalizados para recomendar diferentes categorías de productos. Si la empresa desea agregar personalización a las recomendaciones mediante el uso de información de usuario individual, la cantidad de modelos personalizados aumenta aún más. Hospedar cada modelo personalizado en una instancia informática distinta no solo tiene un costo prohibitivo, sino que también genera una infrautilización de los recursos de hospedaje si no se usan todos los modelos con frecuencia. SageMaker ofrece opciones de hospedaje eficientes para aplicaciones de aprendizaje automático basadas en varios modelos.

El siguiente diagrama muestra opciones de hospedaje de varios modelos para un único punto de conexión con SageMaker.

Canalización de inferencia en serie

Una canalización de inferencia es un modelo de SageMaker que se compone de una secuencia lineal de 2 a 15 contenedores que procesan solicitudes de inferencias sobre datos. Utiliza una canalización de inferencia para definir e implementar cualquier combinación de algoritmos integrados de SageMaker entrenados previamente y sus propios algoritmos personalizados empaquetados en contenedores de Docker. Puede usar una canalización de inferencia para combinar tareas de ciencia de datos de preprocesamiento, predicciones y posprocesamiento. La salida de un contenedor se pasa como entrada al siguiente. Al definir los contenedores para un modelo de canalización, también especifica el orden en que se ejecutan los contenedores. Se representan como un único modelo de canalización en SageMaker. La canalización de inferencia se puede implementar como un MME, donde uno de los contenedores de la canalización puede atender solicitudes de forma dinámica en función del modelo que se invoque. También puede ejecutar un transformación por lotes trabajo con una canalización de inferencia. Las canalizaciones de inferencia están completamente administradas.

La siguiente tabla proporciona orientación sobre cómo evaluar las funciones de adecuación para el hospedaje de modelos de ML mediante una canalización de inferencia en serie.

Implementación de conjuntos de modelos (Triton DAG):

SageMaker ofrece integración con Servidor de inferencia NVIDIA Triton a Contenedores del servidor de inferencia Triton. Estos contenedores incluyen NVIDIA Triton Inference Server, soporte para marcos de ML comunes y variables de entorno útiles que le permiten optimizar el rendimiento en SageMaker. Con las imágenes de contenedor de NVIDIA Triton, puede servir fácilmente modelos ML y beneficiarse de las optimizaciones de rendimiento, el procesamiento por lotes dinámico y la compatibilidad con varios marcos que proporciona NVIDIA Triton. Triton ayuda a maximizar la utilización de GPU y CPU, lo que reduce aún más el costo de la inferencia.

En los casos de uso comercial donde las aplicaciones de ML usan varios modelos para atender una solicitud de predicción, si cada modelo usa un marco diferente o está alojado en una instancia separada, puede generar una mayor carga de trabajo y costos, así como un aumento en la latencia general. SageMaker NVIDIA Triton Inference Server admite la implementación de modelos de todos los marcos principales, como TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT y Python/C++, formatos de modelo y más. El conjunto de modelos Triton representa una canalización de uno o más modelos o lógica de preprocesamiento y posprocesamiento, y la conexión de los tensores de entrada y salida entre ellos. Una única solicitud de inferencia a un conjunto desencadena la ejecución de toda la canalización. Triton también tiene varios algoritmos de programación y procesamiento por lotes integrados que combinan solicitudes de inferencia individuales para mejorar el rendimiento de la inferencia. Estas decisiones de programación y procesamiento por lotes son transparentes para el cliente que solicita la inferencia. Los modelos se pueden ejecutar en CPU o GPU para obtener la máxima flexibilidad y admitir requisitos informáticos heterogéneos.

El alojamiento de múltiples modelos respaldados por GPU en puntos finales de múltiples modelos es compatible a través de la Servidor de inferencia SageMaker Triton. El servidor de inferencia NVIDIA Triton se ha ampliado para implementar un Contrato API MME, para integrarse con las MME. Puede usar NVIDIA Triton Inference Server, que crea una configuración de repositorio de modelos para diferentes backends de marco, para implementar un MME con escalado automático. Esta característica le permite escalar cientos de modelos hiperpersonalizados que están ajustados para satisfacer las experiencias únicas del usuario final en aplicaciones de IA. También puede usar esta característica para lograr el rendimiento de precio necesario para su aplicación de inferencia usando GPU fraccionarias. Para obtener más información, consulte Ejecute varios modelos de aprendizaje profundo en GPU con puntos de enlace de varios modelos de Amazon SageMaker.

La siguiente tabla proporciona orientación sobre cómo evaluar las funciones de aptitud para el hospedaje de modelos de ML mediante MME con compatibilidad con GPU en contenedores de inferencia Triton. Para obtener información sobre las evaluaciones de la función de aptitud de los puntos finales de modelo único y los puntos finales sin servidor, consulte las secciones anteriores de esta publicación.

Mejores prácticas

Considere las siguientes mejores prácticas:

• Alta cohesión y bajo acoplamiento entre modelos – Aloje los modelos en el mismo contenedor que tiene alta cohesión (impulsa la funcionalidad de un solo negocio) y encapsúlelos juntos para facilitar la actualización y la capacidad de administración. Al mismo tiempo, desacople esos modelos entre sí (alójelos en un contenedor diferente) para que pueda actualizar fácilmente un modelo sin afectar a otros modelos. Aloje varios modelos que utilicen diferentes contenedores detrás de un punto final y los invoque de forma independiente o agregue lógica de preprocesamiento y posprocesamiento del modelo como una canalización de inferencia en serie.
• latencia de inferencia – Agrupe los modelos impulsados ​​por la funcionalidad de un solo negocio y alójelos en un solo contenedor para minimizar la cantidad de saltos y, por lo tanto, minimizar la latencia general. Hay otras advertencias, como si los modelos agrupados usan múltiples marcos; también puede optar por hospedar en varios contenedores, pero ejecutarlo en el mismo host para reducir la latencia y minimizar los costos.
• Agrupar lógicamente modelos de ML con alta cohesión – El grupo lógico puede estar formado por modelos que son homogéneos (por ejemplo, todos los modelos XGBoost) o heterogéneos (por ejemplo, algunos XGBoost y algunos BERT). Puede consistir en modelos que se comparten entre múltiples funcionalidades comerciales o puede ser específico para cumplir con una sola funcionalidad comercial.
  • Modelos compartidos – Si el grupo lógico consta de modelos compartidos, la facilidad de actualización de los modelos y la latencia jugarán un papel importante en la arquitectura de los puntos finales de SageMaker. Por ejemplo, si la latencia es una prioridad, es mejor colocar todos los modelos en un solo contenedor detrás de un solo punto final de SageMaker para evitar múltiples saltos. La desventaja es que si es necesario actualizar alguno de los modelos, se actualizarán todos los terminales de SageMaker relevantes que alojan este modelo.
  • Modelos no compartidos – Si el grupo lógico consta solo de modelos específicos de características empresariales y no se comparte con otros grupos, la complejidad del empaquetado y las dimensiones de latencia serán clave para lograrlo. Es aconsejable alojar estos modelos en un único contenedor detrás de un único punto final de SageMaker.
• Uso eficiente del hardware (CPU, GPU) – Agrupe los modelos basados ​​en CPU y alójelos en el mismo host para que pueda usar la CPU de manera eficiente. Del mismo modo, agrupe los modelos basados ​​en GPU para que pueda usarlos y escalarlos de manera eficiente. Hay cargas de trabajo híbridas que requieren CPU y GPU en el mismo host. El alojamiento de los modelos solo de CPU y solo de GPU en el mismo host debe estar impulsado por requisitos de alta cohesión y latencia de la aplicación. Además, el costo, la capacidad de escalar y el radio de explosión en el impacto en caso de falla son las dimensiones clave a considerar.
• Funciones de fitness – Utilice las funciones de fitness como guía para seleccionar una opción de alojamiento de ML.

Conclusión

Cuando se trata de alojamiento ML, no existe un enfoque único para todos. Los profesionales de ML deben elegir el patrón de diseño correcto para abordar sus desafíos de alojamiento de ML. La evaluación de las funciones de aptitud proporciona una guía prescriptiva para seleccionar la opción de alojamiento de ML adecuada.

Para obtener más detalles sobre cada una de las opciones de alojamiento, consulte las siguientes publicaciones de esta serie:

Sobre los autores

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 NLP y Computer Vision. Ayuda a los clientes a lograr una inferencia de modelos de alto rendimiento en SageMaker.

Deepali Rajale es Gerente Técnico de Cuentas Especialista en IA/ML en Amazon Web Services. Trabaja con clientes empresariales brindando orientación técnica sobre la implementación de soluciones de aprendizaje automático con las mejores prácticas. En su tiempo libre, le gusta caminar, ir al cine y salir con familiares y amigos.

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.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/