Evaluación del rendimiento de la inferencia de los LLM en Red Hat OpenShift AI

El panorama de la inteligencia artificial generativa experimentó una evolución rápida durante el último año. A medida que crece el poder de los modelos de lenguaje de gran tamaño (LLM) generativos, las empresas buscan cada vez más aprovechar sus funciones para satisfacer sus necesidades. Debido a las grandes exigencias informáticas de la ejecución de los LLM, es fundamental implementarlos en una plataforma confiable y eficiente para hacer un uso rentable del hardware fundamental, especialmente de las unidades de procesamiento de gráficos (GPU).

En este artículo, se presentan la metodología y los resultados de las pruebas de rendimiento de los modelos llama-2 que se implementaron en la stack de distribución incluida con Red Hat OpenShift AI. Esta plataforma de operaciones de machine learning (MLOps) flexible y con capacidad de ajuste incluye herramientas para diseñar, implementar y gestionar las aplicaciones que utilizan la inteligencia artificial. Está diseñada con tecnologías de open source y proporciona funciones confiables y uniformes en términos operativos para que los equipos realicen pruebas, pongan los modelos a disposición de los usuarios y distribuyan aplicaciones innovadoras.

La stack de distribución de modelos

La stack de software de distribución de modelos se basa en KServe, OpenShift Serverless y OpenShift Service Mesh. Para ejecutar los modelos llama-2, usamos Caikit y Text Generation Inference Server (TGIS), aunque OpenShift AI también es compatible con OpenVINO y ofrece la capacidad de usar otros tiempos de ejecución personalizados de manera modular. NVIDIA GPU Operator administra y expone las GPU para que el contenedor de TGIS pueda usarlas.

Figura 1: Interacciones entre los elementos y el flujo de trabajo del usuario en las stacks de KServe, Caikit y TGIS.

KServe ofrece muchas funciones de servicio de vanguardia para la inferencia de modelos de inteligencia artificial al aprovechar OpenShift Serverless y OpenShift Service Mesh. Estos elementos concentran la complejidad relacionada con las redes, la configuración del servicio, el ajuste automático y la comprobación del estado para la distribución de modelos de producción.

El kit de herramientas Caikit permite que los usuarios gestionen los modelos a través de un conjunto de API sencillas para los desarrolladores. Proporciona interfaces gRPC (llamada a procedimiento remoto) y HTTP estándares que podemos usar para consultar varios modelos base. Reenvía las solicitudes al servicio de inferencia, TGIS.

TGIS es una bifurcación anterior del kit de herramientas de distribución de text-generation-inference denominado Hugging Face. Proporciona varias funciones importantes para optimizar el rendimiento de la distribución de los LLM, como el procesamiento por lotes permanente, el procesamiento por lotes dinámico, el paralelismo de tensores (fragmentación de modelos) y el soporte para la compilación PyTorch 2, entre otras.

NVIDIA GPU Operator automatiza la gestión de varios elementos de software necesarios para preparar y usar las GPU de NVIDIA en OpenShift, lo cual requiere el uso del contenedor de controladores, el plugin de dispositivos, el exportador de indicadores de Data Center GPU Manager (DCGM) y más. El exportador nos permite analizar los indicadores de GPU, como el uso de la memoria, del multiprocesador de flujos (SM) y otros, mediante la instancia de Prometheus para la supervisión de OpenShift.

Metodología de prueba de rendimiento para los modelos de lenguaje de gran tamaño

Para evaluar el rendimiento de un modelo de lenguaje de gran tamaño, seguimos las medidas clásicas de latencia y rendimiento. Sin embargo, la latencia integral de las solicitudes a un LLM puede variar considerablemente según algunos factores. El aspecto más importante es la longitud del resultado, ya que estos modelos generan texto de un token a la vez. Por lo tanto, la medición se lleva a cabo principalmente en función de latencia por token o tiempo por token de salida (TPOT).

Los tokens son unidades de texto que representan una cadena de caracteres de palabras o subpalabras. Para que un modelo de lenguaje de gran tamaño procese textos, primero se deben convertir en estas unidades. El esquema exacto que se usa para asignarles texto varía de un modelo a otro. A los tokens se les asignan representaciones numéricas y se organizan en vectores que se introducen en el modelo y se generan a partir de él.

Otro factor que influye en la latencia total de la solicitud es el tiempo de precarga, que equivale a lo que tardan en procesarse los tokens de las indicaciones de entrada antes de que el modelo genere el primer token nuevo. Un tercer contribuyente importante a la latencia total de las solicitudes es el tiempo de cola. En los casos en que el servicio de inferencia no puede procesar las solicitudes lo suficientemente rápido para mantener el ritmo de la carga entrante debido a las restricciones de hardware, como la memoria de GPU, algunas solicitudes estarán en cola antes de ser procesadas. A causa de estos factores, el tiempo hasta el primer token (TTFT) es un indicador común para medir el rendimiento de los LLM. El TTFT es particularmente importante para los casos prácticos como los chatbots, en los cuales los tokens se transmiten y se muestran a medida que se generan.

De manera similar a la latencia, el rendimiento varía ampliamente si se mide usando solicitudes por segundo según la cantidad de tokens que se generan en ellas. Por lo tanto, medimos el rendimiento general de acuerdo con el total de tokens que se crean por segundo en todos los usuarios que consultan el modelo.

Pruebas de carga con llm-load-test

Hemos creado una herramienta open source denominada llm-load-test para cargar modelos de prueba que se ejecutan en la stack de distribución de modelos de OpenShift AI. Está escrita en Python y, además, internamente, utiliza la herramienta de prueba de carga gRPC denominada ghz. Abrimos una bifurcación de ghz para agregar la capacidad de guardar la respuesta y la identificación del subproceso de trabajo para cada solicitud en el resultado de la prueba.

Además de las funciones que se ofrecen en ghz, llm-load-test nos permite ejecutar varios procesos en paralelo con el conjunto de datos de entrada en un orden aleatorio en cada instancia. Esto nos da la posibilidad de simular muchas consultas diferentes de usuarios al modelo con diferentes indicaciones al mismo tiempo. La herramienta llm-load-test también puede cargar los resultados directamente en un bucket de S3 después de un experimento al etiquetar los objetos con los metadatos correspondientes para la ejecución.

Conjunto de datos de entrada

Las indicaciones de entrada se pueden configurar en llm-load-test para la prueba de carga mediante un archivo JSON. Para generar los resultados compartidos en esta publicación del blog, realizamos experimentos con un conjunto de datos de 32 entradas de OpenOrca con diferentes longitudes de entrada y salida. La entrada más larga en nuestros datos de prueba fue de 1688 tokens, y la salida más larga fue de 377 tokens. En la figura 2, se muestra la distribución de longitudes de entrada y salida en el conjunto de datos de prueba.

Figura 2: Longitud de los tokens del conjunto de datos de prueba.

El uso de una combinación de entradas y salidas de distintos tamaños es importante para probar las funciones de procesamiento por lotes permanente y dinámico de TGIS en un caso real. Los modelos nuevos han comenzado a admitir longitudes de contexto muy grandes de más de 4000, lo cual es particularmente importante para los casos prácticos como la generación aumentada por recuperación (RAG). Es por esto que tenemos la intención de aumentar el tamaño de nuestro conjunto de datos de prueba de carga para incluir longitudes de entrada más grandes en el futuro.

Resultados de rendimiento de llama-2 en OpenShift AI en AWS

Las siguientes mediciones de rendimiento se recopilaron con un clúster de OpenShift autogestionado de infraestructura preparada por el instalador (IPI) que se implementó en AWS. Instalamos el operador de OpenShift AI y creamos los objetos ServingRuntime e InferenceService para habilitar la distribución del modelo con Kserve, Caikit y TGIS.

En la tabla 1 se resumen los resultados de las pruebas de cuatro combinaciones de modelos y tipos de instancias de AWS:

Tabla 1: Resumen de las configuraciones de prueba.

En cada configuración, ejecutamos varias pruebas de carga de cuatro minutos utilizando llm-load-test con diferentes cantidades de subprocesos simultáneos (se muestra el parámetro de simultaneidad en las siguientes figuras). En todas las pruebas, cada subproceso simultáneo envía constantemente una solicitud a la vez tan pronto como recibe la respuesta de la solicitud anterior.

A modo de ejemplo visual de un experimento, en la figura 3 se muestra un gráfico de la latencia total de cada solicitud durante la prueba. El color de cada punto representa la longitud del token, por lo que se puede visualizar el grado de relación que tiene con el resultado general de la solicitud.

Figura 3: Latencia total de todas las solicitudes durante una prueba de carga.

Analizamos los registros de TGIS para obtener la latencia total de cada solicitud y calculamos el rendimiento al dividir el total de tokens que se generaron por la duración de la prueba de carga (240 segundos).

En la figura 4, se muestran la latencia y el rendimiento medidos durante la prueba de carga llama-2-7b en la instancia g5.2xlarge con varias configuraciones de simultaneidad. En este caso, vemos que el rendimiento aumenta a medida que incrementamos la simultaneidad de la prueba hasta llegar a casi 20 subprocesos. Debido a los límites de memoria de la GPU de la instancia g5.2xlarge, TGIS no puede incluir más de 20 solicitudes (según la longitud de entrada y salida) en un lote a la vez.

Figura 4: Resumen de la latencia y el rendimiento para llama-2-7b en g5.2xlarge.

En el gráfico de la figura 5, se muestran la latencia y el rendimiento medidos durante la prueba de carga llama-2-13B en la instancia g5.12xlarge. En este caso, vemos que la latencia mínima por token comienza por debajo del modelo 7B en g5.2xlarge, y el rendimiento aumenta hasta al menos 30 solicitudes simultáneas a pesar de que el modelo es más grande y la instancia tiene el mismo tipo de GPU. Esto se debe a las importantes ventajas de rendimiento que se obtienen al usar el paralelismo de tensores para distribuir el modelo en las cuatro GPU.

Figura 5: Resumen de la latencia y el rendimiento para llama-2-13b en g5.12xlarge.

En la figura 6, se muestran la latencia y el rendimiento medidos durante la prueba de carga llama-2-70b en la instancia g5.48xlarge. Aquí, la latencia por token es mayor en todos los casos, en comparación con las configuraciones anteriores. Los modelos como llama-2-70B tienen requisitos de hardware importantes. Las GPU 8xA10G tienen 192 GB de VRAM combinada, y se requiere la mayor parte de ella solo para cargar los parámetros de 70B con una precisión de 16 bits en la memoria (70B × 16 bits = ~140 GB). Según sus requisitos de rendimiento, es posible que necesite aún más recursos informáticos, como las instancias p4d.24xlarge.

Figura 6: Resumen de la latencia y el rendimiento para llama-2-70b en g5.48xlarge.

En la figura 7, se muestran la latencia y el rendimiento medidos durante la prueba de carga llama-2-70b en la instancia p4d.24xlarge. En esta instancia, podemos mantener una latencia mucho más baja para la misma cantidad de usuarios en comparación con la instancia g5.48xlarge. Incluso hasta en una simultaneidad que equivale a 30, crece el rendimiento a medida que aumenta la simultaneidad de la prueba de carga.

Figura 7: Resumen de la latencia y el rendimiento para llama-2-70b en p4d.24xlarge.

Cálculos del costo

Podemos estimar el costo de generar 1 millón de tokens con el rendimiento medido y los gastos del tipo de instancia. En la siguiente tabla, se resumen estas estimaciones utilizando el rendimiento medido para los resultados que recopilamos con una simultaneidad de carga de 10.

Tabla 2: Resumen de los resultados para cada configuración con el costo calculado por millón de tokens.

Trabajos futuros

Estos resultados son solo una pequeña muestra de las pruebas que llevamos a cabo con el equipo de rendimiento y ajuste para las plataformas de inteligencia artificial (PSAP) de Red Hat. Junto con las pruebas de rendimiento de otros aspectos de OpenShift AI, realizamos permanentemente nuestro análisis de rendimiento y capacidad de ajuste de la stack de distribución de modelos. En el futuro, esperamos compartir más resultados de las pruebas de otros modelos y el ajuste automático de las réplicas de ellos en función del tráfico, entre otras cosas.

Continuaremos desarrollando la herramienta llm-load-test y esperamos agregar varias funciones pronto, como las siguientes:

• La capacidad de medir el tiempo hasta el primer token y el tiempo por token de salida para las solicitudes de flujos
• Interfaces conectables o modulares para consultar los modelos en los que se basan diferentes API, entre las que se encuentran las interfaces HTTP y gRPC
• Etapa de preparación y capacidad para validar que el modelo esté cargado y responda sin errores
• Patrones de carga más complejos, como una tasa de llegada aleatoria de Poisson

Conclusión

Nuestras pruebas de los modelos llama-2 en OpenShift AI brindan una descripción general de las ventajas y desventajas de la latencia, el rendimiento y los costos que implica la ejecución de LLM en varias configuraciones. Por ejemplo, para el modelo 7B, la instancia g5.2xlarge es la más asequible, pero pasar a la instancia g5.12xlarge puede ser beneficioso para algunos casos prácticos debido a las mejoras importantes en la latencia y el rendimiento del paralelismo de tensores. La ejecución de los modelos más grandes debería dar como resultado una salida de mayor calidad, pero requiere más memoria de GPU, lo que conlleva un costo más alto.

OpenShift AI ofrece una herramienta de distribución adaptable y de alto rendimiento para las empresas que enfrentan las complejidades de implementar modelos de gran tamaño generativos. Ya sea que priorice la calidad, la latencia, el rendimiento o el costo del modelo, la flexibilidad de la plataforma se adapta a diversos requisitos. Si desea conocer estos beneficios para su caso práctico específico, implemente el modelo que desee en OpenShift AI.