Cómo escalar la inferencia de aprendizaje automático para casos de uso de SaaS multiusuario

Reeditado por Platón

seguidores: 0

Esta publicación está coescrita con Sowmya Manusani, ingeniera senior de aprendizaje automático en Zendesk

Zendesk es una empresa SaaS que crea software de soporte, ventas y participación del cliente para todos, con la simplicidad como base. Prospera al hacer que más de 170,000 XNUMX empresas en todo el mundo atiendan a sus cientos de millones de clientes de manera eficiente. El equipo de aprendizaje automático de Zendcaesk es responsable de mejorar los equipos de experiencia del cliente para lograr lo mejor. Al combinar el poder de los datos y las personas, Zendesk ofrece productos inteligentes que hacen que sus clientes sean más productivos al automatizar el trabajo manual.

Zendesk ha estado creando productos ML desde 2015, incluidos Bot de respuesta, Predicción de satisfacción, Señales de contenido, Macros sugeridas, y muchos más. En los últimos años, con el crecimiento del aprendizaje profundo, especialmente en NLP, vieron muchas oportunidades para automatizar los flujos de trabajo y ayudar a los agentes a brindar soporte a sus clientes con las soluciones de Zendesk. Actualmente, Zendesk usa TensorFlow y PyTorch para crear modelos de aprendizaje profundo.

Clientes como Zendesk han creado negocios exitosos de software como servicio (SaaS) a gran escala en Amazon Web Services (AWS). Un impulsor clave para un modelo de negocio SaaS exitoso es la capacidad de aplicar múltiples inquilinos en la aplicación y la infraestructura. Esto permite eficiencias operativas y de costos porque la aplicación solo necesita construirse una vez, pero puede usarse muchas veces y la infraestructura puede compartirse. Vemos a muchos clientes crear sistemas multiinquilino seguros, rentables en AWS en todas las capas de la pila, desde computación, almacenamiento, base de datos hasta redes, y ahora vemos que los clientes necesitan aplicarlo al aprendizaje automático (ML ).

Hacer el difícil compromiso entre la reutilización de modelos y la hiperpersonalización

La tenencia múltiple para empresas de SaaS generalmente significa que una sola aplicación se reutiliza entre muchos usuarios (clientes de SaaS). Esto crea eficiencias de costos y reduce los gastos generales operativos. Sin embargo, los modelos de aprendizaje automático a veces necesitan personalizarse con un alto grado de especificidad (hiperpersonalizados) para hacer predicciones precisas. Esto significa que el paradigma SaaS de "crear una vez, usar muchas veces" no siempre se puede aplicar a ML si los modelos tienen especificidad. Tomemos, por ejemplo, el caso de uso de las plataformas de atención al cliente. El lenguaje que los usuarios incluyen en un ticket de soporte varía dependiendo de si se trata de un problema de viaje compartido ("el viaje tomó demasiado tiempo") o un problema de compra de ropa ("decoloración al lavarla"). En este caso de uso, mejorar la precisión de la predicción de la mejor acción de remediación puede requerir entrenar un modelo de procesamiento de lenguaje natural (NLP) en un conjunto de datos específico para un dominio comercial o una industria vertical. Zendesk enfrenta exactamente este desafío cuando intenta aprovechar ML en sus soluciones. Necesitaban crear miles de modelos de ML altamente personalizados, cada uno diseñado para un cliente específico. Para resolver este desafío de implementar miles de modelos de manera rentable, Zendesk recurrió a Amazon SageMaker.

En esta publicación, mostramos cómo usar algunas de las características más nuevas de Amazon SageMaker, un servicio de aprendizaje automático completamente administrado, para crear una capacidad de inferencia de aprendizaje automático multiinquilino. También compartimos un ejemplo del mundo real de cómo Zendesk logró con éxito el mismo resultado mediante la implementación de un término medio feliz entre ser capaz de admitir la hiperpersonalización en sus modelos de ML y el uso compartido y rentable de la infraestructura mediante los puntos finales de varios modelos de SageMaker ( MME).

Puntos finales de varios modelos de SageMaker

Los puntos finales de varios modelos de SageMaker le permiten implementar varios modelos detrás de un único punto final de inferencia que puede contener una o más instancias. Cada instancia está diseñada para cargar y servir múltiples modelos hasta su capacidad de memoria y CPU. Con esta arquitectura, una empresa SaaS puede romper el costo linealmente creciente de hospedar múltiples modelos y lograr la reutilización de la infraestructura de manera consistente con el modelo de tenencia múltiple aplicado en otras partes de la pila de aplicaciones.

El siguiente diagrama ilustra la arquitectura de un extremo de varios modelos de SageMaker.

El extremo multimodelo de SageMaker carga dinámicamente modelos desde Servicio de almacenamiento simple de Amazon (Amazon S3) cuando se invoca, en lugar de descargar todos los modelos cuando se crea el punto final por primera vez. Como resultado, una invocación inicial a un modelo podría tener una latencia de inferencia más alta que las inferencias posteriores, que se completan con una latencia baja. Si el modelo ya está cargado en el contenedor cuando se invoca, se omite el paso de descarga y el modelo devuelve las inferencias con baja latencia. Por ejemplo, suponga que tiene un modelo que solo se usa unas pocas veces al día. Se carga automáticamente a pedido, mientras que los modelos a los que se accede con frecuencia se retienen en la memoria y se invocan con una latencia constantemente baja.

Echemos un vistazo más de cerca a cómo Zendesk usó SageMaker MME para lograr una implementación rentable de aprendizaje automático a hiperescala con su función de aprendizaje automático de macros sugeridas.

Por qué Zendesk creó modelos hiperpersonalizados

Los clientes de Zendesk se distribuyen globalmente en diferentes verticales de la industria con diferentes semánticas de tickets de soporte. Por lo tanto, para brindar un mejor servicio a sus clientes, a menudo tienen que crear modelos personalizados entrenados en datos de tickets de soporte específicos del cliente para identificar correctamente la intención, las macros y más.

En octubre de 2021, lanzaron una nueva función de NLP ML, Sugerencias de macros, que recomienda macros (acciones predefinidas) basadas en miles de predicciones de modelos específicas del cliente. El equipo de aprendizaje automático de Zendesk creó un modelo clasificador de NLP basado en TensorFlow entrenado a partir del historial anterior de contenido de tickets y macros por cliente. Con estos modelos disponibles, se recomienda una predicción macro cada vez que un agente ve el ticket (como se muestra en la siguiente captura de pantalla), lo que ayuda al agente a atender a los clientes rápidamente. Debido a que las macros son específicas para los clientes, Zendesk necesita modelos específicos del cliente para ofrecer predicciones precisas.

Bajo el capó de las macros sugeridas de Zendesk

Los modelos de macros sugeridos son redes neuronales basadas en NLP que tienen un tamaño de entre 7 y 15 MB. El principal desafío es poner en producción miles de estos modelos con soluciones rentables, confiables y escalables.

Cada modelo tiene diferentes patrones de tráfico, con un mínimo de dos solicitudes por segundo y un pico de cientos de solicitudes por segundo, y brinda millones de predicciones por día con una latencia del modelo de aproximadamente 100 milisegundos cuando el modelo está disponible en la memoria. Los puntos de enlace de SageMaker se implementan en varias regiones de AWS y atienden miles de solicitudes por minuto por punto de enlace.

Con su capacidad para albergar varios modelos en un solo punto final, SageMaker ayudó a Zendesk a reducir los gastos generales de implementación y a crear una solución rentable en comparación con la implementación de un punto final de modelo único por cliente. La compensación aquí es menos control sobre la gestión por modelo; sin embargo, esta es un área en la que Zendesk está colaborando con AWS para mejorar los puntos finales de varios modelos.

Una de las funciones multimodelo de SageMaker es la carga diferida de modelos, es decir, los modelos se cargan en la memoria cuando se invocan por primera vez. Esto es para optimizar la utilización de la memoria; sin embargo, provoca picos de tiempo de respuesta en la primera carga, lo que puede verse como un problema de arranque en frío. Para las macros sugeridas, esto fue un desafío; sin embargo, Zendesk superó esto al implementar una funcionalidad de carga previa además del aprovisionamiento de puntos finales de SageMaker para cargar los modelos en la memoria antes de atender el tráfico de producción. En segundo lugar, MME descarga de la memoria los modelos que se usan con poca frecuencia, por lo que para lograr una latencia baja constante en todos los modelos y evitar que los "vecinos ruidosos" afecten a otros modelos menos activos, Zendesk está colaborando con AWS para agregar nuevas funciones, que se analizan más adelante en la publicación, para habilitar una gestión por modelo más explícita. Además, como solución provisional, Zendesk ha dimensionado correctamente la flota de MME para minimizar la descarga de demasiados modelos. Con esto, Zendesk puede brindar predicciones a todos sus clientes con una latencia baja, alrededor de 100 milisegundos, y aun así lograr un ahorro de costos del 90 % en comparación con los puntos finales dedicados.

En el tamaño correcto de MME, Zendesk observó durante las pruebas de carga que tener una mayor cantidad de instancias más pequeñas (sesgo en la escala horizontal) detrás de MME era una mejor opción que tener menos instancias de memoria más grandes (escala vertical). Zendesk observó que empaquetar demasiados modelos (más de 500 modelos de TensorFlow en su caso) en una sola instancia de memoria grande no funcionó bien porque la memoria no es el único recurso en una instancia que puede ser un cuello de botella. Más específicamente, observaron que TensorFlow generó múltiples subprocesos (3 x vCPU de instancia en total) por modelo, por lo que cargar más de 500 modelos en una sola instancia hizo que se infringieran los límites de nivel de kernel en la cantidad máxima de subprocesos que podrían generarse en una instancia. Otro problema relacionado con el uso de menos instancias más grandes ocurrió cuando Zendesk experimentó una limitación (como mecanismo de seguridad) en algunas instancias detrás de MME porque la invocación del modelo único por segundo superó la tasa de Servidor multimodelo (MMS) en una sola instancia podría manejarse de manera segura sin apagar la instancia. Este fue otro problema que se resolvió con el uso de más instancias y más pequeñas.

Desde la perspectiva de la observabilidad, que es un componente crucial de cualquier aplicación de producción, Reloj en la nube de Amazon las métricas como las invocaciones, la CPU, la utilización de la memoria y las métricas específicas de varios modelos, como los modelos cargados en la memoria, el tiempo de carga del modelo, el tiempo de espera de la carga del modelo y el acierto en la memoria caché del modelo, son informativas. Específicamente, el desglose de la latencia del modelo ayudó a Zendesk a comprender el problema del arranque en frío y su impacto.

Bajo el capó del escalado automático de MME

Detrás de cada punto final multimodelo, hay instancias de hospedaje de modelos, como se muestra en el siguiente diagrama. Estas instancias cargan y desalojan múltiples modelos hacia y desde la memoria en función de los patrones de tráfico a los modelos.

SageMaker continúa enrutando las solicitudes de inferencia para un modelo a la instancia donde el modelo ya está cargado, de modo que las solicitudes se atiendan desde la copia del modelo en caché (consulte el siguiente diagrama, que muestra la ruta de solicitud para la primera solicitud de predicción frente a la solicitud de predicción en caché sendero). Sin embargo, si el modelo recibe muchas solicitudes de invocación y hay instancias adicionales para el extremo de varios modelos, SageMaker enruta algunas solicitudes a otra instancia para acomodar el aumento. Para aprovechar el escalado automático de modelos en SageMaker, asegúrese de tener configuración de escalado automático de instancias para aprovisionar capacidad de instancia adicional. Configure su política de escalado a nivel de punto final con parámetros personalizados o invocaciones por minuto (recomendado) para agregar más instancias a la flota de puntos finales.

Casos de uso más adecuados para MME

Los extremos de varios modelos de SageMaker son adecuados para alojar una gran cantidad de modelos similares que puede servir a través de un contenedor de servicio compartido y no es necesario acceder a todos los modelos al mismo tiempo. MME es más adecuado para modelos que son similares en tamaño y latencias de invocación. Es aceptable alguna variación en el tamaño del modelo; por ejemplo, los modelos de Zendesk varían de 10 a 50 Mb, lo que funciona bien, pero las variaciones de tamaño que son un factor de 10, 50 o 100 veces mayor no son adecuadas. Los modelos más grandes pueden causar una mayor cantidad de cargas y descargas de modelos más pequeños para acomodar suficiente espacio de memoria, lo que puede resultar en una mayor latencia en el punto final. Las diferencias en las características de rendimiento de los modelos más grandes también podrían consumir recursos como la CPU de manera desigual, lo que podría afectar a otros modelos en la instancia.

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 que se usan con poca frecuencia se pueden descargar en favor de los modelos que se invocan con frecuencia. Si tiene una cola larga de modelos a los que se accede con poca frecuencia, un punto final de varios modelos puede atender este tráfico de manera eficiente y permitir ahorros de costos significativos.

Resumen

En esta publicación, aprendió cómo SaaS y multiinquilino se relacionan con ML y cómo los terminales de varios modelos de SageMaker permiten multiinquilino y rentabilidad para la inferencia de ML. Aprendió sobre el caso de uso de usuarios múltiples de Zendesk de modelos de aprendizaje automático por cliente y cómo alojaron miles de modelos de aprendizaje automático en SageMaker MME para su función de macros sugeridas y lograron un ahorro de costos del 90 % en la inferencia en comparación con los puntos finales dedicados. Los casos de uso de hiperpersonalización pueden requerir miles de modelos de ML, y MME es una opción rentable para este caso de uso. Continuaremos realizando mejoras en MME para permitirle alojar modelos con baja latencia y con controles más granulares para cada modelo personalizado. Para comenzar con MME, consulte Aloje múltiples modelos en un contenedor detrás de un punto final.

Acerca de los autores

syed jaffry es un Arquitecto de Soluciones Sr. con AWS. Trabaja con una variedad de empresas, desde organizaciones medianas hasta grandes empresas, desde servicios financieros hasta ISV, para ayudarlos a crear y operar aplicaciones seguras, resilientes, escalables y de alto rendimiento en la nube.

Sowmya Manusani es un ingeniero sénior de aprendizaje automático en Zendesk. Trabaja en la producción de funciones de aprendizaje automático basadas en NLP que se centran en mejorar la productividad de los agentes para miles de clientes de Zendesk Enterprise. Tiene experiencia en la creación de canalizaciones de capacitación automatizadas para miles de modelos personalizados y en su servicio mediante aplicaciones seguras, resistentes, escalables y de alto rendimiento. En su tiempo libre, le gusta resolver acertijos e intentar pintar.

Saurabh Trikande es gerente sénior de productos para Amazon SageMaker Inference. Le apasiona trabajar con clientes y hacer que el aprendizaje automático 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.

Deepti Ragha es ingeniero de desarrollo de software en el equipo de Amazon SageMaker. Su trabajo actual se centra en la creación de funciones para alojar modelos de aprendizaje automático de manera eficiente. En su tiempo libre, le gusta viajar, hacer caminatas y cultivar plantas.