Un equipo de 2 personas que sirve de modelo a 1,5 millones de personas con TrueFoundry

En los últimos meses, hemos tenido la oportunidad de trabajar con un equipo reducido. Han desarrollado un modelo de aprendizaje profundo de última generación y han creado asociaciones para hacerlo llegar a más de 10 millones de usuarios con talento extremo.

La última pieza que faltaba en su historia de impacto era gestionar la ingeniería para lograrlo. El modelo requería una gran cantidad de cómputos y, dado que querían ofrecer este modelo a sus usuarios finales, necesitaban una infraestructura confiable y de alto rendimiento que pudieran administrar los dos (1 ingeniero de DevOps y 1 ingeniero de aprendizaje automático).

Necesidad de implementación asíncrona

El modelo fue construido para procesar entradas de audio de diferentes tamaños. Como el modelo tenía un tiempo de procesamiento elevado (con un promedio de aproximadamente 5 segundos), necesitaba una inferencia asíncrona para cada solicitud a fin de procesar y responder a estas solicitudes.

El equipo había desarrollado una pila en AWS Sagemaker

El equipo ha creado su pila inicial para servir el modelo en Sagemaker. Sin embargo, cuando llevaron a cabo su primer proyecto piloto con este diseño, se dieron cuenta de que sería difícil ofrecer el modelo de forma fiable a la escala deseada con esta pila.

Los usuarios se enfrentaron a retrasos de 8 a 10 minutos

Incluso después de usar la configuración asíncrona, dado que las instancias tardaban en ampliarse (de 8 a 10 minutos por máquina), la experiencia del usuario final se vio comprometida al tener que soportar este retraso.

Sin embargo, durante la PoC, se enfrentaron a enormes retrasos en los tiempos de respuesta. Como muchos de los controles relacionados con SageMaker eran nuevos, perdieron un tiempo crucial para encontrar el motivo de los retrasos. Algunos de los desafíos a los que se enfrentaron fueron:

1. Difícil de aprender: Como DS/MLE, les resultó difícil entender los nuevos conceptos necesarios para usar Sagemaker.
2. Visibilidad limitada: Hacer un análisis de la causa raíz de los problemas, especialmente en producción, fue difícil debido a que los paneles e interfaces no eran intuitivos.
3. Difícil de escalar: La expansión de Sagamaker fue lenta, lo que provocó retrasos en las respuestas de los usuarios y una mala experiencia de los clientes.
4. Cuota separada: AWS requiere que presente un argumento por separado para obtener capacidad para las instancias de GPU reservadas por SageMaker. El equipo descubrió que este proceso era lento y restrictivo.
5. Caro: El uso de las GPU con Sagemaker resultaba caro para el equipo, ya que Sagemaker supera estas instancias entre un 25 y un 40% más que en EKS sin procesar.

Tras la PoC, el equipo perdió la confianza en Sagemaker y decidió que necesitaban una solución que los dos (un ingeniero de ML y un ingeniero de DevOps) pudieran ofrecer a su público objetivo de más de 10 millones de usuarios.

Implementación del sistema en TrueFoundry en menos de 2 días

Cuando empezamos a colaborar con el equipo, su piloto estaba a unos 7 días de distancia. Le aseguramos al equipo que podríamos ayudarlos a migrar toda la pila y a reconstruirla con los módulos de TrueFoundry en menos de 2 días para que tuvieran tiempo suficiente para realizar las pruebas antes de que el piloto tuviera que pasar a la fase de producción.

Escalado mucho más rápido

El equipo llevó a cabo los análisis comparativos enviando una ráfaga de 88 solicitudes al modelo para comparar el rendimiento con el de Sagemaker. TrueFoundry ampliado 78% más rápida que Sagemaker, lo que brinda al usuario respuestas mucho más rápidas. El el tiempo necesario para responder a la consulta de principio a fin fue un 40% más rápido con TrueFoundry.

‍

‍

‍

Escalado fiable a más de 150 nodos

El equipo simplemente pudo escalar la aplicación a más de 150 nodos de GPU porque:

1. Fácil de configurar: Solo tenían que cambiar un argumento en la interfaz de usuario y podían configurar fácilmente las reglas de escalado automático en función de la acumulación de solicitudes entrantes. De lo contrario, esto habría requerido varias idas y venidas con el equipo de ingeniería.

2. Cuota de GPU aumentada: Con TrueFoundry, podían usar tanto Spot como Raw ECS. Debido a la escasez de GPU entre los proveedores de nube, TrueFoundry también le dio al equipo la opción de escalar en diferentes proveedores de GPU y regiones.

3. Uso puntual y escalado automático: El equipo no tuvo que hacer ningún esfuerzo adicional para configurar el uso de instancias puntuales para sus servicios. Las instancias también se redujeron cuando el tráfico era bajo. Gracias al mecanismo de confiabilidad de TrueFoundry para la configuración de uso puntual y escalado automático, el equipo ahorró más de 100 000 dólares durante el período piloto.
4. Entorno de desarrollo y demostración: El equipo también ha implementado un servicio de desarrollo y demostración del modelo para recopilar comentarios y, al mismo tiempo, reducir el tamaño de las máquinas cuando no están en uso.

¡Ya hay 1,5 millones de usuarios atendidos y aumentando día a día!

Uso True Foundry, el equipo de 2 miembros puede gestionar toda su carga de trabajo, ¡que a menudo se amplía a más de 150 nodos de GPU! por sí mismos. Mientras trabajaba con nosotros, lo más destacable para el equipo fue nuestra atención al cliente y los bajos tiempos de respuesta. ¡TrueFoundry invierte en el éxito de sus clientes y espera que todos nuestros clientes puedan crecer y crear un impacto a escalas similares a las de este proyecto!