Alcance alto desempenho em escala para serviço de modelo usando endpoints multimodelo do Amazon SageMaker com GPU

Amazon Sage Maker endpoints multi-modelo (MMEs) fornecem uma maneira escalável e econômica de implantar um grande número de modelos de aprendizado de máquina (ML). Ele oferece a capacidade de implantar vários modelos de ML em um único contêiner de serviço atrás de um único endpoint. A partir daí, o SageMaker gerencia o carregamento e o descarregamento dos modelos e dimensiona os recursos em seu nome com base em seus padrões de tráfego. Você se beneficiará com o compartilhamento e reutilização de recursos de hospedagem e uma carga operacional reduzida de gerenciamento de uma grande quantidade de modelos.

Em Novembro de 2022, MMEs adicionaram suporte para GPUs, que permite executar vários modelos em um único dispositivo de GPU e dimensionar instâncias de GPU atrás de um único endpoint. Isso atende à forte demanda de MME por modelos de rede neural profunda (DNN) que se beneficiam da computação acelerada com GPUs. Isso inclui visão computacional (CV), processamento de linguagem natural (NLP) e modelos generativos de IA. As razões para a demanda incluem o seguinte:

• Os modelos DNN são geralmente grandes em tamanho e complexidade e continuam crescendo em ritmo acelerado. Tomando os modelos NLP como exemplo, muitos deles excedem bilhões de parâmetros, o que exige que as GPUs satisfaçam os requisitos de baixa latência e alta taxa de transferência.
• Observamos uma necessidade crescente de personalização desses modelos para oferecer experiências hiperpersonalizadas a usuários individuais. À medida que a quantidade desses modelos aumenta, há necessidade de uma solução mais fácil para implantar e operacionalizar muitos modelos em escala.
• As instâncias de GPU são caras e você deseja reutilizá-las o máximo possível para maximizar a utilização da GPU e reduzir o custo operacional.

Embora todos esses motivos apontem para MMEs com GPU como uma opção ideal para modelos DNN, é recomendável realizar testes de carga para encontrar a configuração de endpoint correta que satisfaça seus requisitos de caso de uso. Muitos fatores podem influenciar os resultados do teste de carga, como tipo de instância, número de instâncias, tamanho do modelo e arquitetura do modelo. Além disso, o teste de carga pode ajudar a orientar as estratégias de dimensionamento automático usando as métricas corretas, em vez de métodos iterativos de tentativa e erro.

Por esses motivos, elaboramos esta postagem para ajudá-lo a realizar testes de carga adequados em MMEs com GPU e encontrar a melhor configuração para seu caso de uso de ML. Compartilhamos nossos resultados de teste de carga para alguns dos modelos DNN mais populares em NLP e CV hospedados usando MMEs em diferentes tipos de instância. Resumimos as percepções e conclusões de nossos resultados de teste para ajudá-lo a tomar uma decisão informada sobre a configuração de suas próprias implantações. Ao longo do caminho, também compartilhamos nossa abordagem recomendada para realizar testes de carga para MMEs na GPU. As ferramentas e técnicas recomendadas determinam o número ideal de modelos que podem ser carregados por tipo de instância e ajudam você a obter a melhor relação custo-benefício.

Visão geral da solução

Para obter uma introdução aos MMEs e MMEs com GPU, consulte Criar um endpoint multimodelo e Execute vários modelos de aprendizado profundo na GPU com endpoints de vários modelos do Amazon SageMaker. Para o contexto do teste de carga neste post, você pode baixar nosso código de amostra do GitHub repo para reproduzir os resultados ou usá-lo como um modelo para comparar seus próprios modelos. Existem dois notebooks fornecidos no repositório: um para testar modelos de CV de carga e outro para NLP. Vários modelos de vários tamanhos e arquiteturas foram comparados em diferentes tipos de instâncias de GPU: ml.g4dn.2xlarge, ml.g5.2xlarge e ml.p3.2xlarge. Isso deve fornecer uma seção transversal razoável de desempenho nas seguintes métricas para cada instância e tipo de modelo:

• Número máximo de modelos que podem ser carregados na memória da GPU
• Latência de resposta de ponta a ponta observada no lado do cliente para cada consulta de inferência
• Taxa de transferência máxima de consultas por segundo que o endpoint pode processar sem erros
• Máximo de usuários atuais por instâncias antes que uma solicitação com falha seja observada

A tabela a seguir lista os modelos testados.

A tabela a seguir lista as instâncias de GPU testadas.

Como mencionado anteriormente, o exemplo de código podem ser adotados para outros modelos e tipos de instância.

Observe que os MMEs atualmente suportam apenas instâncias de GPU únicas. Para obter a lista de tipos de instância compatíveis, consulte Algoritmos, estruturas e instâncias compatíveis.

O procedimento de benchmarking é composto pelas seguintes etapas:

1. Recupere um modelo pré-treinado de um hub de modelo.
2. Prepare o artefato de modelo para exibição em MMEs do SageMaker (consulte Execute vários modelos de aprendizado profundo na GPU com endpoints de vários modelos do Amazon SageMaker para mais detalhes).
3. Implante um SageMaker MME em uma instância de GPU.
4. Determine o número máximo de modelos que podem ser carregados na memória da GPU dentro de um limite especificado.
5. Use o Locust Load Testing Framework para simular o tráfego que invoca aleatoriamente modelos carregados na instância.
6. Colete dados e analise os resultados.
7. Opcionalmente, repita as etapas 2 a 6 após compilar o modelo no TensorRT.

As etapas 4 e 5 garantem uma análise mais profunda. Os modelos dentro de um SageMaker GPU MME são carregados na memória de forma dinâmica. Portanto, na Etapa 4, carregamos um artefato de modelo inicial para Serviço de armazenamento simples da Amazon (Amazon S3) e chame o modelo para carregá-lo na memória. Após a chamada inicial, medimos a quantidade de memória da GPU consumida, fazemos uma cópia do modelo inicial, invocamos a cópia do modelo para carregá-la na memória e medimos novamente a quantidade total de memória da GPU consumida. Esse processo é repetido até que um limite de porcentagem especificado de utilização de memória da GPU seja alcançado. Para o benchmark, definimos o limite como 90% para fornecer um buffer de memória razoável para inferência em lotes maiores ou deixar algum espaço para carregar outros modelos usados ​​com menos frequência.

Simule o tráfego de usuários

Depois de determinar o número de modelos, podemos executar um teste de carga usando o Estrutura de teste de carga do Locust. O teste de carga simula solicitações do usuário para modelos aleatórios e mede automaticamente métricas como latência de resposta e taxa de transferência.

O Locust oferece suporte a formas de teste de carga personalizadas que permitem definir padrões de tráfego personalizados. A forma que foi usada neste benchmark é mostrada no gráfico a seguir. Nos primeiros 30 segundos, o terminal é aquecido com 10 usuários simultâneos. Após 30 segundos, novos usuários são gerados a uma taxa de dois por segundo, atingindo 20 usuários simultâneos na marca de 40 segundos. O endpoint é então comparado de forma constante com 20 usuários simultâneos até a marca de 60 segundos, ponto em que o Locust novamente começa a aumentar os usuários em dois por segundo até 40 usuários simultâneos. Esse padrão de aumento e teste constante é repetido até que o endpoint seja aumentado para 200 usuários simultâneos. Dependendo do seu caso de uso, convém ajustar a forma do teste de carga no locust_benchmark_sm.py para refletir com mais precisão os padrões de tráfego esperados. Por exemplo, se você pretende hospedar modelos de linguagem maiores, um teste de carga com 200 usuários simultâneos pode não ser viável para um modelo hospedado em uma única instância e, portanto, você pode querer reduzir a contagem de usuários ou aumentar o número de instâncias. Você também pode estender a duração do teste de carga para avaliar com mais precisão a estabilidade do ponto de extremidade por um período de tempo mais longo.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

Observe que comparamos apenas o endpoint com modelos homogêneos, todos em execução em bases de serviço consistentes usando PyTorch ou TensorRT. Isso ocorre porque os MMEs são mais adequados para hospedar muitos modelos com características semelhantes, como consumo de memória e tempo de resposta. Os modelos de benchmarking fornecidos no GitHub repo ainda pode ser usado para determinar se servir modelos heterogêneos em MMEs produziria o desempenho e a estabilidade desejados.

Resultados de referência para modelos de CV

Use o notebook cv-benchmark.ipynb para executar testes de carga para modelos de visão computacional. Você pode ajustar o nome do modelo pré-treinado e os parâmetros de tipo de instância para teste de carga de desempenho em diferentes combinações de modelo e tipo de instância. Testamos propositalmente três modelos de CV em diferentes faixas de tamanho, do menor ao maior: resnet50 (25 M), convnext_base (88M), e vit_large_patch16_224 (304M). Pode ser necessário ajustar o código se você escolher um modelo fora desta lista. além disso, o notebook padroniza o formato da imagem de entrada para um tensor de imagem de 224x224x3. Lembre-se de ajustar a forma de entrada de acordo se precisar comparar modelos que tiram uma imagem de tamanho diferente.

Depois de executar todo o notebook, você obterá várias visualizações de análise de desempenho. Os dois primeiros detalham o desempenho do modelo em relação ao aumento de usuários simultâneos. As figuras a seguir são as visualizações de exemplo geradas para o ResNet50 modelo rodando em ml.g4dn.2xlarge, comparando PyTorch (esquerda) vs. TensorRT (direita). Os gráficos da linha superior mostram a latência e a taxa de transferência do modelo no eixo y com números crescentes de trabalhadores de clientes simultâneos refletidos no eixo x. Os gráficos da barra inferior mostram a contagem de solicitações bem-sucedidas e com falha.

Analisando todos os modelos de visão computacional que testamos, observamos o seguinte:

• A latência (em milissegundos) é maior e a taxa de transferência (solicitações por segundo) é menor para modelos maiores (resnet50 > convnext_base > vit_large_patch16_224).
• O aumento da latência é proporcional ao número de usuários à medida que mais solicitações são enfileiradas no servidor de inferência.
• Modelos grandes consomem mais recursos de computação e podem atingir seus limites máximos de taxa de transferência com menos usuários do que um modelo menor. Isso é observado com o vit_large_patch16_224 modelo, que registrou a primeira solicitação com falha em 140 usuários simultâneos. Sendo significativamente maior do que os outros dois modelos testados, ele também apresentou o maior número de solicitações com falha geral em uma simultaneidade mais alta. Este é um sinal claro de que o endpoint precisaria escalar além de uma única instância se a intenção fosse oferecer suporte a mais de 140 usuários simultâneos.

No final da execução do notebook, você também obtém uma comparação resumida dos modelos PyTorch x TensorRT para cada uma das quatro métricas principais. A partir de nossos testes de benchmark, todos os modelos CV tiveram um aumento no desempenho do modelo após a compilação do TensorRT. Levando nosso ResNet50 modelo como o exemplo novamente, a latência diminuiu em 32%, enquanto a taxa de transferência aumentou em 18%. Embora o número máximo de usuários simultâneos tenha permanecido o mesmo para ResNet50, os outros dois modelos observaram uma melhoria de 14% no número de usuários simultâneos aos quais eles podem dar suporte. A melhoria de desempenho do TensorRT, no entanto, ocorreu às custas de uma maior utilização de memória, resultando em menos modelos carregados por MMEs. O impacto é maior para modelos que usam uma rede neural convolucional (CNN). Na verdade, nosso modelo ResNet50 consumiu aproximadamente o dobro da memória da GPU indo de PyTorch para TensorRT, resultando em 50% menos modelos carregados (46 vs. 23). Diagnosticamos esse comportamento mais detalhadamente na seção a seguir.

Resultados de benchmark para modelos de PNL

Para os modelos NLP, use o notebook nlp-benchmark.ipynb para executar o teste de carga. A configuração do notebook deve ser muito semelhante. Testamos dois modelos de NLP: bert-base-uncased (109M) e roberta-large (335M). O modelo pré-treinado e o tokenizer são baixados do hub Hugging Face, e a carga de teste é gerada a partir do tokenizer usando uma string de amostra. O comprimento máximo da sequência é padronizado em 128. Se você precisar testar strings mais longas, lembre-se de ajustar esse parâmetro. A execução no notebook NLP gera o mesmo conjunto de visualizações: Pytorch (esquerda) vs TensorRT (direita).

A partir deles, observamos ainda mais benefícios de desempenho do TensorRT para modelos NLP. Pegando o roberta-large modelo em uma instância ml.g4dn.2xlarge, por exemplo, a latência de inferência diminuiu drasticamente de 180 milissegundos para 56 milissegundos (uma melhoria de 70%), enquanto a taxa de transferência melhorou em 406%, de 33 solicitações por segundo para 167. Além disso, o número máximo de solicitações simultâneas usuários aumentaram em 50%; solicitações com falha não foram observadas até atingirmos 180 usuários simultâneos, em comparação com 120 para o modelo PyTorch original. Em termos de utilização de memória, vimos um modelo a menos carregado para o TensorRT (de nove modelos para oito). No entanto, o impacto negativo é muito menor em comparação com o que observamos com os modelos baseados em CNN.

Análise sobre a utilização de memória

A tabela a seguir mostra a análise completa sobre o impacto da utilização de memória indo de PyTorch para TensorRT. Mencionamos anteriormente que os modelos baseados em CNN são afetados de forma mais negativa. O ResNet50 modelo teve uma redução de mais de 50% no número de modelos carregados em todos os três tipos de instância de GPU. Convnext_base teve uma redução ainda maior em aproximadamente 70% em toda a linha. Por outro lado, o impacto nos modelos de transformadores é pequeno ou misto. vit_large_patch16_224 e roberta-large tiveram uma redução média de aproximadamente 20% e 3%, respectivamente, enquanto bert-base-uncased teve uma melhora de aproximadamente 40%.

Observando todos os pontos de dados como um todo em relação ao desempenho superior em latência, taxa de transferência e confiabilidade, e o menor impacto no número máximo de modelos carregados, recomendamos o modelo TensorRT para arquiteturas de modelo baseadas em transformador. Para CNNs, acreditamos que é necessária uma análise de desempenho de custo adicional para garantir que o benefício de desempenho supere o custo de infraestrutura de hospedagem adicional.

As tabelas a seguir listam nossos resultados de benchmark completos para todas as métricas em todos os três tipos de instâncias de GPU.

A tabela a seguir resume os resultados em todos os tipos de instância. A instância ml.g5.2xlarge oferece o melhor desempenho, enquanto a instância ml.p3.2xlarge geralmente apresenta baixo desempenho, apesar de ser a mais cara das três. As instâncias g5 e g4dn demonstram o melhor valor para cargas de trabalho de inferência.

limpar

Depois de concluir o teste de carga, limpe os recursos gerados para evitar cobranças adicionais. Os principais recursos são os endpoints do SageMaker e os arquivos de artefato de modelo no Amazon S3. Para facilitar, os arquivos do bloco de anotações têm o seguinte código de limpeza para ajudá-lo a excluí-los:

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

Conclusão

Nesta postagem, compartilhamos nossos resultados de teste e análise para vários modelos de rede neural profunda executados em endpoints multimodelo SageMaker com GPU. Os resultados e insights que compartilhamos devem fornecer uma seção transversal razoável de desempenho em diferentes métricas e tipos de instância. No processo, também apresentamos nossa abordagem recomendada para executar testes de benchmark para SageMaker MMEs com GPU. As ferramentas e o código de amostra que fornecemos podem ajudá-lo a iniciar rapidamente seus testes de benchmark e tomar uma decisão mais informada sobre como hospedar centenas de modelos DNN de maneira econômica em hardware de computação acelerada. Para começar a comparar seus próprios modelos com suporte MME para GPU, consulte Algoritmos, estruturas e instâncias compatíveis e os votos de GitHub repo para exemplos e documentação adicionais.

Sobre os autores

James Wu é arquiteto de soluções especialista em IA/ML sênior na AWS. ajudando os clientes a projetar e criar soluções de IA/ML. O trabalho de James abrange uma ampla variedade de casos de uso de ML, com interesse principal em visão computacional, aprendizado profundo e dimensionamento de ML em toda a empresa. Antes de ingressar na AWS, James foi arquiteto, desenvolvedor e líder de tecnologia por mais de 10 anos, incluindo 6 anos em engenharia e 4 anos nos setores de marketing e publicidade.

Vikram Elango é um arquiteto de soluções especialista em IA/ML na Amazon Web Services, com sede na Virgínia, EUA. A Vikram ajuda os clientes do setor financeiro e de seguros com design e liderança de pensamento para criar e implantar aplicativos de aprendizado de máquina em escala. Atualmente, ele está focado em processamento de linguagem natural, IA responsável, otimização de inferência e dimensionamento de ML em toda a empresa. Nas horas vagas, gosta de viajar, fazer caminhadas, cozinhar e acampar com a família.

Simon Zamarin é arquiteto de soluções de AI / ML cujo foco principal é ajudar os clientes a extrair valor de seus ativos de dados. Em seu tempo livre, Simon gosta de passar o tempo com a família, lendo ficção científica e trabalhando em vários projetos de casa DIY.

Saurabh Trikande é gerente de produto sênior da Amazon SageMaker Inference. Ele é apaixonado por trabalhar com clientes e motivado pelo objetivo de democratizar o aprendizado de máquina. Ele se concentra nos principais desafios relacionados à implantação de aplicativos de ML complexos, modelos de ML multilocatários, otimizações de custos e à implantação de modelos de aprendizado profundo mais acessíveis. Em seu tempo livre, Saurabh gosta de caminhar, aprender sobre tecnologias inovadoras, seguir o TechCrunch e passar tempo com sua família.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. Acesse aqui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/