Como avaliar o desempenho da inferência de LLM no Red Hat OpenShift AI

O cenário da inteligência artificial (IA) generativa passou por uma rápida evolução no último ano. À medida que o poder dos Large Language Models (modelos de linguagem de larga escala) ou LLM generativos aumenta, as organizações buscam cada vez mais aproveitar seus recursos. Por conta das altas demandas computacionais geradas pela execução de LLMs, é essencial implantar esses modelos em uma plataforma confiável e de alto desempenho para usar o hardware subjacente de maneira econômica, incluindo principalmente as GPUs.

Este artigo apresenta a metodologia e os resultados dos testes de desempenho dos modelos Llama-2 implantados no stack de serviços de modelos incluído no Red Hat OpenShift AI. O OpenShift AI é uma plataforma de MLOps flexível e escalável, com ferramentas para construir, implantar e gerenciar aplicações habilitadas para IA. Construída com tecnologias open source, ela oferece capacidades confiáveis e operacionalmente consistentes para as equipes experimentarem, servirem modelos e entregarem aplicações inovadoras.

O stack de disponibilização de modelos

O stack de software que disponibiliza modelos é baseado no KServe, OpenShift Serverless e OpenShift Service Mesh. Para executar os modelos Llama-2, também usamos o Caikit e o Text-Generation-Inference-Server (TGIS), embora o OpenShift AI também seja compatível com o OpenVINO e ofereça a capacidade de usar outros runtimes personalizados de maneira modular. O NVIDIA GPU Operator gerencia e expõe as GPUs para que elas sejam usadas pelo container do Text-Generation-Inference-Server (TGIS).

Figura 1. Interações entre os componentes e o fluxo de trabalho do usuário no stack do KServe/Caikit/TGIS.

O KServe oferece muitos recursos avançados de disponibilização para inferência de modelos de IA utilizando o OpenShift Serverless e o OpenShift Service Mesh. Esses componentes fazem o encapsulamento da complexidade da rede, configuração de serviços, escalabilidade automática e verificação de integridade para disponibilizar o modelo de produção.

Com o conjunto de ferramentas do Caikit, os usuários podem gerenciar modelos por meio de um conjunto de APIs fáceis de usar para desenvolvedores. O Caikit oferece interfaces padrão HTTP e de chamada de procedimento remoto (gRPC) que podem ser usadas para consultar vários modelos de base. Ele encaminha as solicitações para o serviço de inferência, o TGIS.

O TGIS é uma das primeiras ramificações do kit de ferramentas de disponibilização Text-Generation-Inference do Hugging Face. Ele oferece várias funcionalidades importantes para otimizar o desempenho da disponibilização de LLMs, como processamento em lote contínuo e dinâmico, paralelismo de tensores (fragmentação do modelo), suporte para a compilação do PyTorch 2 e muito mais.

O NVIDIA GPU Operator automatiza o gerenciamento de vários componentes de software necessários para provisionar e usar as GPUs da NVIDIA no OpenShift. Isso inclui o container do driver, plug-in do dispositivo, exportador de métricas do Data Center GPU Manager (DCGM) e muito mais. Com o exportador de métricas do DCGM, é possível analisar métricas de GPU como utilização da memória e do multiprocessador de streaming (SM), além de outros componentes que usam a instância de monitoramento Prometheus do OpenShift.

Metodologia do teste de desempenho dos Large Language Models

Para avaliar o desempenho de um Large Language Model, usaremos as medidas tradicionais de latência e taxa de transferência. No entanto, a latência de ponta a ponta das solicitações para um LLM pode variar muito dependendo de alguns fatores. O aspecto mais importante é o comprimento da saída devido à maneira como os LLMs geram um token de texto de cada vez. Por isso, fazemos a medição principalmente em termos de latência por token ou “tempo por token de saída” (TPOT).

Os tokens são unidades de texto que representam uma palavra ou uma cadeia de caracteres de uma subpalavra. Quando um Large Language Model processa texto, ele é convertido primeiro em tokens. O esquema usado para mapear o texto aos tokens varia conforme o modelo. Os tokens recebem representações numéricas e são organizados em vetores, que por sua vez são alimentados no modelo e gerados por ele.

Outro fator que afeta a latência total da solicitação é o tempo de “preenchimento prévio”. Isso se refere ao tempo necessário para que os tokens de prompt de entrada sejam processados antes que o modelo produza o primeiro token novo. Um terceiro fator significativo que contribui para a latência total da solicitação é o tempo de fila. Há os casos em que o serviço de inferência não consegue processar as solicitações com rapidez suficiente para acompanhar a carga de entrada, o que acontece devido a restrições no hardware, como a memória da GPU. Nesse caso, algumas solicitações vão precisar aguardar em uma fila antes de serem processadas. Devido a esses fatores, o “tempo para o primeiro token” (TTFT) é uma métrica comum para avaliar o desempenho dos LLMs. O TTFT é muito relevante em casos de uso como chatbots, em que os tokens são transmitidos e exibidos à medida que são gerados.

Assim como a latência, a taxa de transferência varia muito quando avaliada pelas solicitações por segundo, o que depende do número de tokens que são gerados nas solicitações. Portanto, medimos a taxa de transferência geral em termos do total de tokens gerados por segundo para todos os usuários que consultam o modelo.

Teste de carga com o llm-load-test

Criamos uma ferramenta open source chamada de llm-load-test para testar a carga dos modelos executados no stack de disponibilização do OpenShift AI. Ele é escrito em Python e usa a ferramenta de teste de carga gRPC chamada de ghz em segundo plano. Ramificamos o ghz para oferecer a capacidade de salvar a resposta e a ID de thread do trabalhador de cada solicitação na saída do teste.

Além das funcionalidades, o llm-load-test possibilita a execução de vários processos do ghz em paralelo com o conjunto de dados de entrada em uma ordem aleatória em cada instância. Assim, é possível simular vários usuários diferentes que consultam o modelo com diversos prompts ao mesmo tempo. O llm-load-test também carrega os resultados diretamente em um bucket do S3 após um experimento, marcando os objetos da saída com os metadados correspondentes da execução.

Conjunto de dados de entrada

É possível configurar prompts de entrada do llm-load-test para o teste de carga usando um arquivo JSON. Para os experimentos que realizamos para gerar os resultados deste post, escolhemos um conjunto de dados de 32 entradas do OpenOrca com comprimentos de entrada/saída variados. A entrada e a saída mais longas nos nossos dados de teste tinham 1.688 e 377 tokens, respectivamente. A Figura 2 mostra a distribuição dos comprimentos de entrada/saída no conjunto de dados de teste.

Figura 2. Comprimento de token do conjunto de dados de teste.

É importante usar tamanhos variados de entrada e saída para testar a capacidade do processamento em lote contínuo e dinâmico do TGIS em um cenário realista. Modelos recentes começaram a oferecer suporte a comprimentos de contexto muito grandes de mais de 4 mil, o que é importante em casos de uso como a geração aumentada de recuperação (RAG). Por isso, pretendemos aumentar o tamanho do nosso conjunto de dados de teste de carga para incluir comprimentos de entrada maiores no futuro.

Resultados de desempenho do Llama-2 no OpenShift AI executado na AWS

As medições de desempenho a seguir foram coletadas usando um cluster autogerenciado do OpenShift de infraestrutura provisionada pelo instalador (IPI) instalado na AWS. Instalamos o operador do OpenShift AI e criamos os objetos ServingRuntime e InferenceService para viabilizar a disponibilização de modelos com o Kserve, Caikit e TGIS.

A Tabela 1 abaixo resume os resultados dos testes de quatro combinações de modelos e tipos de instâncias da AWS:

Tabela 1. Resumo das configurações de teste.

Em cada configuração, executamos vários testes de carga de quatro minutos usando o llm-load-test com diferentes números de threads simultâneos (o parâmetro de simultaneidade nas figuras abaixo). Em todos os testes, cada thread simultânea envia de maneira contínua uma solicitação por vez assim que recebe a resposta da solicitação anterior.

Para você ter um exemplo visual de um experimento, confira abaixo na Figura 3 um diagrama da latência total de cada solicitação ao longo do teste. A cor de cada ponto representa o comprimento do token. Assim, você visualiza a correlação entre o comprimento do token e a saída da solicitação geral.

Figura 3. Latência total de todas as solicitações ao longo de um teste de carga.

Analisamos os logs do TGIS para coletar a latência total de cada solicitação e calculamos a taxa de transferência dividindo o total de tokens gerados durante o teste de carga pela duração do processo (240 segundos).

A Figura 4 mostra a latência e a taxa de transferência medidas durante o teste de carga do Llama-2-7b na instância g5.2xlarge com várias configurações de simultaneidade. Nesse caso, perceba que a taxa de transferência cresce à medida que aumentamos a simultaneidade do teste de carga a cerca de 20 threads. Devido às restrições na memória da GPU da instância g5.2xlarge, o TGIS não pode acomodar mais do que 20 solicitações (dependendo do comprimento da entrada/saída das solicitações) em um lote de uma vez.

Figura 4. Resumo da latência e da taxa de transferência do Llama-2-7b na instância g5.2xlarge.

O gráfico da Figura 5 mostra a latência e a taxa de transferência medidas durante o teste de carga do Llama-2-13B na instância g5.12xlarge. Nesse caso, vemos que a latência mínima por token começa menor do que o modelo 7B na instância g5.2xlarge. Além disso, a taxa de transferência cresce para até pelo menos 30 solicitações simultâneas, apesar de o modelo ser maior e de a instância ter o mesmo tipo de GPUs. Isso acontece devido ao aumento significativo de desempenho que o paralelismo de tensores oferece ao distribuir o modelo entre as quatro GPUs.

Figura 5. Resumo da latência e da taxa de transferência do Llama-2-13b na instância g5.12xlarge.

A Figura 6 mostra a latência e a taxa de transferência medidas durante o teste de carga do Llama-2-70b na instância g5.48xlarge. Nesse caso, a latência por token é maior em geral do que nas configurações anteriores. Modelos como o Llama-2-70B têm requisitos de hardware significativos. As GPUs 8xA10G têm 192 GB de VRAM combinada, e a maior parte dessa capacidade é necessária apenas para carregar os parâmetros do 70B com precisão de 16 bits na memória (70 B × 16 bits = cerca de 140 GB). Dependendo dos seus requisitos de desempenho, ainda mais computação pode ser exigida, como as instâncias p4d.24xlarge.

Figura 6. Resumo da latência e da taxa de transferência do Llama-2-70b na instância g5.48xlarge.

A Figura 7 mostra a latência e a taxa de transferência medidas durante o teste de carga do Llama-2-70b na instância p4d.24xlarge. Nessa instância, é possível manter uma latência muito menor para o mesmo número de usuários em comparação com a g5.48xlarge. Mesmo com até 30 de simultaneidade, a taxa de transferência continua crescendo à medida que a simultaneidade do teste de carga aumenta.

Figura 7. Resumo da latência e da taxa de transferência do Llama-2-70b na instância p4d.24xlarge.

Cálculos de custo

É possível determinar o gasto da geração de um milhão de tokens usando a taxa de transferência medida e os custos do tipo de instância. A tabela abaixo resume essas estimativas usando a taxa de transferência medida para os resultados que coletamos com 10 de simultaneidade de carga.

Tabela 2. Resumo dos resultados de cada configuração com o custo calculado por um milhão de tokens.

Trabalho futuro

Esses resultados são uma pequena amostra dos testes que a equipe de desempenho e escala para plataforma de IA (PSAP) da Red Hat está realizando. Além dos testes de desempenho de outros aspectos do OpenShift AI, continuamos analisando ativamente o desempenho e a escalabilidade do stack de disponibilização de modelos. Esperamos compartilhar no futuro mais resultados de testes de outros modelos, de escalabilidade automática de réplicas de modelo com base no tráfego e muito mais.

Vamos continuar com o desenvolvimento do llm-load-test, e há várias funcionalidades que esperamos adicionar em breve. Isso inclui o seguinte:

• A capacidade de avaliar o tempo para o primeiro token e o tempo por token de saída em solicitações de streaming.
• Interfaces conectáveis/modulares para consultar os modelos por trás de diferentes APIs, incluindo HTTP e gRPC.
• Fase de aquecimento e capacidade de confirmar se o modelo foi carregado e gera respostas sem erros.
• Padrões de carga mais complexos, como uma taxa de chegada aleatória de Poisson.

Conclusão

Nossos testes de desempenho dos modelos Llama-2 no OpenShift AI oferecem uma visão geral da latência, taxa de transferência e custos envolvidos na execução de LLMs em várias configurações. Por exemplo, para o modelo 7B, a instância g5.2xlarge foi a mais econômica. No entanto, passar para a g5.12xlarge pode ser benéfico em alguns casos de uso devido às melhorias significativas na latência e na taxa de transferência geradas pelo paralelismo de tensores. Executar os modelos maiores produz uma saída de qualidade melhor, mas exige mais memória da GPU, aumentando os custos.

O OpenShift AI oferece uma solução de disponibilização de modelos adaptável e de alto desempenho para as organizações que precisam lidar com a complexidade da implantação de Large Language Models generativos. Seja para priorizar a qualidade do modelo, a latência, a taxa de transferência ou o custo, a flexibilidade da plataforma atende a diversos requisitos. Para avaliar esses benefícios em um caso de uso específico, implante seu modelo no OpenShift AI.