Turbocharging Llama 2 70B com NVIDIA H100

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

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

Qual é o ganho de desempenho bruto ao mudar nossas GPUs de NVIDIA A100 para 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 dessa quantização?

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

Considerando o exposto acima, 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 de rede.

Latência: O tempo total que o servidor de inferência leva para gerar sua resposta completa.

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

Os seguintes fatores influenciariam as métricas-chave, por isso os mantivemos consistentes em diferentes tentativas do experimento.

O desempenho escala com o tamanho do LLM. Mais parâmetros exigem mais computações, resultando em uma inferência mais lenta. Por exemplo, o Llama 2 13B é mais rápido que o Llama 2 70B quando outras configurações são iguais. Mantemos o Llama 2 70B neste experimento porque queremos otimizar para servir aos 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 de resposta geral. Quando a amostragem de dados induz apenas respostas "sim/não" do LLM, a resposta é mais rápida em comparação com amostras que pedem ao LLM para escrever redações. 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 implantação pública do Llama 2 70B.

NVIDIA TensorRT-LLM (versão v0.5.0) é uma biblioteca de código aberto para otimizar a inferência de LLM. Lançada no final de 2023, ela 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.

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

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

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

Para manter a memória por GPU consistente neste experimento, mantivemos nós com 8x80GB de memória de GPU para nossas NVIDIA A100s e 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 do nosso modelo for um número de ponto flutuante de 16 bits, o modelo terá cerca de 140 GB de tamanho, 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 agrupa seus recursos para nos ajudar a atingir o orçamento mínimo de memória necessário para executar o Llama 2 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 taxa de transferência 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 pelas 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 menor uso total de memória da GPU, permitindo menor paralelismo de tensores, o que impulsiona a taxa de transferência.

As implementações de quantização têm o potencial de degradar a precisão. Portanto, avaliamos a precisão para diferentes precisões comparando sua estatística de perplexidade, uma medida de quão bem o LLM prevê cada token seguinte em uma frase, no corpus WikiText. Para o ponto flutuante de 8 bits e peso de 8 bits com ativação de 8 bits e SmoothQuant (w8a8 SQ), não houve alteração significativa na perplexidade (< 1%) em comparação com o fp16 no WikiText, então nos sentimos confiantes para prosseguir. No entanto, o w4a16 exibiu uma alteração 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 formação de lotes é uma estratégia clássica para extrair desempenho de um sistema com restrição de recursos. Ao processar várias solicitações em cada passagem direta pela rede neural, a formação de lotes é conhecida por aumentar a taxa de transferência ao custo de alguma latência. A formação de lotes 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 um tamanho de contexto de 4096, o tamanho do cache KV chega a expressivos 40 GB. Isso acaba impedindo que o Llama 2 70B fp16, cujos pesos sozinhos ocupam 140 GB, caiba confortavelmente nos 160 GB de memória de GPU disponíveis no paralelismo de tensores 2 (TP-2).

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

Figura 1 - A latência de solicitações com tamanho de lote variável em cinco configurações diferentes, todas com paralelismo de tensores 8, o que produz 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 a latência pela metade em comparação com a A100. A A100 usa precisão mista porque a arquitetura carece de suporte nativo para fp8. O w8a8 com SmoothQuant (SQ) destina-se a se parecer com o fp8.

A melhoria de latência da quantização fica em torno de 10% ao comparar H100 fp16 → fp8 e A100 fp16 → w8a8 com SmoothQuant. No entanto, a precisão mista w4a16 na verdade tem um desempenho melhor em tamanhos de lote baixos e pior 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 - A taxa de transferência 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 atendeu a um requisito de latência de 25600ms (20 tokens por segundo para 512 tokens), de modo que comparamos configurações com latência semelhante. Sob esse requisito, a H100 com BS-128 atinge 228% da taxa de transferência em comparação com a A100 BS-64 usando a mesma quantização (fp16) e ainda tem menor latência de resposta, apesar do tamanho do lote dobrado. A quantização com fp8 melhora esse fator para 251%.

Em nossas duas primeiras figuras, apresentamos apenas configurações de TP-8. A H100 alcança 54% de latência e 184% de taxa de transferência 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 taxa de transferência 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 de memória entre a H100 e a A100. Notavelmente, a diferença é menos pronunciada em tamanhos de lote menores, onde a utilização pode ser menor.

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

Figura 3 - A latência em diferentes 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 GPU permanece par.

Quando se trata de quantização e arquitetura, há vencedores claros: a H100 domina a A100 e a quantização de precisão reduzida melhora a utilização de memória, a latência e a taxa de transferência. No entanto, o tamanho do lote e o paralelismo de tensores apresentam uma compensação em nossas métricas-chave. Um tamanho de lote maior otimiza a taxa de transferência ao custo de aumento de latência e consumo de memória. Por outro lado, um paralelismo de tensores maior aumenta o pool geral de memória disponível e otimiza a latência, mas sacrifica a taxa de transferência devido aos custos de sincronização da multiplicação de matrizes distribuídas e por ocupar mais recursos de GPU.

Figura 4 - A taxa de transferência em diferentes tamanhos de lote e paralelismo de tensores para H100 fp8. A maior taxa de transferência vem do TP-2 BS-128, a 460% em comparação com a linha de 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 a taxa de transferência do nosso experimento é H100 / fp8 / TP-2 / BS-128, a 767 tokens de saída por segundo por GPU. Esta é uma melhoria de 460% sobre A100 / fp16 / TP-8 / BS-64. No entanto, isso vem ao custo de latência dobrada - mais próxima de 42000ms para 512 tokens de saída -, portanto, pode ser inadequada como configuração de produção. 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) podem representar melhores compensações em nossas métricas-chave.

Nossos resultados demonstram que:

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

Ao maximizar a taxa de transferência sujeita a uma restrição de latência, H100 / fp8 / TP-8 / BS-128 produz 251% da taxa de transferência em comparação com A100 / fp16 / TP-8 / BS-64, pois pode processar o dobro do lote a uma velocidade maior.

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

O tamanho do lote e o paralelismo de tensores apresentam uma compensação entre a taxa de transferência e a latência para o operador de um sistema de inferência de LLM.

Esses resultados nos deixam confiantes sobre uma transição completa para GPUs H100 em nossa pilha de hardware anteriormente alimentada por A100. Estamos entusiasmados por poder confirmar os ganhos de desempenho anunciados pela NVIDIA e ansiosos por 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 produzir melhorias de até 2x na latência. Estamos entusiasmados em continuar a jornada de inferência ultrarrápida e esperamos capacitar nossos usuários a construir aplicativos poderosos em cima de nossa plataforma.

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

Inscreva-se no Perplexity Pro em perplexity.ai/pro. Tenha 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 infraestrutura de LLM generativa em escala massiva. Explore oportunidades em Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Configuração experimental

Métricas-chave:

Constantes:

Modelo de IA

Conjunto de dados de tokens de entrada/saída

Versão do software

Variáveis

Arquitetura de GPU

Paralelismo de tensores

Quantização

Tamanho do lote

Resultados

Conclusão

O que vem a seguir

Autores: