As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Servidores de modelo para implantação de modelos com Amazon SageMaker AI Você pode usar servidores de modelos populares TorchServe, como o DJL Serving e o Triton Inference Server, para implantar seus modelos na IA. SageMaker Os tópicos a seguir explicam como. **Topics** + [Implemente modelos com TorchServe](deploy-models-frameworks-torchserve.md) + [Implante modelos com o DJL Serving](deploy-models-frameworks-djl-serving.md) + [Implantação de modelo com o servidor de inferência Triton](deploy-models-frameworks-triton.md) # Implemente modelos com TorchServe TorchServe é o servidor modelo recomendado para PyTorch, pré-instalado no AWS PyTorch Deep Learning Container (DLC). Essa ferramenta poderosa oferece aos clientes uma experiência consistente e fácil de usar, oferecendo alto desempenho na implantação de vários PyTorch modelos em várias AWS instâncias, incluindo CPU, GPU, Neuron e Graviton, independentemente do tamanho ou da distribuição do modelo. TorchServe suporta uma ampla variedade de recursos avançados, incluindo batching dinâmico, microbatching, A/B teste de modelo, streaming, torch XLA, TensorRT, ONNX e IPEX. Além disso, ele integra perfeitamente a solução PyTorch de modelos grandes da PiPPy, permitindo o manuseio eficiente de modelos grandes. Além disso, TorchServe estende seu suporte a bibliotecas populares de código aberto DeepSpeed, como Accelerate, Fast Transformers e muito mais, expandindo ainda mais seus recursos. Com TorchServe, AWS os usuários podem implantar e servir seus PyTorch modelos com confiança, aproveitando sua versatilidade e desempenho otimizado em várias configurações de hardware e tipos de modelos. Para obter informações mais detalhadas, você pode consultar a [PyTorchdocumentação e assim TorchServe](https://pytorch.org/serve/) [por diante GitHub](https://github.com/pytorch/serve). A tabela a seguir lista os AWS PyTorch DLCs suportados pelo TorchServe. | Tipo de instância | SageMaker Link do PyTorch DLC AI | | --- | --- | | CPU e GPU | [SageMaker PyTorch Contêineres AI](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-containers-sm-support-only) | | Neuron | [PyTorch Recipientes de neurônios](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#neuron-containers) | | Graviton | [SageMaker Contêineres AI PyTorch Graviton](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-graviton-containers-sm-support-only) | As seções a seguir descrevem a configuração para criar e testar PyTorch DLCs na Amazon SageMaker AI. ## Introdução Para começar, verifique se você tem os seguintes pré-requisitos: 1. Certifique-se de ter acesso a uma AWS conta. Configure seu ambiente para que eles AWS CLI possam acessar sua conta por meio de um usuário AWS do IAM ou de uma função do IAM. Recomendamos usar uma perfil do IAM. Para fins de teste em sua conta pessoal, você pode anexar as seguintes políticas de permissões gerenciadas à perfil do IAM: + [AmazonEC2ContainerRegistryFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess) + [AmazonEC2FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) + [AWS ServiceRoleForAmazonEKSNodegroup](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSServiceRoleForAmazonEKSNodegroup) + [AmazonSageMakerFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSageMakerFullAccess) + [Amazon S3 FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) 1. Configure localmente suas dependências, conforme mostrado no seguinte exemplo: ``` from datetime import datetime import os import json import logging import time # External Dependencies: import boto3 from botocore.exceptions import ClientError import sagemaker sess = boto3.Session() sm = sess.client("sagemaker") region = sess.region_name account = boto3.client("sts").get_caller_identity().get("Account") smsess = sagemaker.Session(boto_session=sess) role = sagemaker.get_execution_role() # Configuration: bucket_name = smsess.default_bucket() prefix = "torchserve" output_path = f"s3://{bucket_name}/{prefix}/models" print(f"account={account}, region={region}, role={role}") ``` 1. Recupere a imagem do PyTorch DLC, conforme mostrado no exemplo a seguir. SageMaker As imagens de PyTorch DLC AI estão disponíveis em todas as AWS regiões. Para obter mais informações, consulte a [lista de imagens de contêineres do DLC](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-containers-sm-support-only). ``` baseimage = sagemaker.image_uris.retrieve( framework="pytorch", region="", py_version="py310", image_scope="inference", version="2.0.1", instance_type="ml.g4dn.16xlarge", ) ``` 1. Crie um espaço de trabalho local. ``` mkdir -p workspace/ ``` ## Adição de um pacote As seções a seguir descrevem como adicionar e pré-instalar pacotes em sua imagem de PyTorch DLC. **Casos de uso do BYOC** As etapas a seguir descrevem como adicionar um pacote à sua imagem de PyTorch DLC. Para obter mais informações sobre como personalizar seu contêiner, consulte [Criação de imagens personalizadas de contêineres de AWS Deep Learning](https://github.com/aws/deep-learning-containers/blob/master/custom_images.md). 1. Suponha que você queira adicionar um pacote à imagem docker do PyTorch DLC. Crie um Dockerfile no diretório `docker`, conforme mostrado no seguinte exemplo: ``` mkdir -p workspace/docker cat workspace/docker/Dockerfile ARG BASE_IMAGE FROM $BASE_IMAGE #Install any additional libraries RUN pip install transformers==4.28.1 ``` 1. Crie e publique a imagem do docker personalizada usando o script [ build\$1and\$1push.sh](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/workspace/docker/build_and_push.sh) a seguir. ``` # Download script build_and_push.sh to workspace/docker ls workspace/docker build_and_push.sh Dockerfile # Build and publish your docker image reponame = "torchserve" versiontag = "demo-0.1" ./build_and_push.sh {reponame} {versiontag} {baseimage} {region} {account} ``` **SageMaker Casos de uso de pré-instalação de IA** O exemplo a seguir mostra como pré-instalar um pacote em seu contêiner de PyTorch DLC. Você deve criar um arquivo `requirements.txt` localmente no diretório `workspace/code`. ``` mkdir -p workspace/code cat workspace/code/requirements.txt transformers==4.28.1 ``` ## Crie artefatos de TorchServe modelo No exemplo a seguir, usamos o [ modelo MNIST](https://github.com/pytorch/serve/tree/master/examples/image_classifier/mnist) pré-treinado. Criamos um diretório`workspace/mnist`, implementamos o [mnist\$1handler.py](https://github.com/pytorch/serve/blob/master/examples/image_classifier/mnist/mnist_handler.py) seguindo as [instruções de serviço TorchServe personalizadas](https://github.com/pytorch/serve/blob/master/docs/custom_service.md#custom-service) e [configuramos os parâmetros do modelo](https://github.com/pytorch/serve/tree/master/model-archiver#config-file) (como tamanho do lote e trabalhadores) em [model-config.yaml](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/workspace/lama/model-config.yaml). Em seguida, usamos a TorchServe ferramenta `torch-model-archiver` para criar os artefatos do modelo e fazer o upload para o Amazon S3. 1. Configure os parâmetros do modelo em `model-config.yaml`. ``` ls -al workspace/mnist-dev mnist.py mnist_handler.py mnist_cnn.pt model-config.yaml # config the model cat workspace/mnist-dev/model-config.yaml minWorkers: 1 maxWorkers: 1 batchSize: 4 maxBatchDelay: 200 responseTimeout: 300 ``` 1. Crie os artefatos do modelo usando o. [torch-model-archiver ](https://github.com/pytorch/serve/tree/master/model-archiver#torch-model-archiver-for-torchserve) ``` torch-model-archiver --model-name mnist --version 1.0 --model-file workspace/mnist-dev/mnist.py --serialized-file workspace/mnist-dev/mnist_cnn.pt --handler workspace/mnist-dev/mnist_handler.py --config-file workspace/mnist-dev/model-config.yaml --archive-format tgz ``` Se quiser pré-instalar um pacote, você deve incluir o diretório `code` no arquivo `tar.gz`. ``` cd workspace torch-model-archiver --model-name mnist --version 1.0 --model-file mnist-dev/mnist.py --serialized-file mnist-dev/mnist_cnn.pt --handler mnist-dev/mnist_handler.py --config-file mnist-dev/model-config.yaml --archive-format no-archive cd mnist mv ../code . tar cvzf mnist.tar.gz . ``` 1. Carregue `mnist.tar.gz` no Amazon S3. ``` # upload mnist.tar.gz to S3 output_path = f"s3://{bucket_name}/{prefix}/models" aws s3 cp mnist.tar.gz {output_path}/mnist.tar.gz ``` ## Usando endpoints de modelo único para implantar com TorchServe [O exemplo a seguir mostra como criar um [único modelo de endpoint de inferência em tempo real](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints-deployment.html), implantar o modelo no endpoint e testar o endpoint usando o Amazon Python SDK. SageMaker ](https://sagemaker.readthedocs.io/en/stable/) ``` from sagemaker.model import Model from sagemaker.predictor import Predictor # create the single model endpoint and deploy it on SageMaker AI model = Model(model_data = f'{output_path}/mnist.tar.gz', image_uri = baseimage, role = role, predictor_cls = Predictor, name = "mnist", sagemaker_session = smsess) endpoint_name = 'torchserve-endpoint-' + time.strftime("%Y-%m-%d-%H-%M-%S", time.gmtime()) predictor = model.deploy(instance_type='ml.g4dn.xlarge', initial_instance_count=1, endpoint_name = endpoint_name, serializer=JSONSerializer(), deserializer=JSONDeserializer()) # test the endpoint import random import numpy as np dummy_data = {"inputs": np.random.rand(16, 1, 28, 28).tolist()} res = predictor.predict(dummy_data) ``` ## Usando endpoints de vários modelos para implantar com TorchServe Os [endpoints multimodelo](https://docs.aws.amazon.com/sagemaker/latest/dg/multi-model-endpoints.html) são uma solução escalável e econômica para a hospedagem de um grande número de modelos atrás de um endpoint. Eles melhoram a utilização do endpoint compartilhando a mesma frota de recursos e contêiner de serviço para hospedar todos os seus modelos. Eles também reduzem a sobrecarga de implantação porque a SageMaker IA gerencia dinamicamente o carregamento e o descarregamento de modelos, além de escalar os recursos com base nos padrões de tráfego. Os endpoints multimodelo são particularmente úteis para modelos de aprendizado profundo e IA generativa que exigem poder computacional acelerado. Ao usar TorchServe endpoints multimodelo de SageMaker IA, você pode acelerar seu desenvolvimento usando uma pilha de serviços com a qual está familiarizado e, ao mesmo tempo, aproveitando o compartilhamento de recursos e o gerenciamento simplificado de modelos que os endpoints multimodelo de SageMaker IA fornecem. [O exemplo a seguir mostra como criar um endpoint multimodelo, implantar o modelo no endpoint e testar o endpoint usando o SDK do Amazon Python. SageMaker ](https://sagemaker.readthedocs.io/en/stable/) Detalhes adicionais podem ser encontrados neste [exemplo de caderno](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/torchserve_multi_model_endpoint.ipynb). ``` from sagemaker.multidatamodel import MultiDataModel from sagemaker.model import Model from sagemaker.predictor import Predictor # create the single model endpoint and deploy it on SageMaker AI model = Model(model_data = f'{output_path}/mnist.tar.gz', image_uri = baseimage, role = role, sagemaker_session = smsess) endpoint_name = 'torchserve-endpoint-' + time.strftime("%Y-%m-%d-%H-%M-%S", time.gmtime()) mme = MultiDataModel( name = endpoint_name, model_data_prefix = output_path, model = model, sagemaker_session = smsess) mme.deploy( initial_instance_count = 1, instance_type = "ml.g4dn.xlarge", serializer=sagemaker.serializers.JSONSerializer(), deserializer=sagemaker.deserializers.JSONDeserializer()) # list models list(mme.list_models()) # create mnist v2 model artifacts cp mnist.tar.gz mnistv2.tar.gz # add mnistv2 mme.add_model(mnistv2.tar.gz) # list models list(mme.list_models()) predictor = Predictor(endpoint_name=mme.endpoint_name, sagemaker_session=smsess) # test the endpoint import random import numpy as np dummy_data = {"inputs": np.random.rand(16, 1, 28, 28).tolist()} res = predictor.predict(date=dummy_data, target_model="mnist.tar.gz") ``` ## Metrics TorchServe suporta métricas no nível do sistema e no nível do modelo. Você pode ativar métricas no modo de formato de log ou no modo do Prometheus por meio da variável de ambiente `TS_METRICS_MODE`. Você pode usar o arquivo TorchServe central de configuração de métricas `metrics.yaml` para especificar os tipos de métricas a serem rastreadas, como contagem de solicitações, latência, uso de memória, utilização de GPU e muito mais. Ao consultar esse arquivo, você pode obter informações sobre o desempenho e a integridade dos modelos implantados e monitorar com eficácia o comportamento do TorchServe servidor em tempo real. Para obter informações mais detalhadas, consulte a [documentação de TorchServe métricas](https://github.com/pytorch/serve/blob/master/docs/metrics.md#torchserve-metrics). Você pode acessar registros de TorchServe métricas semelhantes ao formato StatsD por meio do filtro de CloudWatch registros da Amazon. Veja a seguir um exemplo de um registro de TorchServe métricas: ``` CPUUtilization.Percent:0.0|#Level:Host|#hostname:my_machine_name,timestamp:1682098185 DiskAvailable.Gigabytes:318.0416717529297|#Level:Host|#hostname:my_machine_name,timestamp:1682098185 ``` # Implante modelos com o DJL Serving O DJL Serving é uma solução de serviço de modelo autônoma universal de alto desempenho. Ele usa um modelo de aprendizado profundo, vários modelos ou fluxos de trabalho e os disponibiliza por meio de um endpoint HTTP. Você pode usar um dos DJL Serving [Deep Learning Containers (DLCs)](https://docs.aws.amazon.com/deep-learning-containers/latest/devguide/what-is-dlc.html) para servir seus modelos em AWS. Para saber mais sobre os tipos de modelos e estruturas compatíveis, consulte o repositório [DJL Serving GitHub.](https://github.com/deepjavalibrary/djl-serving) O DJL Serving oferece muitos atributos que ajudam você a implantar seus modelos com alto desempenho: + Facilidade de uso: O DJL Serving pode atender a maioria dos modelos sem nenhuma modificação. Você traz seus artefatos de modelo, e o DJL Serving pode hospedá-los. + Suporte a vários dispositivos e aceleradores — o DJL Serving oferece suporte à implantação de modelos em CPUs GPUs, e Inferentia. AWS + Desempenho: O DJL Serving executa inferência com muitos threads em uma única máquina virtual Java (JVM) para aumentar o throughput. + Lotes dinâmicos: O DJL Serving oferece apoio a lotes dinâmicos para aumentar o throughput. + Ajuste de escala automático: O DJL Serving escala automaticamente os operadores com base na carga de tráfego. + Suporte a vários mecanismos — o DJL Serving pode hospedar modelos simultaneamente usando estruturas diferentes (por exemplo, PyTorch e). TensorFlow + Modelos de conjunto e fluxo de trabalho — O DJL Serving oferece suporte à implantação de fluxos de trabalho complexos compostos por vários modelos e pode executar partes do fluxo de trabalho em e outras partes. CPUs GPUs Os modelos em um fluxo de trabalho podem aproveitar frameworks diferentes. As seções a seguir descrevem como configurar um endpoint com o DJL Serving on SageMaker AI. ## Introdução Para começar, verifique se você tem os seguintes pré-requisitos: 1. Certifique-se de ter acesso a uma AWS conta. Configure seu ambiente para que eles AWS CLI possam acessar sua conta por meio de um usuário AWS do IAM ou de uma função do IAM. Recomendamos usar uma perfil do IAM. Para fins de teste em sua conta pessoal, você pode anexar as seguintes políticas de permissões gerenciadas à perfil do IAM: + [AmazonEC2ContainerRegistryFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess) + [AmazonEC2FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) + [AmazonSageMakerFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSageMakerFullAccess) + [Amazon S3 FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) 1. Verifique se o cliente [docker](https://docs.docker.com/get-docker/) está configurado em seu sistema. 1. Faça login no Amazon Elastic Container Registry e defina as seguintes variáveis de ambiente: ``` export ACCOUNT_ID= export REGION= aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com ``` 1. Extraia a imagem do docker. ``` docker pull 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118 ``` Para ver todas as imagens de contêiner disponíveis do DJL Serving, consulte os [contêineres de inferência de modelos grandes](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#large-model-inference-containers) e os [contêineres de inferência de CPU do DJL Serving](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#djl-cpu-full-inference-containers). Ao escolher uma imagem das tabelas nos links anteriores, substitua a AWS região na coluna URL de exemplo pela região em que você está. Eles DLCs estão disponíveis nas regiões listadas na tabela na parte superior da página [Available Deep Learning Containers Images](https://github.com/aws/deep-learning-containers/blob/master/available_images.md). ## Personalize seu contêiner Você pode adicionar pacotes às imagens base do DLC para personalizar seu contêiner. Suponha que você queira adicionar um pacote à imagem do docker `763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118`. Você deve criar um dockerfile com a imagem desejada como imagem base, adicionar os pacotes necessários e enviar a imagem para o Amazon ECR. Para adicionar um pacote, conclua as seguintes etapas: 1. Especifique as instruções para executar as bibliotecas ou pacotes desejados no dockerfile da imagem base. ``` FROM 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118 ## add custom packages/libraries RUN git clone https://github.com/awslabs/amazon-sagemaker-examples ``` 1. Crie a imagem do Docker do seu dockerfile. Especifique seu repositório do Amazon ECR, o nome da imagem base e uma tag para a imagem. Se você não tiver um repositório do Amazon ECR, consulte [ Uso do Amazon ECR com a AWS CLI](https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html) no *Guia do usuário do Amazon ECR* para obter instruções sobre como criar um. ``` docker build -f Dockerfile -t /: ``` 1. Envie a imagem do Docker para o seu repositório do Amazon ECR. ``` docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/: ``` Agora você deve ter uma imagem de contêiner personalizada para poder usar para o serviço de modelo. Para ver mais exemplos de personalização do seu contêiner, consulte [Criação de imagens personalizadas de contêineres de AWS Deep Learning](https://github.com/aws/deep-learning-containers/blob/master/custom_images.md). ## Prepare seus artefatos de modelo Antes de implantar seu modelo na SageMaker IA, você deve empacotar os artefatos do modelo em um `.tar.gz` arquivo. O DJL Serving aceita os seguintes artefatos em seu arquivo: + Ponto de verificação do modelo: Arquivos que armazenam os pesos do modelo. + `serving.properties`: Um arquivo de configuração que você pode adicionar para cada modelo. Coloque `serving.properties` no mesmo diretório do seu arquivo do modelo. + `model.py`: O código do manipulador de inferência. Isso só é aplicável ao usar o modo Python. Se você não especificar `model.py`, djl-serving usará um dos manipuladores padrão. Veja a seguir um exemplo de uma estrutura de `model.tar.gz`. ``` - model_root_dir # root directory - serving.properties - model.py # your custom handler file for Python, if you choose not to use the default handlers provided by DJL Serving - model binary files # used for Java mode, or if you don't want to use option.model_id and option.s3_url for Python mode ``` O DJL Serving oferece apoio a mecanismos do Java baseados em mecanismos do DJL ou Python. Nem todos os artefatos anteriores são necessários; os artefatos necessários variam de acordo com o modo escolhido. Por exemplo, no modo Python, você só precisa especificar `option.model_id` no arquivo `serving.properties`; você não precisa especificar o ponto de verificação do modelo dentro dos contêineres para LMI. No modo Java, é necessário empacotar o ponto de verificação do modelo. Para obter mais detalhes sobre como configurar `serving.properties` e operar com mecanismos diferentes, consulte [Modos de operação do DJL Serving](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md). ## Use endpoints de modelo único para implantar com o DJL Serving Depois de preparar seus artefatos de modelo, você pode implantar seu modelo em um endpoint de SageMaker IA. Esta seção descreve como implantar um modelo único em um endpoint com o DJL Serving. Se você estiver implantando vários modelos, pule esta seção e acesse [Use endpoints multimodelo para implantar com o DJL Serving](#deploy-models-frameworks-djl-mme). O exemplo a seguir mostra um método para criar um objeto de modelo usando o SDK do Amazon SageMaker Python. Você precisará especificar os seguintes campos: + `image_uri`: Você pode recuperar uma das imagens base do DJL Serving, conforme mostrado neste exemplo, ou pode especificar uma imagem do Docker personalizada do seu repositório Amazon ECR, se tiver seguido as instruções em [Personalize seu contêiner](#deploy-models-frameworks-djl-byoc). + `model_s3_url`: Isso deve ser um URI do Amazon S3 que aponta para seu arquivo `.tar.gz`. + `model_name`: Especifique um nome para o objeto do modelo. ``` import boto3 import sagemaker from sagemaker.model import Model from sagemaker import image_uris, get_execution_role aws_region = "aws-region" sagemaker_session = sagemaker.Session(boto_session=boto3.Session(region_name=aws_region)) role = get_execution_role() def create_model(model_name, model_s3_url): # Get the DJL DeepSpeed image uri image_uri = image_uris.retrieve( framework="djl-deepspeed", region=sagemaker_session.boto_session.region_name, version="0.20.0" ) model = Model( image_uri=image_uri, model_data=model_s3_url, role=role, name=model_name, sagemaker_session=sagemaker_session, ) return model ``` ## Use endpoints multimodelo para implantar com o DJL Serving Se você quiser implantar vários modelos em um endpoint, a SageMaker IA oferece endpoints multimodelo, que são uma solução escalável e econômica para a implantação de um grande número de modelos. O DJL Serving também oferece apoio para o carregamento de vários modelos simultaneamente e a execução de inferência em cada um dos modelos simultaneamente. Os contêineres do DJL Serving aderem aos contratos de endpoints multimodelo de SageMaker IA e podem ser usados para implantar endpoints multimodelo. Cada artefato de modelo individual precisa ser empacotado da mesma forma descrita na seção anterior [Prepare seus artefatos de modelo](#deploy-models-frameworks-djl-artifacts). Você pode definir as configurações específicas do modelo no arquivo `serving.properties` e o código do manipulador de inferência específico do modelo em `model.py`. Para um endpoint multimodelo, os modelos precisam ser organizados da seguinte maneira: ``` root_dir |-- model_1.tar.gz |-- model_2.tar.gz |-- model_3.tar.gz . . . ``` O Amazon SageMaker Python SDK usa o [MultiDataModel](https://sagemaker.readthedocs.io/en/stable/api/inference/multi_data_model.html)objeto para instanciar um endpoint multimodelo. O URI do Amazon S3 para o diretório raiz deve ser passado como o argumento `model_data_prefix` para o construtor `MultiDataModel`. O DJL Serving também fornece vários parâmetros de configuração para gerenciar os requisitos de memória do modelo, como `required_memory_mb` e `reserved_memory_mb`, que podem ser configurados para cada modelo no arquivo [serving.properties](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md#servingproperties). Esses parâmetros são úteis para lidar com erros de falta de memória com mais facilidade. Para todos os parâmetros configuráveis, consulte [OutofMemory manipulação em djl-serving](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/out_of_memory_management.md). O atributo de ajuste de escala automático do DJL Serving facilita a garantia de que os modelos sejam escalados adequadamente para o tráfego de entrada. Por padrão, o DJL Serving determina o número máximo de operadores para um modelo que pode ser compatível com base no hardware disponível (como núcleos de CPU ou dispositivos de GPU). Você pode definir limites inferiores e superiores para cada modelo para garantir que um nível mínimo de tráfego sempre possa ser atendido, e que um único modelo não consuma todos os recursos disponíveis. Você pode definir as seguintes propriedades no arquivo [serving.properties](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md#servingproperties): + `gpu.minWorkers`: Número mínimo de trabalhadores para GPUs. + `gpu.maxWorkers`: Número máximo de trabalhadores para GPUs. + `cpu.minWorkers`: Número mínimo de trabalhadores para CPUs. + `cpu.maxWorkers`: Número máximo de trabalhadores para CPUs. [Para ver um end-to-end exemplo de como implantar um endpoint multimodelo na SageMaker IA usando um contêiner DJL Serving, consulte o exemplo de notebook Multi-Model-Inference-Demo.ipynb.](https://github.com/deepjavalibrary/djl-demo/blob/master/aws/sagemaker/Multi-Model-Inference-Demo.ipynb) # Implantação de modelo com o servidor de inferência Triton O [servidor de inferência Triton](https://github.com/triton-inference-server/server) é um software de serviço de inferência de código aberto que simplifica a inferência de IA. Com o Triton, você pode implantar qualquer modelo criado com várias estruturas de aprendizado profundo e de aprendizado de máquina, incluindo TensorRT,,, PyTorch ONNX, OpenVINO TensorFlow, Python, RAPIDS FIL e muito mais. Os contêineres SageMaker AI Triton ajudam você a implantar o Triton Inference Server na plataforma SageMaker AI Hosting para oferecer modelos treinados em produção. Ele suporta os diferentes modos em que a SageMaker IA opera. Para obter uma lista dos contêineres do Triton Inference Server disponíveis na SageMaker IA, consulte Contêineres de [inferência NVIDIA Triton (somente suporte para SM](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#nvidia-triton-inference-containers-sm-support-only)). Para exemplos de end-to-end notebooks, recomendamos dar uma olhada no [amazon-sagemaker-examples repositório.](https://github.com/aws/amazon-sagemaker-examples/tree/main/sagemaker-triton) ## Modos de hospedagem Os seguintes modos de hospedagem de SageMaker IA são compatíveis com os contêineres Triton: + Endpoints de modelo único + Esse é o modo de operação padrão da SageMaker IA. Nesse modo, o contêiner do Triton pode carregar um modelo único ou um modelo único de conjunto. + O nome do modelo deve ser passado como uma propriedade do ambiente de contêiner, que faz parte da chamada da API de `CreateModel` SageMaker IA. A variável de ambiente usada para passar o nome do modelo é `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME`. + Endpoints de modelo único com conjunto + O servidor de inferência Triton é compatível com um *conjunto*, que é um pipeline ou um DAG (gráfico acíclico direcionado) de modelos. Embora um conjunto seja tecnicamente composto por vários modelos, no modo de endpoint de modelo único padrão, a SageMaker IA pode tratar o *conjunto adequado* (o metamodelo que representa o pipeline) como o modelo principal a ser carregado e, posteriormente, carregar os modelos associados. + O nome do modelo do conjunto propriamente dito deve ser usado para carregar o modelo. Ele deve ser passado como uma propriedade do ambiente do contêiner, que faz parte da chamada da `CreateModel` SageMaker API. A variável de ambiente usada para passar o nome do modelo é `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME`. + Endpoints multimodelo + Nesse modo, a SageMaker IA pode servir vários modelos em um único endpoint. Você pode usar esse modo especificando a variável de ambiente `‘MultiModel’: true` como uma propriedade do ambiente do contêiner, que faz parte da chamada da `CreateModel` SageMaker API. + Por padrão, nenhum modelo é carregado quando a instância é iniciada. Para executar uma solicitação de inferência em um modelo específico, especifique o `*.tar.gz` arquivo do modelo correspondente como um argumento para a `TargetModel` propriedade da chamada da `InvokeEndpoint` SageMaker API. + Endpoints multimodelo com conjunto + Nesse modo, a SageMaker IA funciona conforme descrito para endpoints de vários modelos. No entanto, o contêiner SageMaker AI Triton pode carregar vários modelos de conjunto, o que significa que vários pipelines de modelos podem ser executados na mesma instância. SageMaker A IA trata cada conjunto como um modelo, e o conjunto próprio de cada modelo pode ser invocado especificando o arquivo correspondente como o. `*.tar.gz` `TargetModel` + Para um melhor gerenciamento de memória durante a memória dinâmica `LOAD` e `UNLOAD`, recomendamos que você mantenha o tamanho do conjunto pequeno. ## Tipos de carga útil de inferência O Triton oferece aceita dois métodos de envio de uma carga útil de inferência pela rede: `json` e `binary+json` (ou json codificado em binário). A carga útil JSON em ambos os casos inclui o tipo de dados, a forma e o tensor real da solicitação de inferência. O tensor da solicitação deve ser um tensor binário. Com o formato `binary+json`, você deve especificar o tamanho dos metadados da solicitação no cabeçalho para permitir que o Triton analise corretamente a carga útil binária. No contêiner SageMaker AI Triton, isso é feito usando um `Content-Type` cabeçalho personalizado:`application/vnd.sagemaker-triton.binary+json;json-header-size={}`. Isso é diferente de usar o `Inference-Header-Content-Length` cabeçalho em um servidor de inferência Triton autônomo porque cabeçalhos personalizados não são permitidos na IA. SageMaker ## Uso de config.pbtxt para definir a configuração do modelo Para servidores de inferência Triton em SageMaker IA, cada modelo deve incluir um `config.pbtxt` arquivo que especifique, no mínimo, as seguintes configurações para o modelo: + `name`: Embora isso seja opcional para modelos executados fora da SageMaker IA, recomendamos que você sempre forneça um nome para os modelos a serem executados no Triton on SageMaker AI. + [`platform` e/ou `backend`](https://github.com/triton-inference-server/backend/blob/main/README.md#backends): Configurar um backend é essencial para especificar o tipo do modelo. Alguns backends têm classificação adicional, como `tensorflow_savedmodel` ou ` tensorflow_graphdef`. Essas opções podem ser especificadas como parte da chave `platform`, além da chave `backend`. Os backends mais comuns são `tensorrt`, `onnxruntime`, `tensorflow`, `pytorch`, `python`, `dali`, `fil` e `openvino`. + `input`: Especifique três atributos para a entrada: `name`, `data_type` e `dims` (a forma). + `output`: Especifique três atributos para a saída: `name`, `data_type` e `dims` (a forma). + `max_batch_size`: Defina o tamanho do lote para um valor maior ou igual a 1 que indica o tamanho máximo do lote que o Triton deve usar com o modelo. [Para obter mais detalhes sobre a configuração`config.pbtxt`, consulte o repositório do GitHub Triton.](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md) O Triton fornece várias configurações para ajustar o comportamento do modelo. Algumas das opções de configuração mais comuns e importantes são: + [https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md#instance-groups](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md#instance-groups): Os grupos de instâncias ajudam a especificar o número e a localização de um determinado modelo. Eles têm os atributos `count`, `kind` e `gpus` (usados quando `kind` é `KIND_GPU`). O atributo `count` é equivalente ao número de operadores. Para um serviço de modelo regular, cada operador tem a sua própria cópia do modelo. Da mesma forma, no Triton, `count` especifica o número de cópias do modelo por dispositivo. Por exemplo, se o tipo `instance_group` for `KIND_CPU`, a CPU terá `count` cópias do modelo. **nota** Em uma instância de GPU, a configuração `instance_group` se aplica a cada dispositivo de GPU. Por exemplo, `count` cópias do modelo são colocadas em cada dispositivo de GPU, a menos que você especifique explicitamente quais dispositivos de GPU devem carregar o modelo. + [https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md#dynamic-batcher](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md#dynamic-batcher) e [https://github.com/triton-inference-server/server/blob/main/docs/user_guide/architecture.md#stateful-models](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/architecture.md#stateful-models): O lote dinâmico é usado para modelos sem estado, e o lote de sequência é usado para modelos com estado (onde você deseja rotear uma solicitação para a mesma instância do modelo todas as vezes). Os agendadores de lotes habilitam uma fila por modelo, o que ajuda a aumentar o throughput, dependendo da configuração dos lotes. + [https://github.com/triton-inference-server/server/blob/main/docs/user_guide/architecture.md#ensemble-models](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/architecture.md#ensemble-models): Um modelo de conjunto representa um *pipeline* de um ou mais modelos e a conexão dos tensores de entrada e saída entre esses modelos. Ele pode ser configurado especificando `platform` como `ensemble`. A configuração do conjunto é apenas uma representação do pipeline do modelo. Na SageMaker IA, todos os modelos em um conjunto são tratados como dependentes do modelo de conjunto e são contados como um único modelo para métricas de SageMaker IA, como. `LoadedModelCount` ## Publicação de métricas padrão do Triton na Amazon CloudWatch O NVIDIA Triton Inference Container expõe métricas na porta 8002 (configurável) para os diferentes modelos e GPUs que são utilizadas no Triton Inference Server. Para obter detalhes completos das métricas padrão que estão disponíveis, consulte a GitHub página das métricas do [Triton Inference Server](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/metrics.md). Essas métricas estão no formato do Prometheus e podem ser copiadas usando uma configuração de extração do Prometheus. A partir da versão v23.07, o contêiner SageMaker AI Triton suporta a publicação dessas métricas na Amazon CloudWatch especificando algumas variáveis de ambiente. Para extrair as métricas do Prometheus, o contêiner AI SageMaker Triton usa o agente da Amazon. CloudWatch As variáveis de ambiente necessárias que você deve especificar para coletar métricas são as seguintes: | Variável de ambiente | Description | Valor de exemplo | | --- | --- | --- | | `SAGEMAKER_TRITON_ALLOW_METRICS` | Especifique esta opção para permitir que o Triton publique métricas em seu endpoint do Prometheus. | "true" | | `SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH` | Especifique essa opção para iniciar as pré-verificações necessárias para publicar métricas na Amazon CloudWatch. | "true" | | `SAGEMAKER_TRITON_CLOUDWATCH_LOG_GROUP` | Especifique esta opção para apontar para o grupo de logs no qual as métricas são gravadas. | "/aws/SageMaker AI/Endpoints/TritonMetrics/SageMakerTwoEnsemblesTest" | | `SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE` | Especifique esta opção para apontar para o namespace da métrica em que você deseja ver e plotar as métricas. | "/aws/SageMaker AI/Endpoints/TritonMetrics/SageMakerTwoEnsemblesPublicTest" | | `SAGEMAKER_TRITON_METRICS_PORT` | Especifique isto como 8002 ou qualquer outra porta. Se a SageMaker IA não tiver bloqueado a porta especificada, ela será usada. Caso contrário, outra porta não bloqueada será escolhida automaticamente. | "8002" | Ao publicar métricas com o Triton on SageMaker AI, tenha em mente as seguintes limitações: + Embora você possa gerar métricas personalizadas por meio do back-end C-API e Python (v23.05 em diante), elas atualmente não são suportadas para publicação na Amazon. CloudWatch + No modo de endpoints multimodelo (MME) de SageMaker IA, o Triton é executado em um ambiente que exige que o namespace do modelo seja ativado porque cada modelo (exceto os modelos de conjunto) é tratado como se estivesse em seu próprio repositório de modelos. No momento, isso cria uma limitação para as métricas. Quando o namespacing de modelo está ativado, o Triton não distingue as métricas entre dois modelos com o mesmo nome pertencentes a conjuntos diferentes. Como solução alternativa, verifique se cada modelo que está sendo implantado tem um nome exclusivo. Isso também facilita a consulta de suas métricas em CloudWatch. ## Variáveis de ambiente A tabela a seguir lista as variáveis de ambiente suportadas pelo Triton on SageMaker AI. | Variável de ambiente | Description | Tipo | Possíveis valores | | --- | --- | --- | --- | | `SAGEMAKER_MULTI_MODEL` | Permite que o Triton opere no modo de endpoints multimodelo SageMaker AI. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME` | Especifique o modelo a ser carregado no modo de modelo único SageMaker AI (padrão). Para o modo de conjunto, especifique o nome do conjunto propriamente dito. | String | **conforme especificado em config.pbtxt | | `SAGEMAKER_TRITON_PING_MODE` | `'ready'`é o modo padrão no modo de modelo único da SageMaker IA e `'live'` é o padrão no modo de endpoints multimodelo da SageMaker IA. | String | `ready`, `live` | | `SAGEMAKER_TRITON_DISABLE_MODEL_NAMESPACING` | No contêiner SageMaker AI Triton, isso é definido como `true` padrão. | Booleano | `true`, `false` | | `SAGEMAKER_BIND_TO_PORT` | Enquanto estiver na SageMaker IA, a porta padrão é 8080. Você pode personalizar para uma porta diferente em cenários de vários contêineres. | String | ** | | `SAGEMAKER_SAFE_PORT_RANGE` | Isso é definido pela plataforma de SageMaker IA ao usar o modo de vários contêineres. | String | **–** | | `SAGEMAKER_TRITON_ALLOW_GRPC` | Embora a SageMaker IA não ofereça suporte ao GRPC atualmente, se você estiver usando o Triton na frente de um proxy reverso personalizado, poderá optar por habilitar o GRPC. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_GRPC_PORT` | A porta padrão para o GRPC é 8001, mas você pode alterá-la. | String | ** | | `SAGEMAKER_TRITON_THREAD_COUNT` | Você pode definir o número de threads padrão do manipulador de solicitações HTTP. | String | ** | | `SAGEMAKER_TRITON_LOG_VERBOSE` | `true`por padrão no SageMaker AI, mas você pode desativar essa opção seletivamente. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_LOG_INFO` | `false`por padrão na SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_LOG_WARNING` | `false`por padrão na SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_LOG_ERROR` | `false`por padrão na SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_SHM_DEFAULT_BYTE_SIZE` | Especifique o tamanho de shm para o backend do Python, em bytes. O valor padrão é 16 MB, mas pode ser aumentado. | String | ** | | `SAGEMAKER_TRITON_SHM_GROWTH_BYTE_SIZE` | Especifique o tamanho de crescimento de shm para o backend do Python, em bytes. O valor padrão é 1 MB, mas pode ser aumentado para permitir maiores incrementos. | String | ** | | `SAGEMAKER_TRITON_TENSORFLOW_VERSION` | O valor padrão é `2`. O Triton não oferece mais compatibilidade com o Tensorflow 2 no Triton v23.04. É possível configurar essa variável para as versões anteriores. | String | ** | | `SAGEMAKER_TRITON_MODEL_LOAD_GPU_LIMIT` | Restrinja a porcentagem máxima de memória da GPU usada para carregamento do modelo, permitindo que o restante seja usado para as solicitações de inferência. | String | ** | | `SAGEMAKER_TRITON_ALLOW_METRICS` | `false`por padrão na SageMaker IA. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_METRICS_PORT` | A porta padrão é 8002. | String | ** | | `SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH` | `false`por padrão na SageMaker IA. Defina essa variável `true` para permitir o envio das métricas padrão do Triton para a Amazon. CloudWatch Se essa opção estiver ativada, você será responsável pelos CloudWatch custos quando as métricas forem publicadas em sua conta. | Booleano | `true`, `false` | | `SAGEMAKER_TRITON_CLOUDWATCH_LOG_GROUP` | Obrigatório se você ativou a publicação de métricas em CloudWatch. | String | ** | | `SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE` | Obrigatório se você ativou a publicação de métricas em CloudWatch. | String | ** | | `SAGEMAKER_TRITON_ADDITIONAL_ARGS` | Acrescenta quaisquer argumentos adicionais ao iniciar o servidor Triton. | String | ** |