Introdução à implantação de modelos em tempo real no Amazon SageMaker

Amazon Sage Maker é um serviço totalmente gerenciado que fornece a cada desenvolvedor e cientista de dados a capacidade de construir, treinar e implantar rapidamente modelos de aprendizado de máquina (ML) em escala. ML é realizado em inferência. SageMaker oferece quatro opções de inferência:

1. Inferência em tempo real
2. Inferência sem servidor
3. Inferência assíncrona
4. Transformação em lote

Essas quatro opções podem ser amplamente classificadas em opções de inferência on-line e em lote. Na Inferência Online, espera-se que as solicitações sejam processadas à medida que chegam, e o aplicativo consumidor espera uma resposta após o processamento de cada solicitação. Isso pode acontecer de forma síncrona (inferência em tempo real, sem servidor) ou de forma assíncrona (inferência assíncrona). Em um padrão síncrono, o aplicativo consumidor é bloqueado e não pode prosseguir até receber uma resposta. Essas cargas de trabalho tendem a ser aplicações em tempo real, como detecção de fraudes de cartão de crédito on-line, onde as respostas são esperadas na ordem de milissegundos a segundos e as cargas de solicitação são pequenas (alguns MB). No padrão assíncrono, a experiência do aplicativo não é bloqueada (por exemplo, enviar uma solicitação de seguro por meio de um aplicativo móvel) e geralmente requer tamanhos de carga maiores e/ou tempos de processamento mais longos. Na inferência offline, uma agregação (lote) de solicitações de inferência é processada em conjunto e as respostas são fornecidas somente após todo o lote ter sido processado. Geralmente, essas cargas de trabalho não são sensíveis à latência, envolvem grandes volumes (vários GBs) de dados e são programadas em uma cadência regular (por exemplo, executar detecção de objetos em imagens de câmeras de segurança no final do dia ou processar dados de folha de pagamento no final do dia). fim do mês).

No esqueleto, Inferência em tempo real do SageMaker consiste em um(s) modelo(s), a estrutura/contêiner com o qual você está trabalhando e a infraestrutura/instâncias que dão suporte ao seu endpoint implantado. Nesta postagem, exploraremos como você pode criar e invocar um endpoint de modelo único.

Escolhendo a opção de implantação do modelo

Escolher o tipo de inferência correto pode ser difícil, e o guia simples a seguir pode ajudá-lo. Não é um fluxograma rígido, então se você achar que outra opção funciona melhor para você, sinta-se à vontade para usá-la. Em particular, a Inferência em Tempo Real é uma ótima opção para hospedar seus modelos quando você tem latência baixa e consistente (na ordem de milissegundos ou segundos) e cargas de trabalho sensíveis à taxa de transferência. Você pode controlar o tipo de instância e a contagem do seu endpoint enquanto também configura Escalonamento automático política para lidar com o tráfego. Existem duas outras opções de inferência do SageMaker que você também pode usar para criar um endpoint. Inferência assíncrona ocorre quando você tem grandes tamanhos de carga útil e largura de banda com latência quase em tempo real. Esta é uma boa opção, especialmente para modelos de PNL e Visão Computacional que possuem tempos de pré-processamento mais longos. A inferência sem servidor é uma ótima opção quando você tem tráfego intermitente e não deseja gerenciar o dimensionamento da infraestrutura. A receita para criar um endpoint permanece a mesma, independentemente do tipo de inferência escolhido. Nesta postagem, vamos nos concentrar na criação de um endpoint baseado em instância em tempo real, mas você pode adaptá-lo facilmente a qualquer uma das outras opções de inferência com base no seu caso de uso. Por último, a inferência em lote ocorre offline, para que você possa fornecer um conjunto de dados dos quais deseja obter inferência e nós o executaremos. Isso também é baseado em instância, para que você possa selecionar a instância ideal para sua carga de trabalho. Como não há endpoint instalado e funcionando, você paga apenas pela duração do trabalho. É bom para processar gigabytes de dados e a duração do trabalho pode ser de dias. Existem recursos integrados para facilitar o trabalho com dados estruturados e otimizações para distribuir dados estruturados automaticamente. Alguns exemplos de casos de uso são modelagem de propensão, manutenção preditiva e previsão de rotatividade. Tudo isso pode ocorrer off-line em massa porque não é necessário reagir a um evento específico.

Hospedando um modelo no SageMaker Endpoints

Basicamente, o SageMaker Real-Time Endpoints consiste em um modelo e a infraestrutura com a qual você escolhe apoiar o Endpoint. O SageMaker usa contêineres para hospedar modelos, o que significa que você precisa de um contêiner que configure adequadamente o ambiente para a estrutura usada para cada modelo fornecido. Por exemplo, se você estiver trabalhando com um modelo Sklearn, você deve passar os scripts/dados do seu modelo dentro de um contêiner que configure corretamente o Sklearn. Felizmente, o SageMaker fornece imagens gerenciadas para estruturas populares, como TensorFlow, PyTorch, Sklearn e HuggingFace. Você pode recuperar e utilizar essas imagens usando o alto nível SDK Python do SageMaker e injete seus scripts de modelo e dados nesses contêineres. Caso o SageMaker não tenha um contêiner compatível, você também pode Construa seu próprio contêiner e envie sua própria imagem customizada, instalando as dependências necessárias para seu modelo.

SageMaker oferece suporte a modelos treinados e pré-treinados. No parágrafo anterior, quando falamos sobre scripts/dados de modelo, estamos nos referindo a esse assunto. Você pode montar um script em seu contêiner ou se tiver um artefato de modelo pré-treinado (por exemplo, `modelo.joblib` para SKLearn), então você pode fornecer isso junto com sua imagem para o SageMaker. Para entender o SageMaker Inference, existem três entidades principais que você criará no processo de criação do Endpoint:

1. Entidade do modelo SageMaker - aqui você pode passar os dados do modelo treinado/script do modelo e a imagem com a qual está trabalhando, seja ela de propriedade da AWS ou construída por você.
2. Criação de configuração de endpoint – Aqui você define sua infraestrutura, o que significa que você seleciona o tipo de instância, contagem, etc.
3. Criação de endpoint – Este é o endpoint REST que hospeda seu modelo que você está invocando para obter uma resposta. Vejamos como você pode utilizar uma imagem gerenciada do SageMaker e sua própria imagem personalizada para implantar um endpoint.

Requisitos de endpoint em tempo real

1. Antes de criar um Endpoint, você deve entender que tipo de Modelo deseja hospedar. Se for um modelo Framework, como TensorFlow, PyTorch ou MXNet, você poderá utilizar um dos imagens de estrutura pré-construídas.
   Se for um modelo personalizado ou se você quiser total flexibilidade na criação do contêiner que o SageMaker executará para inferência, você poderá construir seu próprio contêiner.

Pontos de extremidade do SageMaker são constituídos por um Modelo SageMaker e Configuração de terminal.
Se você estiver usando o Boto3, você criará os dois objetos. Caso contrário, se você estiver utilizando o SageMaker Python SDK, a configuração do Endpoint será criada em seu nome quando você usar o .deploy(..) função.

Entidades SageMaker:

• Modelo SageMaker:
  • Contém os detalhes da imagem de inferência, localização dos artefatos do modelo em Serviço de armazenamento simples Amazon (Amazon S3), configuração de rede e AWS Identity and Access Management (IAM) função a ser usada pelo Endpoint.
    • O SageMaker exige que os artefatos do seu modelo sejam compactados em um .tar.gz arquivo. O SageMaker extrai automaticamente isso .tar.gz arquivar no /opt/ml/model/ diretório em seu contêiner. Se você estiver utilizando um dos contêineres da estrutura, como TensorFlow, PyTorch ou MXNet, o contêiner espera que sua estrutura TAR seja a seguinte:
      • TensorFlow
        

        model.tar.gz/
        |--[model_version_number]/
        |--variables
        |--saved_model.pb
        code/
        |--inference.py
        |--requirements.txt

      • PyTorch
        

        model.tar.gz/
        |- model.pth
        |- code/
        |- inference.py
        |- requirements.txt # only for versions 1.3.1 and higher

      • MXNet
        

        model.tar.gz/
        |- model-symbol.json
        |- model-shapes.json
        |- model-0000.params
        |- code/
            |- inference.py
            |- requirements.txt # only for versions 1.6.0 and higher

      • SklearnName
        

        model.tar.gz/
        |- model.joblib
        | code/ 
        |- inference.py

    • Ao utilizar uma imagem do Framework, podemos fornecer um script de ponto de entrada personalizado, onde podemos implementar nosso próprio pré e pós-processamento. No nosso caso, o script de inferência é empacotado em model.tar.gz no diretório /code.

• • Configuração de endpoint
    • Contém as informações de infraestrutura necessárias para implantar o modelo SageMaker no endpoint.
    • Por exemplo, o modelo SageMaker que criamos é especificado aqui, bem como o tipo de instância e a contagem inicial de instâncias.

Estruturas e BYOC

• • Recuperando imagens do SageMaker
    • Esta parte nem sempre é necessária e é abstraída pelo SageMaker Python SDK por meio de estimadores. No entanto, se desejar recuperar uma imagem gerenciada pelo SageMaker para estendê-la, você poderá obter as imagens que estão disponíveis por meio do SDK. A seguir está um exemplo de recuperação de uma imagem TF 2.2 para inferência.

      import sagemaker
      tf_image = sagemaker.image_uris.retreive(framework="tensorflow", region="us-east-1",
      image_scope = "inference", version = "2.2", instance_type = "ml.c5.xlarge)
      print(tf_image)

  • Quadros
    • Caso você queira implantar um modelo de estrutura, como TensorFlow, PyTorch ou MXNet, tudo o que você precisa são os artefatos do modelo.
    • Consulte a documentação para implementar modelos diretamente de artefatos de modelo para TensorFlow, PyTorchou MXNet.

• • Escolhendo entre 1P e BYOC
    • O SageMaker SDK também abstrai o tratamento da imagem, como você viu na seção anterior de Frameworks. Possui estimadores prontos para Sklearn, TensorFlow e PyTorch que selecionam automaticamente a imagem para você com base na versão que você selecionou. Então você pode passar um script de treinamento/inferência através Modo de script nesses estimadores.

      from sagemaker.pytorch import PyTorch #PyTorch Estimator within SageMaker SDK
      estimator_parameters = {"entry_point": "train_deploy_pytorch_without_dependencies.py",
      "source_dir": "pytorch_script","instance_type": train_instance_type,
      "instance_count": 1,"hyperparameters": hyperparameters,
      "role": role,"base_job_name": "pytorch-model","framework_version": "1.5",
      "py_version": "py3",}
      
      ## Model Training
      estimator = PyTorch(**estimator_parameters)estimator.fit(inputs)
      
      ## Deploy Trained model
      pytorch_predictor = estimator.deploy(initial_instance_count=1, instance_type="ml.m5.xlarge", endpoint_name=pytorch_endpoint_name)

    • Nem todos os pacotes e imagens são suportados pelo SageMaker e neste caso você deve traga seu próprio contêiner (BYOC). Isso significa construir um Dockerfile que configurará o ambiente adequado para o atendimento do seu modelo. Um exemplo disso é o módulo Spacy NLP, e não há contêineres SageMaker gerenciados para esta estrutura. Portanto, você deve fornecer um Dockerfile que instale o Spacy. Dentro do contêiner você também monta seus scripts de inferência de modelo. Vamos discutir rapidamente os componentes que você fornece no formato Traga seu próprio contêiner, pois eles permanecem consistentes na maioria dos exemplos.
      • “nginx.conf“ é o arquivo de configuração do front-end nginx. Você não terá que editar este arquivo, a menos que queira ajustar essas partes.
      • “preditor.py“ é o programa que realmente implementa o servidor web Flask e o código do modelo para sua aplicação. Você pode ter mais arquivos ou funções Python em seu contêiner que podem ser chamados neste arquivo.
      • "servir" é o programa iniciado quando o contêiner é iniciado para hospedagem. Ele simplesmente inicia o servidor gunicorn, que executa várias instâncias do aplicativo Flask definido em preditor.py. Assim como o nginx.conf, você não precisa editar este arquivo, a menos que haja ajustes adicionais que você gostaria de realizar.
      • "trem" é o programa invocado quando o contêiner é executado para treinamento. Você modificará este programa para implementar seu algoritmo de treinamento. Se você estiver trazendo um modelo ou estrutura pré-treinado como o Spacy, não precisará deste arquivo.
      • “wsgi.py“ é um pequeno wrapper usado para invocar o aplicativo Flask. Você deve ser capaz de usar este arquivo como está, a menos que tenha alterado o nome do seu arquivo preditor.py. Nesse caso, certifique-se de que os mapas sejam mapeados corretamente aqui.

• • Script de inferência personalizado
    • Os contêineres do SageMaker Framework oferecem flexibilidade para lidar com o pré/pós-processamento da solicitação e o carregamento do modelo usando um ponto de entrada personalizado script/inference.py.
    • Consulte a documentação para criar um script inference.py personalizado para TensorFlow, PyTorch e MXNet.
  • Contêiner personalizado

Diferentes maneiras de interagir com SageMaker Endpoints

Há muitas opções para usar o SageMaker programaticamente para que você possa chamar seus modelos implantados para obter inferência. O Interface de linha de comando da AWS (AWS CLI), API REST, Formação da Nuvem AWS, Kit de desenvolvimento de nuvem AWS (AWS CDK) e AWS SDKs são ferramentas comuns oferecidas pela AWS e amplamente suportadas por outros serviços da AWS. Para o SageMaker, também temos um SDK SageMaker Python. Agora, vamos comparar as diferentes opções para criar, invocar e gerenciar SageMaker Endpoints.

Além de CLI do SageMaker, há duas maneiras de interagir programaticamente com Endpoints no SageMaker por meio dos SDKs. Vejamos algumas diferenças entre SDK Python do SageMaker e SDK do Python Boto3:

1. SDK “Python” do SageMaker de alto nível – Este SDK é uma biblioteca de código aberto que fornece abstração de nível superior especificamente destinada para chamar APIs do SageMaker programaticamente usando Python. A parte boa deste SDK é que é muito fácil chamar APIs do sagemaker, muito trabalho pesado já foi feito, como chamar as APIs no modo síncrono/assíncrono (ajuda a evitar pesquisas), esquema de solicitação/resposta mais simples, muito menos código e muito mais código mais simples. O SageMaker Python SDK fornece várias abstrações de alto nível para trabalhar com o SageMaker. O pacote visa simplificar diferentes processos de ML no SageMaker.
2. AWS SDK de baixo nível (Boto3 SDK) – Este SDK funciona em nível inferior, permitindo que o usuário escolha entre as linguagens de programação suportadas e chame qualquer serviço da AWS programaticamente. Isso não é específico apenas do SageMaker, mas pode ser usado em geral para todos os serviços AWS. Os SDKs da AWS de baixo nível estão disponíveis em várias linguagens de programação, como .NET, Python, Java, Node.js, etc. Um dos SDKs populares usados ​​é o boto3 python SDK, que é popular na comunidade de cientistas de dados para ML. A parte boa deste SDK é que ele é muito leve e está disponível por padrão instalado em AWS Lambda Tempo de execução. Além disso, você pode usar este SDK para interagir com qualquer serviço AWS fora do SageMaker.

Ambos os SDKs podem ser utilizados para as mesmas tarefas, mas em alguns casos é mais intuitivo usar um mais do que o outro. O SageMaker Python SDK é recomendado para testes fáceis, enquanto o AWS SDK/Boto3 é recomendado para casos de uso de produção para melhor controle do desempenho. Por exemplo, o SageMaker como serviço fornece imagens pré-construídas e mantidas para estruturas populares, como Sklearn, PyTorch e TensorFlow. Pode ser particularmente útil usar o SageMaker SDK para recuperar imagens de aprendizagem profunda, treinar modelos usando Estimadorese implante facilmente o modelo usando uma simples chamada de API. Um exemplo para mostrar isso em ação pode ser encontrado SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

Por outro lado, às vezes você tem modelos pré-treinados ou estruturas diferentes que pode estar usando. Isso requer mais personalização e o SageMaker SDK nem sempre oferece isso. Temos três etapas importantes e chamadas de API boto3 correspondentes que precisamos executar para implantar um endpoint: Criação de Modelo, Criação de configuração de endpoint e Criação de endpoint. As duas primeiras entidades foram abstraídas com o SageMaker SDK com nossas estruturas suportadas, mas vemos esses detalhes com o Boto3 SDK. Um exemplo extenso para mostrar as etapas envolvidas no uso de um SDK Boto3 para criar e gerenciar um endpoint pode ser encontrado SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

Considerações sobre hospedagem SageMaker

O SageMaker Real-Time Inference tem duas otimizações principais que você pode considerar: 1/ Otimização de desempenho e 2/ Otimização de custos. Vejamos primeiro Otimização de performance, como quando lidamos com cargas de trabalho sensíveis à latência, cada milissegundo é crucial. Existem diferentes botões que você pode ajustar para otimizar sua latência e rendimento. No nível da instância, você pode usar Recomendador de inferência, nossa ferramenta integrada de teste de carga, para ajudar você a selecionar o tipo de instância correto e a contagem para sua carga de trabalho. Utilizar a combinação adequada de computação ajudará você tanto no desempenho quanto no custo. Você também pode ajustar no nível do contêiner e da estrutura.
As perguntas que você deve fazer a si mesmo incluem:

1. Qual estrutura você está usando?
2. Existem variáveis ​​de ambiente que você pode ajustar em seu contêiner?

Um exemplo disso é maximizar Desempenho do TensorFlow com contêineres SageMaker. Outro exemplo de otimizações no nível do contêiner é utilizando gRPC em vez de REST atrás do seu endpoint. Por último, você também pode otimizar no nível do script. Seu código de inferência está demorando mais em determinados blocos? Cronometrar cada linha do seu script o ajudará a capturar quaisquer gargalos no seu código.

Existem três maneiras de olhar melhorando a utilização do seu endpoint em tempo real:

1. Endpoints multimodelos (MME)
   • Você pode hospedar milhares de modelos em um único endpoint. Isso é perfeito para casos de uso em que você não precisa de um endpoint dedicado para cada um de seus modelos. O MME funciona melhor quando os modelos têm tamanho e latência semelhantes e pertencem à mesma estrutura de ML. Normalmente, eles podem ser usados ​​quando você não precisa chamar o mesmo modelo o tempo todo. Você pode carregar dinamicamente o respectivo modelo no SageMaker Endpoint para atender sua solicitação. Um exemplo que mostra o MME em ação pode ser encontrado SUA PARTICIPAÇÃO FAZ A DIFERENÇA. Se você quiser saber mais sobre as diferentes advertências e práticas recomendadas para hospedar modelos no MME, consulte a postagem SUA PARTICIPAÇÃO FAZ A DIFERENÇA.
2. Terminais de vários contêineres (MCE)
   • Em vez de utilizar vários endpoints para hospedar vários contêineres, você pode hospedar até 15 contêineres em um único endpoint. Cada um desses contêineres pode ser invocado diretamente. Portanto, você pode hospedar modelos diferentes de estruturas diferentes, tudo em um único endpoint. Esta opção é melhor quando os contêineres apresentam características de uso e desempenho semelhantes. Um exemplo que mostra o MCE pode ser encontrado SUA PARTICIPAÇÃO FAZ A DIFERENÇA. Se você quiser saber mais sobre as diferentes advertências e práticas recomendadas para hospedar modelos no MCE, consulte a postagem SUA PARTICIPAÇÃO FAZ A DIFERENÇA.
3. Pipeline de inferência serial (SIP)
   • Se você tiver um pipeline de etapas em sua lógica de inferência, poderá utilizar o Serial Inference Pipeline (SIP). O SIP permite encadear de 2 a 15 contêineres atrás de um único endpoint. O SIP funciona bem quando você tem etapas de pré-processamento e pós-processamento. Se você quiser saber mais sobre os padrões de design para pipelines de inferência serial, consulte a postagem SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

A segunda otimização principal a ter em mente é custo. A inferência em tempo real é uma das três opções na criação de endpoints SageMaker. Os SageMaker Endpoints estão em execução o tempo todo, a menos que sejam excluídos. Portanto, você deve procurar melhorar a utilização do endpoint, o que, por sua vez, oferece um custo-benefício.

SageMaker também oferece Planos de Poupança. Os Planos Poupança podem reduzir seus custos em até 64%. Este é um compromisso de 1 ou 3 anos com uma quantidade consistente de uso (US$/hora). Veja isso link Para maiores informações. E veja isso link para melhor otimizar custos para inferência no Amazon SageMaker.

Conclusão

Neste post, mostramos algumas das melhores práticas para escolher entre diferentes opções de modelo de hospedagem no SageMaker. Discutimos os requisitos do SageMaker Endpoint e também comparamos os requisitos e funcionalidades do Framework e BYOC. Além disso, falamos sobre as diferentes maneiras pelas quais você pode aproveitar os endpoints em tempo real para hospedar seus modelos de ML em produção. de forma econômica e com alto desempenho.

Veja o correspondente Repositório GitHub e experimente os exemplos.

---

Sobre os autores

Raghu Ramesha é arquiteto de soluções de ML da equipe do Amazon SageMaker Service. Ele se concentra em ajudar os clientes a criar, implantar e migrar cargas de trabalho de produção de ML para o SageMaker em escala. Ele é especializado em domínios de aprendizado de máquina, IA e visão computacional e possui mestrado em Ciência da Computação pela UT Dallas. Nos tempos livres gosta de viajar e fotografar.

Ram Vegiraju é um arquiteto de ML da equipe SageMaker Service. Ele se concentra em ajudar os clientes a criar e otimizar suas soluções de IA/ML no Amazon SageMaker. Nas horas vagas, adora viajar e escrever.

Marc Karp é um arquiteto de ML da equipe SageMaker Service. Ele se concentra em ajudar os clientes a projetar, implantar e gerenciar cargas de trabalho de ML em escala. Em seu tempo livre, ele gosta de viajar e explorar novos lugares.

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.

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.