Inferencia de aprendizaje automático rentable con modelos de varios marcos en Amazon SageMaker 

El aprendizaje automático (ML) ha demostrado ser una de las aplicaciones tecnológicas más exitosas y extendidas, que afecta a una amplia gama de industrias e impacta a miles de millones de usuarios todos los días. Con esta rápida adopción de ML en todas las industrias, las empresas enfrentan desafíos para respaldar predicciones de baja latencia y con alta disponibilidad mientras maximizan la utilización de recursos y reducen los costos asociados. Debido a que cada marco de ML tiene sus propias dependencias y los pasos de implementación para cada marco son diferentes, implementar modelos creados en diferentes marcos en producción y administrar cada uno de los puntos finales se vuelve cada vez más complejo.

Amazon SageMaker Los puntos finales de varios contenedores (MCE) nos permiten agrupar modelos en diferentes marcos e implementarlos en el mismo host, creando un único punto final. Puede proporcionar contenedores para los diferentes marcos que usa para crear los modelos, y SageMaker toma todos estos contenedores y los coloca detrás de un punto final. Por ejemplo, podría tener un modelo PyTorch y TensorFlow cargado en dos puntos finales dedicados que atienden los mismos casos de uso o casos de uso completamente diferentes, y ambos modelos tienen tráfico entrante intermitente que no utiliza los recursos al límite. En tal escenario, podría agruparlos usando contenedores en un punto final usando un MCE, mejorando la utilización de recursos mientras reduce los costos incurridos en tener ambos modelos sirviendo desde diferentes puntos finales.

Los puntos finales de múltiples contenedores brindan una solución escalable y rentable para implementar hasta 15 modelos creados en diferentes marcos de ML, servidores de modelos y algoritmos que atienden el mismo caso de uso o uno diferente, lo que significa que puede tener modelos creados en diversos marcos de ML o intermediarios. pasos a través de todos estos contenedores y modelos. Se puede acceder a todos estos modelos individualmente a través de la invocación directa o unirlos a una canalización mediante la invocación en serie, donde la salida de un modelo es la entrada para el siguiente.

En esta publicación, analizamos cómo realizar una inferencia de aprendizaje automático rentable con modelos de marcos múltiples en SageMaker.

Patrones de invocación de MCE

La invocación directa de SageMaker MCE es útil en los casos en los que ha incluido modelos no relacionados en un extremo de MCE o está ejecutando una prueba A/B entre los modelos detrás de un extremo de MCE para medir su rendimiento. Puede llamar al contenedor específico directamente en la llamada API y obtener la predicción de ese modelo.

Con la invocación en serie, puede unir de 2 a 15 contenedores, y la salida de uno se convierte en la entrada del siguiente contenedor en secuencia. Este es un caso de uso ideal si, por ejemplo, tiene una canalización de predicción de varios pasos donde se usa un modelo Scikit-learn para una predicción intermedia y el resultado se alimenta a un modelo TensorFlow para la inferencia final. En lugar de tenerlos implementados como puntos finales diferentes y otra aplicación o trabajo orquestándolos y realizando varias llamadas API, puede implementarlos como SageMaker MCE, abstrayendo la lógica y configurándolos para la invocación en serie, donde SageMaker administra la transferencia de datos entre un contenedor a otro automáticamente y emite la salida del contenedor final al cliente que realiza la solicitud de API.

La invocación en serie de SageMaker MCE es fundamentalmente diferente de una canalización de inferencia en serie de SageMaker (más detalles en las secciones a continuación). Una canalización de inferencia en serie está más dirigida a orquestar flujos de trabajo de ML complejos, como el preprocesamiento de datos, la creación de un conjunto de modelos, la implementación de comprobaciones condicionales para determinar qué modelo invocar o el posprocesamiento de la predicción, lo que involucra la lógica comercial antes de que la predicción se envíe a las aplicaciones posteriores. . Por el contrario, la invocación en serie de MCE está diseñada para unir de 2 a 14 modelos en una canalización para la inferencia, y cada modelo toma la predicción del modelo anterior como entrada.

Todos los contenedores en un MCE están siempre en servicio y en la memoria, por lo que no hay un inicio en frío al invocar el punto final. Los MCE también mejoran la utilización del punto final y mejoran los costos porque los modelos se implementan detrás de un punto final y comparten la instancia informática subyacente, en lugar de que cada modelo ocupe recursos informáticos individuales.

Veamos algunos casos de uso y veamos cómo puede usar los MCE de SageMaker para optimizar la inferencia de ML.

Casos de uso para SageMaker MCE

Supongamos que tiene dos modelos para la clasificación de sentimientos, uno para el idioma inglés y otro para el idioma alemán, y estos modelos están sirviendo a diferentes geografías con tráfico que ingresa en diferentes momentos del día. En lugar de tener dos puntos finales que se ejecutan las 24 horas del día, los 7 días de la semana, puede implementar ambos en un punto final utilizando un MCE y acceder a ellos mediante la invocación directa, optimizando así la utilización de recursos y los costos. Ver el siguiente código:

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

En este ejemplo, tenemos dos modelos (englishModel y germanModel), y definimos los contenedores en el SageMaker create_model construir y definir la InferenceExecutionConfig como 'Directo'. Ahora podemos llamar al punto final para la inferencia y definir el TargetContainerHostname Cómo sea englishModel or germanModel dependiendo del cliente que realiza la llamada a la API:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

También puede usar la invocación directa dentro del MCE para ejecutar pruebas A/B para comparar el rendimiento entre los modelos.

El siguiente diagrama ilustra nuestra arquitectura.

De manera similar, en otros casos de uso de ML, cuando el modelo entrenado se usa para procesar una solicitud, el modelo recibe datos en un formato que necesita ser preprocesado (por ejemplo, destacado) antes de que pueda pasarse al algoritmo para la inferencia. Cuando los algoritmos de ML se encadenan, la salida de un modelo sirve como entrada para el siguiente antes de llegar al resultado final. En este caso, puede crear una canalización en serie de SageMaker MCE, donde los contenedores se comunican entre sí en la secuencia definida en el create_model construya en lugar de implementar cada uno de los modelos en diferentes puntos finales y escribir una lógica independiente para facilitar el flujo de datos entre todos estos modelos y las llamadas a la API. El siguiente diagrama ilustra esta arquitectura.

Para este caso de uso, utilizamos el siguiente código:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

En este ejemplo, tenemos dos contenedores de procesamiento (Processing-1 y Processing-2) para procesamiento de características y transformaciones de datos, y dos contenedores de inferencia (Inference-1 y Inference-2) para ejecutar predicciones del modelo ML en los datos preprocesados. los PipelineModel La instancia le permite definir la canalización de inferencia compuesta por una secuencia lineal de cuatro contenedores que procesan solicitudes de inferencia sobre datos. Los contenedores están ubicados en la misma instancia, lo que le permite ejecutar inferencias con baja latencia.

Escale puntos finales de varios modelos para un gran número de modelos

Los beneficios de los terminales multimodelo de SageMaker aumentan según la escala de consolidación del modelo. Puede ver ahorros de costos al hospedar dos modelos con un punto final, y para casos de uso con cientos o miles de modelos, los ahorros son mucho mayores.

Escalar los puntos finales de MCE también es sencillo usando el SageMakerVariantInvocationsPerInstance métrica predefinida, que proporciona el número promedio de veces por minuto que se invoca cada instancia de un punto final del modelo para definir un TargetScaling política. SageMaker ajusta dinámicamente la cantidad de instancias aprovisionadas para un modelo en respuesta a los cambios en su carga de trabajo. Cuando aumenta la carga de trabajo, el ajuste de escala automático pone más instancias en línea y se carga con los modelos y contenedores de destino para seguir atendiendo las solicitudes. Cuando la carga de trabajo disminuye, el ajuste de escala automático elimina las instancias innecesarias y descarga los contenedores del modelo para que los contenedores no consuman los recursos y no pague por las instancias que no está usando. El tiempo para completar la primera solicitud en un modelo determinado experimenta una latencia adicional (llamada arranque en frío) para descargar el modelo desde Servicio de almacenamiento simple de Amazon (Amazon S3) y cárguelo en la memoria. Las llamadas posteriores finalizan sin sobrecarga adicional porque el modelo ya está cargado. Ver el siguiente código:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

Siguiendo la configuración de política de ejemplo anterior, usamos el SageMakerVariantInvocationsPerInstance métrica predefinida para ajustar el número de instancias variantes para que cada instancia tenga una InvocationsPerInstance métrica de 70.

También podemos escalar los MCE de SageMaker en función de nuestra propia métrica personalizada, como CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationo DiskUtilization, para aumentar o reducir el número de instancias en función de la utilización de un recurso específico. Para obtener más información, consulte Escale automáticamente modelos de Amazon SageMaker.

Se recomienda que el modelo en cada contenedor exhiba requisitos similares de cómputo y latencia en cada solicitud de inferencia, porque si el tráfico al MCE cambia de un modelo de alta utilización de CPU a un modelo de baja utilización de CPU, pero el volumen general de llamadas sigue siendo el mismo, el punto final no escala horizontalmente y es posible que no haya suficientes instancias para manejar todas las solicitudes al modelo de alta utilización de CPU.

MCE seguros

Para los MCE con invocación directa, varios contenedores se alojan en una sola instancia compartiendo memoria y un volumen de almacenamiento. Es importante proteger los contenedores, mantener la asignación correcta de solicitudes a los contenedores de destino y proporcionar a los usuarios el acceso correcto a los contenedores de destino. Puedes restringir invoke_endpoint acceso a un conjunto limitado de contenedores dentro de un MCE usando el sagemaker:TargetContainerHostname Gestión de identidades y accesos de AWS (IAM) clave de condición. Usos de SageMaker IAM roles para proporcionar políticas basadas en la identidad de IAM que utiliza para especificar acciones y recursos permitidos o denegados y las condiciones bajo las cuales se permiten o deniegan las acciones. Las siguientes políticas muestran cómo limitar las llamadas a contenedores específicos dentro de un punto final:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Supervise los puntos finales de varios modelos con las métricas de Amazon CloudWatch

Para hacer concesiones de precio y rendimiento, querrá probar puntos finales de varios modelos con modelos y tráfico representativo de su propia aplicación. SageMaker proporciona métricas adicionales en Reloj en la nube de Amazon para puntos finales de varios modelos para que pueda determinar el uso del punto final y la tasa de aciertos de caché y optimizar su punto final. Las métricas son las siguientes:

• ModeloCargandoEspereTiempo – El intervalo de tiempo que una solicitud de invocación espera a que se descargue o cargue el modelo de destino para realizar la inferencia.
• ModeloDescargaTiempo – El intervalo de tiempo que se tarda en descargar el modelo a través del contenedor UnloadModel Llamada API.
• ModeloDownloadingTime – El intervalo de tiempo que se tarda en descargar el modelo de Amazon S3.
• ModeloTiempodecarga – El intervalo de tiempo que se tarda en cargar el modelo a través del contenedor LoadModel Llamada API.
• ModeloCacheHit - El número de InvokeEndpoint solicitudes enviadas al punto final donde el modelo ya estaba cargado. Tomando el Average La estadística muestra la proporción de solicitudes en las que el modelo ya estaba cargado.
• Número de modelos cargados – El número de modelos cargados en los contenedores en el punto final. Esta métrica se emite por instancia. los Average estadística con un período de 1 minuto le dice el número promedio de modelos cargados por instancia, y el Sum la estadística le indica el número total de modelos cargados en todas las instancias del punto final. Los modelos que rastrea esta métrica no son necesariamente únicos porque puede cargar un modelo en varios contenedores en el punto final.

También hay varias otras métricas que utiliza cada contenedor que se ejecuta en una instancia, como Invocations indicando el número de InvokeEndpoint solicitudes enviadas a un contenedor dentro de un punto final, ContainerLatency dar el tiempo que tardó un punto final en responder al contenedor de destino o a todos los contenedores en una invocación en serie, tal como se ve desde SageMaker, y CPUUtilization y MemoryUtilizaton indicando las unidades de CPU y el porcentaje de memoria.

Conclusión

En la publicación, discutimos cómo los puntos finales de varios contenedores de SageMaker pueden ser útiles para optimizar los costos y la utilización de recursos. Los ejemplos de cuándo utilizar los MCE incluyen, entre otros, los siguientes:

• Modelos de hospedaje en diferentes marcos (como TensorFlow, PyTorch y Scikit-learn) que no tienen suficiente tráfico para saturar la capacidad total de una instancia
• Hospedaje de modelos del mismo marco con diferentes algoritmos de ML (como recomendaciones, pronósticos o clasificación) y funciones de controlador
• Comparaciones de arquitecturas similares que se ejecutan en diferentes versiones del marco (como TensorFlow 1.x frente a TensorFlow 2.x) para escenarios como las pruebas A/B

Los MCE de SageMaker admiten la implementación de hasta 15 contenedores en puntos finales en tiempo real y su invocación independiente para lograr inferencias de baja latencia y ahorrar costos. Los modelos pueden ser completamente heterogéneos, con su propia pila de servicio independiente. Puede invocar estos contenedores de forma secuencial o independiente para cada solicitud. El alojamiento seguro de varios modelos, de diferentes marcos, en una sola instancia podría ahorrarle hasta un 90 % en costos en comparación con el alojamiento de modelos en puntos finales dedicados de una sola instancia.

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 PNL y visión por computadora. Ayuda a los clientes a lograr una inferencia de modelos de alto rendimiento en Amazon SageMaker.

Vikram Elango es Arquitecto Senior de Soluciones Especializado en IA/ML en Amazon Web Services, con sede en Virginia, EE. UU. Vikram ayuda a los clientes globales de la industria financiera y de seguros con diseño y liderazgo de pensamiento para construir e implementar aplicaciones de aprendizaje automático a escala. Actualmente se centra en el procesamiento del lenguaje natural, la IA responsable, la optimización de inferencias y el escalado de ML en toda la empresa. En su tiempo libre, disfruta viajar, hacer caminatas, cocinar y acampar con su familia.

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.