Logre alojamiento de baja latencia para modelos de aprendizaje automático basados ​​en árboles de decisión en NVIDIA Triton Inference Server en Amazon SageMaker

Las implementaciones de modelos de aprendizaje automático (ML) pueden tener requisitos de rendimiento y latencia muy exigentes para las empresas de hoy. Los casos de uso, como la detección de fraudes y la colocación de anuncios, son ejemplos en los que los milisegundos importan y son fundamentales para el éxito empresarial. Se deben cumplir estrictos acuerdos de nivel de servicio (SLA), y una solicitud típica puede requerir varios pasos, como preprocesamiento, transformación de datos, lógica de selección de modelos, agregación de modelos y posprocesamiento. A escala, esto a menudo significa mantener un gran volumen de tráfico mientras se mantiene una baja latencia. Los patrones de diseño comunes incluyen canalizaciones de inferencia en serie, conjuntos (dispersión-reunión) y flujos de trabajo de lógica empresarial, que dan como resultado la realización de todo el flujo de trabajo de la solicitud como un gráfico acíclico dirigido (DAG). Sin embargo, a medida que los flujos de trabajo se vuelven más complejos, esto puede generar un aumento en los tiempos de respuesta generales, lo que a su vez puede afectar negativamente la experiencia del usuario final y poner en peligro los objetivos comerciales. Triton puede abordar estos casos de uso en los que se componen varios modelos en una tubería con tensores de entrada y salida conectados entre ellos, lo que lo ayuda a abordar estas cargas de trabajo.

A medida que evalúa sus objetivos en relación con la inferencia del modelo ML, se pueden considerar muchas opciones, pero pocas son tan capaces y probadas como Amazon SageMaker Servidor de inferencia Triton. SageMaker con Triton Inference Server ha sido una opción popular para muchos clientes porque está diseñado específicamente para maximizar el rendimiento y la utilización del hardware con latencia de inferencia ultrabaja (milisegundos de un solo dígito). Tiene una amplia gama de marcos de ML compatibles (incluidos TensorFlow, PyTorch, ONNX, XGBoost y NVIDIA TensorRT) y backends de infraestructura, que incluyen GPU, CPU y GPU de NVIDIA. Inferencia de AWS. Además, Triton Inference Server está integrado con SageMaker, un servicio de ML de extremo a extremo completamente administrado, que brinda opciones de inferencia en tiempo real para el alojamiento de modelos.

En esta publicación, analizamos la implementación de una carga de trabajo de conjunto de detección de fraudes en SageMaker con Triton Inference Server.

Resumen de la solución

Es fundamental para cualquier proyecto tener una lista de requisitos y una estimación de esfuerzo, para poder aproximar el costo total del proyecto. Es importante estimar el retorno de la inversión (ROI) que respalda la decisión de una organización. Algunas consideraciones a tener en cuenta al mover una carga de trabajo a Triton incluyen:

La estimación del esfuerzo es clave en el desarrollo de software, y su medición a menudo se basa en entradas incompletas, inciertas y ruidosas. Las cargas de trabajo de ML no son diferentes. Múltiples factores afectarán una arquitectura para la inferencia de ML, algunos de los cuales incluyen:

• Presupuesto de latencia del lado del cliente – Especifica el tiempo de espera aceptable máximo de ida y vuelta del lado del cliente para una respuesta de inferencia, comúnmente expresado en percentiles. Para las cargas de trabajo que requieren un presupuesto de latencia de cerca de decenas de milisegundos, las transferencias de red pueden volverse costosas, por lo que el uso de modelos en el perímetro sería una mejor opción.
• Tamaño de distribución de la carga útil de datos – Carga útil, a menudo denominada Cuerpo del mensaje, son los datos de solicitud transmitidos desde el cliente al modelo, así como los datos de respuesta transmitidos desde el modelo al cliente. El tamaño de la carga útil a menudo tiene un gran impacto en la latencia y debe tenerse en cuenta.
• Formato de datos – Esto especifica cómo se envía la carga útil al modelo ML. El formato puede ser legible por humanos, como JSON y CSV; sin embargo, también hay formatos binarios, que a menudo están comprimidos y son más pequeños. Esta es una compensación entre la sobrecarga de compresión y el tamaño de la transferencia, lo que significa que se agregan ciclos de CPU y latencia para comprimir o descomprimir, a fin de ahorrar bytes transferidos a través de la red. Esta publicación muestra cómo utilizar los formatos JSON y binario.
• Pila de software y componentes requeridos – Una pila es una colección de componentes que funcionan juntos para admitir una aplicación ML, incluido el sistema operativo, los tiempos de ejecución y las capas de software. Triton viene con marcos de ML populares incorporados, llamados backends, como ONNX, TensorFlow, FIL, OpenVINO, Python nativo y otros. También puede crear un backend personalizado para sus propios componentes de cosecha propia. Esta publicación trata sobre un modelo XGBoost y el preprocesamiento de datos, que migramos a los backends FIL y Python Triton proporcionados por NVIDIA, respectivamente.

Todos estos factores deberían desempeñar un papel vital en la evaluación del rendimiento de sus cargas de trabajo, pero en este caso de uso nos centramos en el trabajo necesario para mover sus modelos de ML para que se alojen en SageMaker con Triton Inference Server. Específicamente, usamos un ejemplo de un conjunto de detección de fraude compuesto por un modelo XGBoost con lógica de preprocesamiento escrita en Python.

Servidor de inferencia NVIDIA Triton

Triton Inference Server se ha diseñado desde cero para permitir que los equipos implementen, ejecuten y escalen modelos de IA capacitados desde cualquier marco en una infraestructura basada en GPU o CPU. Además, se ha optimizado para ofrecer inferencia de alto rendimiento a escala con funciones como procesamiento por lotes dinámico, ejecuciones simultáneas, configuración óptima del modelo, conjunto de modelos y compatibilidad con entradas de transmisión.

El siguiente diagrama muestra un ejemplo de canalización de conjunto de NVIDIA Triton.

Las cargas de trabajo deben tener en cuenta las capacidades que proporciona Triton junto con el alojamiento de SageMaker para maximizar los beneficios ofrecidos. Por ejemplo, Triton es compatible con HTTP, así como con un API de C, que permiten flexibilidad y optimización de la carga útil cuando es necesario. Como se mencionó anteriormente, Triton admite varios marcos populares listos para usar, incluidos TensorFlow, PyTorch, ONNX, XGBoost y NVIDIA TensorRT. Estos marcos son compatibles con los backends de Triton y, en el raro caso de que un backend no sea compatible con su caso de uso, Triton le permite implementar el suyo propio e integrarlo fácilmente.

El siguiente diagrama muestra un ejemplo de la arquitectura NVIDIA Triton.

NVIDIA Tritón en SageMaker

Alojamiento de SageMaker Los servicios son el conjunto de funciones de SageMaker destinadas a facilitar la implementación y el servicio de modelos. Proporciona una variedad de opciones para implementar, escalar automáticamente, monitorear y optimizar fácilmente los modelos ML adaptados para diferentes casos de uso. Esto significa que puede optimizar sus implementaciones para todo tipo de patrones de uso, desde necesidades persistentes y siempre disponibles con opciones sin servidor hasta necesidades transitorias, de ejecución prolongada o de inferencia por lotes.

Bajo el paraguas de alojamiento de SageMaker también se encuentra el conjunto de contenedores de aprendizaje profundo (DLC) de inferencia de SageMaker, que vienen preempaquetados con el software de servidor modelo apropiado para su marco de ML compatible correspondiente. Esto le permite lograr un alto rendimiento de inferencia sin configurar un servidor de modelos, que suele ser el aspecto técnico más complejo de la implementación de modelos y, en general, no forma parte del conjunto de habilidades de un científico de datos. El servidor de inferencia Triton ya está Hoy Disponibles en los DLC de SageMaker.

Esta amplitud de opciones, modularidad y facilidad de uso de diferentes marcos de trabajo hace que SageMaker y Triton sean una combinación poderosa.

Soporte de back-end NVIDIA FIL

Con la Lanzamiento de la versión 22.05 de Triton, NVIDIA ahora admite modelos forestales entrenados por varios marcos de ML populares, incluidos XGBoost, LightGBM, Scikit-learn y cuML. Al usar el backend de FIL para Triton, debe asegurarse de que los artefactos del modelo que proporcione sean compatibles. Por ejemplo, la FIL apoya model_type xgboost, xgboost_json, lightgbmo treelite_checkpoint, que indica si el modelo proporcionado está en formato binario XGBoost, formato JSON XGBoost, formato de texto LightGBM o formato binario Treelite, respectivamente.

Este soporte de back-end es esencial para que lo usemos en nuestro ejemplo porque FIL admite modelos XGBoost. La única consideración que debe verificar es asegurarse de que el modelo que implementamos admita formatos binarios o JSON.

Además de asegurarse de tener el formato de modelo adecuado, se deben tomar otras consideraciones. El backend de FIL para Triton proporciona opciones configurables para que los desarrolladores ajusten sus cargas de trabajo y optimicen el rendimiento de la ejecución del modelo. La configuración dynamic_batching permite a Triton retener solicitudes del lado del cliente y procesarlas por lotes en el lado del servidor, con el fin de utilizar de manera eficiente el cómputo paralelo de FIL para inferir el lote completo. La opción max_queue_delay_microseconds ofrece un control a prueba de fallas de cuánto tiempo espera Triton para formar un lote. FIL viene con el explicador de Shapley, que se puede activar mediante la configuración treeshap_output; sin embargo, debe tener en cuenta que las salidas de Shapley perjudican el rendimiento debido a su tamaño de salida. Otro aspecto importante es storage_type para equilibrar la huella de memoria y el tiempo de ejecución. Por ejemplo, el uso de almacenamiento como DISPERSO puede reducir el consumo de memoria, mientras que DENSO puede reducir el rendimiento de ejecución de su modelo a expensas de un mayor uso de memoria. Decidir cuál es la mejor opción para cada uno de estos depende de su carga de trabajo y su presupuesto de latencia, por lo que le recomendamos que analice más a fondo todas las opciones en el Preguntas frecuentes sobre el back-end de FIL y del lista de configuraciones disponibles en FIL.

Pasos para alojar un modelo en Triton

Veamos nuestro caso de uso de detección de fraude como un ejemplo de lo que se debe considerar al mover una carga de trabajo a Triton.

Identifica tu carga de trabajo

En este caso de uso, tenemos un modelo de detección de fraude utilizado durante el proceso de pago de un cliente minorista. La canalización de inferencia utiliza un algoritmo XGBoost con lógica de preprocesamiento que incluye la preparación de datos para el preprocesamiento.

Identifique las métricas de rendimiento actuales y objetivo y otros objetivos que puedan aplicarse

Es posible que descubra que su tiempo de inferencia de extremo a extremo está tardando demasiado para ser aceptable. Su objetivo podría ser pasar de decenas de milisegundos de latencia a una latencia de un solo dígito para el mismo volumen de solicitudes y rendimiento respectivo. Determina que la mayor parte del tiempo lo consume el preprocesamiento de datos y el modelo XGBoost. Otros factores, como la red y el tamaño de la carga útil, juegan un papel mínimo en la sobrecarga asociada con el tiempo de inferencia de extremo a extremo.

Trabaje hacia atrás para determinar si Triton puede alojar su carga de trabajo en función de sus requisitos

Para determinar si Triton puede cumplir con sus requisitos, debe prestar atención a dos áreas principales de preocupación. El primero es asegurarse de que Triton pueda servir con una opción de front-end aceptable, como HTTP o C API.

Como se mencionó anteriormente, también es fundamental determinar si Triton admite un backend que pueda servir a sus artefactos. Triton es compatible con una serie de backends que están hechos a medida para admitir varios marcos como PyTorch y TensorFlow. Verifique que sus modelos sean compatibles y que tenga el formato de modelo adecuado que Triton espera. Para hacer esto, primero verifique qué formatos de modelo admite el backend de Triton. En muchos casos, esto no requiere ningún cambio para el modelo. En otros casos, su modelo puede requerir una transformación a un formato diferente. Dependiendo del formato de origen y de destino, existen varias opciones, como transformar un Archivo de pickle de Python para usar el formato de punto de control binario de Treelite.

Para este caso de uso, determinamos el back-end de FIL puede admitir el modelo XGBoost sin necesidad de cambios y que podemos usar el back-end de Python para el preprocesamiento. Con la función de conjunto de Triton, puede optimizar aún más su carga de trabajo al evitar costosas llamadas de red entre instancias de alojamiento.

Cree un plan y calcule el esfuerzo necesario para utilizar Triton para el alojamiento

Hablemos del plan para trasladar sus modelos a Triton. Cada implementación de Triton requiere lo siguiente:

• Modelo de artefactos requeridos por los backends de Triton
• Archivos de configuración de Tritón
• Una carpeta de repositorio de modelos con la estructura adecuada

Mostramos un ejemplo de cómo crear estas dependencias de implementación más adelante en esta publicación.

Ejecutar el plan y validar los resultados

Después de crear los archivos y artefactos necesarios en el repositorio de modelos correctamente estructurado, debe ajustar su implementación y probarla para validar que ahora ha alcanzado las métricas de destino.

En este punto, puede usar Recomendador de inferencia de SageMaker para determinar qué tipo de instancia de punto final es mejor para usted en función de sus requisitos. Además, Triton proporciona herramientas para realizar optimizaciones de compilación para obtener un mejor rendimiento.

Implementación

Ahora veamos los detalles de implementación. Para ello hemos preparado dos cuadernos que sirven de ejemplo de lo que se puede esperar. los primer cuaderno muestra el entrenamiento del modelo XGBoost dado, así como la lógica de preprocesamiento que se usa tanto para el entrenamiento como para el tiempo de inferencia. los segundo cuaderno muestra cómo preparamos los artefactos necesarios para el despliegue en Triton.

La primera libreta muestra una libreta existente que tiene su organización y que usa el RÁPIDOS conjunto de bibliotecas y el kernel RAPIDS Conda. Esta instancia se ejecuta en un tipo de instancia G4DN proporcionada por AWS, acelerada por GPU mediante el uso de procesadores NVIDIA T4.

Las tareas de preprocesamiento de este ejemplo se benefician de la aceleración de la GPU y utilizan en gran medida las bibliotecas cuML y cuDF. Un ejemplo de esto está en el siguiente código, donde mostramos la codificación de etiquetas categóricas usando cuML. También generamos un label_encoders.pkl archivo que podemos usar para serializar los codificadores y usarlos para el preprocesamiento durante el tiempo de inferencia.

El primer cuaderno concluye entrenando nuestro modelo XGBoost y guardando los artefactos en consecuencia.

En este escenario, el código de entrenamiento ya existía y no se necesitan cambios para el modelo en el momento del entrenamiento. Además, aunque usamos la aceleración de GPU para el preprocesamiento durante el entrenamiento, planeamos usar CPU para el preprocesamiento en el momento de la inferencia. Te explicamos más adelante en el post.

Pasemos ahora al segundo cuaderno y recordemos lo que necesitamos para una implementación exitosa de Triton.

Primero, necesitamos los artefactos del modelo requeridos por los backends. Los archivos que necesitamos crear para este conjunto incluyen:

• Artefactos de preprocesamiento (model.py, label_encoders.pkl)
• Artefactos del modelo XGBoost (xgboost.json)

El backend de Python en Triton requiere que usemos un entorno Conda como dependencia. En este caso, usamos el backend de Python para preprocesar los datos sin procesar antes de introducirlos en el modelo XGBoost que se ejecuta en el backend de FIL. Aunque originalmente usamos las bibliotecas RAPIDS cuDF y cuML para realizar el preprocesamiento de datos (como se mencionó anteriormente usando nuestra GPU), aquí usamos Pandas y Scikit-learn como dependencias de preprocesamiento para el tiempo de inferencia (usando nuestra CPU). Hacemos esto por tres razones:

• Para mostrar cómo crear un entorno Conda para sus dependencias y cómo empaquetarlo en el formato esperado por el backend Python de Triton.
• Al mostrar el modelo de preprocesamiento que se ejecuta en el backend de Python en la CPU mientras que el modelo XGBoost se ejecuta en la GPU en el backend de FIL, ilustramos cómo cada modelo en la canalización de conjunto de Triton puede ejecutarse en un backend de marco diferente y ejecutarse en hardware diferente con diferentes configuraciones
• Destaca cómo las bibliotecas RAPIDS (cuDF, cuML) son compatibles con sus contrapartes de CPU (Pandas, Scikit-learn). De esta manera, podemos mostrar cómo LabelEncoders creado en cuML se puede usar en Scikit-learn y viceversa. Tenga en cuenta que si espera preprocesar grandes cantidades de datos tabulares durante el tiempo de inferencia, aún puede usar RAPIDS para acelerarlos con GPU.

Recuerda que creamos el label_encoders.pkl archivo en el primer cuaderno. No hay nada más que hacer para la codificación de categorías que no sea incluirlo en nuestro model.py archivo para preprocesamiento.

Para crear el archivo model.py requerido por el backend Triton Python, nos adherimos a la formato requerido por el backend e incluir nuestra lógica de Python para procesar el tensor entrante y usar el codificador de etiquetas mencionado anteriormente. Puedes revisar el presentar utilizado para el preprocesamiento.

Para el modelo XGBoost, no es necesario hacer nada más. Entrenamos al modelo en el primer portátil y el backend FIL de Triton no requiere ningún esfuerzo adicional para los modelos XGBoost.

A continuación, necesitamos los archivos de configuración de Triton. Cada modelo en el conjunto Triton requiere un config.pbtxt expediente. Además, también creamos un config.pbtxt archivo para el conjunto como un todo. Estos archivos le permiten a Triton conocer metadatos sobre el conjunto con información como las entradas y salidas que esperamos, así como ayudar a definir el DAG asociado con el conjunto.

Por último, para implementar un modelo en Triton, necesitamos que nuestra carpeta de repositorio de modelos tenga la estructura de carpetas adecuada. Triton tiene requisitos específicos para el diseño del repositorio de modelos. Dentro del directorio del repositorio de modelos de nivel superior, cada modelo tiene su propio subdirectorio que contiene la información del modelo correspondiente. Cada directorio de modelo en Triton debe tener al menos un subdirectorio numérico que represente una versión del modelo. Para nuestro caso de uso, la estructura resultante debería verse como la siguiente.

Una vez que tengamos estos tres requisitos previos, creamos un archivo comprimido como paquete para la implementación y lo subimos a Servicio de almacenamiento simple de Amazon (Amazon S3).

Ahora podemos crear un modelo de SageMaker desde el repositorio de modelos que cargamos en Amazon S3 en el paso anterior.

En este paso, también proporcionamos la variable de entorno adicional SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, que especifica el nombre del modelo que Triton cargará. El valor de esta clave debe coincidir con el nombre de la carpeta en el paquete del modelo cargado en Amazon S3. Esta variable es opcional en el caso de un solo modelo. En el caso de modelos de conjuntos, esta clave debe especificarse para que Triton se inicie en SageMaker.

Además, puede configurar SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT y SAGEMAKER_TRITON_THREAD_COUNT para optimizar el número de hilos. Ambos valores de configuración ayudan a ajustar la cantidad de subprocesos que se ejecutan en sus CPU, por lo que posiblemente pueda obtener una mejor utilización al aumentar estos valores para las CPU con una mayor cantidad de núcleos. En la mayoría de los casos, los valores predeterminados suelen funcionar bien, pero puede valer la pena experimentar para ver si se puede obtener una mayor eficiencia para sus cargas de trabajo.

Con el modelo anterior, creamos una configuración de punto final donde podemos especificar el tipo y la cantidad de instancias que queremos en el punto final.

Por último, usamos la configuración de punto final anterior para crear un nuevo punto final de SageMaker y esperamos a que finalice la implementación. El estado cambia a InService después de que la implementación sea exitosa.

¡Eso es todo! Su punto final ahora está listo para la prueba y la validación. En este punto, es posible que desee utilizar varias herramientas para ayudar a optimizar los tipos y la configuración de sus instancias para obtener el mejor rendimiento posible. La siguiente figura proporciona un ejemplo de las ganancias que se pueden lograr al usar el backend FIL para un modelo XGBoost en Triton.

Resumen

En esta publicación, lo guiamos a través de la implementación de una carga de trabajo de conjunto XGBoost en SageMaker con Triton Inference Server. Mover cargas de trabajo a Triton en SageMaker puede ser un retorno de la inversión beneficioso. Al igual que con cualquier adopción de tecnología, un proceso y un plan de investigación son clave, y detallamos un proceso de cinco pasos para guiarlo a través de lo que debe considerar al mover sus cargas de trabajo. Además, profundizamos en los pasos necesarios para implementar un conjunto que usa el preprocesamiento de Python y un modelo XGBoost en Triton en SageMaker.

SageMaker proporciona las herramientas para eliminar el trabajo pesado no diferenciado de cada etapa del ciclo de vida de ML, lo que facilita la experimentación y exploración rápidas necesarias para optimizar por completo las implementaciones de su modelo. La compatibilidad con el alojamiento de SageMaker para Triton Inference Server permite cargas de trabajo de transacciones por segundo (TPS) altas y de baja latencia.

Puede encontrar los cuadernos utilizados para este ejemplo en GitHub.

---

Acerca del autor.

James Park es arquitecto de soluciones en Amazon Web Services. Trabaja con Amazon.com para diseñar, crear e implementar soluciones tecnológicas en AWS y tiene un interés particular en la IA y el aprendizaje automático. En su tiempo libre le gusta buscar nuevas culturas, nuevas experiencias y mantenerse al día con las últimas tendencias tecnológicas.

jiahong liu es arquitecto de soluciones en el equipo de proveedores de servicios en la nube de NVIDIA. Ayuda a los clientes a adoptar soluciones de inteligencia artificial y aprendizaje automático que aprovechan la computación acelerada de NVIDIA para abordar sus desafíos de capacitación e inferencia. En su tiempo libre, disfruta del origami, proyectos de bricolaje y jugar al baloncesto.

Kshitiz Gupta es arquitecto de soluciones en NVIDIA. Le gusta educar a los clientes de la nube sobre las tecnologías GPU AI que NVIDIA tiene para ofrecer y ayudarlos a acelerar sus aplicaciones de aprendizaje automático y aprendizaje profundo. Fuera del trabajo, le gusta correr, caminar y observar la vida silvestre.

Bruno Aguiar de Melo es ingeniero de desarrollo de software en Amazon.com, donde ayuda a los equipos científicos a crear, implementar y lanzar cargas de trabajo de aprendizaje automático. Está interesado en la instrumentación y los aspectos controlables dentro de la fase de modelado/diseño de ML que se deben considerar y medir con la idea de que el rendimiento de la ejecución del modelo es tan importante como el rendimiento de la calidad del modelo, particularmente en casos de uso con latencia limitada. En su tiempo libre, disfruta del vino, los juegos de mesa y la cocina.

Eliuth Triana es Gerente de Relaciones con los Desarrolladores en NVIDIA. Conecta a los líderes de productos, desarrolladores y científicos de Amazon y AWS con los tecnólogos y líderes de productos de NVIDIA para acelerar las cargas de trabajo de Amazon ML/DL, los productos EC2 y los servicios de IA de AWS. Además, Eliuth es un apasionado del ciclismo de montaña, esquiador y jugador de póquer.