Potenciando Llama 2 70B con NVIDIA H100

La búsqueda del rendimiento en el motor de respuestas de Perplexity nos impulsa a adoptar la tecnología más reciente que NVIDIA y AWS tienen para ofrecer. En este blog, nos complace compartir los resultados de nuestros experimentos más recientes: una comparación de la inferencia de Llama 2 70B en varios ajustes de hardware y software.

Nuestra plataforma de inferencia de LLM, pplx-api, está construida sobre una pila de vanguardia impulsada por bibliotecas de código abierto. Desde que comenzó la beta pública de pplx-api en octubre, hemos estado abordando los desafíos de escalabilidad y aprendiendo cómo ajustar mejor nuestra configuración para lograr una escala masiva. Esto nos llevó a realizar experimentos con las siguientes preguntas orientadoras:

¿Cuál es el aumento bruto de rendimiento al cambiar nuestras GPU de NVIDIA A100 a NVIDIA H100, manteniéndose todos los demás ajustes iguales?

¿Cuál es el aumento de eficiencia de la cuantización de punto flotante de 8 bits (fp8), para la cual H100 añade compatibilidad nativa? ¿Cuál es el costo en precisión de esta cuantización?

¿Cómo afectan el paralelismo de tensores y el tamaño de lote a la latencia y al rendimiento de tokens?

Teniendo en cuenta lo anterior, ¿qué configuración da como resultado el equilibrio más escalable entre rendimiento y rentabilidad?

Ejecutamos el siguiente experimento como una serie de pruebas de referencia locales para evitar la latencia de red.

Latencia: El tiempo total que le toma al servidor de inferencia generar su respuesta completa.

Rendimiento: El número de tokens de salida, por segundo, por GPU, que el servidor de inferencia puede generar en todos los usuarios y solicitudes.

Los siguientes factores influirían en las métricas clave, por lo que los mantuvimos constantes en las diferentes pruebas del experimento.

El rendimiento escala con el tamaño del LLM. Más parámetros requieren más cálculos, lo que resulta en una inferencia más lenta. Por ejemplo, Llama 2 13B es más rápido que Llama 2 70B cuando los demás ajustes son iguales. Nos atenemos a Llama 2 70B en este experimento porque queremos optimizar para servir a los modelos de código abierto más capaces.

La cantidad de tokens de entrada y salida en cada par de solicitud/respuesta de muestra puede influir en las mediciones de rendimiento. En general, la generación de tokens de salida domina el tiempo de respuesta total. Cuando los datos de muestreo solo inducen respuestas de "sí/no" por parte del LLM, la respuesta es más rápida en comparación con las muestras que piden al LLM que escriba ensayos. Nuestro conjunto de datos se compone de solicitudes sintéticas con 1024 tokens de entrada que inducen 512 tokens de salida. Esta distribución se eligió para que coincida con la distribución observada del tráfico en nuestra implementación pública de Llama2 70B.

NVIDIA TensorRT-LLM (versión v0.5.0) es una biblioteca de código abierto para optimizar la inferencia de LLM. Lanzada a finales de 2023, sintetiza las numerosas optimizaciones de inferencia de NVIDIA y proporciona una capa flexible de personalización para los parámetros clave de este experimento: tamaño de lote, cuantización y paralelismo de tensores.

Experimentamos en 4 ejes de configuración: paralelismo de tensores, arquitectura de GPU, cuantización y tamaño de lote máx. Estos ejes están interconectados porque cada uno representa una compensación con respecto al recurso de cuello de botella crítico de la memoria de la GPU.

La arquitectura de GPU Hopper de novena generación (H100-HBM3-80GB / p5.48xlarge) incluye una enorme lista de características en comparación con su predecesora, Ampere (A100-SXM4-80GB / p4de.24xlarge), incluidas tasas de cálculo de 2x a 6x y un ancho de banda de memoria de GPU casi 2x mayor. El ancho de banda de la memoria de la GPU es una métrica crítica para la inferencia porque un cuello de botella de latencia principal de las multiplicaciones de matrices de la inferencia proviene de cargar gigabytes de datos del modelo desde la memoria de la GPU en los registros de cómputo. Con base en estas estadísticas, formulamos la hipótesis de que una comparación directa ("apples-to-apples") entre NVIDIA H100 y A100 mostrará una mejora de 2x tanto en la latencia como en el rendimiento.

Otra diferencia clave entre NVIDIA H100 y A100 es que el núcleo tensorial de la H100 añade soporte nativo para instrucciones de punto flotante de 8 bits (fp8), lo que abre la puerta a más optimizaciones detalladas a continuación. Es por esto que utilizamos fp8 y fp16 específicamente para la H100.

Para mantener la memoria por GPU constante en este experimento, nos mantuvimos en nodos con memoria de GPU de 8x80GB tanto para nuestras NVIDIA A100 como H100. Además de permitir tamaños de lote más grandes, la memoria de la GPU es importante porque los parámetros del modelo se cargan en la memoria de la GPU durante el inicio del servidor para un acceso rápido. Por ejemplo, si cada uno de los 70 mil millones de parámetros de nuestro modelo es un número de punto flotante de 16 bits, el tamaño del modelo es de alrededor de 140 GB, lo cual no cabe en una sola GPU. De ahí la necesidad del paralelismo de tensores, que explicamos a continuación.

El paralelismo de tensores se refiere al número de dispositivos de GPU consumidos para ejecutar el servidor de inferencia. Cuando asignamos un número de GPU, TensorRT-LLM agrupa sus recursos para ayudarnos a alcanzar el presupuesto de memoria mínimo requerido para ejecutar Llama2 70B. Nuestra hipótesis es que un menor paralelismo de tensores dará como resultado una mayor latencia (debido a la menor cantidad de recursos consumidos para satisfacer cada lote), pero un mayor rendimiento por GPU (debido a una mejor utilización) en comparación con un mayor paralelismo de tensores.

La cuantización es la reducción de la precisión en los pesos y activaciones utilizados por las redes neuronales. Utilizamos esta técnica para reducir a la mitad el consumo de memoria de la GPU cuando cambiamos de fp16 a fp8. Esto hace posible ejecutar el mismo modelo con un uso total de memoria de GPU menor, lo que permite un menor paralelismo de tensores, lo que impulsa el rendimiento.

Las implementaciones de cuantización tienen el potencial de degradar la precisión. Por lo tanto, evaluamos la precisión para diferentes precisiones comparando su estadística de perplejidad, una medida de qué tan bien el LLM predice cada token siguiente en una oración, en el corpus WikiText. Para el punto flotante de 8 bits y el peso de 8 bits con activación de 8 bits y SmoothQuant (w8a8 SQ), no hubo un cambio significativo en la perplejidad (< 1%) en comparación con fp16 en WikiText, por lo que nos sentimos seguros para continuar. Sin embargo, w4a16 mostró un cambio sustancial del 7% en la perplejidad, potencialmente atribuible a la precisión aún menor y a las conversiones dinámicas necesarias entre int4 y fp16.

El paralelismo mediante el procesamiento por lotes ("batching") es una estrategia clásica para exprimir el rendimiento de un sistema con recursos limitados. Al procesar múltiples solicitudes en cada pase hacia adelante a través de la red neuronal, se sabe que el procesamiento por lotes aumenta el rendimiento a costa de cierta latencia. El procesamiento por lotes también genera un mayor consumo de memoria de la GPU porque el tamaño de la caché KV que administra el mecanismo de atención crece linealmente con el tamaño del lote.

En el caso de Llama 2 70B (que tiene 80 capas), fp16 con un tamaño de lote de 32 para un tamaño de contexto de 4096, el tamaño de la caché KV asciende a unos sustanciales 40 GB. Esto termina evitando que Llama 2 70B fp16, cuyos pesos por sí solos ocupan 140 GB, quepa cómodamente en la memoria de GPU de 160 GB disponible con un paralelismo de tensores de 2 (TP-2).

Exploramos combinaciones compatibles de las 4 variables del experimento y presentamos las tendencias más reveladoras a continuación.

Figura 1: La latencia de solicitudes con tamaño de lote variable en cinco configuraciones diferentes, todas con un paralelismo de tensores de 8, lo que produce la mejor latencia con 8 GPU disponibles. Dentro de cada configuración, la latencia generalmente se duplica al aumentar el tamaño de lote de 1 → 32, y se duplica nuevamente de 32 → 128. En tamaños de lote suficientemente grandes, la H100 reduce aproximadamente a la mitad la latencia en comparación con la A100. La A100 utiliza precisión mixta porque la arquitectura carece de soporte nativo para fp8. w8a8 con SmoothQuant (SQ) está destinado a asemejarse a fp8.

La mejora en la latencia de la cuantización se encuentra alrededor del 10% al comparar H100 fp16 → fp8 y A100 fp16 → w8a8 con SmoothQuant. Sin embargo, la precisión mixta w4a16 en realidad rinde mejor en tamaños de lote pequeños y peor en tamaños de lote más grandes en comparación con fp16. Esto puede deberse a varios factores, incluidos núcleos de cómputo menos optimizados, tiempo de conversión entre int4 y fp16, y el hecho de que w4a16 aún utiliza puntos flotantes de 16 bits para las activaciones, lo que no genera ahorros en las dimensiones de la caché KV. Debido a que w4a16 también demostró una menor precisión, concluimos que debemos atenernos a w8a8 SQ para las A100 y a fp8 para las H100.

Figura 2: El rendimiento en las configuraciones de TP-8 con diferentes arquitectura, cuantización y tamaño de lote. Para cada arquitectura y cuantización, se eligió el tamaño de lote más grande que cumpliera con un requisito de latencia de 25600 ms (20 tokens por segundo para 512 tokens), de modo que comparemos configuraciones que tengan una latencia similar. Bajo este requisito, la H100 con BS-128 alcanza el 228% de rendimiento en comparación con la A100 BS-64 utilizando la misma cuantización (fp16) e incluso tiene una latencia de respuesta menor a pesar del tamaño de lote duplicado. La cuantización con fp8 mejora este factor al 251%.

En nuestras primeras dos figuras, solo presentamos configuraciones de TP-8. La H100 logra un 54% de latencia y un 184% de rendimiento en comparación con la A100 cuando ambas usan fp16 / BS-128 / TP-8, lo que mejora a 49% de latencia y 202% de rendimiento al usar fp8 en la H100. Esta mejora en el rendimiento se puede atribuir a los aumentos en la potencia de cómputo y el ancho de banda de la memoria entre la H100 y la A100. En particular, la diferencia es menos pronunciada en tamaños de lote más bajos, donde la utilización puede ser menor.

A medida que construimos nuestra plataforma, queremos cumplir con ciertos requisitos de latencia para nuestros usuarios mientras maximizamos el rendimiento. Por lo tanto, en lugar de comparar A100 frente a H100 con el mismo tamaño de lote, en realidad tiene más sentido para nosotros comparar su rendimiento únicamente bajo configuraciones en las que cumplen con un requisito de latencia. Establecimos un límite de 25600 ms de latencia para la finalización de los 512 tokens de salida y descubrimos que H100 / TP-8 / fp8 / BS-128 produce un 251% de rendimiento en comparación con A100 / TP-8 / fp16 / BS-64, ya que puede procesar el doble de tamaño de lote con una latencia menor. Dado que la cuantización proporciona ahorros en la memoria de la GPU, ahora necesitamos evaluar cómo el paralelismo de tensores puede agregar una siguiente capa de optimización.

Figura 3: La latencia en diferentes tamaños de lote y paralelismo de tensores para H100 fp8. La latencia generalmente se duplica al aumentar el tamaño de lote de 1 → 32, y se duplica nuevamente de 32 → 128. TP-2 es consistentemente alrededor del doble de lento que TP-8 cuando los tamaños de lote son iguales. Duplicar el paralelismo de tensores mientras se duplica el tamaño de lote mantiene la latencia relativamente estable, ya que el número de lotes procesados por GPU se mantiene uniforme.

Cuando se trata de cuantización y arquitectura, hay claros ganadores: la H100 domina a la A100 y la cuantización de precisión reducida mejora la utilización de la memoria, la latencia y el rendimiento. Sin embargo, el tamaño de lote y el paralelismo de tensores presentan una compensación en nuestras métricas clave. Un tamaño de lote mayor optimiza el rendimiento a costa de una mayor latencia y consumo de memoria. Por otro lado, un mayor paralelismo de tensores aumenta el conjunto total de memoria disponible y optimiza la latencia, pero se compensa con el rendimiento debido a los costos de sincronización de la multiplicación de matrices distribuida y en virtud de bloquear más recursos de GPU.

Figura 4: El rendimiento en diferentes tamaños de lote y paralelismo de tensores para H100 fp8. El rendimiento más alto proviene de TP-2 BS-128, con un 460% en comparación con la línea base de A100/TP-8/fp16/BS-64. Sin embargo, TP-2 BS-128 es también el resultado más lento en la Figura 3.

La configuración que maximiza el rendimiento de nuestro experimento es H100 / fp8 / TP-2 / BS-128, con 767 tokens de salida por segundo por GPU. Esto representa una mejora del 460% sobre A100 / fp16 / TP-8 / BS-64. Sin embargo, esto tiene el costo de duplicar la latencia (más cerca de 42000 ms para 512 tokens de salida), por lo que puede no ser adecuado como configuración de producción. Los resultados de TP-4 BS-128 (626 tok/s/gpu a 26188 ms de tiempo de respuesta) y TP-2 BS-32 (435 tok/s/gpu a 18821 ms de tiempo de respuesta) pueden representar mejores compensaciones en nuestras métricas clave.

Nuestros resultados demuestran que:

Alcanzamos un 54% de latencia y un 184% de rendimiento utilizando la H100 en comparación con la A100 con la misma configuración, lo que mejora al 49% y al 202% respectivamente cuando la H100 aprovecha su soporte nativo para fp8.

Al maximizar el rendimiento sujeto a una restricción de latencia, H100 / fp8 / TP-8 / BS-128 produce un 251% de rendimiento en comparación con A100 / fp16 / TP-8 / BS-64, ya que puede procesar el doble de lote a una velocidad mayor.

Aprovechando la H100 con TP-2 con fp8, podemos lograr un 373% del rendimiento de A100 / fp16 / TP-8 / BS-128, con un aumento de latencia inferior al 10%.

El tamaño de lote y el paralelismo de tensores presentan una compensación entre el rendimiento y la latencia para el operador de un sistema de inferencia de LLM.

Estos resultados nos hacen sentir seguros acerca de una transición completa a las GPU H100 en nuestra pila de hardware previamente impulsada por A100. Nos entusiasma poder confirmar las ganancias de rendimiento anunciadas por NVIDIA y esperamos sus próximos avances en hardware acelerado.

Nuestra próxima frontera para la optimización es examinar el impacto en la precisión y el rendimiento de la esparsidad estructurada y la precisión int4, lo que podría reducir significativamente la huella de memoria de la GPU de Llama 2 70B y producir mejoras de hasta 2x en la latencia. Nos entusiasma continuar el viaje de la inferencia ultrarrápida y esperamos empoderar a nuestros usuarios para que construyan aplicaciones potentes sobre nuestra plataforma.

A corto plazo, pplx-api eliminará los límites de velocidad y ofrecerá más LLM personalizados de Perplexity, incluido un LLM impulsado por internet con conexión a tierra para datos reales.

Regístrate en Perplexity Pro en perplexity.ai/pro. Obtén acceso a nuestra vanguardista pplx-api y aprovecha estas capacidades avanzadas en tus proyectos. Descubre más sobre pplx-api en nuestro blog.

¿Te interesa dar forma al futuro de la IA? ¡Estamos contratando! Sé parte de un equipo que impulsa infraestructura de LLM generativa a escala masiva. Explora oportunidades en Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Configuración experimental

Métricas clave:

Constantes:

Modelo de IA

Conjunto de datos de tokens de entrada/salida

Versión de software

Variables

Arquitectura de GPU

Paralelismo de tensores

Cuantización

Tamaño de lote

Resultados

Conclusión

¿Qué sigue?

Autores: