Logre un rendimiento de hiperescala para el servicio de modelos con NVIDIA Triton Inference Server en Amazon SageMaker

Las aplicaciones de aprendizaje automático (ML) son complejas de implementar y, a menudo, requieren varios modelos de ML para atender una sola solicitud de inferencia. Una solicitud típica puede fluir a través de múltiples modelos con pasos como preprocesamiento, transformaciones de datos, lógica de selección de modelos, agregación de modelos y posprocesamiento. Esto ha llevado a la evolución de patrones de diseño comunes, como canalizaciones de inferencia en serie, conjuntos (recolección de dispersión) y flujos de trabajo de lógica de negocios, lo que da 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 conduce a un aumento en los tiempos de respuesta generales, o latencia, de estas aplicaciones, lo que a su vez afecta la experiencia general del usuario. Además, si estos componentes están alojados en diferentes instancias, la latencia de red adicional entre estas instancias aumenta la latencia general. Considere un ejemplo de un caso de uso de ML popular para un asistente virtual en atención al cliente. Es posible que una solicitud típica deba pasar por varios pasos relacionados con el reconocimiento de voz, el procesamiento del lenguaje natural (NLP), el seguimiento del estado del diálogo, la política de diálogo, la generación de texto y, finalmente, el texto a voz. Además, para que la interacción del usuario sea más personalizada, también puede utilizar modelos NLP basados ​​en transformadores de última generación, como diferentes versiones de BERTI, BARTy GPT. El resultado final son tiempos de respuesta prolongados para estos conjuntos de modelos y una mala experiencia para el cliente.

Un patrón común para reducir los tiempos de respuesta sin comprometer el rendimiento general es alojar estos modelos en la misma instancia junto con la lógica comercial liviana integrada en él. Estos modelos se pueden encapsular aún más dentro de uno o varios contenedores en la misma instancia para proporcionar aislamiento para los procesos en ejecución y mantener baja la latencia. Además, la latencia general también depende de la lógica de la aplicación de inferencia, las optimizaciones del modelo, la infraestructura subyacente (incluidos el procesamiento, el almacenamiento y las redes) y el servidor web subyacente que toma las solicitudes de inferencia. Servidor de inferencia NVIDIA Triton es un software de servicio de inferencia de código abierto con características para maximizar el rendimiento y la utilización del hardware con una latencia de inferencia ultrabaja (milisegundos de un solo dígito). Tiene una amplia compatibilidad con marcos de aprendizaje automático (incluidos TensorFlow, PyTorch, ONNX, XGBoost y NVIDIA TensorRT) y backends de infraestructura, incluidas GPU, CPU y Inferencia de AWS. Además, Triton Inference Server está integrado con Amazon SageMaker, un servicio de ML de extremo a extremo completamente administrado, que brinda opciones de inferencia en tiempo real, que incluyen soltero y multimodelo hospedaje Estas opciones de inferencia incluyen albergar varios modelos dentro del mismo contenedor detrás de un punto final únicoy hospedaje múltiples modelos con múltiples contenedores detrás de un único punto final.

En noviembre de 2021, anunciamos la integración de Triton Inference Server en SageMaker. AWS trabajó en estrecha colaboración con NVIDIA para permitirle obtener lo mejor de ambos mundos y facilitar la implementación de modelos con Triton en AWS.

En esta publicación, analizamos las prácticas recomendadas para implementar modelos de transformadores a escala en GPU mediante Triton Inference Server en SageMaker. Primero, comenzamos con un resumen de los conceptos clave sobre la latencia en SageMaker y una descripción general de las pautas de ajuste del rendimiento. A continuación, proporcionamos una descripción general de Triton y sus funciones, así como un código de ejemplo para implementar en SageMaker. Finalmente, realizamos pruebas de carga utilizando Recomendador de inferencia de SageMaker y resuma los conocimientos y las conclusiones de las pruebas de carga de un popular modelo de transformador proporcionado por Hugging Face.

Puede revisar el cuaderno solíamos implementar modelos y realizar pruebas de carga por su cuenta usando el código en GitHub.

Ajuste y optimización del rendimiento para la publicación de modelos en SageMaker

El ajuste y la optimización del rendimiento es un proceso empírico que a menudo implica múltiples iteraciones. El número de parámetros a ajustar es combinatorio y el conjunto de valores de los parámetros de configuración no son independientes entre sí. Varios factores afectan el ajuste óptimo de los parámetros, incluido el tamaño de la carga útil, el tipo y la cantidad de modelos ML en el gráfico de flujo de solicitud de inferencia, el tipo de almacenamiento, el tipo de instancia informática, la infraestructura de red, el código de la aplicación, el tiempo de ejecución y la configuración del software de servicio de inferencia, y más.

Si usa SageMaker para implementar modelos de aprendizaje automático, debe seleccionar una instancia informática con la mejor relación precio-rendimiento, lo cual es un proceso complicado e iterativo que puede llevar semanas de experimentación. Primero, debe elegir el tipo de instancia de ML correcto entre más de 70 opciones según los requisitos de recursos de sus modelos y el tamaño de los datos de entrada. A continuación, debe optimizar el modelo para el tipo de instancia seleccionado. Por último, debe aprovisionar y administrar la infraestructura para ejecutar pruebas de carga y ajustar la configuración de la nube para obtener un rendimiento y un costo óptimos. Todo esto puede retrasar la implementación del modelo y el tiempo de comercialización. Además, debe evaluar las compensaciones entre latencia, rendimiento y costo para seleccionar la configuración de implementación óptima. Recomendador de inferencia de SageMaker selecciona automáticamente el tipo de instancia informática, el recuento de instancias, los parámetros del contenedor y las optimizaciones del modelo correctos para la inferencia a fin de maximizar el rendimiento, reducir la latencia y minimizar el costo.

Inferencia y latencia en tiempo real en SageMaker

Inferencia en tiempo real de SageMaker es ideal para cargas de trabajo de inferencia donde tiene requisitos de baja latencia, interactivos y en tiempo real. Hay cuatro métricas más utilizadas para monitorear la latencia de solicitud de inferencia para puntos finales de inferencia de SageMaker

• Latencia del contenedor – El tiempo que lleva enviar la solicitud, obtener la respuesta del contenedor del modelo y completar la inferencia en el contenedor. Esta métrica está disponible en Amazon CloudWatch como parte de la Métricas de invocación publicado por SageMaker.
• latencia del modelo – El tiempo total que tardan todos los contenedores de SageMaker en un tubería de inferencia. Esta métrica está disponible en Amazon CloudWatch como parte de la Métricas de invocación publicado por SageMaker.
• latencia de sobrecarga – Medido desde el momento en que SageMaker recibe la solicitud hasta que devuelve una respuesta al cliente, menos la latencia del modelo. Esta métrica está disponible en Amazon CloudWatch como parte de la Métricas de invocación publicado por SageMaker.
• Latencia de extremo a extremo – Medido desde el momento en que el cliente envía la solicitud de inferencia hasta que recibe una respuesta. Los clientes pueden publicar esto como una métrica personalizada en Amazon CloudWatch.

El siguiente diagrama ilustra estos componentes.

La latencia del contenedor depende de varios factores; los siguientes son algunos de los más importantes:

• Protocolo subyacente (HTTP(s)/gRPC) utilizado para comunicarse con el servidor de inferencia
• Sobrecarga relacionada con la creación de nuevas conexiones TLS
• Tiempo de deserialización de la carga útil de solicitud/respuesta
• Solicitud de colas y funciones de procesamiento por lotes proporcionadas por el servidor de inferencia subyacente
• Capacidades de programación de solicitudes proporcionadas por el servidor de inferencia subyacente
• Rendimiento de tiempo de ejecución subyacente del servidor de inferencia
• Rendimiento de las bibliotecas de preprocesamiento y posprocesamiento antes de llamar a la función de predicción del modelo
• Rendimiento de back-end del marco de ML subyacente
• Optimizaciones específicas del modelo y del hardware

En esta publicación, nos enfocamos principalmente en optimizar la latencia del contenedor junto con el rendimiento y el costo general. Específicamente, exploramos el ajuste del rendimiento de Triton Inference Server ejecutándose dentro de un contenedor de SageMaker.

Resumen del caso de uso

Implementar y escalar modelos NLP en una configuración de producción puede ser todo un desafío. Los modelos de PNL suelen tener un tamaño muy grande y contienen millones de parámetros de modelo. Se requieren configuraciones de modelo óptimas para satisfacer los estrictos requisitos de rendimiento y escalabilidad de las aplicaciones NLP de grado de producción.

En esta publicación, comparamos un caso de uso de NLP utilizando un punto final en tiempo real de SageMaker basado en un contenedor Triton Inference Server y recomendamos optimizaciones de ajuste de rendimiento para nuestro caso de uso de ML. Usamos un Hugging Face basado en un transformador grande y preentrenado BERT grande sin carcasa modelo, que tiene alrededor de 336 millones de parámetros de modelo. La oración de entrada utilizada para el modelo de clasificación binaria se rellena y se trunca a una longitud máxima de secuencia de entrada de 512 tokens. La prueba de carga de inferencia simula 500 invocaciones por segundo (30,000 XNUMX invocaciones como máximo por minuto) y ModelLatency de menos de 0.5 segundos (500 milisegundos).

La siguiente tabla resume nuestra configuración de referencia.

Servidor de inferencia NVIDIA Triton

Triton Inference Server está diseñado específicamente para permitir una implementación escalable, rápida y fácil de modelos en producción. Triton es compatible con una variedad de marcos de IA importantes, incluidos TensorFlow, TensorRT, PyTorch, XGBoost y ONNX. Con el backend personalizado de Python y C++, también puede implementar su carga de trabajo de inferencia para casos de uso más personalizados.

Lo que es más importante, Triton proporciona una configuración simple basada en la configuración para alojar sus modelos, lo que expone un amplio conjunto de funciones de optimización del rendimiento que puede usar con poco esfuerzo de codificación.

Triton aumenta el rendimiento de la inferencia al maximizar la utilización del hardware con diferentes técnicas de optimización (las ejecuciones simultáneas de modelos y el procesamiento por lotes dinámico son las más utilizadas). Encontrar las configuraciones de modelos óptimas a partir de varias combinaciones de tamaños de lotes dinámicos y la cantidad de instancias de modelos concurrentes es clave para lograr una inferencia en tiempo real dentro de un servicio de bajo costo con Triton.

Procesamiento por lotes dinámico

Muchos profesionales tienden a ejecutar la inferencia secuencialmente cuando se invoca el servidor con múltiples solicitudes independientes. Aunque es más fácil de configurar, generalmente no es la mejor práctica utilizar la potencia de cómputo de la GPU. Para abordar esto, Triton ofrece las optimizaciones integradas de procesamiento por lotes dinámico para combinar estas solicitudes de inferencia independientes en el lado del servidor para formar dinámicamente un lote más grande para aumentar el rendimiento. El siguiente diagrama ilustra la arquitectura de tiempo de ejecución de Triton.

En la arquitectura anterior, todas las solicitudes llegan primero al dosificador dinámico antes de ingresar a las colas del programador del modelo real para esperar la inferencia. Puede establecer sus tamaños de lote preferidos para el procesamiento por lotes dinámico utilizando el tamaño_de_lote_preferido ajustes en la configuración del modelo. (Tenga en cuenta que el tamaño del lote formado debe ser menor que el tamaño_max_batch admite el modelo.) También puede configurar max_queue_delay_microsegundos para especificar el tiempo de demora máximo en el procesador por lotes para esperar otras solicitudes para unirse al lote en función de sus requisitos de latencia.

El siguiente fragmento de código muestra cómo puede agregar esta función con los archivos de configuración del modelo para establecer el procesamiento por lotes dinámico con un tamaño de lote preferido de 16 para la inferencia real. Con la configuración actual, la instancia del modelo se invoca instantáneamente cuando se alcanza el tamaño de lote preferido de 16 o ha transcurrido el tiempo de retraso de 100 microsegundos desde que la primera solicitud llegó al dosificador dinámico.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Ejecutar modelos simultáneamente

Otra optimización esencial que se ofrece en Triton para maximizar la utilización del hardware sin sobrecarga de latencia adicional es ejecución de modelo concurrente, que permite que varios modelos o varias copias del mismo modelo se ejecuten en paralelo. Esta característica permite que Triton maneje varias solicitudes de inferencia simultáneamente, lo que aumenta el rendimiento de la inferencia al utilizar la potencia de cómputo inactiva en el hardware.

La siguiente figura muestra cómo puede configurar fácilmente diferentes políticas de implementación de modelos con solo unas pocas líneas de cambios de código. Por ejemplo, la configuración A (izquierda) muestra que puede transmitir la misma configuración de dos instancias modelo de bert-large-uncased a todas las GPU disponibles. Por el contrario, la configuración B (en el medio) muestra una configuración diferente solo para GPU 0, sin cambiar las políticas en las otras GPU. También puede implementar instancias de diferentes modelos en una sola GPU, como se muestra en la configuración C (derecha).

En la configuración C, la instancia informática puede manejar dos solicitudes simultáneas para el modelo DistilGPT-2 y siete solicitudes simultáneas para el bert-large-uncased modelo en paralelo. Con estas optimizaciones, los recursos de hardware se pueden utilizar mejor para el proceso de servicio, lo que mejora el rendimiento y proporciona una mayor rentabilidad para su carga de trabajo.

TensorRT

TensorRT de NVIDIA es un SDK para la inferencia de aprendizaje profundo de alto rendimiento que funciona a la perfección con Triton. TensorRT, que es compatible con todos los principales marcos de aprendizaje profundo, incluye un optimizador de inferencias y un tiempo de ejecución que ofrece baja latencia y alto rendimiento para ejecutar inferencias con volúmenes masivos de datos a través de potentes optimizaciones.

TensorRT optimiza el gráfico para minimizar el consumo de memoria al liberar memoria innecesaria y reutilizarla de manera eficiente. Además, la compilación de TensorRT fusiona las operaciones dispersas dentro del gráfico del modelo para formar un núcleo más grande para evitar la sobrecarga de varios lanzamientos de núcleos pequeños. El ajuste automático del kernel lo ayuda a utilizar completamente el hardware al seleccionar el mejor algoritmo en su GPU de destino. Las secuencias CUDA permiten que los modelos se ejecuten en paralelo para maximizar la utilización de la GPU y obtener el mejor rendimiento. Por último, pero no menos importante, la técnica de cuantificación puede utilizar completamente la aceleración de precisión mixta de los núcleos Tensor para ejecutar el modelo en FP32, TF32, FP16 e INT8 para lograr el mejor rendimiento de inferencia.

Tritón en alojamiento 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 correspondiente marco de aprendizaje automático compatible. 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 contenedores de aprendizaje profundo de SageMaker (DLC).

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

Recomendador de inferencia de SageMaker para resultados de pruebas comparativas

Usamos SageMaker Inference Recommender para ejecutar nuestros experimentos. SageMaker Inference Recommender ofrece dos tipos de trabajos: predeterminado y avanzado, como se ilustra en el siguiente diagrama.

El trabajo predeterminado proporciona recomendaciones sobre tipos de instancias con solo el modelo y una carga útil de muestra para comparar. Además de las recomendaciones de instancias, el servicio también ofrece parámetros de tiempo de ejecución que mejoran el rendimiento. Las recomendaciones del trabajo predeterminado están destinadas a limitar la búsqueda de instancias. En algunos casos, podría ser la familia de instancias y, en otros, podrían ser tipos de instancias específicas. Los resultados del trabajo predeterminado se introducen luego en el trabajo avanzado.

El trabajo avanzado ofrece más controles para ajustar aún más el rendimiento. Estos controles simulan el entorno real y los requisitos de producción. Entre estos controles se encuentra el patrón de tráfico, que tiene como objetivo organizar el patrón de solicitud de los puntos de referencia. Puede establecer rampas o tráfico constante utilizando las múltiples fases del patrón de tráfico. por ejemplo, un NúmeroInicialDeUsuarios de 1, tasa de generación de 1, y DuraciónEnSegundos de 600 puede resultar en un tráfico de rampa de 10 minutos con 1 usuario simultáneo al principio y 10 al final. Además, en los controles, MaxInvocaciones y ModeloLatenciaUmbrales establece el umbral de producción, de modo que cuando se supera uno de los umbrales, la evaluación comparativa se detiene.

Finalmente, métricas de recomendación incluyen el rendimiento, la latencia en el rendimiento máximo y el costo por inferencia, por lo que es fácil compararlos.

Usamos el tipo de trabajo avanzado de SageMaker Inference Recommender para ejecutar nuestros experimentos para obtener un control adicional sobre los patrones de tráfico y ajustar la configuración del contenedor de servicio.

Configuración del experimento

Usamos la función de prueba de carga personalizada de SageMaker Inference Recommender para comparar el perfil NLP descrito en nuestro caso de uso. Primero definimos los siguientes requisitos previos relacionados con el modelo NLP y la tarea ML. SageMaker Inference Recommender utiliza esta información para extraer una imagen de Docker de inferencia de Registro de contenedores elásticos de Amazon (Amazon ECR) y registre el modelo con el registro de modelos de SageMaker.

Las configuraciones de patrones de tráfico en SageMaker Inference Recommender nos permiten definir diferentes fases para la prueba de carga personalizada. La prueba de carga comienza con dos usuarios iniciales y genera dos nuevos usuarios cada minuto, con una duración total de 25 minutos (1500 segundos), como se muestra en el siguiente código:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

Experimentamos con pruebas de carga del mismo modelo en dos estados diferentes. Los experimentos basados ​​en PyTorch utilizan el modelo PyTorch estándar e inalterado. Para los experimentos basados ​​en TensorRT, convertimos el modelo PyTorch en un motor TensorRT de antemano.

Aplicamos diferentes combinaciones de las funciones de optimización del rendimiento en estos dos modelos, que se resumen en la siguiente tabla.

Resultados de la prueba y observaciones

Realizamos pruebas de carga para tres tipos de instancias dentro de la misma familia g4dn: ml.g4dn.xlarge, ml.g4dn.2xlarge y ml.g4dn.12xlarge. Todos los tipos de instancias g4dn tienen acceso a GPU NVIDIA T4 Tensor Core y procesadores Intel Cascade Lake de segunda generación. La lógica detrás de la elección de los tipos de instancias era tener tanto una instancia con una sola GPU disponible como una instancia con acceso a varias GPU: cuatro en el caso de ml.g2dn.4xlarge. Además, queríamos probar si aumentar la capacidad de vCPU en la instancia con solo una GPU disponible generaría una mejora en la relación costo-rendimiento.

Repasemos primero la aceleración de la optimización individual. El siguiente gráfico muestra que la optimización de TensorRT proporciona una reducción del 50 % en la latencia del modelo en comparación con la nativa en PyTorch en la instancia ml.g4dn.xlarge. Esta reducción de latencia crece hasta más de tres veces en las instancias multi-GPU de ml.g4dn.12xlarge. Mientras tanto, la mejora del rendimiento del 30 % es consistente en ambas instancias, lo que resulta en una mejor rentabilidad después de aplicar las optimizaciones de TensorRT.

Con el procesamiento por lotes dinámico, podemos lograr una mejora cercana al doble en el rendimiento utilizando la misma arquitectura de hardware en todas las instancias de experimentos de ml.g2dn.xlarge, ml.g4dn.4xlarge y ml.g2dn.4xlarge sin un aumento notable de la latencia.

De manera similar, la ejecución simultánea del modelo nos permite obtener una mejora de 3 a 4 veces en el rendimiento al maximizar la utilización de GPU en la instancia ml.g4dn.xlarge y una mejora de aproximadamente 2x tanto en la instancia ml.g4dn.2xlarge como en la instancia multi-GPU de ml. g4dn.12xlarge.. Este aumento de rendimiento se produce sin sobrecarga en la latencia.

Mejor aún, podemos integrar todas estas optimizaciones para brindar el mejor rendimiento al utilizar los recursos de hardware al máximo. La siguiente tabla y gráficos resumen los resultados que obtuvimos en nuestros experimentos.

[1] El recuento de instancias inicial en la tabla anterior es la cantidad recomendada de instancias para usar con una política de escalado automático para mantener los requisitos de rendimiento y latencia para su carga de trabajo.

[2] El costo por hora en la tabla anterior se calcula en función del recuento de instancias iniciales y el precio para el tipo de instancia.

Los resultados validan principalmente el impacto que se esperaba de las diferentes funciones de optimización del rendimiento:

• La compilación de TensorRT tiene el impacto más confiable en todos los tipos de instancias. Las transacciones por minuto por instancia aumentaron entre un 30 % y un 35 %, con una reducción constante de costos de aproximadamente un 25 % en comparación con el rendimiento del motor TensorRT para el PyTorch BERT predeterminado (pt-base). El mayor rendimiento del motor TensorRT se ve agravado y explotado por las otras características de ajuste de rendimiento probadas.
• La carga de dos modelos en cada GPU (grupo de instancias) duplicó casi estrictamente todas las métricas medidas. Las invocaciones por minuto por instancia aumentaron aproximadamente entre un 80 y un 90 %, lo que produjo una reducción de costos del orden del 50 %, casi como si estuviéramos usando dos GPU. De hecho, Reloj en la nube de Amazon Las métricas de nuestros experimentos en g4dn.2xlarge (como ejemplo) confirman que la utilización de CPU y GPU se duplica cuando configuramos un grupo de instancias de dos modelos.

Más consejos de rendimiento y optimización de costos

El punto de referencia presentado en esta publicación solo rascó la superficie de las posibles funciones y técnicas que puede usar con Triton para mejorar el rendimiento de la inferencia. Estos van desde técnicas de preprocesamiento de datos, como el envío de cargas útiles binarias al servidor modelo o cargas útiles con lotes más grandes, hasta características nativas de Triton, como las siguientes:

• modelo de calentamiento, que evita solicitudes de inferencia iniciales lentas al inicializar completamente el modelo antes de que se reciba la primera solicitud de inferencia.
• Caché de respuesta, que almacena en caché las solicitudes repetidas.
• montaje de modelos, que le permite crear una canalización de uno o más modelos y la conexión de tensores de entrada y salida entre esos modelos. Esto abre la posibilidad de agregar pasos de preprocesamiento y posprocesamiento, o incluso inferencia con otros modelos, al flujo de procesamiento de cada solicitud.

Esperamos probar y comparar estas técnicas y características en una publicación futura, ¡así que manténgase al tanto!

Conclusión

En esta publicación, exploramos algunos parámetros que puede usar para maximizar el rendimiento de su terminal en tiempo real de SageMaker para servir modelos PyTorch BERT con Triton Inference Server. Usamos SageMaker Inference Recommender para realizar las pruebas comparativas para ajustar estos parámetros. Estos parámetros están básicamente relacionados con la optimización del modelo basado en TensorRT, lo que lleva a una mejora de casi el 50 % en los tiempos de respuesta en comparación con la versión no optimizada. Además, la ejecución simultánea de modelos y el uso de procesamiento por lotes dinámico de Triton condujo a un aumento de casi el 70 % en el rendimiento. El ajuste fino de estos parámetros también condujo a una reducción general del costo de inferencia.

La mejor manera de derivar los valores correctos es a través de la experimentación. Sin embargo, para comenzar a generar conocimientos empíricos sobre el ajuste y la optimización del rendimiento, puede observar las combinaciones de diferentes parámetros relacionados con Triton y su efecto en el rendimiento en los modelos de ML y las instancias de SageMaker ML.

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.

Puede encontrar el cuaderno utilizado para las pruebas de carga y la implementación en GitHub. Puede actualizar las configuraciones de Triton y la configuración del Recomendador de inferencias de SageMaker para que se adapten mejor a su caso de uso para lograr cargas de trabajo de inferencia rentables y de mejor rendimiento.

Acerca de los autores

Vikram Elango es Arquitecto de Soluciones Especializado en AI/ML en Amazon Web Services, con sede en Virginia, EE. UU. Vikram ayuda a los clientes de la industria financiera y de seguros con diseño y liderazgo intelectual para crear e implementar aplicaciones de aprendizaje automático a escala. Actualmente se centra en el procesamiento del lenguaje natural, la IA responsable, la optimización de inferencias y el escalado de ML en toda la empresa. En su tiempo libre, disfruta viajar, hacer caminatas, cocinar y acampar con su familia.

joão moura es un arquitecto de soluciones especializado en IA/ML en Amazon Web Services. Se enfoca principalmente en los casos de uso de NLP y en ayudar a los clientes a optimizar el entrenamiento y la implementación del modelo de aprendizaje profundo. También es un defensor activo de las soluciones de aprendizaje automático de código bajo y el hardware especializado en aprendizaje automático.

Mohán Gandhi es ingeniero de software sénior en AWS. Ha estado con AWS durante los últimos 9 años y ha trabajado en varios servicios de AWS como EMR, EFA y RDS en Outposts. Actualmente, se centra en mejorar la experiencia de inferencia de SageMaker. En su tiempo libre le gusta caminar y correr maratones.

Patel Dhawal es Arquitecto Principal de Aprendizaje Automático en AWS. Ha trabajado con organizaciones que van desde grandes empresas hasta empresas emergentes medianas en problemas relacionados con la computación distribuida y la inteligencia artificial. Se enfoca en el aprendizaje profundo, incluidos los dominios de NLP y Computer Vision. Ayuda a los clientes a lograr una inferencia de modelos de alto rendimiento en SageMaker.

santosh bhavani es Gerente de Producto Técnico Senior en el equipo de Inferencia elástica de Amazon SageMaker. Se centra en ayudar a los clientes de SageMaker a acelerar la inferencia e implementación de modelos. En su tiempo libre, le gusta viajar, jugar al tenis y beber mucho té Pu'er.

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.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/