Obtenez des performances élevées à grande échelle pour la diffusion de modèles à l'aide de points de terminaison multimodèles Amazon SageMaker avec GPU

Amazon Sage Maker points de terminaison multimodèle (MME) offrent un moyen évolutif et rentable de déployer un grand nombre de modèles d'apprentissage automatique (ML). Il vous donne la possibilité de déployer plusieurs modèles ML dans un seul conteneur de service derrière un seul point de terminaison. À partir de là, SageMaker gère le chargement et le déchargement des modèles et la mise à l'échelle des ressources en votre nom en fonction de vos modèles de trafic. Vous bénéficierez du partage et de la réutilisation des ressources d'hébergement et d'une réduction de la charge opérationnelle liée à la gestion d'une grande quantité de modèles.

En Novembre 2022, Les MME ont ajouté la prise en charge du GPUs, qui vous permet d'exécuter plusieurs modèles sur un seul périphérique GPU et de mettre à l'échelle des instances GPU derrière un seul point de terminaison. Cela répond à la forte demande MME pour les modèles de réseaux neuronaux profonds (DNN) qui bénéficient d'un calcul accéléré avec les GPU. Ceux-ci incluent la vision par ordinateur (CV), le traitement du langage naturel (NLP) et les modèles d'IA générative. Les raisons de la demande comprennent les suivantes :

• Les modèles DNN sont généralement de grande taille et de complexité et continuent de croître à un rythme rapide. En prenant les modèles NLP comme exemple, beaucoup d'entre eux dépassent des milliards de paramètres, ce qui nécessite que les GPU satisfassent aux exigences de faible latence et de débit élevé.
• Nous avons observé un besoin accru de personnalisation de ces modèles pour offrir des expériences hyper-personnalisées aux utilisateurs individuels. À mesure que la quantité de ces modèles augmente, il est nécessaire de trouver une solution plus simple pour déployer et opérationnaliser de nombreux modèles à grande échelle.
• Les instances GPU sont coûteuses et vous souhaitez réutiliser ces instances autant que possible pour maximiser l'utilisation du GPU et réduire les coûts d'exploitation.

Bien que toutes ces raisons indiquent que les MME avec GPU sont une option idéale pour les modèles DNN, il est conseillé d'effectuer des tests de charge pour trouver la bonne configuration de point de terminaison qui répond aux exigences de votre cas d'utilisation. De nombreux facteurs peuvent influencer les résultats des tests de charge, tels que le type d'instance, le nombre d'instances, la taille du modèle et l'architecture du modèle. De plus, les tests de charge peuvent aider à guider les stratégies de mise à l'échelle automatique en utilisant les bonnes métriques plutôt que des méthodes itératives d'essais et d'erreurs.

Pour ces raisons, nous avons rédigé cet article pour vous aider à effectuer des tests de charge appropriés sur les MME avec GPU et à trouver la meilleure configuration pour votre cas d'utilisation ML. Nous partageons nos résultats de test de charge pour certains des modèles DNN les plus populaires en NLP et CV hébergés à l'aide de MME sur différents types d'instances. Nous résumons les informations et les conclusions de nos résultats de test pour vous aider à prendre une décision éclairée sur la configuration de vos propres déploiements. En cours de route, nous partageons également notre approche recommandée pour effectuer des tests de charge pour les MME sur GPU. Les outils et la technique recommandés déterminent le nombre optimal de modèles pouvant être chargés par type d'instance et vous aident à obtenir le meilleur rapport qualité-prix.

Vue d'ensemble de la solution

Pour une introduction aux MME et aux MME avec GPU, reportez-vous à Créer un point de terminaison multimodèle et les Exécutez plusieurs modèles d'apprentissage en profondeur sur GPU avec les points de terminaison multimodèles d'Amazon SageMaker. Pour le contexte des tests de charge dans cet article, vous pouvez télécharger notre exemple de code à partir du GitHub repo pour reproduire les résultats ou l'utiliser comme modèle pour comparer vos propres modèles. Deux blocs-notes sont fournis dans le référentiel : un pour les modèles de CV de test de charge et un autre pour le NLP. Plusieurs modèles de tailles et d'architectures différentes ont été évalués sur différents types d'instances GPU : ml.g4dn.2xlarge, ml.g5.2xlarge et ml.p3.2xlarge. Cela devrait fournir une analyse transversale raisonnable des performances des métriques suivantes pour chaque instance et type de modèle :

• Nombre maximum de modèles pouvant être chargés dans la mémoire GPU
• Latence de réponse de bout en bout observée côté client pour chaque requête d'inférence
• Débit maximal de requêtes par seconde que le point de terminaison peut traiter sans erreur
• Nombre maximal d'utilisateurs actuels par instance avant qu'une demande ayant échoué ne soit observée

Le tableau suivant répertorie les modèles testés.

Le tableau suivant répertorie les instances de GPU testées.

Comme mentionné précédemment, le exemple de code peut être adopté pour d'autres modèles et types d'instances.

Notez que les MME ne prennent actuellement en charge que les instances GPU uniques. Pour la liste des types d'instances pris en charge, reportez-vous à Algorithmes, cadres et instances pris en charge.

La procédure de benchmarking comprend les étapes suivantes :

1. Récupérez un modèle pré-entraîné à partir d'un hub de modèles.
2. Préparez l'artefact de modèle pour servir sur les MME SageMaker (voir Exécutez plusieurs modèles d'apprentissage en profondeur sur GPU avec les points de terminaison multimodèles d'Amazon SageMaker pour plus de détails).
3. Déployez un MME SageMaker sur une instance GPU.
4. Déterminez le nombre maximal de modèles pouvant être chargés dans la mémoire GPU dans un seuil spécifié.
5. Utilisez le cadre de test de charge Locust pour simuler le trafic qui appelle de manière aléatoire des modèles chargés sur l'instance.
6. Recueillir des données et analyser les résultats.
7. Si vous le souhaitez, répétez les étapes 2 à 6 après avoir compilé le modèle dans TensorRT.

Les étapes 4 et 5 justifient un examen plus approfondi. Les modèles d'un MME GPU SageMaker sont chargés en mémoire de manière dynamique. Par conséquent, à l'étape 4, nous téléchargeons un artefact de modèle initial dans Service de stockage simple Amazon (Amazon S3) et appelez le modèle pour le charger en mémoire. Après l'invocation initiale, nous mesurons la quantité de mémoire GPU consommée, faisons une copie du modèle initial, invoquons la copie du modèle pour la charger en mémoire, et mesurons à nouveau la quantité totale de mémoire GPU consommée. Ce processus est répété jusqu'à ce qu'un seuil de pourcentage spécifié d'utilisation de la mémoire GPU soit atteint. Pour le benchmark, nous avons défini le seuil à 90 % afin de fournir une mémoire tampon raisonnable pour inférer sur des lots plus importants ou laisser de l'espace pour charger d'autres modèles moins fréquemment utilisés.

Simuler le trafic des utilisateurs

Après avoir déterminé le nombre de modèles, nous pouvons exécuter un test de charge en utilisant le Cadre de test de charge Locust. Le test de charge simule les demandes des utilisateurs à des modèles aléatoires et mesure automatiquement des métriques telles que la latence de réponse et le débit.

Locust prend en charge les formes de test de charge personnalisées qui vous permettent de définir des modèles de trafic personnalisés. La forme qui a été utilisée dans ce benchmark est illustrée dans le tableau suivant. Au cours des 30 premières secondes, le point de terminaison est préchauffé avec 10 utilisateurs simultanés. Après 30 secondes, de nouveaux utilisateurs apparaissent à un rythme de deux par seconde, atteignant 20 utilisateurs simultanés au bout de 40 secondes. Le point de terminaison est ensuite étalonné régulièrement avec 20 utilisateurs simultanés jusqu'à la marque des 60 secondes, moment auquel Locust recommence à augmenter les utilisateurs à raison de deux par seconde jusqu'à 40 utilisateurs simultanés. Ce schéma d'accélération et de tests réguliers est répété jusqu'à ce que le terminal atteigne 200 utilisateurs simultanés. En fonction de votre cas d'utilisation, vous souhaiterez peut-être ajuster la forme du test de charge dans locust_benchmark_sm.py pour refléter plus précisément vos modèles de trafic attendus. Par exemple, si vous avez l'intention d'héberger des modèles de langage plus volumineux, un test de charge avec 200 utilisateurs simultanés peut ne pas être réalisable pour un modèle hébergé sur une seule instance, et vous pouvez donc vouloir réduire le nombre d'utilisateurs ou augmenter le nombre d'instances. Vous pouvez également prolonger la durée du test de charge pour évaluer plus précisément la stabilité du point de terminaison sur une plus longue période.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

Notez que nous n'avons comparé le point de terminaison qu'avec des modèles homogènes fonctionnant tous sur des bases de service cohérentes à l'aide de PyTorch ou de TensorRT. En effet, les MME sont les mieux adaptés pour héberger de nombreux modèles présentant des caractéristiques similaires, telles que la consommation de mémoire et le temps de réponse. Les modèles d'analyse comparative fournis dans le GitHub repo peut toujours être utilisé pour déterminer si servir des modèles hétérogènes sur des MME donnerait les performances et la stabilité souhaitées.

Résultats de référence pour les modèles de CV

Utilisez le bloc-notes cv-benchmark.ipynb pour exécuter des tests de charge pour les modèles de vision par ordinateur. Vous pouvez ajuster les paramètres de nom de modèle et de type d'instance pré-formés aux tests de charge de performance sur différentes combinaisons de modèles et de types d'instance. Nous avons délibérément testé trois modèles de CV dans différentes gammes de taille, de la plus petite à la plus grande : resnet50 (25 millions), convnext_base (88M), et vit_large_patch16_224 (304M). Vous devrez peut-être vous adapter au code si vous choisissez un modèle en dehors de cette liste. en outre, l'ordinateur portable définit par défaut la forme de l'image d'entrée sur un tenseur d'image 224x224x3. N'oubliez pas d'ajuster la forme d'entrée en conséquence si vous avez besoin de comparer des modèles qui prennent une image de taille différente.

Après avoir parcouru l'intégralité du bloc-notes, vous obtiendrez plusieurs visualisations d'analyse des performances. Les deux premiers détaillent les performances du modèle en ce qui concerne l'augmentation des utilisateurs simultanés. Les figures suivantes sont des exemples de visualisations générées pour le ResNet50 modèle exécuté sur ml.g4dn.2xlarge, comparant PyTorch (à gauche) à TensorRT (à droite). Les graphiques linéaires supérieurs montrent la latence et le débit du modèle sur l'axe des ordonnées avec un nombre croissant de travailleurs clients simultanés reflétés sur l'axe des abscisses. Les graphiques à barres inférieurs indiquent le nombre de demandes réussies et échouées.

En examinant tous les modèles de vision par ordinateur que nous avons testés, nous avons observé ce qui suit :

• La latence (en millisecondes) est plus élevée et le débit (requêtes par seconde) est plus faible pour les modèles plus grands (resnet50 > convnext_base > vit_large_patch16_224).
• L'augmentation de la latence est proportionnelle au nombre d'utilisateurs à mesure que davantage de requêtes sont mises en file d'attente sur le serveur d'inférence.
• Les grands modèles consomment plus de ressources de calcul et peuvent atteindre leurs limites de débit maximales avec moins d'utilisateurs qu'un modèle plus petit. Ceci est observé avec le vit_large_patch16_224 modèle, qui a enregistré la première requête ayant échoué chez 140 utilisateurs simultanés. Étant nettement plus grand que les deux autres modèles testés, il avait également le plus grand nombre de requêtes échouées avec une simultanéité plus élevée. C'est un signal clair que le point de terminaison devrait évoluer au-delà d'une seule instance si l'intention est de prendre en charge plus de 140 utilisateurs simultanés.

À la fin de l'exécution du notebook, vous obtenez également une comparaison récapitulative des modèles PyTorch et TensorRT pour chacune des quatre métriques clés. D'après nos tests de référence, les modèles CV ont tous vu leurs performances augmenter après la compilation TensorRT. Prenant notre ResNet50 modèle à titre d'exemple, la latence a diminué de 32 % tandis que le débit a augmenté de 18 %. Bien que le nombre maximal d'utilisateurs simultanés soit resté le même pendant ResNet50, les deux autres modèles ont tous deux enregistré une amélioration de 14 % du nombre d'utilisateurs simultanés qu'ils peuvent prendre en charge. Cependant, l'amélioration des performances de TensorRT s'est faite au détriment d'une utilisation plus élevée de la mémoire, ce qui a entraîné une diminution du nombre de modèles chargés par les MME. L'impact est plus important pour les modèles utilisant un réseau de neurones convolutifs (CNN). En fait, notre modèle ResNet50 a consommé environ deux fois la mémoire GPU allant de PyTorch à TensorRT, ce qui a entraîné 50 % de modèles en moins chargés (46 contre 23). Nous diagnostiquons ce comportement plus en détail dans la section suivante.

Résultats de référence pour les modèles NLP

Pour les modèles NLP, utilisez le bloc-notes nlp-benchmark.ipynb pour exécuter le test de charge. La configuration de l'ordinateur portable devrait être très similaire. Nous avons testé deux modèles NLP : bert-base-uncased (109M) et roberta-large (335M). Le modèle pré-formé et le tokenizer sont tous deux téléchargés à partir du hub Hugging Face, et la charge utile de test est générée à partir du tokenizer à l'aide d'un exemple de chaîne. La longueur maximale de la séquence est par défaut de 128. Si vous devez tester des chaînes plus longues, n'oubliez pas d'ajuster ce paramètre. L'exécution du bloc-notes NLP génère le même ensemble de visualisations : Pytorch (à gauche) vs TensorRT (à droite).

À partir de ceux-ci, nous avons observé encore plus d'avantages en termes de performances de TensorRT pour les modèles NLP. Prenant le roberta-large modèle sur une instance ml.g4dn.2xlarge par exemple, la latence d'inférence a considérablement diminué, passant de 180 millisecondes à 56 millisecondes (une amélioration de 70 %), tandis que le débit s'est amélioré de 406 %, passant de 33 requêtes par seconde à 167. De plus, le nombre maximal de requêtes simultanées les utilisateurs ont augmenté de 50 % ; les demandes échouées n'ont pas été observées jusqu'à ce que nous ayons atteint 180 utilisateurs simultanés, contre 120 pour le modèle PyTorch d'origine. En termes d'utilisation de la mémoire, nous avons vu un modèle de moins chargé pour TensorRT (de neuf modèles à huit). Cependant, l'impact négatif est beaucoup plus faible par rapport à ce que nous avons observé avec les modèles basés sur CNN.

Analyse sur l'utilisation de la mémoire

Le tableau suivant montre l'analyse complète de l'impact de l'utilisation de la mémoire entre PyTorch et TensorRT. Nous avons mentionné plus tôt que les modèles basés sur CNN sont impactés plus négativement. Le ResNet50 Le modèle avait une réduction de plus de 50 % du nombre de modèles chargés sur les trois types d'instances de GPU. Convnext_base avait une réduction encore plus importante à environ 70% dans tous les domaines. D'autre part, l'impact sur les modèles de transformateurs est faible ou mixte. vit_large_patch16_224 et les roberta-large une réduction moyenne d'environ 20 % et 3 %, respectivement, tandis que bert-base-uncased avait une amélioration d'environ 40 %.

En examinant tous les points de données dans leur ensemble en ce qui concerne les performances supérieures en termes de latence, de débit et de fiabilité, et l'impact mineur sur le nombre maximal de modèles chargés, nous recommandons le modèle TensorRT pour les architectures de modèles basées sur des transformateurs. Pour les CNN, nous pensons qu'une analyse plus approfondie des performances des coûts est nécessaire pour s'assurer que les avantages en termes de performances l'emportent sur le coût d'une infrastructure d'hébergement supplémentaire.

Les tableaux suivants répertorient nos résultats de référence complets pour toutes les métriques sur les trois types d'instances GPU.

Le tableau suivant résume les résultats pour tous les types d'instance. L'instance ml.g5.2xlarge offre les meilleures performances, tandis que l'instance ml.p3.2xlarge est généralement sous-performante bien qu'elle soit la plus chère des trois. Les instances g5 et g4dn présentent la meilleure valeur pour les charges de travail d'inférence.

Nettoyer

Après avoir terminé votre test de charge, nettoyez les ressources générées pour éviter des frais supplémentaires. Les principales ressources sont les points de terminaison SageMaker et les fichiers d'artefacts de modèle dans Amazon S3. Pour vous faciliter la tâche, les fichiers du bloc-notes contiennent le code de nettoyage suivant pour vous aider à les supprimer :

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

Conclusion

Dans cet article, nous avons partagé nos résultats de test et nos analyses pour divers modèles de réseaux de neurones profonds exécutés sur des points de terminaison multimodèles SageMaker avec GPU. Les résultats et les informations que nous avons partagés devraient fournir un échantillon représentatif raisonnable des performances sur différentes métriques et types d'instances. Dans le processus, nous avons également introduit notre approche recommandée pour exécuter des tests de référence pour les MME SageMaker avec GPU. Les outils et l'exemple de code que nous avons fournis peuvent vous aider à démarrer rapidement vos tests de référence et à prendre une décision plus éclairée sur la manière d'héberger de manière rentable des centaines de modèles DNN sur du matériel de calcul accéléré. Pour commencer à comparer vos propres modèles avec le support MME pour GPU, reportez-vous à Algorithmes, cadres et instances pris en charge et les terres parsemées de GitHub repo pour des exemples et de la documentation supplémentaires.

À propos des auteurs

James Wu est un architecte de solution spécialiste senior AI/ML chez AWS. aider les clients à concevoir et à créer des solutions d'IA/ML. Le travail de James couvre un large éventail de cas d'utilisation du ML, avec un intérêt principal pour la vision par ordinateur, l'apprentissage en profondeur et la mise à l'échelle du ML dans l'entreprise. Avant de rejoindre AWS, James a été architecte, développeur et leader technologique pendant plus de 10 ans, dont 6 ans en ingénierie et 4 ans dans les secteurs du marketing et de la publicité.

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.

Simon Zamarin est un architecte de solutions AI / ML dont l'objectif principal est d'aider les clients à extraire de la valeur de leurs actifs de données. Dans ses temps libres, Simon aime passer du temps avec sa famille, lire de la science-fiction et travailler sur divers projets de bricolage.

Saurabh Trikandé est chef de produit senior pour Amazon SageMaker Inference. Il est passionné par le travail avec les clients et est motivé par l'objectif de démocratiser l'apprentissage automatique. Il se concentre sur les principaux défis liés au déploiement d'applications ML complexes, de modèles ML multi-locataires, d'optimisations de coûts et de rendre le déploiement de modèles d'apprentissage en profondeur plus accessible. Dans ses temps libres, Saurabh aime faire de la randonnée, découvrir des technologies innovantes, suivre TechCrunch et passer du temps avec sa famille.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/