Obtenez des performances à très grande échelle pour la diffusion de modèles à l'aide du serveur d'inférence NVIDIA Triton sur Amazon SageMaker

Les applications d'apprentissage automatique (ML) sont complexes à déployer et nécessitent souvent plusieurs modèles ML pour répondre à une seule requête d'inférence. Une demande typique peut circuler sur plusieurs modèles avec des étapes telles que le prétraitement, les transformations de données, la logique de sélection de modèle, l'agrégation de modèles et le post-traitement. Cela a conduit à l'évolution de modèles de conception courants tels que les pipelines d'inférence en série, les ensembles (regroupement de dispersion) et les flux de travail de logique métier, ce qui a permis de réaliser l'intégralité du flux de travail de la demande sous la forme d'un graphe acyclique dirigé (DAG). Cependant, à mesure que les flux de travail deviennent plus complexes, cela entraîne une augmentation des temps de réponse globaux, ou latence, de ces applications, ce qui à son tour a un impact sur l'expérience utilisateur globale. De plus, si ces composants sont hébergés sur des instances différentes, la latence réseau supplémentaire entre ces instances augmente la latence globale. Prenons un exemple de cas d'utilisation ML populaire pour un assistant virtuel dans le support client. Une demande typique peut devoir passer par plusieurs étapes impliquant la reconnaissance vocale, le traitement du langage naturel (NLP), le suivi de l'état du dialogue, la politique de dialogue, la génération de texte et enfin la synthèse vocale. De plus, pour rendre l'interaction de l'utilisateur plus personnalisée, vous pouvez également utiliser des modèles NLP de pointe basés sur des transformateurs, comme différentes versions de BERT, BARTet GPT. Le résultat final est de longs temps de réponse pour ces ensembles de modèles et une mauvaise expérience client.

Un modèle courant pour réduire les temps de réponse sans compromettre le débit global consiste à héberger ces modèles sur la même instance avec la logique métier légère qui y est intégrée. Ces modèles peuvent en outre être encapsulés dans un ou plusieurs conteneurs sur la même instance afin de fournir une isolation pour les processus en cours d'exécution et de maintenir une latence faible. De plus, la latence globale dépend également de la logique d'application d'inférence, des optimisations de modèle, de l'infrastructure sous-jacente (y compris le calcul, le stockage et la mise en réseau) et du serveur Web sous-jacent prenant les demandes d'inférence. Serveur d'inférence NVIDIA Triton est un logiciel de service d'inférence open source avec des fonctionnalités pour maximiser le débit et l'utilisation du matériel avec une latence d'inférence ultra-faible (un chiffre en millisecondes). Il prend largement en charge les frameworks ML (y compris TensorFlow, PyTorch, ONNX, XGBoost et NVIDIA TensorRT) et les backends d'infrastructure, y compris les GPU, les CPU et Inférence AWS. De plus, Triton Inference Server est intégré à Amazon Sage Maker, un service de ML de bout en bout entièrement géré, offrant des options d'inférence en temps réel, notamment unique ainsi que multi-modèle hébergement. Ces options d'inférence incluent l'hébergement de plusieurs modèles dans le même conteneur derrière un point de terminaison unique, et hébergement plusieurs modèles avec plusieurs conteneurs derrière un seul point final.

En novembre 2021, nous avons annoncé l'intégration de Triton Inference Server sur SageMaker. AWS a travaillé en étroite collaboration avec NVIDIA pour vous permettre de tirer le meilleur parti des deux mondes et de faciliter le déploiement de modèles avec Triton sur AWS.

Dans cet article, nous examinons les meilleures pratiques pour déployer des modèles de transformateur à grande échelle sur des GPU à l'aide de Triton Inference Server sur SageMaker. Tout d'abord, nous commençons par un résumé des concepts clés autour de la latence dans SageMaker et un aperçu des directives de réglage des performances. Ensuite, nous fournissons un aperçu de Triton et de ses fonctionnalités ainsi qu'un exemple de code pour le déploiement sur SageMaker. Enfin, nous effectuons des tests de charge en utilisant Recommandateur d'inférence SageMaker et résumer les idées et les conclusions des tests de charge d'un modèle de transformateur populaire fourni par Hugging Face.

Vous pouvez consulter le cahier nous avions l'habitude de déployer des modèles et d'effectuer des tests de charge par vous-même en utilisant le code sur GitHub.

Réglage et optimisation des performances pour le service de modèle sur SageMaker

Le réglage et l'optimisation des performances est un processus empirique impliquant souvent plusieurs itérations. Le nombre de paramètres à régler est combinatoire et l'ensemble des valeurs des paramètres de configuration ne sont pas indépendants les uns des autres. Divers facteurs affectent le réglage optimal des paramètres, notamment la taille de la charge utile, le type et le nombre de modèles ML dans le graphique de flux de demande d'inférence, le type de stockage, le type d'instance de calcul, l'infrastructure réseau, le code d'application, l'inférence servant l'exécution et la configuration du logiciel, etc.

Si vous utilisez SageMaker pour déployer des modèles ML, vous devez sélectionner une instance de calcul avec le meilleur rapport qualité-prix, ce qui est un processus compliqué et itératif qui peut prendre des semaines d'expérimentation. Tout d'abord, vous devez choisir le bon type d'instance ML parmi plus de 70 options en fonction des besoins en ressources de vos modèles et de la taille des données d'entrée. Ensuite, vous devez optimiser le modèle pour le type d'instance sélectionné. Enfin, vous devez provisionner et gérer l'infrastructure pour exécuter des tests de charge et ajuster la configuration du cloud pour des performances et des coûts optimaux. Tout cela peut retarder le déploiement du modèle et le délai de mise sur le marché. De plus, vous devez évaluer les compromis entre la latence, le débit et le coût pour sélectionner la configuration de déploiement optimale. Recommandateur d'inférence SageMaker sélectionne automatiquement le bon type d'instance de calcul, le nombre d'instances, les paramètres de conteneur et les optimisations de modèle pour l'inférence afin de maximiser le débit, de réduire la latence et de minimiser les coûts.

Inférence et latence en temps réel dans SageMaker

Inférence en temps réel SageMaker est idéal pour les charges de travail d'inférence où vous avez des exigences en temps réel, interactives et à faible latence. Il existe quatre métriques les plus couramment utilisées pour surveiller la latence des demandes d'inférence pour les points de terminaison d'inférence SageMaker

• Latence du conteneur – Le temps nécessaire pour envoyer la requête, extraire la réponse du conteneur du modèle et terminer l'inférence dans le conteneur. Cette métrique est disponible dans Amazon CloudWatch dans le cadre du Métriques d'appel publié par SageMaker.
• Latence du modèle – Le temps total pris par tous les conteneurs SageMaker dans un pipeline d'inférence. Cette métrique est disponible dans Amazon CloudWatch dans le cadre du Métriques d'appel publié par SageMaker.
• Latence de surcharge – Mesuré à partir du moment où SageMaker reçoit la demande jusqu'à ce qu'il renvoie une réponse au client, moins la latence du modèle. Cette métrique est disponible dans Amazon CloudWatch dans le cadre du Métriques d'appel publié par SageMaker.
• Latence de bout en bout – Mesuré à partir du moment où le client envoie la demande d'inférence jusqu'à ce qu'il reçoive une réponse. Les clients peuvent publier cela en tant que métrique personnalisée dans Amazon CloudWatch.

Le schéma suivant illustre ces composants.

La latence du conteneur dépend de plusieurs facteurs ; les suivants sont parmi les plus importants :

• Protocole sous-jacent (HTTP(s)/gRPC) utilisé pour communiquer avec le serveur d'inférence
• Frais généraux liés à la création de nouvelles connexions TLS
• Temps de désérialisation de la charge utile de requête/réponse
• Fonctionnalités de mise en file d'attente et de traitement par lots des demandes fournies par le serveur d'inférence sous-jacent
• Fonctionnalités de planification des demandes fournies par le serveur d'inférence sous-jacent
• Performances d'exécution sous-jacentes du serveur d'inférence
• Performances des bibliothèques de prétraitement et de post-traitement avant d'appeler la fonction de prédiction du modèle
• Performances sous-jacentes du backend du framework ML
• Optimisations spécifiques au modèle et au matériel

Dans cet article, nous nous concentrons principalement sur l'optimisation de la latence des conteneurs ainsi que sur le débit et le coût globaux. Plus précisément, nous explorons le réglage des performances de Triton Inference Server exécuté dans un conteneur SageMaker.

Présentation des cas d'utilisation

Le déploiement et la mise à l'échelle des modèles NLP dans une configuration de production peuvent être assez difficiles. Les modèles NLP sont souvent de très grande taille, contenant des millions de paramètres de modèle. Des configurations de modèle optimales sont nécessaires pour satisfaire les exigences strictes en matière de performances et d'évolutivité des applications NLP de niveau production.

Dans cet article, nous comparons un cas d'utilisation NLP à l'aide d'un point de terminaison en temps réel SageMaker basé sur un conteneur Triton Inference Server et recommandons des optimisations de réglage des performances pour notre cas d'utilisation ML. Nous utilisons un grand visage étreignant pré-formé basé sur un transformateur BERT grand sans boîtier modèle, qui compte environ 336 millions de paramètres de modèle. La phrase d'entrée utilisée pour le modèle de classification binaire est complétée et tronquée à une longueur de séquence d'entrée maximale de 512 jetons. Le test de charge d'inférence simule 500 appels par seconde (30,000 XNUMX appels maximum par minute) et ModelLatency de moins de 0.5 seconde (500 millisecondes).

Le tableau suivant résume notre configuration de référence.

Serveur d'inférence NVIDIA Triton

Triton Inference Server est spécialement conçu pour permettre un déploiement évolutif, rapide et facile des modèles en production. Triton prend en charge une variété de frameworks d'IA majeurs, notamment TensorFlow, TensorRT, PyTorch, XGBoost et ONNX. Avec le backend personnalisé Python et C++, vous pouvez également implémenter votre charge de travail d'inférence pour des cas d'utilisation plus personnalisés.

Plus important encore, Triton fournit une configuration simple basée sur la configuration pour héberger vos modèles, qui expose un riche ensemble de fonctionnalités d'optimisation des performances que vous pouvez utiliser avec peu d'effort de codage.

Triton augmente les performances d'inférence en maximisant l'utilisation du matériel avec différentes techniques d'optimisation (les exécutions de modèles simultanées et le traitement par lots dynamique sont les plus fréquemment utilisés). Trouver les configurations de modèles optimales à partir de diverses combinaisons de tailles de lots dynamiques et du nombre d'instances de modèles simultanées est essentiel pour obtenir une inférence en temps réel dans un service à faible coût à l'aide de Triton.

Mise en lots dynamique

De nombreux praticiens ont tendance à exécuter l'inférence de manière séquentielle lorsque le serveur est invoqué avec plusieurs requêtes indépendantes. Bien que plus facile à configurer, il n'est généralement pas recommandé d'utiliser la puissance de calcul du GPU. Pour résoudre ce problème, Triton propose les optimisations intégrées de traitement par lots dynamique pour combiner ces demandes d'inférence indépendantes côté serveur pour former dynamiquement un lot plus important afin d'augmenter le débit. Le schéma suivant illustre l'architecture d'exécution de Triton.

Dans l'architecture précédente, toutes les demandes atteignent d'abord le doseur dynamique avant d'entrer dans les files d'attente du planificateur de modèle réel pour attendre l'inférence. Vous pouvez définir vos tailles de lot préférées pour le traitement par lots dynamique à l'aide de la taille_de_lot_préférée paramètres dans la configuration du modèle. (Notez que la taille du lot formé doit être inférieure à la max_batch_size le modèle prend en charge.) Vous pouvez également configurer max_queue_delay_microsecondes pour spécifier le délai maximal dans le batcher pour attendre que d'autres demandes rejoignent le lot en fonction de vos exigences de latence.

L'extrait de code suivant montre comment vous pouvez ajouter cette fonctionnalité avec des fichiers de configuration de modèle pour définir le traitement par lot dynamique avec une taille de lot préférée de 16 pour l'inférence réelle. Avec les paramètres actuels, l'instance de modèle est invoquée instantanément lorsque la taille de lot préférée de 16 est atteinte ou que le délai de 100 microsecondes s'est écoulé depuis que la première demande a atteint le doseur dynamique.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Exécution simultanée de modèles

Une autre optimisation essentielle offerte dans Triton pour maximiser l'utilisation du matériel sans surcharge de latence supplémentaire est exécution simultanée du modèle, ce qui permet à plusieurs modèles ou à plusieurs copies du même modèle de s'exécuter en parallèle. Cette fonctionnalité permet à Triton de gérer simultanément plusieurs demandes d'inférence, ce qui augmente le débit d'inférence en utilisant une puissance de calcul autrement inactive sur le matériel.

La figure suivante montre comment vous pouvez facilement configurer différentes stratégies de déploiement de modèles avec seulement quelques lignes de modifications de code. Par exemple, la configuration A (à gauche) montre que vous pouvez diffuser la même configuration de deux instances de modèle de bert-large-uncased à tous les GPU disponibles. En revanche, la configuration B (milieu) montre une configuration différente pour le GPU 0 uniquement, sans modifier les politiques sur les autres GPU. Vous pouvez également déployer des instances de différents modèles sur un seul GPU, comme illustré dans la configuration C (à droite).

Dans la configuration C, l'instance de calcul peut gérer deux requêtes simultanées pour le modèle DistilGPT-2 et sept requêtes simultanées pour le modèle bert-large-uncased modèle en parallèle. Grâce à ces optimisations, les ressources matérielles peuvent être mieux utilisées pour le processus de service, améliorant ainsi le débit et offrant une meilleure rentabilité pour votre charge de travail.

TensorRT

NVIDIA TensorRT est un SDK pour l'inférence d'apprentissage en profondeur hautes performances qui fonctionne de manière transparente avec Triton. TensorRT, qui prend en charge tous les principaux frameworks d'apprentissage en profondeur, comprend un optimiseur d'inférence et un environnement d'exécution qui offre une faible latence et un débit élevé pour exécuter des inférences avec d'énormes volumes de données via de puissantes optimisations.

TensorRT optimise le graphique pour minimiser l'empreinte mémoire en libérant de la mémoire inutile et en la réutilisant efficacement. De plus, la compilation TensorRT fusionne les opérations éparses à l'intérieur du graphe du modèle pour former un noyau plus grand afin d'éviter la surcharge de plusieurs lancements de petits noyaux. Le réglage automatique du noyau vous aide à utiliser pleinement le matériel en sélectionnant le meilleur algorithme sur votre GPU cible. Les flux CUDA permettent aux modèles de s'exécuter en parallèle afin de maximiser l'utilisation de votre GPU pour de meilleures performances. Enfin, la technique de quantification peut utiliser pleinement l'accélération à précision mixte des cœurs Tensor pour exécuter le modèle dans FP32, TF32, FP16 et INT8 afin d'obtenir les meilleures performances d'inférence.

Hébergement Triton sur SageMaker

Hébergement SageMaker Les services sont l'ensemble des fonctionnalités de SageMaker visant à faciliter le déploiement et le service des modèles. Il fournit une variété d'options pour déployer, mettre à l'échelle automatiquement, surveiller et optimiser facilement des modèles ML adaptés à différents cas d'utilisation. Cela signifie que vous pouvez optimiser vos déploiements pour tous les types de modèles d'utilisation, des besoins persistants et toujours disponibles avec des options sans serveur aux besoins transitoires, de longue durée ou d'inférence par lots.

Sous l'égide de l'hébergement SageMaker se trouve également l'ensemble des conteneurs d'apprentissage en profondeur (DLC) d'inférence SageMaker, qui sont préemballés avec le logiciel de serveur de modèle approprié pour leur cadre ML pris en charge correspondant. Cela vous permet d'obtenir des performances d'inférence élevées sans configuration de serveur de modèle, ce qui est souvent l'aspect technique le plus complexe du déploiement de modèle et, en général, ne fait pas partie des compétences d'un scientifique des données. Le serveur d'inférence Triton est maintenant disponibles sur les conteneurs d'apprentissage en profondeur SageMaker (DLC).

Cette étendue d'options, la modularité et la facilité d'utilisation des différents frameworks de service font de SageMaker et de Triton une combinaison puissante.

Recommandateur d'inférence SageMaker pour comparer les résultats des tests

Nous utilisons SageMaker Inference Recommender pour exécuter nos expériences. SageMaker Inference Recommender propose deux types de tâches : par défaut et avancées, comme illustré dans le diagramme suivant.

La tâche par défaut fournit des recommandations sur les types d'instance avec uniquement le modèle et un exemple de charge utile à comparer. En plus des recommandations d'instance, le service propose également des paramètres d'exécution qui améliorent les performances. Les recommandations de la tâche par défaut visent à affiner la recherche d'instance. Dans certains cas, il peut s'agir de la famille d'instances, et dans d'autres, de types d'instances spécifiques. Les résultats de la tâche par défaut sont ensuite intégrés dans la tâche avancée.

Le travail avancé offre plus de contrôles pour affiner davantage les performances. Ces contrôles simulent l'environnement réel et les exigences de production. Parmi ces contrôles figure le modèle de trafic, qui vise à mettre en scène le modèle de demande pour les benchmarks. Vous pouvez définir des rampes ou un trafic régulier en utilisant les phases multiples du modèle de trafic. Par exemple, un InitialNumberOfUsers de 1, Taux d'apparition de 1, et Durée en secondes de 600 peut entraîner un trafic en rampe de 10 minutes avec 1 utilisateur simultané au début et 10 à la fin. De plus, sur les commandes, MaxInvocations ainsi que ModèleLatenceSeuils fixer le seuil de production, ainsi lorsque l'un des seuils est dépassé, le benchmarking s'arrête.

Enfin, mesures de recommandation incluent le débit, la latence au débit maximal et le coût par inférence, il est donc facile de les comparer.

Nous utilisons le type de travail avancé de SageMaker Inference Recommender pour exécuter nos expériences afin d'obtenir un contrôle supplémentaire sur les modèles de trafic et d'affiner la configuration du conteneur de service.

Configuration du test

Nous utilisons la fonction de test de charge personnalisé de SageMaker Inference Recommender pour comparer le profil NLP décrit dans notre cas d'utilisation. Nous définissons d'abord les prérequis suivants liés au modèle NLP et à la tâche ML. SageMaker Inference Recommender utilise ces informations pour extraire une image Docker d'inférence Registre des conteneurs élastiques Amazon (Amazon ECR) et enregistrez le modèle auprès du registre de modèles SageMaker.

Les configurations de modèles de trafic dans SageMaker Inference Recommender nous permettent de définir différentes phases pour le test de charge personnalisé. Le test de charge commence avec deux utilisateurs initiaux et génère deux nouveaux utilisateurs toutes les minutes, pour une durée totale de 25 minutes (1500 XNUMX secondes), comme indiqué dans le code suivant :

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

Nous expérimentons le test de charge du même modèle dans deux états différents. Les expériences basées sur PyTorch utilisent le modèle PyTorch standard non modifié. Pour les expériences basées sur TensorRT, nous convertissons au préalable le modèle PyTorch en un moteur TensorRT.

Nous appliquons différentes combinaisons des fonctionnalités d'optimisation des performances sur ces deux modèles, résumées dans le tableau suivant.

Résultats des tests et observations

Nous avons effectué des tests de charge pour trois types d'instances au sein de la même famille g4dn : ml.g4dn.xlarge, ml.g4dn.2xlarge et ml.g4dn.12xlarge. Tous les types d'instances g4dn ont accès aux GPU NVIDIA T4 Tensor Core et aux processeurs Intel Cascade Lake de 2e génération. La logique derrière le choix des types d'instance était d'avoir à la fois une instance avec un seul GPU disponible, ainsi qu'une instance avec accès à plusieurs GPU, quatre dans le cas de ml.g4dn.12xlarge. De plus, nous voulions tester si l'augmentation de la capacité du vCPU sur l'instance avec un seul GPU disponible entraînerait une amélioration du rapport coût-performance.

Passons d'abord en revue l'accélération de l'optimisation individuelle. Le graphique suivant montre que l'optimisation TensorRT offre une réduction de 50 % de la latence du modèle par rapport à la latence native dans PyTorch sur l'instance ml.g4dn.xlarge. Cette réduction de latence est multipliée par plus de trois sur les instances multi-GPU de ml.g4dn.12xlarge. Pendant ce temps, l'amélioration du débit de 30 % est cohérente sur les deux instances, ce qui se traduit par une meilleure rentabilité après l'application des optimisations TensorRT.

Avec le traitement par lots dynamique, nous pouvons obtenir une amélioration de près de 2 fois le débit en utilisant la même architecture matérielle sur toutes les instances d'expériences de ml.g4dn.xlarge, ml.g4dn.2xlarge et ml.g4dn.12xlarge sans augmentation notable de la latence.

De même, l'exécution simultanée de modèles nous permet d'obtenir une amélioration d'environ 3 à 4 fois du débit en maximisant l'utilisation du GPU sur l'instance ml.g4dn.xlarge et une amélioration d'environ 2 fois sur l'instance ml.g4dn.2xlarge et l'instance multi-GPU de ml. g4dn.12xlarge.. Cette augmentation du débit s'accompagne d'une latence sans surcoût.

Mieux encore, nous pouvons intégrer toutes ces optimisations pour fournir les meilleures performances en utilisant au maximum les ressources matérielles. Le tableau et les graphiques suivants résument les résultats que nous avons obtenus dans nos expériences.

[1] Le nombre d'instances initial dans le tableau ci-dessus correspond au nombre recommandé d'instances à utiliser avec une règle d'autoscaling pour maintenir les exigences de débit et de latence pour votre charge de travail.

[2] Le coût par heure dans le tableau ci-dessus est calculé en fonction du nombre d'instances initiales et du prix pour le type d'instance.

Les résultats valident principalement l'impact attendu des différentes fonctionnalités d'optimisation des performances :

• La compilation TensorRT a l'impact le plus fiable sur tous les types d'instances. Les transactions par minute et par instance ont augmenté de 30 à 35 %, avec une réduction constante des coûts d'environ 25 % par rapport aux performances du moteur TensorRT par rapport au BERT PyTorch par défaut (pt-base). Les performances accrues du moteur TensorRT sont aggravées et exploitées par les autres fonctionnalités de réglage des performances testées.
• Le chargement de deux modèles sur chaque GPU (groupe d'instances) doublait presque strictement toutes les métriques mesurées. Les appels par minute et par instance ont augmenté d'environ 80 à 90 %, ce qui a entraîné une réduction des coûts de l'ordre de 50 %, presque comme si nous utilisions deux GPU. En réalité, Amazon Cloud Watch Les métriques de nos expériences sur g4dn.2xlarge (à titre d'exemple) confirment que l'utilisation du CPU et du GPU double lorsque nous configurons un groupe d'instances de deux modèles.

Autres conseils d'optimisation des performances et des coûts

La référence présentée dans cet article vient d'effleurer la surface des fonctionnalités et techniques possibles que vous pouvez utiliser avec Triton pour améliorer les performances d'inférence. Celles-ci vont des techniques de prétraitement des données, telles que l'envoi de charges utiles binaires au serveur de modèle ou de charges utiles avec des lots plus importants, aux fonctionnalités natives de Triton, telles que les suivantes :

• Échauffement du modèle, qui empêche les demandes d'inférence initiales et lentes en initialisant complètement le modèle avant la réception de la première demande d'inférence.
• Cache de réponse, qui met en cache les requêtes répétées.
• Assemblage du modèle, qui vous permet de créer un pipeline d'un ou plusieurs modèles et la connexion des Tensors d'entrée et de sortie entre ces modèles. Cela ouvre la possibilité d'ajouter des étapes de prétraitement et de post-traitement, voire même une inférence avec d'autres modèles, au flux de traitement de chaque requête.

Nous prévoyons de tester et de comparer ces techniques et fonctionnalités dans un prochain article, alors restez à l'écoute !

Conclusion

Dans cet article, nous avons exploré quelques paramètres que vous pouvez utiliser pour optimiser les performances de votre point de terminaison en temps réel SageMaker pour servir les modèles PyTorch BERT avec Triton Inference Server. Nous avons utilisé SageMaker Inference Recommender pour effectuer les tests d'analyse comparative afin d'affiner ces paramètres. Ces paramètres sont essentiellement liés à l'optimisation du modèle basé sur TensorRT, entraînant une amélioration de près de 50 % des temps de réponse par rapport à la version non optimisée. De plus, l'exécution simultanée de modèles et l'utilisation du traitement par lots dynamique de Triton ont entraîné une augmentation de près de 70 % du débit. Le réglage fin de ces paramètres a également entraîné une réduction globale du coût d'inférence.

La meilleure façon de dériver les valeurs correctes est par l'expérimentation. Cependant, pour commencer à acquérir des connaissances empiriques sur le réglage et l'optimisation des performances, vous pouvez observer les combinaisons de différents paramètres liés à Triton et leur effet sur les performances des modèles ML et des instances SageMaker ML.

SageMaker fournit les outils permettant de supprimer les charges lourdes indifférenciées de chaque étape du cycle de vie ML, facilitant ainsi l'expérimentation et l'exploration rapides nécessaires pour optimiser pleinement vos déploiements de modèles.

Vous pouvez trouver le notebook utilisé pour les tests de charge et le déploiement sur GitHub. Vous pouvez mettre à jour les configurations Triton et les paramètres de l'outil de recommandation d'inférence SageMaker pour qu'ils correspondent le mieux à votre cas d'utilisation afin d'obtenir des charges de travail d'inférence rentables et performantes.

À propos des auteurs

Vikram Elango est un architecte de solutions spécialisé AI/ML chez Amazon Web Services, basé en Virginie aux États-Unis. Vikram aide les clients des secteurs de la finance et de l'assurance avec la conception et le leadership éclairé pour créer et déployer des applications d'apprentissage automatique à grande échelle. Il se concentre actuellement sur le traitement du langage naturel, l'IA responsable, l'optimisation des inférences et la mise à l'échelle du ML dans l'entreprise. Dans ses temps libres, il aime voyager, faire de la randonnée, cuisiner et camper avec sa famille.

Joao Moura est architecte de solutions spécialisées en IA/ML chez Amazon Web Services. Il se concentre principalement sur les cas d'utilisation du NLP et aide les clients à optimiser la formation et le déploiement du modèle Deep Learning. Il est également un partisan actif des solutions ML low-code et du matériel spécialisé ML.

Mohan Ghandi est ingénieur logiciel senior chez AWS. Il travaille chez AWS depuis 9 ans et a travaillé sur divers services AWS tels que EMR, EFA et RDS sur Outposts. Actuellement, il se concentre sur l'amélioration de l'expérience d'inférence SageMaker. Dans ses temps libres, il aime faire de la randonnée et courir des marathons.

Dhawal Patel est architecte principal en apprentissage machine chez AWS. Il a travaillé avec des organisations allant des grandes entreprises aux startups de taille moyenne sur des problèmes liés à l'informatique distribuée et à l'intelligence artificielle. Il se concentre sur l'apprentissage en profondeur, y compris les domaines de la PNL et de la vision par ordinateur. Il aide les clients à obtenir une inférence de modèle haute performance sur SageMaker.

Santosh Bhavani est Senior Technical Product Manager au sein de l'équipe Amazon SageMaker Elastic Inference. Il se concentre sur l'aide aux clients de SageMaker pour accélérer l'inférence et le déploiement de modèles. Dans ses temps libres, il aime voyager, jouer au tennis et boire beaucoup de thé Pu'er.

Jia Hong Liu est architecte de solutions au sein de l'équipe Cloud Service Provider de NVIDIA. Il aide les clients à adopter des solutions d'apprentissage automatique et d'IA qui tirent parti de l'informatique accélérée de NVIDIA pour relever leurs défis de formation et d'inférence. Dans ses temps libres, il aime l'origami, les projets de bricolage et jouer au basket.

• Coinsmart. Le meilleur échange Bitcoin et Crypto d'Europe.
• Platoblockchain. Intelligence métaverse Web3. Connaissance amplifiée. ACCÈS LIBRE.
• CryptoHawk. Radar Altcoins. Essai gratuit.
• Source : https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/