Déploiement de modèles avec Triton Inference Server - Amazon SageMaker

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.

Déploiement de modèles avec Triton Inference Server

Le serveur d'inférence Triton 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 conçu avec plusieurs frameworks d'apprentissage profond et d'apprentissage automatique, notamment TensorRT TensorFlow, PyTorch,ONNX, OpenVINO, Python RAPIDSFIL, etc.

Les conteneurs SageMaker Triton vous aident à déployer le serveur d'inférence Triton sur la plateforme SageMaker d'hébergement pour servir des modèles entraînés en production. Il supporte les différents modes de SageMaker fonctionnement. Pour obtenir la liste des conteneurs Triton Inference Server disponibles sur SageMaker, consultez NVIDIATriton Inference Containers (support SM uniquement).

Pour des exemples de end-to-end blocs-notes, nous vous recommandons de consulter le amazon-sagemaker-examples référentiel.

Modes d'hébergement

Les modes SageMaker d'hébergement suivants sont pris en charge par les conteneurs Triton :

  • Points de terminaison à modèle unique

    • Il s'agit SageMaker du mode de fonctionnement par défaut. 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'CreateModel SageMakerAPIappel. 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 acyclique dirigé) de modèles. Alors qu'un ensemble comprend techniquement plusieurs modèles, dans le mode point de terminaison par défaut à modèle unique, il SageMaker 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'CreateModel SageMaker APIappel. La variable d'environnement utilisée pour transmettre le nom du modèle est SAGEMAKER_TRITON_DEFAULT_MODEL_NAME.

  • Points de terminaison multi-modèles

    • Dans ce mode, il SageMaker 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'CreateModel SageMaker APIappel.

    • 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'InvokeEndpoint SageMaker APIappel.

  • Points de terminaison multimodèles avec ensemble

    • Dans ce mode, SageMaker fonctionne comme décrit pour les points de terminaison multimodèles. Cependant, le conteneur SageMaker 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 traite chaque ensemble comme un seul modèle, et l'ensemble propre de chaque modèle peut être invoqué en spécifiant l'*.tar.gzarchive correspondante en tant queTargetModel.

    • 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 JSON charge utile 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 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-Lengthen-tête sur un serveur d'inférence Triton autonome, car les en-têtes personnalisés ne sont pas autorisés à entrer. SageMaker

Utilisation de config.pbtxt pour définir la configuration du modèle

Pour les serveurs d'inférence Triton SageMaker activés, 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 fonctionnant en dehors de SageMaker, nous vous recommandons de toujours donner un nom aux modèles à exécuter dans Triton on SageMaker.

  • platform et/ou backend : 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 configurationconfig.pbtxt, consultez le GitHub référentiel 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 :

  • 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 instance_group type estKIND_CPU, il CPU contient un count certain nombre de copies du modèle.

    Note

    Sur une GPU instance, la instance_group configuration s'applique par GPU appareil. Par exemple, count le nombre de copies du modèle est placé sur chaque GPU appareil, sauf si vous spécifiez explicitement quels GPU appareils doivent charger le modèle.

  • dynamic_batching et sequence_batching : 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.

  • ensemble : 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. Activé SageMaker, tous les modèles d'un ensemble sont traités comme des dépendants du modèle d'ensemble et sont comptés comme un modèle unique pour les SageMaker métriques, telles queLoadedModelCount.

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. 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 Triton prend en charge la publication de ces métriques sur Amazon CloudWatch en spécifiant quelques variables d'environnement. Afin de récupérer les métriques de Prometheus, le conteneur 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/ /Endpoints/SageMaker/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/ /Endpoints/SageMaker/TritonMetrics» SageMakerTwoEnsemblesPublicTest

SAGEMAKER_TRITON_METRICS_PORT

Spécifiez ce port comme 8002 ou tout autre port. S'il n' SageMaker 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 activé SageMaker, gardez à l'esprit les limites suivantes :

  • Bien que vous puissiez générer des métriques personnalisées via le backend C API et Python (versions 23.05 et ultérieures), celles-ci ne sont actuellement pas prises en charge pour la publication sur Amazon. CloudWatch

  • En mode endpoints SageMaker multimodèles (MME), 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.

Variable d'environnement Description Type Valeurs possibles

SAGEMAKER_MULTI_MODEL

Permet à Triton de fonctionner en mode terminaux SageMaker multimodèles.

Booléen

true, false

SAGEMAKER_TRITON_DEFAULT_MODEL_NAME

Spécifiez le modèle à charger en mode modèle SageMaker unique (par défaut). Pour le mode ensemble, spécifiez le nom de l'ensemble proprement dit.

Chaîne

<model_name> comme spécifié dans config.pbtxt

SAGEMAKER_TRITON_PING_MODE

'ready'est le mode par défaut dans SageMaker le mode modèle unique, et 'live' est le mode par défaut dans le mode points SageMaker de terminaison multimodèles.

Chaîne

ready, live

SAGEMAKER_TRITON_DISABLE_MODEL_NAMESPACING

Dans le conteneur SageMaker Triton, cette valeur est définie true par défaut.

Booléen

true, false

SAGEMAKER_BIND_TO_PORT

Lorsque cette option est activée SageMaker, le port par défaut est 8080. Vous pouvez le personnaliser pour un port différent dans les scénarios multi-conteneurs.

Chaîne

<port_number>

SAGEMAKER_SAFE_PORT_RANGE

Ceci est défini par la SageMaker plateforme lors de l'utilisation du mode multi-conteneurs.

Chaîne

<port_1><port_2>

SAGEMAKER_TRITON_ALLOW_GRPC

Bien que SageMaker cela ne soit pas compatible GRPC actuellement, si vous utilisez Triton devant un proxy inverse personnalisé, vous pouvez choisir de l'activerGRPC.

Booléen

true, false

SAGEMAKER_TRITON_GRPC_PORT

Le port par défaut pour GRPC est 8001, mais vous pouvez le modifier.

Chaîne

<port_number>

SAGEMAKER_TRITON_THREAD_COUNT

Vous pouvez définir le nombre de threads du gestionnaire de HTTP demandes par défaut.

Chaîne

<number>

SAGEMAKER_TRITON_LOG_VERBOSE

trueactivé par défaut SageMaker, mais vous pouvez désactiver cette option de manière sélective.

Booléen

true, false

SAGEMAKER_TRITON_LOG_INFO

falseactivé par défaut SageMaker.

Booléen

true, false

SAGEMAKER_TRITON_LOG_WARNING

falseactivé par défaut SageMaker.

Booléen

true, false

SAGEMAKER_TRITON_LOG_ERROR

falseactivé par défaut SageMaker.

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.

Chaîne

<number>

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.

Chaîne

<number>

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.

Chaîne

<number>

SAGEMAKER_TRITON_MODEL_LOAD_GPU_LIMIT

Limitez le pourcentage de GPU mémoire maximal utilisé pour le chargement du modèle, le reste pouvant être utilisé pour les demandes d'inférence.

Chaîne

<number>

SAGEMAKER_TRITON_ALLOW_METRICS

falseactivé par défaut SageMaker.

Booléen

true, false

SAGEMAKER_TRITON_METRICS_PORT

La valeur par défaut du port est 8002.

Chaîne

<number>

SAGEMAKER_TRITON_PUBLISH_METRICS_TO_CLOUDWATCH

falseactivé par défaut SageMaker. 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.

Chaîne

<cloudwatch_log_group_name>

SAGEMAKER_TRITON_CLOUDWATCH_METRIC_NAMESPACE

Obligatoire si vous avez activé la publication des statistiques sur CloudWatch.

Chaîne

<cloudwatch_metric_namespace>

SAGEMAKER_TRITON_ADDITIONAL_ARGS

Ajoute des arguments supplémentaires lors du démarrage du serveur Triton.

Chaîne

<additional_args>