Execute e otimize a inferência de vários modelos com endpoints de vários modelos do Amazon SageMaker

Amazon Sage Maker O multi-model endpoint (MME) permite que você implemente e hospede vários modelos de maneira econômica em um único endpoint e, em seguida, dimensione horizontalmente o endpoint para alcançar a escala. Conforme ilustrado na figura a seguir, essa é uma técnica eficaz para implementar a multilocação de modelos em sua infraestrutura de aprendizado de máquina (ML). Vimos que as empresas de software como serviço (SaaS) usam esse recurso para aplicar hiperpersonalização em seus modelos de ML e, ao mesmo tempo, obter custos mais baixos.

Para obter uma visão geral de alto nível de como o MME funciona, confira o vídeo do AWS Summit Escalando o ML para o próximo nível: hospedando milhares de modelos no SageMaker. Para saber mais sobre os casos de uso hiperpersonalizados e multilocatários que o MME permite, consulte Como dimensionar a inferência de aprendizado de máquina para casos de uso de SaaS multilocatário.

No restante desta postagem, nos aprofundamos na arquitetura técnica do SageMaker MME e compartilhamos as melhores práticas para otimizar seus terminais multimodelo.

Casos de uso mais adequados para MME

Os endpoints de vários modelos do SageMaker são adequados para hospedar um grande número de modelos que você pode servir por meio de um contêiner de serviço compartilhado e não precisa acessar todos os modelos ao mesmo tempo. Dependendo do tamanho da memória da instância do endpoint, um modelo pode ocasionalmente ser descarregado da memória em favor do carregamento de um novo modelo para maximizar o uso eficiente da memória, portanto, seu aplicativo precisa ser tolerante a picos de latência ocasionais em modelos descarregados.

O MME também foi projetado para co-hospedar modelos que usam a mesma estrutura de ML porque usam o contêiner compartilhado para carregar vários modelos. Portanto, se você tiver uma combinação de estruturas de ML em sua frota de modelos (como PyTorch e TensorFlow), os endpoints dedicados do SageMaker ou a hospedagem de vários contêineres são a melhor escolha.

Finalmente, o MME é adequado para aplicativos que podem tolerar uma penalidade ocasional de latência de inicialização a frio, porque os modelos são carregados na primeira chamada e os modelos usados ​​com pouca frequência podem ser descarregados da memória em favor do carregamento de novos modelos. Portanto, se você tiver uma combinação de modelos acessados ​​com frequência e com pouca frequência, um endpoint de vários modelos poderá atender a esse tráfego com eficiência com menos recursos e maior economia de custos.

Também vimos alguns cenários em que os clientes implantam um cluster MME com capacidade de memória agregada suficiente para caber em todos os seus modelos, evitando assim o descarregamento do modelo e ainda obtendo economia de custos devido à infraestrutura de inferência compartilhada.

Contêineres de serviço de modelo

Quando você usa o SageMaker Inference Toolkit ou um contêiner de serviço de modelo SageMaker pré-criado compatível com MME, seu contêiner tem a Servidor de vários modelos (processo JVM) em execução. A maneira mais fácil de ter o Multi Model Server (MMS) incorporado ao seu contêiner de serviço de modelo é usar Contêineres de serviço de modelo SageMaker compatível com MME (procure aqueles com Job Type=inference e CPU/GPU=CPU). O MMS é uma ferramenta de código aberto e fácil de usar para servir modelos de aprendizado profundo. Ele fornece uma API REST com um servidor web para servir e gerenciar vários modelos em um único host. No entanto, não é obrigatório usar MMS; você pode implementar seu próprio servidor de modelo, desde que ele implemente o APIs exigidas pelo MME.

Quando usado como parte da plataforma MME, todas as chamadas de API de previsão, carregamento e descarregamento para MMS ou seu próprio servidor de modelo são canalizadas por meio do controlador de plano de dados MME. As chamadas de API do controlador de plano de dados são feitas apenas no host local para impedir o acesso não autorizado de fora da instância. Um dos principais benefícios do MMS é que ele permite uma interface padronizada para carregar, descarregar e invocar modelos com compatibilidade em uma ampla variedade de estruturas de aprendizado profundo.

Configuração avançada de MMS

Se você optar por usar o MMS para veiculação de modelo, considere as seguintes configurações avançadas para otimizar a escalabilidade e a taxa de transferência de suas instâncias do MME.

Aumentar o paralelismo de inferência por modelo

O MMS cria um ou mais processos de trabalho do Python por modelo com base no valor do default_workers_per_model parâmetro de configuração. Esses trabalhadores do Python lidam com cada solicitação de inferência individual executando qualquer função de pré-processamento, previsão e pós-processamento que você fornecer. Para mais informações, consulte o manipulador de serviço personalizado Repo do GitHub.

Ter mais de um trabalhador de modelo aumenta o paralelismo de previsões que podem ser atendidas por um determinado modelo. No entanto, quando um grande número de modelos está sendo hospedado em uma instância com um grande número de CPUs, você deve realizar um teste de carga do seu MME para encontrar o valor ideal para default_workers_per_model para evitar qualquer esgotamento de recursos de memória ou CPU.

Design para picos de tráfego

Cada processo MMS em uma instância de endpoint tem uma fila de solicitações que pode ser configurada com o job_queue_size parâmetro (o padrão é 100). Isso determina o número de solicitações que o MMS colocará na fila quando todos os processos de trabalho estiverem ocupados. Use esse parâmetro para ajustar a capacidade de resposta de suas instâncias de endpoint depois de decidir o número ideal de workers por modelo.

Em uma proporção ideal de trabalhador por modelo, o padrão de 100 deve ser suficiente para a maioria dos casos. No entanto, para os casos em que o tráfego de solicitação para o endpoint aumenta de forma incomum, você pode reduzir o tamanho da fila se quiser que o endpoint falhe rapidamente para passar o controle para o aplicativo ou aumentar o tamanho da fila se quiser que o endpoint absorva o pico .

Maximize os recursos de memória por instância

Ao usar vários processos de trabalho por modelo, por padrão, cada processo de trabalho carrega sua própria cópia do modelo. Isso pode reduzir a memória de instância disponível para outros modelos. Você pode otimizar a utilização de memória compartilhando um único modelo entre processos de trabalho definindo o parâmetro de configuração preload_model = verdadeiro. Aqui você está trocando paralelismo de inferência reduzido (devido a uma única instância de modelo) com mais eficiência de memória. Essa configuração, juntamente com vários processos de trabalho, pode ser uma boa opção para casos de uso em que a latência do modelo é baixa, mas você tem pré-processamento e pós-processamento mais pesados ​​(feitos pelos processos de trabalho) por solicitação de inferência.

Definir valores para configurações avançadas de MMS

O MMS usa um arquivo config.properties para armazenar as configurações. O MMS usa a seguinte ordem para localizar este arquivo config.properties:

1. Se o MMS_CONFIG_FILE variável de ambiente estiver definida, o MMS carrega a configuração da variável de ambiente.
2. Se o --mms-config parâmetro é passado para o MMS, ele carrega a configuração do parâmetro.
3. Se houver um config.properties na pasta atual onde o usuário inicia o MMS, ele carrega o config.properties arquivo do diretório de trabalho atual.

Se nenhuma das opções acima for especificada, o MMS carrega a configuração interna com valores padrão.

Veja a seguir um exemplo de linha de comando para iniciar o MMS com um arquivo de configuração explícito:

multi-model-server --start --mms-config /home/mms/config.properties

Principais métricas para monitorar o desempenho do seu endpoint

As principais métricas que podem ajudá-lo a otimizar seu MME geralmente estão relacionadas à utilização da CPU e da memória e à latência de inferência. As métricas em nível de instância são emitidas pelo MMS, enquanto as métricas de latência vêm do MME. Nesta seção, discutimos as métricas típicas que você pode usar para entender e otimizar seu MME.

Métricas no nível da instância do endpoint (métricas MMS)

De lista de métricas de MMS, CPUUtilization e MemoryUtilization podem ajudá-lo a avaliar se sua instância ou o cluster MME está ou não no tamanho certo. Se ambas as métricas tiverem porcentagens entre 50 e 80%, seu MME está no tamanho certo.

Normalmente, CPUUtilization baixo e MemoryUtilization alto são uma indicação de um cluster MME superprovisionado porque indica que os modelos invocados com pouca frequência não estão sendo descarregados. Isso pode ser devido a um número maior do que o ideal de instâncias de endpoint provisionadas para o MME e, portanto, a memória agregada maior do que o ideal está disponível para que os modelos acessados ​​com pouca frequência permaneçam na memória. Por outro lado, perto de 100% de utilização dessas métricas significa que seu cluster está subprovisionado, portanto, você precisa ajustar sua política de dimensionamento automático de cluster.

Métricas no nível da plataforma (métricas MME)

De lista completa de métricas de MME, uma métrica importante que pode ajudá-lo a entender a latência de sua solicitação de inferência é ModelCacheHit. Essa métrica mostra a proporção média de solicitações de invocação para as quais o modelo já foi carregado na memória. Se essa proporção for baixa, isso indica que seu cluster MME está com provisionamento insuficiente porque provavelmente não há capacidade de memória agregada suficiente no cluster MME para o número de invocações de modelo exclusivo, fazendo com que os modelos sejam descarregados da memória com frequência.

Lições do campo e estratégias para otimizar o MME

Vimos as seguintes recomendações de alguns dos usos em alta escala do MME em vários clientes.

O escalonamento horizontal com instâncias menores é melhor do que o escalonamento vertical com instâncias maiores

Você pode enfrentar limitações nas invocações de modelo ao executar solicitações altas por segundo (RPS) em menos instâncias de endpoint. Existem limites internos para o número de invocações por segundo (carregamentos e descarregamentos que podem ocorrer simultaneamente em uma instância) e, portanto, é sempre melhor ter um número maior de instâncias menores. A execução de um número maior de instâncias menores significa uma capacidade agregada total maior desses limites para o endpoint.

Outro benefício do dimensionamento horizontal com instâncias menores é que você reduz o risco de esgotar os recursos de CPU e memória da instância ao executar o MMS com níveis mais altos de paralelismo, juntamente com um número maior de modelos na memória (conforme descrito anteriormente nesta postagem).

Evitar a surra é uma responsabilidade compartilhada

Debatendo no MME é quando os modelos são frequentemente descarregados da memória e recarregados devido à memória insuficiente, seja em uma instância individual ou em um agregado no cluster.

De uma perspectiva de uso, você deve dimensionar corretamente instâncias de endpoint individuais e dimensionar corretamente o tamanho geral do cluster MME para garantir que haja capacidade de memória suficiente disponível por instância e também agregada para o cluster para seu caso de uso. A frota de roteadores da plataforma MME também maximizará o acerto do cache.

Não seja agressivo ao empacotar muitos modelos em menos instâncias de memória maiores

A memória não é o único recurso na instância a ser conhecido. Outros recursos, como CPU, podem ser um fator restritivo, conforme visto nos resultados do teste de carga a seguir. Em alguns outros casos, também observamos outros recursos do kernel, como IDs de processo sendo esgotados em uma instância, devido a uma combinação de muitos modelos sendo carregados e a estrutura de ML subjacente (como TensorFlow) gerando threads por modelo que eram múltiplos de disponíveis vCPUs.

O teste de desempenho a seguir demonstra um exemplo de restrição de CPU que afeta a latência do modelo. Nesse teste, um endpoint de instância única com uma instância grande, embora tenha memória mais do que suficiente para manter todos os quatro modelos na memória, produziu latências de modelo comparativamente piores sob carga quando comparado a um endpoint com quatro instâncias menores.

latência do modelo de endpoint de instância única

Utilização de CPU e memória de endpoint de instância única

latência do modelo de endpoint de quatro instâncias

utilização de CPU e memória de endpoint de quatro instâncias

Para obter desempenho e economia, dimensione corretamente seu cluster MME com um número maior de instâncias menores que, em conjunto, fornecem a memória e a capacidade de CPU ideais, ao mesmo tempo em que são relativamente equivalentes ao custo com menos instâncias de memória, porém maiores.

Modelo mental para otimizar o MME

Existem quatro métricas principais que você deve sempre considerar ao dimensionar corretamente seu MME:

• O número e o tamanho dos modelos
• O número de modelos exclusivos invocados em um determinado momento
• O tipo e o tamanho da instância
• A contagem de instâncias por trás do endpoint

Comece pelos dois primeiros pontos, pois eles informam o terceiro e o quarto. Por exemplo, se não houver instâncias suficientes atrás do endpoint para o número ou tamanho de modelos exclusivos que você tem, a memória agregada para o endpoint será baixa e você verá uma taxa de acertos de cache mais baixa e thrashing no nível do endpoint porque o MME irá carregar e descarregar modelos dentro e fora da memória com freqüência.

Da mesma forma, se as invocações para modelos exclusivos forem maiores que a memória agregada de todas as instâncias atrás do endpoint, você verá um acerto de cache menor. Isso também pode acontecer se o tamanho das instâncias (especialmente a capacidade de memória) for muito pequeno.

O dimensionamento vertical com instâncias de memória realmente grandes também pode levar a problemas porque, embora os modelos possam caber na memória, outros recursos, como processos de CPU e kernel e limites de thread, podem ser esgotados. Carregue o dimensionamento horizontal de teste na pré-produção para obter o número e o tamanho ideais de instâncias para seu MME.

Resumo

Neste post, você tem uma compreensão mais profunda da plataforma MME. Você aprendeu para quais casos de uso técnico o MME é adequado e revisou a arquitetura da plataforma MME. Você obteve uma compreensão mais profunda da função de cada componente dentro da arquitetura MME e de quais componentes você pode influenciar diretamente o desempenho. Por fim, você deu uma olhada mais profunda nos parâmetros de configuração que podem ser ajustados para otimizar o MME para seu caso de uso e as métricas que devem ser monitoradas para manter o desempenho ideal.

Para começar com o MME, revise Endpoints multimodelo do Amazon SageMaker usando XGBoost e Hospede vários modelos em um contêiner atrás de um endpoint.

Sobre o autor

Syed Jaffry é um arquiteto de soluções principal da AWS. Ele trabalha com uma variedade de empresas de organizações de médio porte, grandes empresas, serviços financeiros e ISVs para ajudá-los a criar e operar aplicativos de IA/ML escaláveis ​​e econômicos na nuvem.

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.