Logre un alto rendimiento a escala para el servicio de modelos utilizando puntos de enlace multimodelo de Amazon SageMaker con GPU

Amazon SageMaker puntos finales de varios modelos (MMEs) proporcionan una forma escalable y rentable de implementar una gran cantidad de modelos de aprendizaje automático (ML). Le brinda la capacidad de implementar múltiples modelos de ML en un solo contenedor de servicio detrás de un único punto final. A partir de ahí, SageMaker gestiona la carga y descarga de los modelos y escala los recursos en su nombre en función de sus patrones de tráfico. Se beneficiará de compartir y reutilizar los recursos de alojamiento y de una carga operativa reducida al administrar una gran cantidad de modelos.

En noviembre 2022, MME agregó soporte para GPUs, que le permite ejecutar varios modelos en un solo dispositivo de GPU y escalar instancias de GPU detrás de un único punto final. Esto satisface la fuerte demanda de MME de modelos de redes neuronales profundas (DNN) que se benefician del cómputo acelerado con GPU. Estos incluyen visión por computadora (CV), procesamiento de lenguaje natural (NLP) y modelos generativos de IA. Entre los motivos de la demanda se encuentran los siguientes:

• Los modelos DNN suelen ser de gran tamaño y complejidad y continúan creciendo a un ritmo rápido. Tomando los modelos NLP como ejemplo, muchos de ellos superan los miles de millones de parámetros, lo que requiere que las GPU satisfagan los requisitos de baja latencia y alto rendimiento.
• Hemos observado una mayor necesidad de personalizar estos modelos para ofrecer experiencias hiperpersonalizadas a usuarios individuales. A medida que aumenta la cantidad de estos modelos, existe la necesidad de una solución más fácil para implementar y poner en funcionamiento muchos modelos a escala.
• Las instancias de GPU son costosas y desea reutilizarlas tanto como sea posible para maximizar la utilización de GPU y reducir los costos operativos.

Aunque todas estas razones apuntan a los MME con GPU como una opción ideal para los modelos DNN, se recomienda realizar pruebas de carga para encontrar la configuración de punto final correcta que satisfaga los requisitos de su caso de uso. Muchos factores pueden influir en los resultados de las pruebas de carga, como el tipo de instancia, la cantidad de instancias, el tamaño del modelo y la arquitectura del modelo. Además, las pruebas de carga pueden ayudar a guiar las estrategias de escalado automático utilizando las métricas correctas en lugar de métodos iterativos de prueba y error.

Por esos motivos, elaboramos esta publicación para ayudarlo a realizar pruebas de carga adecuadas en MME con GPU y encontrar la mejor configuración para su caso de uso de ML. Compartimos los resultados de nuestras pruebas de carga para algunos de los modelos DNN más populares en NLP y CV alojados mediante MME en diferentes tipos de instancias. Resumimos los conocimientos y las conclusiones de los resultados de nuestras pruebas para ayudarlo a tomar una decisión informada sobre la configuración de sus propias implementaciones. En el camino, también compartimos nuestro enfoque recomendado para realizar pruebas de carga para MME en GPU. Las herramientas y la técnica recomendadas determinan la cantidad óptima de modelos que se pueden cargar por tipo de instancia y lo ayudan a lograr la mejor relación precio-rendimiento.

Resumen de la solución

Para obtener una introducción a MME y MME con GPU, consulte Crear un punto final de varios modelos y Ejecute varios modelos de aprendizaje profundo en GPU con puntos de enlace de varios modelos de Amazon SageMaker. Para el contexto de las pruebas de carga en esta publicación, puede descargar nuestro código de muestra desde el Repositorio GitHub para reproducir los resultados o utilizarlo como plantilla para comparar sus propios modelos. Hay dos cuadernos proporcionados en el repositorio: uno para pruebas de carga de modelos CV y ​​otro para NLP. Se compararon varios modelos de diferentes tamaños y arquitecturas en diferentes tipos de instancias de GPU: ml.g4dn.2xlarge, ml.g5.2xlarge y ml.p3.2xlarge. Esto debería proporcionar una sección transversal razonable de rendimiento en las siguientes métricas para cada instancia y tipo de modelo:

• Número máximo de modelos que se pueden cargar en la memoria de la GPU
• Latencia de respuesta de extremo a extremo observada en el lado del cliente para cada consulta de inferencia
• Rendimiento máximo de consultas por segundo que el extremo puede procesar sin errores
• Máximo de usuarios actuales por instancias antes de que se observe una solicitud fallida

La siguiente tabla enumera los modelos probados.

La siguiente tabla enumera las instancias de GPU probadas.

Como se mencionó anteriormente, el ejemplo de código se puede adaptar a otros modelos y tipos de instancias.

Tenga en cuenta que los MME actualmente solo admiten instancias de GPU únicas. Para ver la lista de tipos de instancias compatibles, consulte Algoritmos, marcos e instancias compatibles.

El procedimiento de evaluación comparativa consta de los siguientes pasos:

1. Recupere un modelo previamente entrenado de un centro de modelos.
2. Prepare el artefacto del modelo para publicarlo en los MME de SageMaker (consulte Ejecute varios modelos de aprendizaje profundo en GPU con puntos de enlace de varios modelos de Amazon SageMaker para más detalles).
3. Implemente un MME de SageMaker en una instancia de GPU.
4. Determine la cantidad máxima de modelos que se pueden cargar en la memoria de la GPU dentro de un umbral específico.
5. Utilice el marco de prueba de carga de Locust para simular el tráfico que invoca aleatoriamente modelos cargados en la instancia.
6. Recoger datos y analizar los resultados.
7. Opcionalmente, repita los pasos 2 a 6 después de compilar el modelo en TensorRT.

Los pasos 4 y 5 justifican una mirada más profunda. Los modelos dentro de una GPU MME de SageMaker se cargan en la memoria de forma dinámica. Por lo tanto, en el Paso 4, subimos un artefacto de modelo inicial a Servicio de almacenamiento simple de Amazon (Amazon S3) e invoque el modelo para cargarlo en la memoria. Después de la invocación inicial, medimos la cantidad de memoria GPU consumida, hacemos una copia del modelo inicial, invocamos la copia del modelo para cargarlo en la memoria y nuevamente medimos la cantidad total de memoria GPU consumida. Este proceso se repite hasta que se alcanza un umbral porcentual específico de utilización de memoria GPU. Para el punto de referencia, establecimos el umbral en 90 % para proporcionar un búfer de memoria razonable para hacer inferencias en lotes más grandes o dejar algo de espacio para cargar otros modelos que se usan con menos frecuencia.

Simular el tráfico de usuarios

Después de haber determinado el número de modelos, podemos ejecutar una prueba de carga usando el Marco de pruebas de carga Locust. La prueba de carga simula solicitudes de usuarios a modelos aleatorios y mide automáticamente métricas como la latencia de respuesta y el rendimiento.

Locust admite formas de prueba de carga personalizadas que le permiten definir patrones de tráfico personalizados. La forma que se utilizó en este punto de referencia se muestra en el siguiente gráfico. En los primeros 30 segundos, el punto final se calienta con 10 usuarios simultáneos. Después de 30 segundos, se generan nuevos usuarios a una velocidad de dos por segundo, llegando a 20 usuarios simultáneos en la marca de 40 segundos. Luego, el punto final se compara constantemente con 20 usuarios simultáneos hasta la marca de 60 segundos, momento en el cual Locust nuevamente comienza a aumentar los usuarios a dos por segundo hasta 40 usuarios simultáneos. Este patrón de aumento gradual y pruebas constantes se repite hasta que el punto final aumenta a 200 usuarios simultáneos. Dependiendo de su caso de uso, es posible que desee ajustar la forma de la prueba de carga en locust_benchmark_sm.py para reflejar con mayor precisión los patrones de tráfico esperados. Por ejemplo, si pretende hospedar modelos de idiomas más grandes, una prueba de carga con 200 usuarios simultáneos puede no ser factible para un modelo hospedado en una sola instancia y, por lo tanto, es posible que desee reducir el número de usuarios o aumentar el número de instancias. También es posible que desee ampliar la duración de la prueba de carga para medir con mayor precisión la estabilidad del terminal durante un período de tiempo más largo.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

Tenga en cuenta que solo hemos evaluado el punto final con modelos homogéneos que se ejecutan en bases de servicio consistentes utilizando PyTorch o TensorRT. Esto se debe a que los MME son más adecuados para albergar muchos modelos con características similares, como el consumo de memoria y el tiempo de respuesta. Las plantillas de evaluación comparativa proporcionadas en el Repositorio GitHub todavía se puede usar para determinar si servir modelos heterogéneos en MME produciría el rendimiento y la estabilidad deseados.

Resultados de referencia para modelos de CV

Utilice el cuaderno cv-benchmark.ipynb para ejecutar pruebas de carga para modelos de visión artificial. Puede ajustar el nombre del modelo previamente entrenado y los parámetros del tipo de instancia para realizar pruebas de carga en diferentes combinaciones de modelo y tipo de instancia. Probamos a propósito tres modelos CV en diferentes rangos de tamaño, desde el más pequeño hasta el más grande: resnet50 (25 millones), convnext_base (88 M) y vit_large_patch16_224 (304M). Es posible que deba ajustarse al código si elige un modelo fuera de esta lista. además, el portátil establece por defecto la forma de la imagen de entrada en un tensor de imagen de 224x224x3. Recuerde ajustar la forma de entrada en consecuencia si necesita comparar modelos que toman una imagen de diferente tamaño.

Después de ejecutar todo el cuaderno, obtendrá varias visualizaciones de análisis de rendimiento. Los dos primeros detallan el rendimiento del modelo con respecto al aumento de usuarios concurrentes. Las siguientes figuras son visualizaciones de ejemplo generadas para el ResNet50 modelo ejecutándose en ml.g4dn.2xlarge, comparando PyTorch (izquierda) con TensorRT (derecha). Los gráficos de la línea superior muestran la latencia y el rendimiento del modelo en el eje y con números crecientes de trabajadores de clientes simultáneos reflejados en el eje x. Los gráficos de barras inferiores muestran el recuento de solicitudes exitosas y fallidas.

Mirando a través de todos los modelos de visión artificial que probamos, observamos lo siguiente:

• La latencia (en milisegundos) es mayor y el rendimiento (solicitudes por segundo) es menor para los modelos más grandes (resnet50 > convnext_base > vit_large_patch16_224).
• El aumento de la latencia es proporcional al número de usuarios a medida que se ponen en cola más solicitudes en el servidor de inferencia.
• Los modelos grandes consumen más recursos informáticos y pueden alcanzar sus límites de rendimiento máximo con menos usuarios que un modelo más pequeño. Esto se observa con el vit_large_patch16_224 modelo, que registró la primera solicitud fallida en 140 usuarios concurrentes. Al ser significativamente más grande que los otros dos modelos probados, también tuvo la mayor cantidad de solicitudes fallidas en general con una mayor concurrencia. Esta es una señal clara de que el punto final necesitaría escalar más allá de una sola instancia si la intención es admitir más de 140 usuarios simultáneos.

Al final de la ejecución del cuaderno, también obtiene una comparación resumida de los modelos PyTorch y TensorRT para cada una de las cuatro métricas clave. Según nuestras pruebas comparativas, todos los modelos CV vieron un aumento en el rendimiento del modelo después de la compilación de TensorRT. Tomando nuestro ResNet50 modelo como el ejemplo nuevamente, la latencia disminuyó en un 32% mientras que el rendimiento aumentó en un 18%. Aunque el número máximo de usuarios simultáneos permaneció igual para ResNet50, los otros dos modelos vieron una mejora del 14 % en la cantidad de usuarios simultáneos que pueden admitir. Sin embargo, la mejora del rendimiento de TensorRT se produjo a expensas de una mayor utilización de la memoria, lo que resultó en menos modelos cargados por MME. El impacto es mayor para los modelos que utilizan una red neuronal convolucional (CNN). De hecho, nuestro modelo ResNet50 consumió aproximadamente el doble de memoria GPU al pasar de PyTorch a TensorRT, lo que resultó en un 50 % menos de modelos cargados (46 frente a 23). Diagnosticamos este comportamiento con más detalle en la siguiente sección.

Resultados de referencia para modelos de PNL

Para los modelos NLP, use el cuaderno nlp-benchmark.ipynb para ejecutar la prueba de carga. La configuración del portátil debería ser muy similar. Probamos dos modelos NLP: bert-base-uncased (109M) y roberta-large (335M). El modelo preentrenado y el tokenizador se descargan del concentrador Hugging Face, y la carga útil de prueba se genera desde el tokenizador usando una cadena de muestra. La longitud máxima de secuencia está predeterminada en 128. Si necesita probar cadenas más largas, recuerde ajustar ese parámetro. Ejecutar el cuaderno NLP genera el mismo conjunto de visualizaciones: Pytorch (izquierda) frente a TensorRT (derecha).

A partir de estos, observamos aún más beneficios de rendimiento de TensorRT para modelos NLP. Tomando el roberta-large modelo en una instancia ml.g4dn.2xlarge, por ejemplo, la latencia de inferencia disminuyó drásticamente de 180 milisegundos a 56 milisegundos (una mejora del 70 %), mientras que el rendimiento mejoró en un 406 % de 33 solicitudes por segundo a 167. Además, el número máximo de solicitudes simultáneas los usuarios aumentaron en un 50%; No se observaron solicitudes fallidas hasta que alcanzamos los 180 usuarios simultáneos, en comparación con los 120 del modelo PyTorch original. En términos de utilización de la memoria, vimos un modelo menos cargado para TensorRT (de nueve modelos a ocho). Sin embargo, el impacto negativo es mucho menor en comparación con lo que observamos con los modelos basados ​​en CNN.

Análisis sobre la utilización de la memoria

La siguiente tabla muestra el análisis completo sobre el impacto de la utilización de la memoria de PyTorch a TensorRT. Mencionamos anteriormente que los modelos basados ​​en CNN se ven más afectados negativamente. El ResNet50 El modelo tuvo una reducción de más del 50 % en la cantidad de modelos cargados en los tres tipos de instancias de GPU. Convnext_base tuvo una reducción aún mayor en aproximadamente el 70% en todos los ámbitos. Por otro lado, el impacto en los modelos de transformadores es pequeño o mixto. vit_large_patch16_224 y roberta-large tuvo una reducción promedio de aproximadamente 20% y 3%, respectivamente, mientras que bert-base-uncased tuvo una mejora de aproximadamente un 40%.

Al observar todos los puntos de datos en su conjunto con respecto al rendimiento superior en latencia, rendimiento y confiabilidad, y el impacto menor en la cantidad máxima de modelos cargados, recomendamos el modelo TensorRT para arquitecturas de modelos basadas en transformadores. Para las CNN, creemos que se necesita más análisis de rendimiento de costos para garantizar que el beneficio de rendimiento supere el costo de la infraestructura de alojamiento adicional.

Las siguientes tablas enumeran nuestros resultados de referencia completos para todas las métricas en los tres tipos de instancias de GPU.

La siguiente tabla resume los resultados en todos los tipos de instancias. La instancia ml.g5.2xlarge proporciona el mejor rendimiento, mientras que la instancia ml.p3.2xlarge generalmente tiene un rendimiento inferior a pesar de ser la más costosa de las tres. Las instancias g5 y g4dn demuestran el mejor valor para las cargas de trabajo de inferencia.

Limpiar

Después de completar la prueba de carga, limpie los recursos generados para evitar incurrir en cargos adicionales. Los principales recursos son los puntos finales de SageMaker y los archivos de artefactos de modelo en Amazon S3. Para ponértelo más fácil, los archivos del bloc de notas tienen el siguiente código de limpieza para ayudarte a eliminarlos:

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

Conclusión

En esta publicación, compartimos los resultados de nuestras pruebas y el análisis de varios modelos de redes neuronales profundas que se ejecutan en terminales multimodelo de SageMaker con GPU. Los resultados y la información que compartimos deberían proporcionar una sección transversal razonable del rendimiento en diferentes métricas y tipos de instancias. En el proceso, también presentamos nuestro enfoque recomendado para ejecutar pruebas comparativas para SageMaker MME con GPU. Las herramientas y el código de muestra que proporcionamos pueden ayudarlo a iniciar rápidamente sus pruebas comparativas y tomar una decisión más informada sobre cómo alojar de manera rentable cientos de modelos DNN en hardware de cómputo acelerado. Para comenzar con la evaluación comparativa de sus propios modelos con soporte MME para GPU, consulte Algoritmos, marcos e instancias compatibles y del Repositorio GitHub para ejemplos adicionales y documentación.

Sobre los autores

James Wu es un arquitecto de soluciones especialista en inteligencia artificial/aprendizaje automático sénior en AWS. ayudar a los clientes a diseñar y crear soluciones de IA/ML. El trabajo de James cubre una amplia gama de casos de uso de ML, con un interés principal en la visión artificial, el aprendizaje profundo y la ampliación de ML en toda la empresa. Antes de unirse a AWS, James fue arquitecto, desarrollador y líder tecnológico durante más de 10 años, incluidos 6 años en ingeniería y 4 años en las industrias de marketing y publicidad.

Vikram Elango es Arquitecto de Soluciones Especializado en AI/ML en Amazon Web Services, con sede en Virginia, EE. UU. Vikram ayuda a los clientes de la industria financiera y de seguros con diseño y liderazgo intelectual para crear 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.

Simón Zamarin es un arquitecto de soluciones de IA / ML cuyo objetivo principal es ayudar a los clientes a extraer valor de sus activos de datos. En su tiempo libre, a Simon le gusta pasar tiempo con la familia, leer ciencia ficción y trabajar en varios proyectos de bricolaje.

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/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/