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
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
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 estSAGEMAKER_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 estSAGEMAKER_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 laTargetModel
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.gz
archive correspondante en tant queTargetModel
. Pour une meilleure gestion de la mémoire pendant la
LOAD
et laUNLOAD
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-Length
en-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/oubackend
: 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
outensorflow_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 sonttensorrt
,onnxruntime
,tensorflow
,pytorch
,python
,dali
,fil
etopenvino
. -
input
: spécifiez trois attributs pour l'entrée :name
,data_type
etdims
(la forme). -
output
: spécifiez trois attributs pour la sortie :name
,data_type
etdims
(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
-
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
etgpus
(utilisés quandkind
estKIND_GPU
). L'attributcount
é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, lecount
spécifie le nombre de copies du modèle par appareil. Par exemple, si leinstance_group
type estKIND_CPU
, il CPU contient uncount
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
commeensemble
. 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
À 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 |
---|---|---|
|
Spécifiez cette option pour autoriser Triton à publier des métriques sur son point de terminaison Prometheus. |
"true" |
|
Spécifiez cette option pour démarrer les vérifications préalables nécessaires à la publication des statistiques sur Amazon CloudWatch. |
"true" |
|
Spécifiez cette option pour pointer vers le groupe de journaux dans lequel les métriques sont écrites. |
« /aws/ /Endpoints/SageMaker/TritonMetrics» SageMakerTwoEnsemblesTest |
|
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 |
|
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 |
---|---|---|---|
|
Permet à Triton de fonctionner en mode terminaux SageMaker multimodèles. |
Booléen |
|
|
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 |
|
|
|
Chaîne |
|
|
Dans le conteneur SageMaker Triton, cette valeur est définie |
Booléen |
|
|
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 |
|
|
Ceci est défini par la SageMaker plateforme lors de l'utilisation du mode multi-conteneurs. |
Chaîne |
|
|
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 |
|
|
Le port par défaut pour GRPC est 8001, mais vous pouvez le modifier. |
Chaîne |
|
|
Vous pouvez définir le nombre de threads du gestionnaire de HTTP demandes par défaut. |
Chaîne |
|
|
|
Booléen |
|
|
|
Booléen |
|
|
|
Booléen |
|
|
|
Booléen |
|
|
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 |
|
|
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 |
|
|
La valeur par défaut est |
Chaîne |
|
|
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 |
|
|
|
Booléen |
|
|
La valeur par défaut du port est 8002. |
Chaîne |
|
|
|
Booléen |
|
|
Obligatoire si vous avez activé la publication des statistiques sur CloudWatch. |
Chaîne |
|
|
Obligatoire si vous avez activé la publication des statistiques sur CloudWatch. |
Chaîne |
|
|
Ajoute des arguments supplémentaires lors du démarrage du serveur Triton. |
Chaîne |
|