Obtenez un débit d'inférence ML quatre fois plus élevé à un coût par inférence trois fois inférieur avec les instances Amazon EC2 G5 pour les modèles NLP et CV PyTorch

Cloud de calcul élastique Amazon (Amazon EC2) Instances G5 sont les premières et les seules instances dans le cloud à proposer des GPU NVIDIA A10G Tensor Core, que vous pouvez utiliser pour un large éventail de cas d'utilisation à forte intensité graphique et d'apprentissage automatique (ML). Avec les instances G5, les clients ML bénéficient de hautes performances et d'une infrastructure rentable pour former et déployer des modèles plus grands et plus sophistiqués pour les cas d'utilisation du traitement du langage naturel (NLP), de la vision par ordinateur (CV) et du moteur de recommandation.

L'objectif de cet article est de présenter les avantages en termes de performances des instances G5 pour les charges de travail d'inférence ML à grande échelle. Pour ce faire, nous comparons le rapport qualité-prix (mesuré en dollars par million d'inférences) des modèles NLP et CV avec les instances G4dn. Nous commençons par décrire notre approche d'analyse comparative, puis présentons les courbes de débit par rapport à la latence selon la taille des lots et la précision du type de données. Par rapport aux instances G4dn, nous constatons que les instances G5 offrent un coût par million d'inférences systématiquement inférieur pour les modes de précision complète et de précision mixte pour les modèles NLP et CV tout en obtenant un débit plus élevé et une latence plus faible.

Approche d'analyse comparative

Pour développer une étude prix-performance entre G5 et G4dn, nous devons mesurer le débit, la latence et le coût par million d'inférences en fonction de la taille du lot. Nous étudions également l'impact de la précision totale par rapport à la précision mixte. Le graphe du modèle et les entrées sont chargés dans CUDA avant l'inférence.

Comme indiqué dans le diagramme d'architecture suivant, nous créons d'abord des images de conteneur de base respectives avec CUDA pour l'instance EC2 sous-jacente (G4dn, G5). Pour créer les images de conteneur de base, nous commençons par Conteneurs AWS Deep Learning, qui utilisent des images Docker pré-packagées pour déployer des environnements d'apprentissage en profondeur en quelques minutes. Les images contiennent les bibliothèques et outils d'apprentissage en profondeur PyTorch requis. Vous pouvez ajouter vos propres bibliothèques et outils à ces images pour un meilleur contrôle sur la surveillance, la conformité et le traitement des données.

Ensuite, nous créons une image de conteneur spécifique au modèle qui encapsule la configuration du modèle, le traçage du modèle et le code associé pour exécuter des passes vers l'avant. Toutes les images de conteneur sont chargées dans ECR d'Amazon pour permettre une mise à l'échelle horizontale de ces modèles pour diverses configurations de modèles. Nous utilisons Service de stockage simple Amazon (Amazon S3) en tant que magasin de données commun pour télécharger la configuration et télécharger les résultats de référence pour la synthèse. Vous pouvez utiliser cette architecture pour recréer et reproduire les résultats de référence et les réutiliser pour comparer différents types de modèles (tels que les modèles Hugging Face, les modèles PyTorch, d'autres modèles personnalisés) sur les types d'instance EC2 (CPU, GPU, Inf1).

Avec cette expérience mise en place, notre objectif est d'étudier la latence en fonction du débit. Cette courbe est importante pour que la conception des applications aboutisse à une infrastructure optimale en termes de coûts pour l'application cible. Pour ce faire, nous simulons différentes charges en mettant en file d'attente les requêtes de plusieurs threads, puis en mesurant le temps d'aller-retour pour chaque requête terminée. Le débit est mesuré en fonction du nombre de requêtes terminées par unité de temps d'horloge. De plus, vous pouvez faire varier la taille des lots et d'autres variables telles que la longueur de la séquence et la précision totale par rapport à la demi-précision pour balayer complètement l'espace de conception afin d'obtenir des mesures de performances indicatives. Dans notre étude, grâce à un balayage paramétrique de la taille des lots et des requêtes des clients multithreads, la courbe débit/latence est déterminée. Chaque demande peut être regroupée pour garantir une utilisation complète de l'accélérateur, en particulier pour les petites demandes qui peuvent ne pas utiliser pleinement le nœud de calcul. Vous pouvez également adopter cette configuration pour identifier la taille du lot côté client pour des performances optimales.

En résumé, nous pouvons représenter mathématiquement ce problème comme suit : (Débit, Latence) = fonction de (Taille du lot, Nombre de threads, Précision).

Cela signifie que, compte tenu de l'espace exhaustif, le nombre d'expériences peut être important. Heureusement, chaque expérience peut être exécutée indépendamment. Nous recommandons d'utiliser Lot AWS pour effectuer cette analyse comparative à l'échelle horizontale en un temps compressé sans augmentation du coût de l'analyse comparative par rapport à une approche linéaire des tests. Le code de réplication des résultats est présent dans le GitHub référentiel préparé pour AWS Re:Invent 2021. Le référentiel est complet pour effectuer des analyses comparatives sur différents accélérateurs. Vous pouvez vous référer à l'aspect GPU du code pour construire le conteneur (Dockerfile-gpu) puis reportez-vous au code à l'intérieur Container-Root pour des exemples spécifiques pour BERT et ResNet50.

Nous avons utilisé l'approche précédente pour développer des études de performances sur deux types de modèles : Bert-base-uncased (110 millions de paramètres, NLP) et ResNet50 (25.6 millions de paramètres, CV). Le tableau suivant résume les détails du modèle.

Type de modèle	Modèle	Détails
PNL	twmkn9/bert-base-uncased-squad2	110 millions de paramètres Longueur de séquence = 128
CV	ResNet50	25.6 millions de paramètres

De plus, pour comparer les types de données (complet, demi-précision), nous utilisons torch.cuda.amp, qui fournit des méthodes pratiques pour gérer la précision mixte lorsque certaines opérations utilisent le torch.float32 type de données (flottant) et autres opérations utilisées torch.float16 (demi). Par exemple, les opérateurs comme les couches linéaires et les convolutions sont beaucoup plus rapides avec float16, alors que d'autres comme les réductions nécessitent souvent la plage dynamique de float32. La précision mixte automatique essaie de faire correspondre chaque opérateur à son type de données approprié pour optimiser le temps d'exécution et l'empreinte mémoire du réseau.

Résultats de l'analyse comparative

Pour une juste comparaison, nous avons sélectionné G4dn.4xlarge ainsi que G5.4xlarge instances avec des attributs similaires, comme indiqué dans le tableau suivant.

Instance	GPU	Mémoire GPU (Gio)	vCPU	Mémoire (Gio)	Stockage d'instance (Go)	Performances réseau (Gbit/s)	Bande passante EBS (Gbit/s)	Tarification Linux à la demande (us-east-1)
G5.4xlarge	1	24	16	64	1x SSD 600 NVMe	jusqu'à 25	8	$1.204 / heure
G4dn.4xlarge	1	16	16	64	1x SSD 225 NVMe	jusqu'à 25	4.75	$1.624 / heure

Dans les sections suivantes, nous comparons les performances d'inférence ML des modèles BERT et RESNET50 avec une approche de balayage de grille pour des tailles de lots spécifiques (32, 16, 8, 4, 1) et la précision du type de données (pleine et demi-précision) pour arriver au débit vs courbe de latence. De plus, nous étudions l'effet du débit par rapport à la taille du lot pour la précision complète et la demi-précision. Enfin, nous mesurons le coût par million d'inférences en fonction de la taille du lot. Les résultats consolidés de ces expériences sont résumés plus loin dans cet article.

Débit vs latence

Les figures suivantes comparent les instances G4dn et G5 pour les charges de travail NLP et CV à la fois en pleine et demi-précision. Par rapport aux instances G4dn, l'instance G5 offre un débit environ cinq fois supérieur (précision totale) et environ 2.5 fois supérieur (demi-précision) pour un modèle de base BERT, et environ 2 à 2.5 fois supérieur pour un modèle ResNet50. Dans l'ensemble, G5 est un choix préféré, avec des tailles de lot croissantes pour les deux modèles pour une précision complète et mixte du point de vue des performances.

Les graphiques suivants comparent le débit et la latence P95 à pleine et demi-précision pour BERT.

Les graphiques suivants comparent le débit et la latence P95 à pleine et demi-précision pour ResNet50.

Débit et latence par rapport à la taille du lot

Les graphiques suivants montrent le débit en fonction de la taille du lot. À de faibles tailles de lot, l'accélérateur ne fonctionne pas à sa pleine capacité et à mesure que la taille du lot augmente, le débit augmente au prix de la latence. La courbe de débit asymptote vers une valeur maximale qui est fonction des performances de l'accélérateur. La courbe a deux caractéristiques distinctes : une section montante et une section plate asymptotique. Pour un modèle donné, un accélérateur performant (G5) est capable d'étirer la section montante à des tailles de lots plus élevées que G4dn et asymptote à un débit plus élevé. De plus, il existe un compromis linéaire entre la latence et la taille du lot. Par conséquent, si l'application est liée à la latence, nous pouvons utiliser la latence P95 par rapport à la taille du lot pour déterminer la taille de lot optimale. Cependant, si l'objectif est de maximiser le débit à la latence la plus faible, il est préférable de sélectionner la taille de lot correspondant au "coude" entre les sections montante et asymptotique, car toute augmentation supplémentaire de la taille du lot se traduirait par le même débit à un pire latence. Pour obtenir le meilleur rapport prix-performances, en ciblant un débit plus élevé avec une latence plus faible, il vaut mieux mettre à l'échelle horizontalement cet optimum via plusieurs serveurs d'inférence plutôt que d'augmenter simplement la taille du lot.

Coût vs taille de lot

Dans cette section, nous présentons les résultats comparatifs des coûts d'inférence (en dollars par million d'inférences) par rapport à la taille du lot. À partir de la figure suivante, nous pouvons clairement observer que le coût (mesuré en dollars par million d'inférences) est systématiquement inférieur avec G5 par rapport à G4dn (pleine précision et demi-précision).

Le tableau suivant résume les comparaisons de débit, de latence et de coût (USD par million d'inférences) pour les modèles BERT et RESNET50 dans les deux modes de précision pour des tailles de lot spécifiques. Malgré un coût par instance plus élevé, G5 surpasse systématiquement G4dn dans tous les aspects de la latence d'inférence, du débit et du coût (inférence par million de dollars), pour toutes les tailles de lot. En combinant les différentes métriques en un coût (USD par million d'inférences), le modèle BERT (taille de lot 32, précision totale) avec G5 est 3.7 fois plus favorable que G4dn, et avec le modèle ResNet50 (taille de lot 32, précision totale), il est de 1.6 fois plus favorable que G4dn.

Modèle	Taille du lot	La précision	Cadence de production (Taille du lot X Requêtes/s)		Latence (ms)		$/million Inférences (à la demande)		Coût Bénéfice (G5 sur G4dn)
.	.	.	G5	G4dn	G5	G4dn	G5	G4dn
Bert-base-sans boîtier	32	Full	723	154	44	208	$0.6	$2.2	3.7X
		Mixte	870	410	37	79	$0.5	$0.8	1.6X
	16	Full	651	158	25	102	$0.7	$2.1	3.0X
		Mixte	762	376	21	43	$0.6	$0.9	1.5X
	8	Full	642	142	13	57	$0.7	$2.3	3.3X
		Mixte	681	350	12	23	$0.7	$1.0	1.4X
.	1	Full	160	116	6	9	$2.8	$2.9	1.0X
		Mixte	137	102	7	10	$3.3	$3.3	1.0X
ResNet50	32	Full	941	397	34	82	$0.5	$0.8	1.6X
		Mixte	1533	851	21	38	$0.3	$0.4	1.3X
	16	Full	888	384	18	42	$0.5	$0.9	1.8X
		Mixte	1474	819	11	20	$0.3	$0.4	1.3X
	8	Full	805	340	10	24	$0.6	$1.0	1.7X
		Mixte	1419	772	6	10	$0.3	$0.4	1.3X
.	1	Full	202	164	5	6	$2.2	$2	0.9X
		Mixte	196	180	5	6	$2.3	$1.9	0.8X

Repères d'inférence supplémentaires

En plus de la base BERT et des résultats ResNet50 dans les sections précédentes, nous présentons des résultats d'analyse comparative supplémentaires pour d'autres grands modèles NLP et CV couramment utilisés dans PyTorch. L'avantage de performance de G5 par rapport à G4dn a été présenté pour les modèles BERT Large à différentes précisions et les modèles Yolo-v5 pour différentes tailles. Pour le code de réplication du benchmark, reportez-vous à Exemples d'apprentissage en profondeur NVIDIA pour les cœurs Tensor. Ces résultats montrent l'avantage d'utiliser G5 par rapport à G4dn pour un large éventail de tâches d'inférence couvrant différents types de modèles.

Modèle	La précision	Taille du lot	Longueur de la séquence	Débit (envoi/s)	Débit : G4dn	Accélération sur G4dn
BERT-grand	FP16	1	128	93.5	40.31	2.3
BERT-grand	FP16	4	128	264.2	87.4	3.0
BERT-grand	FP16	8	128	392.1	107.5	3.6
BERT-grand	FP32	1	128	68.4	22.67	3.0
BERT-grand		4	128	118.5	32.21	3.7
BERT-grand		8	128	132.4	34.67	3.8

Modèle	GFLOPS	Nombre de paramètres	Prétraitement (ms)	Inférence (ms)	Inférence (suppression non maximale) (NMS/image)
YOLOv5	16.5	7.2M	0.2	3.6	4.5
YOLOv5m	49.1	21M	0.2	6.5	4.5
YOLOv5l	109.3	46M	0.2	9.1	3.5
YOLOv5x	205.9	86M	0.2	14.4	1.3

Conclusion

Dans cet article, nous avons montré que pour l'inférence avec de grands modèles NLP et CV PyTorch, les instances EC2 G5 sont un meilleur choix par rapport aux instances G4dn. Bien que le coût horaire à la demande pour les instances G5 soit supérieur à celui des instances G4dn, ses performances supérieures peuvent atteindre 2 à 5 fois le débit à n'importe quelle précision pour les modèles NLP et CV, ce qui rend le coût par million d'inférences 1.5 à 3.5 fois plus favorable que instances G4dn. Même pour les applications liées à la latence, G5 est 2.5 à 5 fois meilleur que G4dn pour les modèles NLP et CV.

En résumé, les instances AWS G5 constituent un excellent choix pour vos besoins d'inférence, tant du point de vue des performances que du coût par inférence. L'universalité du framework CUDA ainsi que l'échelle et la profondeur du pool d'instances G5 sur AWS vous offrent une capacité unique d'effectuer des inférences à grande échelle.

---

À propos des auteurs

Ankur Srivastava est un architecte de solutions senior dans l'équipe ML Frameworks. Il se concentre sur l'aide aux clients avec une formation distribuée autogérée et une inférence à grande échelle sur AWS. Son expérience comprend la maintenance prédictive industrielle, les jumeaux numériques, l'optimisation de la conception probabiliste et a terminé ses études doctorales en génie mécanique à l'Université Rice et ses recherches postdoctorales au Massachusetts Institute of Technology.

Sundar Ranganathan est le responsable du développement commercial, ML Frameworks au sein de l'équipe Amazon EC2. Il se concentre sur les charges de travail ML à grande échelle sur les services AWS comme Amazon EKS, Amazon ECS, Elastic Fabric Adapter, AWS Batch et Amazon SageMaker. Son expérience comprend des rôles de direction dans la gestion et le développement de produits chez NetApp, Micron Technology, Qualcomm et Mentor Graphics.

Mahadevan Balasubramaniam est un architecte principal de solutions pour l'informatique autonome avec près de 20 ans d'expérience dans le domaine de l'apprentissage approfondi basé sur la physique, de la construction et du déploiement de jumeaux numériques pour les systèmes industriels à grande échelle. Mahadevan a obtenu son doctorat en génie mécanique du Massachusetts Institute of Technology et a plus de 25 brevets et publications à son actif.

Amr Ragab est un architecte de solutions principal pour les plates-formes accélérées EC2 pour AWS, qui se consacre à aider les clients à exécuter des charges de travail de calcul à grande échelle. Dans ses temps libres, il aime voyager et trouver de nouvelles façons d'intégrer la technologie dans la vie quotidienne.