Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Serveurs de modèles pour le déploiement de modèles avec Amazon SageMaker AI Vous pouvez utiliser des modèles de serveurs populaires TorchServe, tels que DJL Serving et Triton Inference Server, pour déployer vos modèles sur l'IA. SageMaker Les rubriques suivantes expliquent comment procéder. **Topics** + [Déployez des modèles avec TorchServe](deploy-models-frameworks-torchserve.md) + [Déploiement de modèles avec DJL Serving](deploy-models-frameworks-djl-serving.md) + [Déploiement de modèles avec Triton Inference Server](deploy-models-frameworks-triton.md) # Déployez des modèles avec TorchServe TorchServe est le modèle de serveur recommandé pour PyTorch, préinstallé dans le AWS PyTorch Deep Learning Container (DLC). Ce puissant outil offre aux clients une expérience cohérente et conviviale, offrant des performances élevées lors du déploiement de plusieurs PyTorch modèles sur différentes AWS instances, notamment le processeur, le GPU, le Neuron et le Graviton, quelle que soit la taille ou la distribution du modèle. TorchServe prend en charge un large éventail de fonctionnalités avancées, notamment le traitement par lots dynamiques, le microtraitement, les A/B tests de modèles, le streaming, Torch XLA, TensorRT, ONNX et IPEX. De plus, il intègre parfaitement PyTorch la solution Pi pour les grands modèlesPPy, permettant une manipulation efficace des grands modèles. En outre, il TorchServe étend son support aux bibliothèques open source populaires telles que Accelerate DeepSpeed, Fast Transformers, etc., étendant ainsi encore ses capacités. AWS Les utilisateurs peuvent ainsi déployer et servir leurs PyTorch modèles en toute confiance, en tirant parti de sa polyvalence et de ses performances optimisées pour différentes configurations matérielles et types de modèles. TorchServe [Pour des informations plus détaillées, vous pouvez consulter la [PyTorchdocumentation](https://pytorch.org/serve/) et TorchServe plus encore GitHub.](https://github.com/pytorch/serve) Le tableau suivant répertorie les solutions AWS PyTorch DLCs prises en charge par TorchServe. | Type d’instance | SageMaker Lien vers le PyTorch DLC AI | | --- | --- | | CPU et GPU | [SageMaker PyTorch Conteneurs AI](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-containers-sm-support-only) | | Neuron | [PyTorch Conteneurs Neuron](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#neuron-containers) | | Graviton | [SageMaker PyTorch Conteneurs AI Graviton](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#sagemaker-framework-graviton-containers-sm-support-only) | Les sections suivantes décrivent la configuration pour créer et tester PyTorch DLCs sur Amazon SageMaker AI. ## Prise en main Avant de démarrer, vérifiez que les conditions préalables suivantes sont respectées : 1. Assurez-vous d'avoir accès à un AWS compte. Configurez votre environnement de manière à ce qu'ils AWS CLI puissent accéder à votre compte via un utilisateur AWS IAM ou un rôle IAM. Nous vous recommandons d'utiliser un rôle IAM. À des fins de test dans votre compte personnel, vous pouvez associer les politiques d'autorisations gérées suivantes au rôle 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. Configurez vos dépendances de façon locale, comme indiqué dans l'exemple suivant : ``` 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. Récupérez l'image du PyTorch DLC, comme indiqué dans l'exemple suivant. SageMaker Les images du PyTorch DLC AI sont disponibles dans toutes les AWS régions. Pour plus d'informations, consultez la [liste des images des conteneurs 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. Créez un espace de travail local. ``` mkdir -p workspace/ ``` ## Ajout d'un package Les sections suivantes décrivent comment ajouter et préinstaller des packages à l'image de votre PyTorch DLC. **Cas d'utilisation BYOC** Les étapes suivantes expliquent comment ajouter un package à l'image de votre PyTorch DLC. Pour plus d'informations sur la personnalisation de votre conteneur, consultez la section [Création d'images personnalisées pour les AWS Deep Learning Containers](https://github.com/aws/deep-learning-containers/blob/master/custom_images.md). 1. Supposons que vous souhaitiez ajouter un package à l'image du docker du PyTorch DLC. Créez un Dockerfile dans le répertoire `docker`, comme indiqué dans l'exemple suivant : ``` 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. Créez et publiez l'image Docker personnalisée à l'aide du script [build\$1and\$1push.sh](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/workspace/docker/build_and_push.sh) suivant. ``` # 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 Cas d'utilisation de la préinstallation de l'IA** L'exemple suivant montre comment préinstaller un package dans votre conteneur de PyTorch DLC. Vous devez créer un fichier `requirements.txt` localement dans le répertoire `workspace/code`. ``` mkdir -p workspace/code cat workspace/code/requirements.txt transformers==4.28.1 ``` ## Création d'artefacts TorchServe de modèle Dans l'exemple suivant, nous utilisons le [modèle MNIST](https://github.com/pytorch/serve/tree/master/examples/image_classifier/mnist) pré-entraîné. Nous créons un répertoire`workspace/mnist`, implémentons [mnist\$1handler.py](https://github.com/pytorch/serve/blob/master/examples/image_classifier/mnist/mnist_handler.py) en suivant les [instructions de service TorchServe personnalisées](https://github.com/pytorch/serve/blob/master/docs/custom_service.md#custom-service) et [configurons les paramètres du modèle (tels que la](https://github.com/pytorch/serve/tree/master/model-archiver#config-file) taille du lot et les travailleurs) dans [model-config.yaml](https://github.com/aws/amazon-sagemaker-examples/blob/main/inference/torchserve/mme-gpu/workspace/lama/model-config.yaml). Ensuite, nous utilisons l' TorchServe outil `torch-model-archiver` pour créer les artefacts du modèle et les télécharger sur Amazon S3. 1. Configurez les paramètres du modèle dans `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. Créez les artefacts du modèle en utilisant [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 ``` Si vous souhaitez préinstaller un package, vous devez inclure le répertoire `code` dans le fichier `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. Charger `mnist.tar.gz` dans 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 ``` ## Utilisation de points de terminaison à modèle unique pour le déploiement avec TorchServe L'exemple suivant vous montre comment créer un point de [terminaison d'inférence en temps réel à modèle unique](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints-deployment.html), déployer le modèle sur le point de terminaison et tester le point de terminaison à l'aide du [SDK Amazon SageMaker Python](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) ``` ## Utilisation de points de terminaison multimodèles pour le déploiement avec TorchServe Les [points de terminaison multimodèles](https://docs.aws.amazon.com/sagemaker/latest/dg/multi-model-endpoints.html) offrent une solution évolutive et économique pour l'hébergement d'un grand nombre de modèles au-delà d'un point de terminaison. Ils améliorent l'utilisation des points de terminaison en partageant la même flotte de ressources et un conteneur de service pour héberger tous vos modèles. Ils réduisent également les frais de déploiement, car l' SageMaker IA gère les modèles de chargement et de déchargement de manière dynamique, ainsi que le dimensionnement des ressources en fonction des modèles de trafic. Les points de terminaison multimodèles sont particulièrement utiles pour le deep learning et les modèles d'IA générative qui nécessitent une puissance de calcul accélérée. En utilisant des points de terminaison multimodèles basés TorchServe sur l' SageMaker IA, vous pouvez accélérer votre développement en utilisant une pile de serveurs que vous connaissez bien, tout en tirant parti du partage des ressources et de la gestion simplifiée des modèles fournis par les points de terminaison multimodèles basés sur l' SageMaker IA. L'exemple suivant vous montre comment créer un point de terminaison multimodèle, déployer le modèle sur le point de terminaison et tester le point de terminaison à l'aide du [SDK Amazon SageMaker Python](https://sagemaker.readthedocs.io/en/stable/). Vous trouverez des informations supplémentaires dans cet [exemple de bloc-notes](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") ``` ## Métriques TorchServe prend en charge les métriques au niveau du système et au niveau du modèle. Vous pouvez activer les métriques en mode journal ou en mode Prometheus via la variable d'environnement `TS_METRICS_MODE`. Vous pouvez utiliser le fichier de configuration TorchServe central des métriques `metrics.yaml` pour spécifier les types de métriques à suivre, tels que le nombre de demandes, la latence, l'utilisation de la mémoire, l'utilisation du GPU, etc. En consultant ce fichier, vous pouvez obtenir des informations sur les performances et l'état des modèles déployés et surveiller efficacement le comportement TorchServe du serveur en temps réel. Pour des informations plus détaillées, consultez la [documentation sur TorchServe les métriques](https://github.com/pytorch/serve/blob/master/docs/metrics.md#torchserve-metrics). Vous pouvez accéder aux journaux de TorchServe mesures similaires au format StatsD via le filtre de CloudWatch journal Amazon. Voici un exemple de journal de TorchServe mesures : ``` CPUUtilization.Percent:0.0|#Level:Host|#hostname:my_machine_name,timestamp:1682098185 DiskAvailable.Gigabytes:318.0416717529297|#Level:Host|#hostname:my_machine_name,timestamp:1682098185 ``` # Déploiement de modèles avec DJL Serving DJL Serving est une solution de service de modèle autonome universelle à hautes performances. Elle utilise plusieurs modèles ou flux de travail de deep learning et les rend disponibles via un point de terminaison HTTP. Vous pouvez utiliser l'un des DJL Serving [Deep Learning Containers (DLCs)](https://docs.aws.amazon.com/deep-learning-containers/latest/devguide/what-is-dlc.html) pour y diffuser vos modèles. AWS Pour en savoir plus sur les types de modèles et les frameworks pris en charge, consultez le [ GitHubréférentiel DJL Serving](https://github.com/deepjavalibrary/djl-serving). DJL Serving propose de nombreuses fonctionnalités qui vous aident à déployer vos modèles avec des performances élevées : + Facilité d'utilisation : DJL Serving peut fonctionner avec la plupart des modèles sans aucune modification. Vous apportez les artefacts de votre modèle et DJL Serving peut les héberger. + Prise en charge de plusieurs appareils et accélérateurs : DJL Serving prend en charge le déploiement de modèles sur CPUs GPUs, et AWS Inferentia. + Performances : DJL Serving exécute une inférence multithreads sur une seule machine virtuelle Java (JVM) afin d'augmenter le débit. + Traitement par lots dynamique : DJL Serving prend en charge le traitement par lots dynamique pour augmenter le débit. + Mise à l'échelle automatique : DJL Serving met automatiquement à l'échelle les applications de travail en fonction de la charge de trafic. + Support multimoteur — DJL Serving peut héberger simultanément des modèles utilisant différents frameworks (par exemple, PyTorch et TensorFlow). + Modèles d'ensemble et de flux de travail : DJL Serving prend en charge le déploiement de flux de travail complexes composés de plusieurs modèles et peut exécuter des parties du flux de travail sur CPUs et d'autres parties sur GPUs. Les modèles d'un flux de travail peuvent exploiter différents frameworks. Les sections suivantes décrivent comment configurer un point de terminaison avec DJL Serving on SageMaker AI. ## Prise en main Avant de démarrer, vérifiez que les conditions préalables suivantes sont respectées : 1. Assurez-vous d'avoir accès à un AWS compte. Configurez votre environnement de manière à ce qu'ils AWS CLI puissent accéder à votre compte via un utilisateur AWS IAM ou un rôle IAM. Nous vous recommandons d'utiliser un rôle IAM. À des fins de test dans votre compte personnel, vous pouvez associer les politiques d'autorisations gérées suivantes au rôle 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. Assurez-vous que le client [docker](https://docs.docker.com/get-docker/) est configuré sur votre système. 1. Connectez-vous à Amazon Elastic Container Registry et définissez les variables d'environnement suivantes : ``` 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. Extrayez l'image Docker. ``` docker pull 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118 ``` Pour toutes les images de conteneurs DJL Serving disponibles, consultez les [conteneurs d'inférence de grands modèles](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#large-model-inference-containers) et les [conteneurs d'inférence de CPU DJL Serving](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#djl-cpu-full-inference-containers). Lorsque vous choisissez une image dans les tableaux des liens précédents, remplacez la AWS région dans la colonne d'exemple d'URL par la région dans laquelle vous vous trouvez. Elles DLCs sont disponibles dans les régions répertoriées dans le tableau en haut de la page [Available Deep Learning Containers Images](https://github.com/aws/deep-learning-containers/blob/master/available_images.md). ## Personnalisation de votre conteneur Vous pouvez ajouter des packages aux images DLC de base pour personnaliser votre conteneur. Supposons que vous souhaitiez ajouter un package à l'image Docker `763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.22.1-deepspeed0.9.2-cu118`. Vous devez créer un fichier Docker avec l'image souhaitée comme image de base, ajouter les packages requis et envoyer l'image vers Amazon ECR. Pour ajouter un package, exécutez les étapes suivantes : 1. Spécifiez les instructions pour exécuter les bibliothèques ou les packages souhaités dans le fichier Docker de l'image de 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. Créez l'image Docker à partir de votre fichier Docker. Spécifiez votre référentiel Amazon ECR, le nom de l'image de base et une balise pour l'image. Si vous ne possédez pas de référentiel Amazon ECR, consultez [Utilisation d'Amazon ECR avec l' AWS CLI](https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html) dans le *Guide de l'utilisateur Amazon ECR* pour savoir comment en créer un. ``` docker build -f Dockerfile -t /: ``` 1. Transmettez l'image Docker dans le référentiel Amazon ECR. ``` docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/: ``` Vous devriez maintenant disposer d'une image de conteneur personnalisée que vous pouvez utiliser pour le service de modèles. Pour d'autres exemples de personnalisation de votre conteneur, consultez [Building AWS Deep Learning Containers Custom Images](https://github.com/aws/deep-learning-containers/blob/master/custom_images.md). ## Préparation des artefacts de votre modèle Avant de déployer votre modèle sur l' SageMaker IA, vous devez empaqueter les artefacts de votre modèle dans un `.tar.gz` fichier. DJL Serving accepte les artefacts suivants dans vos archives : + Point de contrôle du modèle : fichiers qui stockent les poids de votre modèle. + `serving.properties` : fichier de configuration que vous pouvez ajouter pour chaque modèle. Placez `serving.properties` dans le même répertoire que votre fichier de modèle. + `model.py` : le code du gestionnaire d'inférence. Cela ne s'applique que lors de l'utilisation du mode Python. Si vous ne spécifiez pas `model.py`, djl-serving utilise l'un des gestionnaires par défaut. Voici un exemple de structure `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 ``` DJL Serving prend en charge les moteurs Java alimentés par des moteurs DJL ou Python. Les artefacts précédents ne sont pas tous obligatoires ; les artefacts requis varient en fonction du mode que vous choisissez. Par exemple, en mode Python, il suffit de spécifier `option.model_id` dans le fichier `serving.properties` ; il n'est pas nécessaire de spécifier le point de contrôle du modèle à l'intérieur des conteneurs LMI. En mode Java, vous devez empaqueter le point de contrôle du modèle. Pour plus de détails sur la configuration `serving.properties` et le fonctionnement de différents moteurs, consultez [Modes de fonctionnement de DJL Serving](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md) (langue française non garantie). ## Utilisez des points de terminaison à modèle unique pour le déploiement avec DJL Serving Après avoir préparé les artefacts de votre modèle, vous pouvez déployer votre modèle sur un point de terminaison d' SageMaker IA. Cette section explique comment déployer un modèle unique sur un point de terminaison avec DJL Serving. Si vous déployez plusieurs modèles, ignorez cette section et passez à [Utilisation de points de terminaison multimodèles pour le déploiement avec DJL Serving](#deploy-models-frameworks-djl-mme). L'exemple suivant montre une méthode pour créer un objet de modèle à l'aide du SDK Amazon SageMaker Python. Vous devez spécifier les champs suivants : + `image_uri` : vous pouvez soit récupérer l'une des images de base de DJL Serving, comme indiqué dans cet exemple, soit spécifier une image Docker personnalisée à partir de votre référentiel Amazon ECR, si vous avez suivi les instructions indiquées dans [Personnalisation de votre conteneur](#deploy-models-frameworks-djl-byoc). + `model_s3_url` : il doit s'agir d'un URI Amazon S3 pointant vers votre fichier `.tar.gz`. + `model_name` : spécifiez le nom de l'objet de modèle. ``` 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 ``` ## Utilisation de points de terminaison multimodèles pour le déploiement avec DJL Serving Si vous souhaitez déployer plusieurs modèles sur un point de terminaison, l' SageMaker IA propose des points de terminaison multimodèles, qui constituent une solution évolutive et rentable pour déployer un grand nombre de modèles. DJL Serving prend également en charge le chargement simultané de plusieurs modèles et l'exécution d'une inférence sur chacun des modèles simultanément. Les conteneurs DJL Serving respectent les contrats de points de terminaison multimodèles SageMaker AI et peuvent être utilisés pour déployer des points de terminaison multimodèles. Chaque modèle d'artefact individuel doit être empaqueté de la même manière que celle décrite dans la section [Préparation des artefacts de votre modèle](#deploy-models-frameworks-djl-artifacts) précédente. Vous pouvez définir des configurations spécifiques au modèle dans le fichier `serving.properties` et le code du gestionnaire d'inférence spécifique au modèle dans `model.py`. Pour un point de terminaison multimodèle, les modèles doivent être organisés de la manière suivante : ``` root_dir |-- model_1.tar.gz |-- model_2.tar.gz |-- model_3.tar.gz . . . ``` Le SDK Amazon SageMaker Python utilise l'[MultiDataModel](https://sagemaker.readthedocs.io/en/stable/api/inference/multi_data_model.html)objet pour instancier un point de terminaison multimodèle. L'URI Amazon S3 pour le répertoire racine doit être transmis en tant qu'argument `model_data_prefix` au constructeur `MultiDataModel`. DJL Serving fournit également plusieurs paramètres de configuration pour gérer les besoins en mémoire du modèle, tels que `required_memory_mb` et `reserved_memory_mb`, qui peuvent être configurés pour chaque modèle dans le fichier [serving.properties](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md#servingproperties). Ces paramètres sont utiles pour gérer plus facilement les erreurs liées au manque de mémoire. Pour tous les paramètres configurables, voir [OutofMemory gestion dans djl-serving](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/out_of_memory_management.md). La fonctionnalité de mise à l'échelle automatique de DJL Serving permet de garantir facilement que les modèles sont mis à l'échelle pour le trafic entrant. Par défaut, DJL Serving détermine le nombre maximum d'applications de travail pour un modèle pouvant être pris en charge en fonction du matériel disponible (tel que les cœurs de CPU ou les dispositifs GPU). Vous pouvez définir des limites inférieures et supérieures pour chaque modèle afin de garantir qu'un niveau de trafic minimum puisse toujours être atteint et qu'un seul modèle ne consomme pas toutes les ressources disponibles. Vous pouvez définir les propriétés suivantes dans le fichier [serving.properties](https://github.com/deepjavalibrary/djl-serving/blob/master/serving/docs/modes.md#servingproperties) : + `gpu.minWorkers`: Nombre minimum de travailleurs pour GPUs. + `gpu.maxWorkers`: Nombre maximum de travailleurs pour GPUs. + `cpu.minWorkers`: Nombre minimum de travailleurs pour CPUs. + `cpu.maxWorkers`: Nombre maximum de travailleurs pour CPUs. [Pour un end-to-end exemple de déploiement d'un point de terminaison multimodèle sur l' SageMaker IA à l'aide d'un conteneur de service DJL, consultez l'exemple de bloc-notes Multi-model-Inference-Demo.ipynb.](https://github.com/deepjavalibrary/djl-demo/blob/master/aws/sagemaker/Multi-Model-Inference-Demo.ipynb) # Déploiement de modèles avec Triton Inference Server [Triton Inference Server](https://github.com/triton-inference-server/server) est un logiciel de service d’inférence open source qui rationalise l’inférence par IA. Avec Triton, vous pouvez déployer n'importe quel modèle construit avec plusieurs frameworks d'apprentissage profond et d'apprentissage automatique, notamment TensorRT,, ONNX TensorFlow PyTorch, OpenVINO, Python, RAPIDS FIL, etc. Les conteneurs SageMaker AI Triton vous aident à déployer le serveur d'inférence Triton sur la plateforme d'hébergement SageMaker AI pour servir des modèles entraînés en production. Il prend en charge les différents modes de fonctionnement de SageMaker l'IA. Pour obtenir la liste des conteneurs Triton Inference Server disponibles sur SageMaker AI, consultez la section Conteneurs [NVIDIA Triton Inference (support SM uniquement](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#nvidia-triton-inference-containers-sm-support-only)). Pour des exemples de end-to-end blocs-notes, nous vous recommandons de consulter le [amazon-sagemaker-examples référentiel](https://github.com/aws/amazon-sagemaker-examples/tree/main/sagemaker-triton). ## Modes d'hébergement Les modes d'hébergement SageMaker AI suivants sont pris en charge par les conteneurs Triton : + Points de terminaison à modèle unique + Il s'agit du mode de fonctionnement par défaut de l' SageMaker IA. Dans ce mode, le conteneur Triton peut charger un seul modèle ou un seul modèle d'ensemble. + Le nom du modèle doit être transmis en tant que propriété de l'environnement du conteneur, qui fait partie de l'appel d'API `CreateModel` SageMaker AI. La variable d'environnement utilisée pour transmettre le nom du modèle est `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME`. + Points de terminaison à modèle unique avec ensemble + Le serveur d'inférence Triton prend en charge un *ensemble*, qui est un pipeline, ou un DAG (graphe orienté acyclique) de modèles. Alors qu'un ensemble comprend techniquement plusieurs modèles, dans le mode point final par défaut d'un modèle unique, l' SageMaker IA peut traiter l'*ensemble proprement dit* (le méta-modèle qui représente le pipeline) comme le modèle principal à charger, puis charger les modèles associés. + Le nom du modèle de l'ensemble proprement dit doit être utilisé pour charger le modèle. Il doit être transmis en tant que propriété de l'environnement du conteneur, qui fait partie de l'appel d'`CreateModel` SageMaker API. La variable d'environnement utilisée pour transmettre le nom du modèle est `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME`. + Points de terminaison multimodèles + Dans ce mode, SageMaker l'IA peut servir plusieurs modèles sur un seul terminal. Vous pouvez utiliser ce mode en spécifiant la variable d'environnement `‘MultiModel’: true` en tant que propriété de l'environnement du conteneur, qui fait partie de l'appel d'`CreateModel` SageMaker API. + Par défaut, aucun modèle n'est chargé au démarrage de l'instance. Pour exécuter une demande d'inférence sur un modèle particulier, spécifiez le `*.tar.gz` fichier du modèle correspondant comme argument de la `TargetModel` propriété de l'appel d'`InvokeEndpoint` SageMaker API. + Points de terminaison multimodèles avec ensemble + Dans ce mode, l' SageMaker IA fonctionne comme décrit pour les points de terminaison multimodèles. Cependant, le conteneur SageMaker AI Triton peut charger plusieurs modèles d'ensemble, ce qui signifie que plusieurs pipelines de modèles peuvent s'exécuter sur la même instance. SageMaker L'IA traite chaque ensemble comme un seul modèle, et l'ensemble propre à chaque modèle peut être invoqué en spécifiant l'`*.tar.gz`archive correspondante en tant que`TargetModel`. + Pour une meilleure gestion de la mémoire pendant la `LOAD` et la `UNLOAD` de la mémoire dynamique, nous vous recommandons de réduire la taille de l'ensemble. ## Types de charge utile d'inférence Triton prend en charge deux méthodes pour envoyer une charge utile d'inférence sur le réseau : `json` et `binary+json` (ou json codé en binaire). Dans les deux cas, la charge utile JSON inclut le type de données, la forme et le tenseur de demande d'inférence réel. Le tenseur de demande doit être un tenseur binaire. Avec le format `binary+json`, vous devez spécifier la longueur des métadonnées de la demande dans l'en-tête pour permettre à Triton d'analyser correctement la charge utile binaire. Dans le conteneur SageMaker AI Triton, cela se fait à l'aide d'un `Content-Type` en-tête personnalisé :`application/vnd.sagemaker-triton.binary+json;json-header-size={}`. Cela est différent de l'utilisation de l'`Inference-Header-Content-Length`en-tête sur un serveur d'inférence Triton autonome, car les en-têtes personnalisés ne sont pas autorisés dans AI. SageMaker ## Utilisation de config.pbtxt pour définir la configuration du modèle Pour les serveurs d'inférence Triton sur SageMaker IA, chaque modèle doit inclure un `config.pbtxt` fichier qui spécifie, au minimum, les configurations suivantes pour le modèle : + `name`: Bien que cela soit facultatif pour les modèles exécutés en dehors de l' SageMaker IA, nous vous recommandons de toujours donner un nom aux modèles à exécuter dans Triton on SageMaker AI. + [`platform` et/ou `backend`](https://github.com/triton-inference-server/backend/blob/main/README.md#backends) : la définition d'un backend est essentielle pour spécifier le type du modèle. Certains backends ont une classification supplémentaire, telle que `tensorflow_savedmodel` ou ` tensorflow_graphdef`. Ces options peuvent être spécifiées dans le cadre de la clé `platform`, en plus de la clé `backend`. Les backends les plus courants sont `tensorrt`, `onnxruntime`, `tensorflow`, `pytorch`, `python`, `dali`, `fil` et `openvino`. + `input` : spécifiez trois attributs pour l'entrée : `name`, `data_type` et `dims` (la forme). + `output` : spécifiez trois attributs pour la sortie : `name`, `data_type` et `dims` (la forme). + `max_batch_size` : définissez la taille du lot sur une valeur supérieure ou égale à 1 qui indique la taille de lot maximale que Triton doit utiliser avec le modèle. Pour plus de détails sur la configuration`config.pbtxt`, consultez le GitHub [référentiel](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/model_configuration.md) de Triton. Triton propose plusieurs configurations pour modifier le comportement du modèle. Certaines des options de configuration les plus courantes et les plus importantes sont les suivantes : + [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) : les groupes d'instances aident à spécifier le numéro et l'emplacement d'un modèle donné. Ils ont les attributs `count`, `kind` et `gpus` (utilisés quand `kind` est `KIND_GPU`). L'attribut `count` équivaut au nombre d'applications de travail. Pour le service des modèles réguliers, chaque application de travail a sa propre copie du modèle. De même, dans Triton, le `count` spécifie le nombre de copies du modèle par appareil. Par exemple, si le type `instance_group` est `KIND_CPU`, le CPU possède le nombre `count` de copies du modèle. **Note** Sur une instance de GPU, la configuration `instance_group` s'applique à chaque dispositif GPU. Par exemple, le nombre `count` de copies du modèle est placé sur chaque dispositif GPU, sauf si vous spécifiez explicitement quels dispositifs GPU doivent charger le modèle. + [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) et [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) : le traitement par lots dynamique est utilisé pour les modèles sans état et le traitement par lots de séquences est utilisé pour les modèles dynamiques (dans lesquels vous souhaitez acheminer une demande vers la même instance de modèle à chaque fois). Les planificateurs de traitement par lots activent une file d'attente par modèle, ce qui contribue à augmenter le débit, en fonction de la configuration du traitement par lots. + [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) : un modèle d'ensemble représente un *pipeline* d'un ou plusieurs modèles et la connexion des tenseurs d'entrée et de sortie entre eux. Il peut être configuré en spécifiant `platform` comme `ensemble`. La configuration de l'ensemble n'est qu'une représentation du pipeline du modèle. Sur l' SageMaker IA, tous les modèles d'un ensemble sont traités comme dépendants du modèle d'ensemble et sont considérés comme un modèle unique pour les métriques de l' SageMaker IA, telles que`LoadedModelCount`. ## Publication des métriques Triton par défaut sur Amazon CloudWatch Le conteneur d'inférence NVIDIA Triton expose les métriques sur le port 8002 (configurable) pour les différents modèles et GPUs qui sont utilisées dans le serveur d'inférence Triton. Pour plus de détails sur les métriques par défaut disponibles, consultez la GitHub page consacrée aux métriques du [serveur d'inférence Triton](https://github.com/triton-inference-server/server/blob/main/docs/user_guide/metrics.md). Ces métriques sont au format Prometheus et peuvent être récupérées à l'aide d'une configuration de récupération Prometheus. À partir de la version v23.07, le conteneur SageMaker AI Triton prend en charge la publication de ces métriques sur Amazon en CloudWatch spécifiant quelques variables d'environnement. Afin de récupérer les métriques Prometheus, le conteneur AI Triton utilise SageMaker l'agent Amazon. CloudWatch Les variables d'environnement requises que vous devez spécifier pour collecter des métriques sont les suivantes : | Variable d'environnement | Description | Exemple de valeur | | --- | --- | --- | | `SAGEMAKER_TRITON_ALLOW_METRICS` | Spécifiez cette option pour autoriser Triton à publier des métriques sur son point de terminaison Prometheus. | "true" | | `SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH` | Spécifiez cette option pour démarrer les vérifications préalables nécessaires à la publication des statistiques sur Amazon CloudWatch. | "true" | | `SAGEMAKER_TRITON_CLOUDWATCH_LOG_GROUP` | Spécifiez cette option pour pointer vers le groupe de journaux dans lequel les métriques sont écrites. | "/aws/SageMaker AI/Endpoints/TritonMetrics/SageMakerTwoEnsemblesTest" | | `SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE` | Spécifiez cette option pour pointer vers l'espace de noms des métriques dans lequel vous souhaitez voir et tracer les métriques. | "/aws/SageMaker AI/Endpoints/TritonMetrics/SageMakerTwoEnsemblesPublicTest" | | `SAGEMAKER_TRITON_METRICS_PORT` | Spécifiez ce port comme 8002 ou tout autre port. Si SageMaker l'IA n'a pas bloqué le port spécifié, il est utilisé. Dans le cas contraire, un autre port non bloqué est automatiquement sélectionné. | « 8002 » | Lorsque vous publiez des statistiques avec Triton on SageMaker AI, gardez à l'esprit les limites suivantes : + Bien que vous puissiez générer des métriques personnalisées via l'API C-API et le backend Python (versions 23.05 et ultérieures), celles-ci ne sont actuellement pas prises en charge pour la publication sur Amazon. CloudWatch + En mode points de terminaison multimodèles (MME) de l' SageMaker IA, Triton s'exécute dans un environnement qui nécessite l'activation de l'espacement des noms des modèles, car chaque modèle (à l'exception des modèles d'ensemble) est traité comme s'il se trouvait dans son propre référentiel de modèles. À l'heure actuelle, cela crée une limite pour les métriques. Lorsque l'espacement des noms des modèles est activé, Triton ne fait pas la distinction entre des métriques de deux modèles portant le même nom et appartenant à des ensembles différents. Pour contourner le problème, assurez-vous que chaque modèle déployé porte un nom unique. Cela facilite également la recherche de vos indicateurs CloudWatch. ## Variables d’environnement Le tableau suivant répertorie les variables d'environnement prises en charge pour Triton on SageMaker AI. | Variable d'environnement | Description | Type | Valeurs possibles | | --- | --- | --- | --- | | `SAGEMAKER_MULTI_MODEL` | Permet à Triton de fonctionner en mode points de terminaison multi-modèles basés sur l' SageMaker IA. | Booléen | `true`, `false` | | `SAGEMAKER_TRITON_DEFAULT_MODEL_NAME` | Spécifiez le modèle à charger en mode modèle unique SageMaker AI (par défaut). Pour le mode ensemble, spécifiez le nom de l'ensemble proprement dit. | String | **comme spécifié dans config.pbtxt | | `SAGEMAKER_TRITON_PING_MODE` | `'ready'`est le mode par défaut dans le mode modèle unique de l' SageMaker IA, et `'live'` c'est le mode par défaut dans le mode endpoints multimodèles de l' SageMaker IA. | String | `ready`, `live` | | `SAGEMAKER_TRITON_DISABLE_MODEL_NAMESPACING` | Dans le conteneur SageMaker AI Triton, ce paramètre est défini `true` par défaut. | Booléen | `true`, `false` | | `SAGEMAKER_BIND_TO_PORT` | Lorsque vous utilisez l' SageMaker IA, le port par défaut est 8080. Vous pouvez le personnaliser pour un port différent dans les scénarios multi-conteneurs. | String | ** | | `SAGEMAKER_SAFE_PORT_RANGE` | Ceci est défini par la plate-forme SageMaker AI lors de l'utilisation du mode multi-conteneurs. | String | **–** | | `SAGEMAKER_TRITON_ALLOW_GRPC` | Bien que l' SageMaker IA ne supporte pas le GRPC actuellement, si vous utilisez Triton devant un proxy inverse personnalisé, vous pouvez choisir d'activer le GRPC. | Booléen | `true`, `false` | | `SAGEMAKER_TRITON_GRPC_PORT` | Le port par défaut du GRPC est 8001, mais vous pouvez le modifier. | String | ** | | `SAGEMAKER_TRITON_THREAD_COUNT` | Vous pouvez définir le nombre de threads du gestionnaire de requêtes HTTP par défaut. | String | ** | | `SAGEMAKER_TRITON_LOG_VERBOSE` | `true`par défaut sur SageMaker AI, mais vous pouvez désactiver cette option de manière sélective. | Booléen | `true`, `false` | | `SAGEMAKER_TRITON_LOG_INFO` | `false`par défaut sur SageMaker AI. | Booléen | `true`, `false` | | `SAGEMAKER_TRITON_LOG_WARNING` | `false`par défaut sur SageMaker AI. | Booléen | `true`, `false` | | `SAGEMAKER_TRITON_LOG_ERROR` | `false`par défaut sur SageMaker AI. | Booléen | `true`, `false` | | `SAGEMAKER_TRITON_SHM_DEFAULT_BYTE_SIZE` | Spécifiez la taille du shm pour le backend Python, en octets. La valeur par défaut est de 16 Mo, mais elle peut être augmentée. | String | ** | | `SAGEMAKER_TRITON_SHM_GROWTH_BYTE_SIZE` | Spécifiez la taille de croissance du shm pour le backend Python, en octets. La valeur par défaut est de 1 Mo, mais elle peut être augmentée pour permettre des incréments plus importants. | String | ** | | `SAGEMAKER_TRITON_TENSORFLOW_VERSION` | La valeur par défaut est `2`. Triton ne prend plus en charge Tensorflow 2 depuis Triton v23.04. Vous pouvez configurer cette variable pour les versions précédentes. | String | ** | | `SAGEMAKER_TRITON_MODEL_LOAD_GPU_LIMIT` | Limitez le pourcentage de mémoire de GPU maximal utilisé pour le chargement du modèle, le reste pouvant être utilisé pour les demandes d'inférence. | String | ** | | `SAGEMAKER_TRITON_ALLOW_METRICS` | `false`par défaut sur SageMaker AI. | Booléen | `true`, `false` | | `SAGEMAKER_TRITON_METRICS_PORT` | La valeur par défaut du port est 8002. | String | ** | | `SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH` | `false`par défaut sur SageMaker AI. Définissez cette variable sur `true` pour autoriser le transfert des métriques par défaut de Triton vers Amazon CloudWatch. Si cette option est activée, vous êtes responsable des CloudWatch coûts lorsque les statistiques sont publiées sur votre compte. | Booléen | `true`, `false` | | `SAGEMAKER_TRITON_CLOUDWATCH_LOG_GROUP` | Obligatoire si vous avez activé la publication des statistiques sur CloudWatch. | String | ** | | `SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE` | Obligatoire si vous avez activé la publication des statistiques sur CloudWatch. | String | ** | | `SAGEMAKER_TRITON_ADDITIONAL_ARGS` | Ajoute des arguments supplémentaires lors du démarrage du serveur Triton. | String | ** |