Inferência de ML econômica com modelos multiframework no Amazon SageMaker 

O aprendizado de máquina (ML) provou ser uma das aplicações de tecnologia mais bem-sucedidas e difundidas, afetando uma ampla gama de setores e impactando bilhões de usuários todos os dias. Com esta rápida adoção do ML em todos os setores, as empresas enfrentam desafios no suporte a previsões de baixa latência e com alta disponibilidade, ao mesmo tempo que maximizam a utilização de recursos e reduzem os custos associados. Como cada estrutura de ML tem suas próprias dependências e as etapas de implantação para cada estrutura são diferentes, a implantação de modelos construídos em diferentes estruturas na produção e o gerenciamento de cada um dos endpoints se tornam cada vez mais complexos.

Amazon Sage Maker endpoints de vários contêineres (MCEs) nos permitem agrupar modelos em diferentes estruturas e implantá-los no mesmo host, criando um único endpoint. Você pode fornecer contêineres para as diferentes estruturas que está usando para construir os modelos, e o SageMaker pega todos esses contêineres e os coloca atrás de um endpoint. Por exemplo, você poderia ter um modelo PyTorch e um modelo TensorFlow carregado em dois endpoints dedicados atendendo aos mesmos casos de uso ou a casos de uso totalmente diferentes, e ambos os modelos têm tráfego de entrada intermitente que não utiliza recursos até seu limite. Nesse cenário, você poderia agrupá-los usando contêineres em um ponto final usando um MCE, melhorando a utilização de recursos e reduzindo os custos incorridos em ter ambos os modelos atendendo a partir de pontos finais diferentes.

Os endpoints de vários contêineres fornecem uma solução escalonável e econômica para implantar até 15 modelos criados em diferentes estruturas de ML, servidores de modelo e algoritmos que atendem ao mesmo caso de uso ou a casos de uso diferentes, o que significa que você pode ter modelos criados em diversas estruturas de ML ou intermediários. etapas em todos esses contêineres e modelos. Todos esses modelos podem ser acessados ​​individualmente por invocação direta ou integrados em um pipeline usando invocação serial, onde a saída de um modelo é a entrada para o próximo.

Nesta postagem, discutimos como realizar inferência de ML econômica com modelos multiestrutura no SageMaker.

Padrões de invocação MCE

A invocação direta do SageMaker MCE é útil nos casos em que você incorporou modelos não relacionados em um endpoint MCE ou está executando um teste A/B entre os modelos por trás de um endpoint MCE para avaliar seu desempenho. Você pode chamar o contêiner específico diretamente na chamada da API e obter a previsão desse modelo.

Com a invocação serial, você pode unir de 2 a 15 contêineres, e a saída de um se torna a entrada do próximo contêiner na sequência. Este é um caso de uso ideal se, por exemplo, você tiver um pipeline de previsão de várias etapas em que um modelo Scikit-learn é usado para uma previsão intermediária e o resultado é alimentado em um modelo TensorFlow para inferência final. Em vez de implantá-los como endpoints diferentes e outro aplicativo ou trabalho orquestrá-los e fazer várias chamadas de API, você pode implantá-los como um SageMaker MCE, abstraindo a lógica e configurando-os para invocação serial, onde o SageMaker gerencia a transferência de dados entre um contêiner para outro automaticamente e emite a saída do contêiner final para o cliente que faz a solicitação da API.

A invocação serial do SageMaker MCE é fundamentalmente diferente de um pipeline de inferência serial do SageMaker (mais detalhes nas seções abaixo). Um pipeline de inferência serial é mais direcionado para orquestrar fluxos de trabalho complexos de ML, como pré-processamento de dados, construção de um conjunto de modelos, implementação de verificações condicionais para determinar qual modelo invocar ou pós-processamento da previsão, envolvendo lógica de negócios antes que a previsão seja enviada para os aplicativos downstream. . Em contraste, a invocação serial do MCE é projetada para unir de 2 a 14 modelos em um pipeline para inferência, cada modelo tomando a previsão do modelo anterior como entrada.

Todos os contêineres em um MCE estão sempre em serviço e na memória, portanto, não há inicialização a frio ao invocar o terminal. Os MCEs também melhoram a utilização do endpoint e melhoram os custos porque os modelos são implantados atrás de um endpoint e compartilham a instância de computação subjacente, em vez de cada modelo ocupar recursos de computação individuais.

Vejamos alguns casos de uso e como você pode usar MCEs do SageMaker para otimizar a inferência de ML.

Casos de uso para MCEs SageMaker

Suponha que você tenha dois modelos para classificação de sentimentos, um para o idioma inglês e outro para o idioma alemão, e esses modelos atendem a regiões geográficas diferentes, com tráfego chegando em horários diferentes do dia. Em vez de ter dois endpoints em execução 24 horas por dia, 7 dias por semana, você pode implantar ambos em um endpoint usando um MCE e acessá-los usando invocação direta, otimizando assim a utilização de recursos e os custos. Veja o seguinte código:

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

Neste exemplo, temos dois modelos (englishModel e germanModel), e definimos os contêineres no SageMaker create_model construir e definir o InferenceExecutionConfig como ‘Direto’. Agora podemos chamar o ponto final para inferência e definir o TargetContainerHostname como também englishModel or germanModel dependendo do cliente que faz a chamada da API:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

Você também pode usar a invocação direta no MCE para executar testes A/B e comparar o desempenho entre os modelos.

O diagrama a seguir ilustra nossa arquitetura.

Da mesma forma, em outros casos de uso de ML, quando o modelo treinado é usado para processar uma solicitação, o modelo recebe dados em um formato que precisa ser pré-processado (por exemplo, caracterizado) antes de poder ser passado ao algoritmo para inferência. Quando os algoritmos de ML são encadeados, a saída de um modelo serve como entrada para o próximo antes de chegar ao resultado final. Neste caso, você pode construir um pipeline serial SageMaker MCE, onde os contêineres se comunicam entre si na sequência definida no arquivo create_model construa em vez de implantar cada um dos modelos em endpoints diferentes e escrever uma lógica independente para facilitar o fluxo de dados entre todos esses modelos e chamadas de API. O diagrama a seguir ilustra essa arquitetura.

Para este caso de uso, usamos o seguinte código:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

Neste exemplo, temos dois contêineres de processamento (Processing-1 e Processing-2) para processamento de recursos e transformações de dados e dois contêineres de inferência (Inference-1 e Inference-2) para executar previsões do modelo de ML nos dados pré-processados. O PipelineModel instance permite definir o pipeline de inferência composto por uma sequência linear de quatro contêineres que processam solicitações de inferência sobre dados. Os contêineres estão localizados na mesma instância, permitindo executar inferência com baixa latência.

Dimensione endpoints multimodelos para um grande número de modelos

Os benefícios dos endpoints multimodelo SageMaker aumentam com base na escala de consolidação do modelo. Você pode ver economias de custos ao hospedar dois modelos com um endpoint e, para casos de uso com centenas ou milhares de modelos, a economia é muito maior.

O dimensionamento dos endpoints do MCE também é simples usando o SageMakerVariantInvocationsPerInstance métrica predefinida, que fornece o número médio de vezes por minuto que cada instância de um endpoint do modelo é invocada para definir um TargetScaling política. O SageMaker ajusta dinamicamente o número de instâncias provisionadas para um modelo em resposta às alterações na sua carga de trabalho. Quando a carga de trabalho aumenta, o escalonamento automático coloca mais instâncias on-line e carrega os modelos e contêineres de destino para continuar atendendo às solicitações. Quando a carga de trabalho diminui, o escalonamento automático remove instâncias desnecessárias e descarrega os contêineres do modelo para que os contêineres não consumam os recursos e você não pague pelas instâncias que não está usando. O tempo para concluir a primeira solicitação em um determinado modelo sofre latência adicional (chamada de inicialização a frio) para baixar o modelo do Serviço de armazenamento simples da Amazon (Amazon S3) e carregue-o na memória. As chamadas subsequentes terminam sem sobrecarga adicional porque o modelo já está carregado. Veja o seguinte código:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

Seguindo o exemplo de configuração de política anterior, usamos o método SageMakerVariantInvocationsPerInstance métrica predefinida para ajustar o número de instâncias variantes para que cada instância tenha uma InvocationsPerInstance métrica de 70.

Também podemos dimensionar MCEs SageMaker com base em nossa própria métrica personalizada, como CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationou DiskUtilization, para aumentar ou diminuir o número de instâncias com base na utilização de um recurso específico. Para obter mais informações, consulte Dimensionar automaticamente modelos do Amazon SageMaker.

É recomendado que o modelo em cada contêiner exiba requisitos de computação e latência semelhantes em cada solicitação de inferência, porque se o tráfego para o MCE mudar de um modelo de alta utilização de CPU para um modelo de baixa utilização de CPU, mas o volume geral de chamadas permanecer o mesmo, o terminal não aumenta e pode não haver instâncias suficientes para lidar com todas as solicitações para o modelo de alta utilização de CPU.

MCEs seguros

Para MCEs com invocação direta, vários contêineres são hospedados em uma única instância compartilhando memória e um volume de armazenamento. É importante proteger os contêineres, manter o mapeamento correto das solicitações para os contêineres de destino e fornecer aos usuários o acesso correto aos contêineres de destino. Você pode restringir invoke_endpoint acesso a um conjunto limitado de contêineres dentro de um MCE usando o sagemaker:TargetContainerHostname Gerenciamento de acesso e identidade da AWS (IAM) chave de condição. SageMaker usa Papéis IAM para fornecer políticas baseadas em identidade do IAM que você usa para especificar ações e recursos permitidos ou negados e as condições sob as quais as ações são permitidas ou negadas. As políticas a seguir mostram como limitar chamadas para contêineres específicos em um endpoint:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Monitore endpoints multimodelos usando métricas do Amazon CloudWatch

Para fazer concessões de preço e desempenho, você desejará testar endpoints multimodelos com modelos e tráfego representativo de seu próprio aplicativo. SageMaker fornece métricas adicionais em Amazon CloudWatch para endpoints multimodelos para que você possa determinar o uso do endpoint e a taxa de acertos do cache e otimizar seu endpoint. As métricas são as seguintes:

• ModelLoadingWaitTime – O intervalo de tempo que uma solicitação de chamada aguarda até que o modelo de destino seja baixado ou carregado para executar a inferência.
• Hora de descarga do modelo – O intervalo de tempo que leva para descarregar o modelo através do contêiner UnloadModel Chamada API.
• Tempo de download do modelo – O intervalo de tempo necessário para fazer download do modelo do Amazon S3.
• ModelLoadingTime – O intervalo de tempo que leva para carregar o modelo através do contêiner LoadModel Chamada API.
• ModeloCacheHit - O número de InvokeEndpoint solicitações enviadas ao endpoint onde o modelo já foi carregado. Pegando o Average a estatística mostra a proporção de solicitações nas quais o modelo já foi carregado.
• LoadedModelCount – O número de modelos carregados nos contêineres no endpoint. Essa métrica é emitida por instância. O Average estatística com período de 1 minuto informa o número médio de modelos carregados por instância e o Sum A estatística informa o número total de modelos carregados em todas as instâncias no endpoint. Os modelos que essa métrica rastreia não são necessariamente exclusivos porque você pode carregar um modelo em vários contêineres no endpoint.

Existem também diversas outras métricas que são usadas por cada contêiner em execução em uma instância, como Invocations indicando o número de InvokeEndpoint solicitações enviadas para um contêiner dentro de um endpoint, ContainerLatency fornecendo o tempo que um endpoint levou para o contêiner de destino ou todos os contêineres em uma invocação serial responderem conforme visualizado no SageMaker, e CPUUtilization e MemoryUtilizaton indicando as unidades de CPU e porcentagem de memória.

Conclusão

Na postagem, discutimos como os endpoints multicontêiner SageMaker podem ser úteis na otimização de custos e utilização de recursos. Exemplos de quando utilizar MCEs incluem, mas não estão limitados a, o seguinte:

• Hospedagem de modelos em diferentes estruturas (como TensorFlow, PyTorch e Scikit-learn) que não têm tráfego suficiente para saturar a capacidade total de uma instância
• Hospedagem de modelos da mesma estrutura com diferentes algoritmos de ML (como recomendações, previsão ou classificação) e funções de manipulador
• Comparações de arquiteturas semelhantes executadas em diferentes versões de estrutura (como TensorFlow 1.x vs. TensorFlow 2.x) para cenários como testes A/B

Os MCEs SageMaker suportam a implantação de até 15 contêineres em endpoints em tempo real e a invocação deles de forma independente para inferência de baixa latência e economia de custos. Os modelos podem ser completamente heterogêneos, com sua própria pilha de serviços independente. Você pode invocar esses contêineres sequencialmente ou de forma independente para cada solicitação. Hospedar com segurança vários modelos, de diferentes estruturas, em uma única instância pode economizar até 90% em custos em comparação com a hospedagem de modelos em endpoints dedicados de instância única.

Sobre os autores

Dhawal Patel é Arquiteto Principal de Machine Learning na AWS. Ele trabalhou com organizações que vão de grandes empresas a startups de médio porte em problemas relacionados à computação distribuída e inteligência artificial. Ele se concentra em aprendizado profundo, incluindo domínios de PNL e visão computacional. Ele ajuda os clientes a obter inferência de modelo de alto desempenho no Amazon SageMaker.

Vikram Elango é arquiteto sênior de soluções especializadas em IA/ML na Amazon Web Services, com sede na Virgínia, EUA. A Vikram ajuda clientes globais do setor financeiro e de seguros com liderança em design e pensamento para construir 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 escalonamento de ML em toda a empresa. Nas horas vagas, ele gosta de viajar, fazer caminhadas, cozinhar e acampar com a família.

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 custo 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.