Cómo Veriff redujo el tiempo de implementación en un 80% utilizando los puntos de enlace multitarea de Amazon SageMaker

Cómo Veriff redujo el tiempo de implementación en un 80% con los puntos de enlace multitarea de Amazon SageMaker

Veriff es una plataforma de verificación de identidad asociada a organizaciones innovadoras impulsadas por el crecimiento, incluyendo pioneros en servicios financieros, tecnología financiera (FinTech), criptomonedas, juegos, movilidad y mercados en línea. Proporcionan tecnología avanzada que combina la automatización impulsada por IA con la retroalimentación humana, conocimientos profundos y experiencia.

Veriff ofrece una infraestructura comprobada que permite a sus clientes confiar en las identidades y atributos personales de sus usuarios en todos los momentos relevantes de su trayectoria como clientes. Veriff cuenta con la confianza de clientes como Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot y Wise.

Siendo una solución impulsada por IA, Veriff necesita crear y ejecutar docenas de modelos de aprendizaje automático (ML) de manera rentable. Estos modelos van desde modelos ligeros basados en árboles hasta modelos de visión por computadora de aprendizaje profundo, que deben funcionar en unidades de procesamiento gráfico (GPU) para lograr baja latencia y mejorar la experiencia del usuario. Veriff también está agregando actualmente más productos a su oferta, apuntando a una solución hiperpersonalizada para sus clientes. Brindar diferentes modelos para diferentes clientes aumenta la necesidad de una solución de entrega de modelos escalable.

• Investigadores de CMU y Google DeepMind presentan AlignProp un enfoque de IA basado en retropropagación directa para afinar los modelos de difusión de texto a imagen para una función de recompensa deseada.
• Proyecto Green Light de Google sincroniza los semáforos para reducir en un 30% las paradas
• Las empresas de internet informan sobre la mayor operación de denegación de servicio jamás registrada

En esta publicación, te mostramos cómo Veriff estandarizó su flujo de trabajo de implementación de modelos utilizando Amazon SageMaker, reduciendo costos y tiempo de desarrollo.

Desafíos de infraestructura y desarrollo

La arquitectura de backend de Veriff se basa en un patrón de microservicios, con servicios en ejecución en diferentes clústeres de Kubernetes alojados en la infraestructura de AWS. Este enfoque se utilizó inicialmente para todos los servicios de la empresa, incluidos los microservicios que ejecutan modelos de visión por computadora de ML costosos.

Algunos de estos modelos requieren implementarse en instancias de GPU. Consciente del costo comparativamente más alto de los tipos de instancias respaldadas por GPU, Veriff desarrolló una solución personalizada en Kubernetes para compartir los recursos de una GPU determinada entre réplicas de servicios diferentes. Una sola GPU típicamente tiene suficiente VRAM para almacenar en memoria múltiples modelos de visión por computadora de Veriff.

Aunque la solución alivió los costos de la GPU, también vino con la restricción de que los científicos de datos debían indicar de antemano cuánta memoria de GPU requeriría su modelo. Además, los equipos de DevOps tenían la carga de aprovisionar manualmente instancias de GPU en respuesta a los patrones de demanda. Esto generaba una sobrecarga operativa y una sobreaprovisionamiento de instancias, lo que resultaba en un perfil de costos subóptimo.

Además de la provisión de GPU, esta configuración también requería que los científicos de datos construyeran un envoltorio de API REST para cada modelo, necesario para proporcionar una interfaz genérica para que otros servicios de la empresa consuman y encapsulen el procesamiento previo y posterior de los datos del modelo. Estas APIs requerían código en producción de calidad, lo que dificultaba la producciónización de los modelos para los científicos de datos.

El equipo de la plataforma de ciencia de datos de Veriff buscó formas alternativas de abordar este enfoque. El objetivo principal era brindar apoyo a los científicos de datos de la empresa con una mejor transición de la investigación a la producción mediante la implementación de canalizaciones de implementación más simples. El objetivo secundario era reducir los costos operativos de provisión de instancias de GPU.

Descripción general de la solución

Veriff necesitaba una nueva solución que resolviera dos problemas:

• Permitir la creación fácil de envoltorios de API REST alrededor de modelos de ML
• Permitir la gestión óptima y, si es posible, automática de la capacidad de las instancias de GPU provisionadas

Finalmente, el equipo de la plataforma de ML se decidió por utilizar Sagemaker multi-model endpoints (MMEs). Esta decisión se basó en el soporte de MMEs para el Triton Inference Server de NVIDIA (un servidor enfocado en ML que facilita la creación de modelos como APIs REST; Veriff también estaba experimentando con Triton), así como en su capacidad para gestionar de forma nativa el escalado automático de las instancias de GPU mediante políticas sencillas de escalado automático.

En Veriff se crearon dos MMEs, uno para el entorno de prueba y otro para producción. Este enfoque les permite realizar pruebas en un entorno de prueba sin afectar a los modelos de producción.

Sagemaker MMEs

SageMaker es un servicio completamente administrado que proporciona a los desarrolladores y científicos de datos la capacidad de construir, entrenar e implementar modelos de ML rápidamente. Los MMEs de SageMaker ofrecen una solución escalable y rentable para implementar una gran cantidad de modelos para inferencia en tiempo real. Los MMEs utilizan un contenedor de servicio compartido y una flota de recursos que pueden utilizar instancias aceleradas como GPUs para alojar todos tus modelos. Esto reduce los costos de alojamiento al maximizar la utilización del punto de enlace en comparación con el uso de puntos de enlace de un solo modelo. También reduce la sobrecarga de implementación porque SageMaker se encarga de cargar y descargar los modelos en memoria y de escalarlos en función de los patrones de tráfico del punto de enlace. Además, todos los puntos de enlace en tiempo real de SageMaker se benefician de capacidades integradas para gestionar y supervisar los modelos, como la inclusión de variantes sombra, escalado automático e integración nativa con Amazon CloudWatch (para obtener más información, consulta las métricas de CloudWatch para implementaciones de puntos de enlace de múltiples modelos).

Modelos de conjunto Triton personalizados

Hubo varias razones por las que Veriff decidió usar Triton Inference Server, las principales son:

• Permite a los científicos de datos crear API REST a partir de modelos organizando los archivos de artefactos modelo en un formato de directorio estándar (sin solución de código)
• Es compatible con todos los principales frameworks de IA (PyTorch, Tensorflow, XGBoost, y más)
• Proporciona optimizaciones de servidor y nivel inferior específicas de ML, como agrupación dinámica de solicitudes

Utilizar Triton permite a los científicos de datos implementar modelos con facilidad porque solo necesitan construir repositorios de modelos formateados en lugar de escribir código para construir API REST (Triton también admite modelos de Python si se requiere una lógica de inferencia personalizada). Esto reduce el tiempo de implementación del modelo y brinda a los científicos de datos más tiempo para centrarse en construir modelos en lugar de implementarlos.

Otra característica importante de Triton es que permite construir modelos de conjunto, que son grupos de modelos encadenados entre sí. Estos conjuntos se pueden ejecutar como si fueran un solo modelo Triton. Actualmente, Veriff emplea esta característica para implementar lógica de preprocesamiento y posprocesamiento con cada modelo de IA utilizando modelos de Python (como se mencionó anteriormente), asegurando que no haya discrepancias en los datos de entrada o en la salida del modelo cuando se utilizan en producción.

El siguiente es un ejemplo de cómo se ve un repositorio de modelos Triton típico para esta carga de trabajo:

El archivo model.py contiene el código de preprocesamiento y posprocesamiento. Los pesos del modelo entrenado se encuentran en el directorio screen_detection_inferencer, bajo la versión del modelo 1 (en este ejemplo, el modelo está en formato ONNX, pero también puede ser en formato TensorFlow, PyTorch u otros). La definición del modelo de conjunto se encuentra en el directorio screen_detection_pipeline, donde las entradas y salidas entre pasos se mapean en un archivo de configuración.

Las dependencias adicionales necesarias para ejecutar los modelos de Python se detallan en un archivo requirements.txt, y deben ser empacadas conda para construir un entorno Conda (python_env.tar.gz). Para obtener más información, consulte Gestión de tiempo de ejecución y bibliotecas de Python. Además, los archivos de configuración para los pasos de Python deben apuntar a python_env.tar.gz utilizando la directiva EXECUTION_ENV_PATH.

Luego, la carpeta del modelo debe ser comprimida en formato TAR y renombrada utilizando model_version.txt. Finalmente, el archivo resultante <nombre_del_modelo>_< versión_del_modelo>.tar.gz se copia en el depósito de Amazon Simple Storage Service (Amazon S3) conectado al MME, lo que permite que SageMaker detecte y sirva el modelo.

Versionado de modelos e implementación continua

Como indicaba la sección anterior, construir un repositorio de modelos Triton es sencillo. Sin embargo, ejecutar todos los pasos necesarios para implementarlo manualmente puede ser tedioso y propenso a errores. Para superar esto, Veriff construyó un monorepo que contiene todos los modelos que se implementarán en MMEs, donde los científicos de datos colaboran utilizando un enfoque similar a Gitflow. Este monorepo tiene las siguientes características:

• Se gestiona utilizando Pants.
• Se aplican herramientas de calidad de código como Black y MyPy utilizando Pants.
• Se definen pruebas unitarias para cada modelo, las cuales verifican que la salida del modelo sea la salida esperada para una determinada entrada del modelo.
• Los pesos del modelo se almacenan junto con los repositorios del modelo. Estos pesos pueden ser archivos binarios grandes, por lo que se utiliza DVC para sincronizarlos con Git de manera versionada.

Este monorepo está integrado con una herramienta de integración continua (CI). Para cada nueva carga en el repositorio o nuevo modelo, se ejecutan los siguientes pasos:

1. Pasar la revisión de calidad del código.
2. Descargar los pesos del modelo.
3. Construir el entorno Conda.
4. Crear un servidor Triton utilizando el entorno Conda y utilizarlo para procesar solicitudes definidas en pruebas unitarias.
5. Construir el archivo TAR final del modelo (<nombre_del_modelo>_<versión_del_modelo>.tar.gz).

Estos pasos aseguran que los modelos tengan la calidad requerida para su implementación, por lo que en cada carga a una rama del repositorio, el archivo TAR resultante se copia (en otro paso de CI) en el bucket de S3 de puesta en escena. Cuando se hacen cargas en la rama principal, el archivo del modelo se copia en el bucket de S3 de producción. El siguiente diagrama representa este sistema de CI/CD.

Beneficios de costos y velocidad de implementación

El uso de MMEs permite a Veriff utilizar un enfoque de monorepo para implementar modelos en producción. En resumen, el flujo de trabajo de implementación de nuevos modelos de Veriff consta de los siguientes pasos:

1. Crear una rama en el monorepo con el nuevo modelo o versión del modelo.
2. Definir y ejecutar pruebas unitarias en una máquina de desarrollo.
3. Cargar la rama cuando el modelo esté listo para ser probado en el entorno de puesta en escena.
4. Combinar la rama con la rama principal cuando el modelo esté listo para ser utilizado en producción.

Con esta nueva solución implementada, la implementación de un modelo en Veriff es una parte sencilla del proceso de desarrollo. El tiempo de desarrollo de nuevos modelos ha disminuido de 10 días a un promedio de 2 días.

Las características de aprovisionamiento de infraestructura gestionada y escalado automático de SageMaker brindaron beneficios adicionales a Veriff. Utilizaron la métrica de CloudWatch InvocationsPerInstance para escalar según los patrones de tráfico, ahorrando en costos sin comprometer la confiabilidad. Para definir el valor umbral de la métrica, realizaron pruebas de carga en el punto final de puesta en escena para encontrar el mejor equilibrio entre latencia y costos.

Después de implementar siete modelos de producción en MMEs y analizar los gastos, Veriff informó una reducción del 75% en costos en el servicio de modelos GPU en comparación con la solución original basada en Kubernetes. Los costos operativos también se redujeron, ya que se eliminó la carga de aprovisionar instancias manualmente de los ingenieros de DevOps de la compañía.

Conclusión

En esta publicación, revisamos por qué Veriff eligió las MMEs de Sagemaker en lugar de la implementación de modelos autoadministrados en Kubernetes. SageMaker se encarga de las tareas pesadas y no diferenciadas, lo que permite a Veriff reducir el tiempo de desarrollo de modelos, aumentar la eficiencia de ingeniería y disminuir drásticamente los costos para la inferencia en tiempo real, al tiempo que mantiene el rendimiento necesario para sus operaciones críticas para el negocio. Por último, mostramos el sencillo pero efectivo flujo de trabajo de implementación de modelos de CI/CD y el mecanismo de versionado de modelos de Veriff, que puede utilizarse como una implementación de referencia de las mejores prácticas de desarrollo de software y las MMEs de SageMaker. Puede encontrar ejemplos de código sobre cómo alojar varios modelos usando MMEs de SageMaker en GitHub.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!