Ejecute y optimice la inferencia de varios modelos con puntos de enlace de varios modelos de Amazon SageMaker

Amazon SageMaker El punto final multimodelo (MME) le permite implementar y alojar de manera rentable varios modelos en un único punto final y luego escalar horizontalmente el punto final para lograr la escala. Como se ilustra en la siguiente figura, esta es una técnica eficaz para implementar la tenencia múltiple de modelos dentro de su infraestructura de aprendizaje automático (ML). Hemos visto empresas de software como servicio (SaaS) que utilizan esta característica para aplicar hiperpersonalización en sus modelos de ML y lograr costos más bajos.

Para obtener una descripción general de alto nivel sobre cómo funciona MME, consulte el video de la Cumbre de AWS Escalar ML al siguiente nivel: alojamiento de miles de modelos en SageMaker. Para obtener más información sobre los casos de uso multiinquilino hiperpersonalizados que permite MME, consulte Cómo escalar la inferencia de aprendizaje automático para casos de uso de SaaS multiinquilino.

En el resto de esta publicación, profundizaremos en la arquitectura técnica de SageMaker MME y compartimos las mejores prácticas para optimizar sus terminales multimodelo.

Casos de uso más adecuados para MME

Los extremos de varios modelos de SageMaker son adecuados para alojar una gran cantidad de modelos que puede servir a través de un contenedor de servicio compartido y no necesita acceder a todos los modelos al mismo tiempo. Según el tamaño de la memoria de la instancia del punto final, es posible que un modelo se descargue ocasionalmente de la memoria a favor de cargar un nuevo modelo para maximizar el uso eficiente de la memoria, por lo tanto, su aplicación debe tolerar picos de latencia ocasionales en modelos descargados.

MME también está diseñado para cohospedar modelos que usan el mismo marco de ML porque usan el contenedor compartido para cargar varios modelos. Por lo tanto, si tiene una combinación de marcos de ML en su flota modelo (como PyTorch y TensorFlow), los terminales dedicados de SageMaker o el alojamiento de varios contenedores son una mejor opción.

Finalmente, MME es adecuado para aplicaciones que pueden tolerar una penalización de latencia de inicio en frío ocasional, porque los modelos se cargan en la primera invocación y los modelos que se usan con poca frecuencia se pueden descargar de la memoria para cargar nuevos modelos. Por lo tanto, si tiene una combinación de modelos a los que se accede con frecuencia y con poca frecuencia, un punto final de varios modelos puede atender este tráfico de manera eficiente con menos recursos y mayores ahorros de costos.

También hemos visto algunos escenarios en los que los clientes implementan un clúster MME con suficiente capacidad de memoria agregada para adaptarse a todos sus modelos, evitando así las descargas de modelos por completo y aún logrando ahorros de costos debido a la infraestructura de inferencia compartida.

Recipientes modelo para servir

Cuando utiliza SageMaker Inference Toolkit o un contenedor de servicio modelo de SageMaker preconstruido compatible con MME, su contenedor tiene la Servidor multimodelo (proceso JVM) en ejecución. La forma más fácil de tener Multi Model Server (MMS) incorporado en su contenedor de servicio modelo es usar Contenedores de servicio modelo SageMaker compatible con MME (busque aquellos con Tipo de trabajo=inferencia y CPU/GPU=CPU). MMS es una herramienta de código abierto y fácil de usar para servir modelos de aprendizaje profundo. Proporciona una API REST con un servidor web para servir y administrar múltiples modelos en un solo host. Sin embargo, no es obligatorio usar MMS; podría implementar su propio servidor modelo siempre que implemente el API requeridas por MME.

Cuando se utiliza como parte de la plataforma MME, todas las llamadas API de predicción, carga y descarga a MMS o su propio servidor modelo se canalizan a través del controlador de plano de datos MME. Las llamadas a la API desde el controlador del plano de datos se realizan a través del host local solo para evitar el acceso no autorizado desde fuera de la instancia. Uno de los beneficios clave de MMS es que permite una interfaz estandarizada para cargar, descargar e invocar modelos con compatibilidad en una amplia gama de marcos de aprendizaje profundo.

Configuración avanzada de MMS

Si elige usar MMS para el servicio de modelos, considere las siguientes configuraciones avanzadas para optimizar la escalabilidad y el rendimiento de sus instancias de MME.

Aumentar el paralelismo de inferencia por modelo

MMS crea uno o más procesos de trabajo de Python por modelo en función del valor del trabajadores_predeterminados_por_modelo parámetro de configuración. Estos trabajadores de Python manejan cada solicitud de inferencia individual mediante la ejecución de cualquier función de preprocesamiento, predicción y posprocesamiento que proporcione. Para obtener más información, consulte el controlador de servicio personalizado Repo de GitHub.

Tener más de un trabajador modelo aumenta el paralelismo de las predicciones que puede servir un modelo dado. Sin embargo, cuando se aloja una gran cantidad de modelos en una instancia con una gran cantidad de CPU, debe realizar una prueba de carga de su MME para encontrar el valor óptimo para default_workers_per_model para evitar el agotamiento de los recursos de memoria o CPU.

Diseño para picos de tráfico

Cada proceso MMS dentro de una instancia de punto final tiene una cola de solicitudes que se puede configurar con el tamaño_cola_trabajo parámetro (el valor predeterminado es 100). Esto determina la cantidad de solicitudes que MMS pondrá en cola cuando todos los procesos de trabajo estén ocupados. Utilice este parámetro para ajustar la capacidad de respuesta de sus instancias de punto final después de haber decidido la cantidad óptima de trabajadores por modelo.

En una proporción óptima de trabajador por modelo, el valor predeterminado de 100 debería ser suficiente para la mayoría de los casos. Sin embargo, para aquellos casos en los que el tráfico de solicitudes al punto final aumenta inusualmente, puede reducir el tamaño de la cola si desea que el punto final falle rápidamente para pasar el control a la aplicación o aumentar el tamaño de la cola si desea que el punto final absorba el pico. .

Maximice los recursos de memoria por instancia

Cuando se utilizan varios procesos de trabajo por modelo, de forma predeterminada, cada proceso de trabajo carga su propia copia del modelo. Esto puede reducir la memoria de instancia disponible para otros modelos. Puede optimizar la utilización de la memoria compartiendo un único modelo entre los procesos de trabajo estableciendo el parámetro de configuración precargar_modelo=verdadero. Aquí está intercambiando un paralelismo de inferencia reducido (debido a una sola instancia de modelo) con más eficiencia de memoria. Esta configuración, junto con varios procesos de trabajo, puede ser una buena opción para casos de uso en los que la latencia del modelo es baja pero tiene un preprocesamiento y un posprocesamiento más intensos (realizados por los procesos de trabajo) por solicitud de inferencia.

Establecer valores para configuraciones avanzadas de MMS

MMS usa un archivo config.properties para almacenar configuraciones. MMS usa el siguiente orden para ubicar este archivo config.properties:

1. Si MMS_CONFIG_FILE se establece la variable de entorno, MMS carga la configuración desde la variable de entorno.
2. Si --mms-config el parámetro se pasa a MMS, carga la configuración del parámetro.
3. Si hay un config.properties en la carpeta actual donde el usuario inicia MMS, carga el config.properties archivo del directorio de trabajo actual.

Si no se especifica ninguno de los anteriores, MMS carga la configuración integrada con los valores predeterminados.

El siguiente es un ejemplo de línea de comandos para iniciar MMS con un archivo de configuración explícito:

multi-model-server --start --mms-config /home/mms/config.properties

Métricas clave para monitorear el rendimiento de su terminal

Las métricas clave que pueden ayudarlo a optimizar su MME generalmente están relacionadas con la utilización de CPU y memoria y la latencia de inferencia. Las métricas a nivel de instancia son emitidas por MMS, mientras que las métricas de latencia provienen de MME. En esta sección, discutimos las métricas típicas que puede usar para comprender y optimizar su MME.

Métricas a nivel de instancia de punto final (métricas MMS)

Desde el lista de métricas MMS, CPUUtilization y MemoryUtilization pueden ayudarlo a evaluar si su instancia o el clúster MME tienen el tamaño correcto o no. Si ambas métricas tienen porcentajes entre 50 y 80 %, entonces su MME tiene el tamaño adecuado.

Por lo general, CPUUtilization bajo y MemoryUtilization alto es una indicación de un clúster de MME sobreaprovisionado porque indica que los modelos invocados con poca frecuencia no se están descargando. Esto podría deberse a una cantidad superior a la óptima de instancias de punto final aprovisionadas para el MME y, por lo tanto, la memoria agregada superior a la óptima está disponible para que los modelos a los que se accede con poca frecuencia permanezcan en la memoria. Por el contrario, una utilización cercana al 100 % de estas métricas significa que su clúster no tiene suficiente aprovisionamiento, por lo que debe ajustar la política de escalado automático de su clúster.

Métricas a nivel de plataforma (métricas MME)

Desde el lista completa de métricas MME, una métrica clave que puede ayudarlo a comprender la latencia de su solicitud de inferencia es ModelCacheHit. Esta métrica muestra la proporción promedio de solicitudes de invocación para las cuales el modelo ya estaba cargado en la memoria. Si esta proporción es baja, indica que su clúster de MME no tiene suficiente aprovisionamiento porque es probable que no haya suficiente capacidad de memoria agregada en el clúster de MME para la cantidad de invocaciones de modelos únicos, lo que provoca que los modelos se descarguen con frecuencia de la memoria.

Lecciones del campo y estrategias para optimizar MME

Hemos visto las siguientes recomendaciones de algunos de los usos a gran escala de MME en varios clientes.

La escala horizontal con instancias más pequeñas es mejor que la escala vertical con instancias más grandes

Es posible que experimente limitaciones en las invocaciones de modelos cuando ejecuta muchas solicitudes por segundo (RPS) en menos instancias de puntos finales. Hay límites internos para la cantidad de invocaciones por segundo (cargas y descargas que pueden ocurrir simultáneamente en una instancia) y, por lo tanto, siempre es mejor tener una mayor cantidad de instancias más pequeñas. Ejecutar una mayor cantidad de instancias más pequeñas significa una mayor capacidad agregada total de estos límites para el punto final.

Otro beneficio de escalar horizontalmente con instancias más pequeñas es que reduce el riesgo de agotar los recursos de CPU y memoria de la instancia cuando ejecuta MMS con niveles más altos de paralelismo, junto con una mayor cantidad de modelos en la memoria (como se describe anteriormente en esta publicación).

Evitar la paliza es una responsabilidad compartida

Paliza en MME es cuando los modelos se descargan con frecuencia de la memoria y se vuelven a cargar debido a la memoria insuficiente, ya sea en una instancia individual o en conjunto en el clúster.

Desde una perspectiva de uso, debe dimensionar correctamente las instancias de punto final individuales y el tamaño general del clúster MME para garantizar que haya suficiente capacidad de memoria disponible por instancia y también en conjunto para el clúster para su caso de uso. La flota de enrutadores de la plataforma MME también maximizará el golpe de caché.

No sea agresivo con el embalaje en contenedores de demasiados modelos en menos instancias de memoria más grandes

La memoria no es el único recurso de la instancia a tener en cuenta. Otros recursos como la CPU pueden ser un factor limitante, como se ve en los siguientes resultados de la prueba de carga. En algunos otros casos, también hemos observado que otros recursos del kernel, como los ID de proceso, se agotaron en una instancia, debido a una combinación de demasiados modelos que se cargaron y el marco de ML subyacente (como TensorFlow) generó subprocesos por modelo que eran múltiplos de los disponibles. vCPU.

La siguiente prueba de rendimiento muestra un ejemplo de restricción de CPU que afecta la latencia del modelo. En esta prueba, un punto final de una sola instancia con una instancia grande, aunque tenía memoria más que suficiente para mantener los cuatro modelos en la memoria, produjo latencias de modelo comparativamente peores bajo carga en comparación con un punto final con cuatro instancias más pequeñas.

latencia del modelo de punto final de instancia única

Utilización de memoria y CPU de punto final de instancia única

latencia del modelo de punto final de cuatro instancias

Utilización de memoria y CPU de punto final de cuatro instancias

Para lograr tanto el rendimiento como la rentabilidad, dimensione correctamente su clúster MME con una mayor cantidad de instancias más pequeñas que, en conjunto, le brinden la memoria y la capacidad de CPU óptimas, al tiempo que se mantienen relativamente a la par del costo con menos instancias de memoria pero más grandes.

Modelo mental para optimizar MME

Hay cuatro métricas clave que siempre debe tener en cuenta al dimensionar correctamente su MME:

• El número y tamaño de los modelos.
• El número de modelos únicos invocados en un momento dado
• El tipo y el tamaño de la instancia.
• El recuento de instancias detrás del punto final

Comience con los dos primeros puntos, porque informan el tercero y el cuarto. Por ejemplo, si no hay suficientes instancias detrás del punto final para la cantidad o el tamaño de los modelos únicos que tiene, la memoria agregada para el punto final será baja y verá una proporción de aciertos de caché más baja y una hiperpaginación en el nivel del punto final porque el MME cargará y descargará modelos dentro y fuera de la memoria con frecuencia.

De manera similar, si las invocaciones para modelos únicos son más altas que la memoria agregada de todas las instancias detrás del punto final, verá un golpe de caché más bajo. Esto también puede suceder si el tamaño de las instancias (especialmente la capacidad de memoria) es demasiado pequeño.

El escalado vertical con instancias de memoria realmente grandes también podría generar problemas porque, aunque los modelos pueden caber en la memoria, otros recursos como los procesos de CPU y kernel y los límites de subprocesos podrían agotarse. Realice pruebas de carga de escalado horizontal en preproducción para obtener el número y el tamaño óptimos de instancias para su MME.

Resumen

En esta publicación, obtuvo una comprensión más profunda de la plataforma MME. Aprendió para qué casos de uso técnico es adecuado MME y revisó la arquitectura de la plataforma MME. Obtuvo una comprensión más profunda de la función de cada componente dentro de la arquitectura MME y de qué componentes puede influir directamente en el rendimiento. Finalmente, tuvo una mirada más profunda a los parámetros de configuración que puede ajustar para optimizar MME para su caso de uso y las métricas que debe monitorear para mantener un rendimiento óptimo.

Para comenzar con MME, revise Puntos finales de varios modelos de Amazon SageMaker con XGBoost y Aloje múltiples modelos en un contenedor detrás de un punto final.

Sobre la autora

syed jaffry es un Arquitecto Principal de Soluciones con AWS. Trabaja con una variedad de empresas de organizaciones medianas, grandes empresas, servicios financieros e ISV para ayudarlos a crear y operar aplicaciones de IA/ML rentables y escalables en la nube.

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.