Turbinando o Llama 2 70B com a NVIDIA H100

A busca por desempenho no mecanismo de resposta da Perplexity nos leva a adotar a tecnologia mais recente que a NVIDIA e a AWS têm a oferecer. Neste blog, estamos animados em compartilhar os resultados dos nossos experimentos mais recentes: uma comparação da inferência do Llama 2 70B em diversas configurações de hardware e software.

Nossa plataforma de inferência de LLM, pplx-api, é construída sobre uma pilha de tecnologia de ponta alimentada por bibliotecas de código aberto. Desde que a versão beta pública da pplx-api começou em outubro, temos enfrentado desafios de escalabilidade e aprendido a melhor forma de ajustar nossa configuração para atingir uma escala massiva. Isso nos levou a realizar experimentos com as seguintes perguntas norteadoras:

Qual é o ganho de desempenho bruto ao trocar nossas GPUs da NVIDIA A100 para a NVIDIA H100, mantendo todas as outras configurações iguais?

Qual é o ganho de eficiência da quantização de ponto flutuante de 8 bits (fp8), para a qual a H100 adiciona suporte nativo? Qual é o custo de precisão desta quantização?

Como o paralelismo de tensores e o tamanho do lote afetam a latência e o throughput de tokens?

Considerando o exposto, qual configuração resulta no equilíbrio mais escalável entre desempenho e eficiência de custos?

Executamos o seguinte experimento como uma série de benchmarks locais para evitar a latência da rede.

Latência: O tempo total necessário para que o servidor de inferência gere sua resposta completa.

Throughput: O número de tokens de saída, por segundo, por GPU, que o servidor de inferência pode gerar para todos os usuários e solicitações.

Os fatores a seguir influenciariam as principais métricas, por isso os mantivemos consistentes em diferentes tentativas do experimento.

O desempenho escala com o tamanho do LLM. Mais parâmetros exigem mais cálculos, resultando em uma inferência mais lenta. Por exemplo, o Llama 2 13B é mais rápido que o Llama 2 70B quando as outras configurações são iguais. Mantivemos o Llama 2 70B neste experimento porque queremos otimizar o fornecimento dos modelos de código aberto mais capazes.

A quantidade de tokens de entrada e saída em cada par de solicitação/resposta de amostra pode influenciar as medições de desempenho. Em geral, a geração de tokens de saída domina o tempo total de resposta. Quando os dados de amostragem induzem apenas respostas “sim/não” do LLM, a resposta é mais rápida em comparação com amostras que pedem ao LLM para escrever ensaios. Nosso conjunto de dados é composto por solicitações sintéticas com 1024 tokens de entrada induzindo 512 tokens de saída. Esta distribuição foi escolhida para corresponder à distribuição observada de tráfego em nossa implementação pública do Llama2 70B.

O NVIDIA TensorRT-LLM (versão v0.5.0) é uma biblioteca de código aberto para otimizar a inferência de LLM. Lançado no final de 2023, ele sintetiza as muitas otimizações de inferência da NVIDIA e fornece uma camada flexível de personalização para os principais parâmetros deste experimento: tamanho do lote, quantização e paralelismo de tensores.

Experimentamos em 4 eixos de configuração: paralelismo de tensores, arquitetura de GPU, quantização e tamanho máximo de lote. Esses eixos estão interconectados porque cada um representa um compromisso em relação ao recurso de gargalo crítico da memória da GPU.

A arquitetura da GPU Hopper de nona geração (H100-HBM3-80GB / p5.48xlarge) traz uma enorme lista de recursos em relação ao seu predecessor, Ampere (A100-SXM4-80GB / p4de.24xlarge), incluindo taxas de computação de 2x a 6x superiores e quase 2x a largura de banda de memória da GPU. A largura de banda de memória da GPU é uma métrica crítica para inferência, porque um gargalo de latência primário das multiplicações de matrizes de inferência vem do carregamento de gigabytes de dados de modelo da memória da GPU para os registros de computação. Com base nesses dados, levantamos a hipótese de que uma comparação direta entre a NVIDIA H100 e a A100 apresentará uma melhoria de 2x tanto na latência quanto no throughput.

Outra diferença fundamental entre a NVIDIA H100 e a A100 é que o núcleo de tensor da H100 adiciona suporte nativo para instruções de ponto flutuante de 8 bits (fp8), o que abre caminho para otimizações adicionais detalhadas abaixo. É por isso que usamos fp8 e fp16 especificamente para a H100.

Para manter a memória por GPU consistente neste experimento, utilizamos nós com 8x80GB de memória de GPU tanto para nossas NVIDIA A100s quanto para as H100s. Além de permitir tamanhos de lote maiores, a memória da GPU é importante porque os parâmetros do modelo são carregados na memória da GPU durante a inicialização do servidor para acesso rápido. Por exemplo, se cada um dos 70 bilhões de parâmetros em nosso modelo for um número de ponto flutuante de 16 bits, o modelo terá cerca de 140 GB, o que não cabe em uma única GPU. Daí a necessidade de paralelismo de tensores, que explicamos abaixo.

O paralelismo de tensores refere-se ao número de dispositivos de GPU consumidos para executar o servidor de inferência. Quando alocamos um número de GPUs, o TensorRT-LLM reúne seus recursos para nos ajudar a atingir o orçamento de memória mínimo necessário para executar o Llama2 70B. Nossa hipótese é que um paralelismo de tensores menor resultará em maior latência (devido a menos recursos consumidos para atender a cada lote), mas maior throughput por GPU (devido a uma melhor utilização) quando comparado a um paralelismo de tensores maior.

A quantização é a redução da precisão nos pesos e ativações usados por redes neurais. Usamos essa técnica para reduzir pela metade o consumo de memória da GPU quando mudamos de fp16 para fp8. Isso torna possível executar o mesmo modelo com um uso total de memória da GPU menor, permitindo um paralelismo de tensores menor, o que aumenta o throughput.

Implementações de quantização têm o potencial de degradar a precisão. Assim, avaliamos a precisão para diferentes precisões comparando sua estatística de perplexidade, uma medida de quão bem o LLM prevê cada próximo token em uma frase, no corpus WikiText. Para ponto flutuante de 8 bits e peso de 8 bits com ativação de 8 bits e SmoothQuant (w8a8 SQ), não houve mudança significativa na perplexidade (< 1%) em comparação com fp16 no WikiText, então nos sentimos confiantes para prosseguir. No entanto, o w4a16 exibiu uma mudança substancial de 7% na perplexidade, potencialmente atribuível à precisão ainda menor e às conversões dinâmicas necessárias entre int4 e fp16.

O paralelismo via processamento em lote é uma estratégia clássica para extrair desempenho de um sistema com recursos limitados. Ao processar várias solicitações em cada passagem direta através da rede neural, o processamento em lote é conhecido por aumentar o throughput ao custo de alguma latência. O processamento em lote também incorre em maior consumo de memória da GPU, porque o tamanho do cache KV, que gerencia o mecanismo de atenção, cresce linearmente com o tamanho do lote.

No caso do Llama 2 70B (que possui 80 camadas), fp16 com tamanho de lote 32 para tamanho de contexto 4096, o tamanho do cache KV chega a substanciais 40 GB. Isso acaba impedindo que o Llama 2 70B fp16, cujos pesos sozinhos ocupam 140GB, caiba confortavelmente nos 160GB de memória da GPU disponíveis no paralelismo de tensores 2 (TP-2).

Analisamos as combinações compatíveis das 4 variáveis do experimento e apresentamos as tendências mais reveladoras abaixo.

Figura 1 - A latência de solicitações com tamanhos de lote variáveis em cinco configurações diferentes, todas com paralelismo de tensores 8, que oferece a melhor latência com 8 GPUs disponíveis. Dentro de cada configuração, a latência geralmente dobra ao aumentar o tamanho do lote de 1 → 32, e dobra novamente de 32 → 128. Em tamanhos de lote suficientemente grandes, a H100 reduz aproximadamente pela metade a latência em comparação com a A100. A A100 usa precisão mista porque a arquitetura não possui suporte nativo para fp8. O w8a8 com SmoothQuant (SQ) destina-se a se assemelhar ao fp8.

A melhoria de latência da quantização fica na casa de 10% ao comparar H100 fp16 → fp8 e A100 fp16 → w8a8 com SmoothQuant. No entanto, o w4a16 de precisão mista na verdade apresenta melhor desempenho em tamanhos de lote baixos e pior desempenho em tamanhos de lote mais altos em comparação com o fp16. Isso pode ser devido a vários fatores, incluindo kernels de computação menos otimizados, tempo de conversão entre int4 e fp16 e o fato de que o w4a16 ainda usa pontos flutuantes de 16 bits para ativações, resultando em nenhuma economia nas dimensões do cache KV. Como o w4a16 também demonstrou menor precisão, concluímos que devemos manter o w8a8 SQ para A100s e o fp8 para H100s.

Figura 2 - O throughput em configurações TP-8 com diferentes arquiteturas, quantizações e tamanhos de lote. Para cada arquitetura e quantização, o tamanho do lote foi escolhido como o maior que respeitasse um requisito de latência de 25600ms (20 tokens por segundo para 512 tokens), para que pudéssemos comparar configurações com latência semelhante. Sob este requisito, a H100 com BS-128 atinge 228% de throughput em comparação com a A100 BS-64 usando a mesma quantização (fp16) e ainda tem menor latência de resposta, apesar do dobro do tamanho do lote. A quantização com fp8 melhora esse fator para 251%.

Em nossas duas primeiras figuras, apresentamos apenas configurações de TP-8. A H100 atinge 54% de latência e 184% de throughput em comparação com a A100 quando ambas usam fp16 / BS-128 / TP-8, o que melhora para 49% de latência e 202% de throughput ao usar fp8 na H100. Essa melhoria no desempenho pode ser atribuída aos aumentos no poder de computação e na largura de banda da memória entre a H100 e a A100. Notavelmente, a diferença é menos pronunciada sob tamanhos de lote menores, onde a utilização pode ser menor.

À medida que construímos nossa plataforma, queremos honrar certos requisitos de latência para nossos usuários enquanto maximizamos o throughput. Portanto, em vez de comparar A100 vs. H100 no mesmo tamanho de lote, faz mais sentido para nós comparar seu throughput apenas sob configurações onde eles atendam a um requisito de latência. Definimos um corte de 25600ms de latência para a conclusão dos 512 tokens de saída e descobrimos que H100 / TP-8 / fp8 / BS-128 gera 251% de throughput em comparação com A100 / TP-8 / fp16 / BS-64, uma vez que é capaz de processar o dobro do tamanho do lote com uma latência menor. Dado que a quantização proporciona economia de memória da GPU, agora precisamos avaliar como o paralelismo de tensores pode adicionar uma próxima camada de otimização.

Figura 3 - A latência em vários tamanhos de lote e paralelismo de tensores para H100 fp8. A latência geralmente dobra ao aumentar o tamanho do lote de 1 → 32, e dobra novamente de 32 → 128. O TP-2 é consistentemente cerca de duas vezes mais lento que o TP-8 quando os tamanhos de lote são iguais. Dobrar o paralelismo de tensores enquanto se dobra o tamanho do lote mantém a latência relativamente estável, pois o número de lotes processados por GPUs permanece uniforme.

Quando se trata de quantização e arquitetura, há vencedores claros: a H100 domina a A100 e a quantização de menor precisão melhora a utilização da memória, a latência e o throughput. No entanto, o tamanho do lote e o paralelismo de tensores apresentam um compromisso em nossas principais métricas. Um tamanho de lote maior otimiza para throughput ao custo de aumento da latência e do consumo de memória. Por outro lado, um paralelismo de tensores mais alto aumenta o pool total de memória disponível e otimiza para latência, mas sacrifica o throughput devido aos custos de sincronização da multiplicação de matrizes distribuída e devido ao bloqueio de mais recursos de GPU.

Figura 4 - O throughput em vários tamanhos de lote e paralelismo de tensores para H100 fp8. O maior throughput vem do TP-2 BS-128, a 460% em comparação com a base de A100/TP-8/fp16/BS-64. No entanto, o TP-2 BS-128 também é o resultado mais lento na Figura 3.

A configuração que maximiza o throughput do nosso experimento é H100 / fp8 / TP-2 / BS-128, a 767 tokens de saída por segundo por GPU. Esta é uma melhoria de 460% em relação à A100 / fp16 / TP-8 / BS-64. No entanto, isso ocorre ao custo de uma latência dobrada - mais próxima de 42000ms para 512 tokens de saída - portanto, pode ser inadequada como uma configuração de produção. Os resultados do TP-4 BS-128 (626 tok/seg/gpu a 26188ms de tempo de resposta) e TP-2 BS-32 (435 tok/seg/gpu a 18821ms de tempo de resposta) podem representar melhores compromissos em nossas principais métricas.

Nossos resultados demonstram que:

Alcançamos 54% de latência e 184% de throughput usando a H100 em comparação com a A100 com a mesma configuração, o que melhora para 49% e 202%, respectivamente, quando a H100 aproveita seu suporte nativo para fp8.

Ao maximizar o throughput sujeito a uma restrição de latência, H100 / fp8 / TP-8 / BS-128 gera 251% de throughput em comparação com A100 / fp16 / TP-8 / BS-64, pois pode processar o dobro do lote a uma velocidade mais rápida.

Aproveitando a H100 com TP-2 com fp8, podemos alcançar 373% do throughput da A100 / fp16 / TP-8 / BS-128, com menos de um aumento de 10% na latência.

O tamanho do lote e o paralelismo de tensores apresentam um compromisso entre throughput e latência para o operador de um sistema de inferência de LLM.

Esses resultados nos deixam confiantes sobre uma transição total para GPUs H100 em nossa pilha de hardware anteriormente alimentada por A100. Estamos empolgados em poder confirmar os ganhos de desempenho anunciados pela NVIDIA e aguardamos ansiosamente seus próximos avanços em hardware acelerado.

Nossa próxima fronteira para otimização é examinar a precisão e o impacto no desempenho da esparsidade estruturada e da precisão int4, o que poderia reduzir significativamente a pegada de memória de GPU do Llama 2 70B e gerar até 2x de melhoria na latência. Estamos empolgados em continuar a jornada da inferência extremamente rápida e esperamos capacitar nossos usuários a construir aplicativos poderosos sobre nossa plataforma.

No curto prazo, a pplx-api suspenderá os limites de taxa e oferecerá mais LLMs Perplexity personalizados, incluindo um LLM alimentado pela internet com base em fatos.

Inscreva-se no Perplexity Pro em perplexity.ai/pro. Obtenha acesso à nossa pplx-api de ponta e aproveite esses recursos avançados em seus projetos. Descubra mais sobre a pplx-api em nosso blog.

Interessado em moldar o futuro da IA? Estamos contratando! Faça parte de uma equipe que impulsiona a infraestrutura de LLM generativa em escala massiva. Explore as oportunidades em Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Configuração experimental

Principais métricas:

Constantes:

Modelo de IA

Conjunto de dados de tokens de entrada/saída

Versão do software

Variáveis

Arquitetura da GPU

Paralelismo de tensores

Quantização

Tamanho do lote

Resultados

Conclusão

O que vem a seguir

Autores: