Acelerando Llama 2 70B con NVIDIA H100

A busca do rendemento no motor de respostas de Perplexity lévanos a adoptar a tecnoloxía máis recente que NVIDIA e AWS ofrecen. Neste blog, estamos encantados de compartir os resultados dos nosos últimos experimentos: unha comparación da inferencia de Llama 2 70B en varias configuracións de hardware e software.

A nosa plataforma de inferencia LLM, pplx-api, está construída sobre unha pila de vangarda impulsada por bibliotecas de código aberto. No tempo transcorrido desde que comezou a beta pública de pplx-api en outubro, estivemos a abordar desafíos de escalabilidade e a aprender a mellor forma de axustar a nosa configuración para acadar unha escala masiva. Isto levounos a realizar experimentos coas seguintes preguntas orientadoras:

Cal é o ganho de rendemento en bruto ao cambiar as nosas GPUs de NVIDIA A100 a NVIDIA H100, permanecendo igual o resto das configuracións?

Cal é o ganho de eficiencia da cuantización en coma flotante de 8 bits (fp8), para a cal H100 engade soporte nativo? Cal é o custo en precisión desta cuantización?

Como afectan o paralelismo de tensores e o tamaño do lote á latencia e ao rendemento de tokens?

Tendo en conta o anterior, que configuración resulta no equilibrio máis escalable entre rendemento e eficiencia de custos?

Executamos o seguinte experimento como unha serie de probas de rendemento locais para evitar a latencia de rede.

Latencia: O tempo total que tarda o servidor de inferencia en xerar a súa resposta completa.

Rendemento: O número de tokens de saída, por segundo, por GPU, que o servidor de inferencia pode xerar en todos os usuarios e solicitudes.

Os seguintes factores influirían nas métricas clave, polo que os mantivemos consistentes en diferentes probas do experimento.

O rendemento escala co tamaño do LLM. Máis parámetros requiren máis cómputos, o que resulta nunha inferencia máis lenta. Por exemplo, Llama 2 13B é máis rápido que Llama 2 70B cando as demais configuracións son iguais. Mantémonos en Llama 2 70B neste experimento porque queremos optimizar para servir aos modelos de código aberto máis capaces.

A cantidade de tokens de entrada e saída en cada par de solicitude/resposta de mostra pode influír nas medicións de rendemento. En xeral, a xeración de tokens de saída domina o tempo de resposta global. Cando os datos de mostra só inducen respostas "si/non" do LLM, entón a resposta é máis rápida en comparación coas mostras que lle piden ao LLM que escriba ensaios. O noso conxunto de datos está composto por solicitudes sintéticas con 1024 tokens de entrada que inducen 512 tokens de saída. Esta distribución foi elixida para coincidir coa distribución observada de tráfico na nosa implantación pública de Llama2 70B.

NVIDIA TensorRT-LLM (versión v0.5.0) é unha biblioteca de código aberto para optimizar a inferencia de LLM. Lanzada a finais de 2023, sintetiza as moitas optimizacións de inferencia de NVIDIA e proporciona unha capa flexible de personalización para os parámetros clave deste experimento: tamaño do lote, cuantización e paralelismo de tensores.

Experimentamos a través de 4 eixes de configuración: paralelismo de tensores, arquitectura de GPU, cuantización e tamaño máximo de lote. Estes eixes están interconectados porque cada un representa un compromiso con respecto ao recurso de cogulo crítico da memoria de GPU.

A arquitectura de GPU Hopper de novena xeración (H100-HBM3-80GB / p5.48xlarge) achega unha inmensa lista de características sobre o seu predecesor, Ampere (A100-SXM4-80GB / p4de.24xlarge), incluíndo taxas de cómputo de 2x a 6x e case o doble de ancho de banda de memoria de GPU. O ancho de banda de memoria de GPU é unha métrica crítica para a inferencia porque un coadxuvante principal de latencia das multiplicacións de matriz da inferencia provén de cargar gigabytes de datos do modelo desde a memoria de GPU nos rexistros de cómputo. Baseándonos nestas estatísticas, formulamos a hipótese de que unha comparación directa entre NVIDIA H100 e A100 amosará unha mellora de 2x tanto en latencia como en rendemento.

Outra diferencia clave entre NVIDIA H100 e A100 é que o núcleo de tensor H100 engade de forma nativa soporte para instrucións en coma flotante de 8 bits (fp8), o que abre a porta a máis optimizacións detalladas a continuación. É por iso que usamos fp8 e fp16 especificamente para a H100.

Para manter a memoria por GPU consistente neste experimento, mantivemos nós con 8x80GB de memoria de GPU tanto para as nosas NVIDIA A100 como H100. Ademais de permitir tamaños de lote maiores, a memoria de GPU é importante porque os parámetros do modelo cárganse na memoria de GPU durante o inicio do servidor para un acceso rápido. Por exemplo, se cada un dos 70 mil millóns de parámetros do noso modelo é un número en coma flotante de 16 bits, entón o modelo ten un tamaño de arredor de 140 GB, o cal non cabe nunha soa GPU. De aí a necesidade do paralelismo de tensores, que explicamos a continuación.

O paralelismo de tensores refírese ao número de dispositivos de GPU consumidos para executar o servidor de inferencia. Cando asignamos un número de GPUs, TensorRT-LLM agrupa os seus recursos para axudarnos a alcanzar o orzamento de memoria mínimo requirido para executar Llama2 70B. A nosa hipótese é que un paralelismo de tensores menor resultará nunha maior latencia (debido a menos recursos consumidos para satisfacer cada lote) pero un maior rendemento por GPU (debido a unha mellor utilización) en comparación cun paralelismo de tensores maior.

A cuantización é a redución da precisión nos pesos e activacións utilizados polas redes neuronais. Usamos esta técnica para reducir á metade o consumo de memoria de GPU cando pasamos de fp16 a fp8. Isto fai posible executar o mesmo modelo cun uso de memoria de GPU total menor, o que permite un paralelismo de tensores menor, o que impulsa o rendemento.

As implementacións de cuantización teñen o potencial de degradar a precisión. Polo tanto, evaluamos a precisión para diferentes precisións comparando a súa estatística de perplexidade, unha medida de como de ben o LLM predice cada seguinte token nunha oración, no corpus WikiText. Para a coma flotante de 8 bits e o peso de 8 bits con activación de 8 bits e SmoothQuant (w8a8 SQ), non houbo ningún cambio significativo na perplexidade (< 1%) en comparación con fp16 en WikiText, polo que nos sentimos seguros para continuar. Non obstante, w4a16 amosou un cambio substancial do 7% en perplexidade, potencialmente atribuíble á precisión aínda menor e ás conversións dinámicas necesarias entre int4 e fp16.

O paralelismo mediante lotes é unha estratexia clásica para exprimir o rendemento dun sistema limitado en recursos. Ao procesar múltiples solicitudes en cada paso cara adiante a través da rede neuronal, sábese que o loteo aumenta o rendemento a costa dunha certa latencia. O loteo tamén incorre nun maior consumo de memoria de GPU porque o tamaño da caché KV que xestiona o mecanismo de atención medra linealmente co tamaño do lote.

No caso de Llama 2 70B (que ten 80 capas), fp16 cun tamaño de lote de 32 para un tamaño de contexto de 4096, o tamaño da caché KV resulta nun substancial 40 GB. Isto remata por evitar que Llama 2 70B fp16, cuxos pesos por si sos ocupan 140 GB, quepa comodamente nos 160 GB de memoria de GPU dispoñibles no paralelismo de tensores 2 (TP-2).

Percorremos as combinacións compatibles das 4 variables do experimento e presentamos as tendencias máis esclarecedoras a continuación.

Figura 1: A latencia das solicitudes con tamaños de lote variados en cinco configuracións diferentes, todas co paralelismo de tensores 8, o que produce a mellor latencia con 8 GPUs dispoñibles. Dentro de cada configuración, a latencia xeralmente duplícase ao aumentar o tamaño do lote de 1 → 32, e duplícase de novo de 32 → 128. En tamaños de lote suficientemente grandes, H100 reduce aproximadamente á metade a latencia en comparación con A100. A100 usa precisión mixta porque a arquitectura carece de soporte nativo para fp8. w8a8 con SmoothQuant (SQ) pretende asemellarse a fp8.

A mellora da latencia da cuantización está arredor do 10% cando se compara H100 fp16 → fp8 e A100 fp16 → w8a8 con SmoothQuant. Non obstante, a precisión mixta w4a16 realmente funciona mellor en tamaños de lote pequenos e peor en tamaños de lote maiores en comparación con fp16. Isto pode deberse a varios factores, incluíndo kernels de cómputo menos optimizados, o tempo de casting entre int4 e fp16, e o feito de que w4a16 aínda usa comas flotantes de 16 bits para as activacións, o que non resulta en aforros nas dimensións da caché KV. Dado que w4a16 tamén amosou unha menor precisión, concluímos que debemos manternos en w8a8 SQ para A100s e fp8 para H100s.

Figura 2: O rendemento a través de configuracións TP-8 con diferentes arquitectura, cuantización e tamaño de lote. Para cada arquitectura e cuantización, elixiuse o tamaño de lote como o maior que cumpría cun requisito de latencia de 25600ms (20 tokens por segundo para 512 tokens), de xeito que comparamos configuracións que teñen unha latencia similar. Baixo este requisito, H100 con BS-128 alcanza o 228% de rendemento en comparación con A100 BS-64 usando a mesma cuatización (fp16) e mesmo ten menor latencia de resposta malia o tamaño de lote duplicado. A cuantización con fp8 mellora este factor ata o 251%.

Nas nosas dúas primeiras figuras, só presentamos configuracións de TP-8. H100 acadar o 54% de latencia e un 184% de rendemento en comparación con A100 cando ambos usan fp16 / BS-128 / TP-8, o que mellora ata o 49% de latencia e o 202% de rendemento cando se usa fp8 en H100. Esta mellora no rendemento pode atribuírse aos incrementos na potencia de cómputo e no ancho de banda de memoria entre H100 e A100. En particular, a diferencia é menos pronunciada baixo tamaños de lote menores onde a utilización pode ser menor.

A medida que construímos a nosa plataforma, queremos cumprir certos requisitos de latencia para os nosos usuarios ao tempo que maximizamos o rendemento. Polo tanto, en lugar de comparar A100 fronte a H100 co mesmo tamaño de lote, ten máis sentido para nós comparar o seu rendemento só baixo configuracións onde cumpren un requisito de latencia. Estabelecemos un límite de 25600ms de latencia para a finalización dos 512 tokens de saída e atopamos que H100 / TP-8 / fp8 / BS-128 produce un 251% de rendemento en comparación con A100 / TP-8 / fp16 / BS-64, xa que é quen de procesar o dobre do tamaño de lote cunha latencia menor. Dado que a cuantización proporciona aforros de memoria de GPU, agora necesitamos avaliar como o paralelismo de tensores pode engadir unha seguinte capa de optimización.

Figura 3: A latencia a través de tamaños de lote variados e paralelismo de tensores para H100 fp8. A latencia xeralmente duplícase ao aumentar o tamaño do lote de 1 → 32, e duplícase de novo de 32 → 128. TP-2 é consistentemente arredor do doble de lento que TP-8 cando os tamaños de lote son iguais. Duplicar o paralelismo de tensores mentres se duplica o tamaño do lote mantén a latencia relativamente estable xa que o número de lotes procesados por GPU permanece igual.

Cando se trata de cuantización e arquitectura, hai gañadores claros: H100 domina a A100 e a cuantización de precisión reducida mellora a utilización da memoria, a latencia e o rendemento. Non obstante, o tamaño do lote e o paralelismo de tensores presentan un compromiso nas nosas métricas clave. Un tamaño de lote maior optimiza o rendemento a costa dunha maior latencia e consumo de memoria. Por outra banda, un paralelismo de tensores maior aumenta o conxunto total de memoria dispoñible e optimiza a latencia, pero compromete o rendemento debido aos custos de sincronización da multiplicación de matriz distribuída e en virtude de bloquear máis recursos de GPU.

Figura 4: O rendemento a través de tamaños de lote variados e paralelismo de tensores para H100 fp8. O maior rendemento provén de TP-2 BS-128, cun 460% en comparación coa liña de base de A100/TP-8/fp16/BS-64. Non obstante, TP-2 BS-128 é tamén o resultado máis lento na Figura 3.

A configuración que maximiza o rendemento do noso experimento é H100 / fp8 / TP-2 / BS-128, con 767 tokens de saída por segundo por GPU. Isto representa unha mellora do 460% sobre A100 / fp16 / TP-8 / BS-64. Non obstante, isto ten un custo de latencia duplicada (preto de 42000ms para 512 tokens de saída), polo que pode ser inadecuado como configuración de produción. Os resultados de TP-4 BS-128 (626 tok/sec/gpu a 26188ms de tempo de resposta) e TP-2 BS-32 (435 tok/sec/gpu a 18821ms de tempo de resposta) poden representar mellores compromisos nas nosas métricas clave.

Os nosos resultados demostran que:

Alcanzamos o 54% de latencia e un 184% de rendemento usando H100 en comparación con A100 dada a mesma configuración, o que mellora ata o 49% e o 202% respectivamente cando H100 aproveita o seu soporte nativo para fp8.

Ao maximizar o rendemento suxeito a unha restrición de latencia, H100 / fp8 / TP-8 / BS-128 produce un 251% de rendemento en comparación con A100 / fp16 / TP-8 / BS-64, xa que pode procesar o dobre do lote a unha velocidade maior.

Aproveitando H100 con TP-2 con fp8, podemos acadar o 373% do rendemento de A100 / fp16 / TP-8 / BS-128, cun incremento de latencia inferior ao 10%.

O tamaño do lote e o paralelismo de tensores presentan un compromiso entre o rendemento e a latencia para o operador dun sistema de inferencia LLM.

Estes resultados fan que nos sintamos seguros dunha transición completa ás GPUs H100 na nosa pila de hardware previamente impulsada por A100. Estamos encantados de poder confirmar os ganancias de rendemento anunciadas por NVIDIA e agardamos con interese os seus seguintes avances en hardware acelerado.

A nosa seguinte fronteira para a optimización é examinar a precisión e o impacto no rendemento da esparcidade estruturada e a precisión int4, o que podería reducir significativamente a pegada de memoria de GPU de Llama 2 70B e producir melloras de ata 2x na latencia. Estamos encantados de continuar a viaxe dunha inferencia extremadamente rápida e agardamos capacitar aos nosos usuarios para construír aplicacións potentes sobre a nosa plataforma.

A curto prazo, pplx-api eliminará os límites de taxa e ofrecerá máis LLMs personalizados de Perplexity, incluíndo un LLM impulsado por internet con fundamentación de feitos.

Rexístrese en Perplexity Pro en perplexity.ai/pro. Obteña acceso ao noso pplx-api de vangarda e aproveite estas capacidades avanzadas nos seus proxectos. Descubra máis sobre pplx-api no noso blog.

Interésalle dar forma ao futuro da IA? Estamos a contratar! Forme parte dun equipo que impulsa a infraestrutura de LLM xerativa a escala masiva. Explore oportunidades en Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Configuración experimental

Métricas clave:

Constantes:

Modelo de IA

Conxunto de datos de tokens de entrada/saída

Versión de software

Variables

Arquitectura de GPU

Paralelismo de tensores

Cuantización

Tamaño do lote

Resultados

Conclusión

O que segue

Autores: