Erzielen Sie einen viermal höheren ML-Inferenzdurchsatz bei dreimal niedrigeren Kosten pro Inferenz mit Amazon EC2 G5-Instances für NLP- und CV-PyTorch-Modelle

Amazon Elastic Compute-Cloud (Amazon EC2) G5-Instanzen sind die ersten und einzigen Instanzen in der Cloud, die über NVIDIA A10G Tensor Core-GPUs verfügen, die Sie für eine Vielzahl von grafikintensiven Anwendungsfällen und Anwendungsfällen für maschinelles Lernen (ML) verwenden können. Mit G5-Instanzen erhalten ML-Kunden eine hohe Leistung und eine kosteneffiziente Infrastruktur, um größere und anspruchsvollere Modelle für die Verarbeitung natürlicher Sprache (NLP), Computer Vision (CV) und Anwendungsfälle für Empfehlungsmaschinen zu trainieren und bereitzustellen.

Der Zweck dieses Beitrags besteht darin, die Leistungsvorteile von G5-Instances für umfangreiche ML-Inferenz-Workloads zu demonstrieren. Wir tun dies, indem wir das Preis-Leistungs-Verhältnis (gemessen als Inferenzen in $ pro Million) für NLP- und CV-Modelle mit G4dn-Instanzen vergleichen. Wir beginnen mit der Beschreibung unseres Benchmarking-Ansatzes und präsentieren dann Durchsatz-gegen-Latenz-Kurven über Batch-Größen und Datentyppräzision. Im Vergleich zu G4dn-Instances stellen wir fest, dass G5-Instances konsistent niedrigere Cost-per-Million-Inferenzen sowohl für Full Precision- als auch Mixed Precision-Modi für die NLP- und CV-Modelle liefern und gleichzeitig einen höheren Durchsatz und eine geringere Latenz erreichen.

Benchmarking-Ansatz

Um eine Preis-Leistungs-Studie zwischen G5 und G4dn zu entwickeln, müssen wir Durchsatz, Latenz und Kosten-pro-Million-Inferenzen als Funktion der Batchgröße messen. Wir untersuchen auch die Auswirkung von voller Präzision im Vergleich zu gemischter Präzision. Sowohl der Modellgraph als auch die Eingaben werden vor der Inferenz in CUDA geladen.

Wie im folgenden Architekturdiagramm gezeigt, erstellen wir zunächst entsprechende Basis-Container-Images mit CUDA für die zugrunde liegende EC2-Instance (G4dn, G5). Um die Basis-Container-Images zu erstellen, beginnen wir mit AWS Deep Learning Container, die vorgefertigte Docker-Images verwenden, um Deep-Learning-Umgebungen in wenigen Minuten bereitzustellen. Die Bilder enthalten die erforderlichen Deep-Learning-PyTorch-Bibliotheken und -Tools. Sie können diese Bilder mit Ihren eigenen Bibliotheken und Tools ergänzen, um ein höheres Maß an Kontrolle über Überwachung, Compliance und Datenverarbeitung zu erhalten.

Dann erstellen wir ein modellspezifisches Container-Image, das die Modellkonfiguration, die Modellablaufverfolgung und den zugehörigen Code zum Ausführen von Vorwärtsdurchläufen kapselt. Alle Container-Images werden in geladen Amazon ECR um eine horizontale Skalierung dieser Modelle für verschiedene Modellkonfigurationen zu ermöglichen. Wir gebrauchen Amazon Simple Storage-Service (Amazon S3) als gemeinsamer Datenspeicher zum Herunterladen der Konfiguration und zum Hochladen von Benchmark-Ergebnissen zur Zusammenfassung. Sie können diese Architektur verwenden, um die Benchmark-Ergebnisse neu zu erstellen und zu reproduzieren und umzufunktionieren, um verschiedene Modelltypen (z. B. Hugging Face-Modelle, PyTorch-Modelle, andere benutzerdefinierte Modelle) über EC2-Instance-Typen (CPU, GPU, Inf1) hinweg zu bewerten.

Mit diesem Experimentaufbau ist es unser Ziel, die Latenz als Funktion des Durchsatzes zu untersuchen. Diese Kurve ist für das Anwendungsdesign wichtig, um zu einer kostenoptimalen Infrastruktur für die Zielanwendung zu gelangen. Um dies zu erreichen, simulieren wir unterschiedliche Lasten, indem wir Abfragen aus mehreren Threads in eine Warteschlange stellen und dann die Umlaufzeit für jede abgeschlossene Anforderung messen. Der Durchsatz wird anhand der Anzahl abgeschlossener Anforderungen pro Zeiteinheit gemessen. Darüber hinaus können Sie die Stapelgrößen und andere Variablen wie Sequenzlänge und volle Genauigkeit im Vergleich zu halber Genauigkeit variieren, um den Designraum umfassend zu durchsuchen, um zu indikativen Leistungsmetriken zu gelangen. In unserer Studie wird durch einen parametrischen Sweep der Batchgröße und Abfragen von Multithread-Clients die Durchsatz-/Latenzkurve ermittelt. Jede Anfrage kann gebündelt werden, um sicherzustellen, dass der Beschleuniger vollständig genutzt wird, insbesondere bei kleinen Anfragen, die den Rechenknoten möglicherweise nicht vollständig auslasten. Sie können dieses Setup auch übernehmen, um die clientseitige Stapelgröße für eine optimale Leistung zu identifizieren.

Zusammenfassend können wir dieses Problem mathematisch darstellen als: (Durchsatz, Latenz) = Funktion von (Batch-Größe, Anzahl der Threads, Genauigkeit).

Dies bedeutet, dass angesichts des erschöpfenden Raums die Anzahl der Experimente groß sein kann. Glücklicherweise kann jedes Experiment unabhängig voneinander durchgeführt werden. Wir empfehlen die Verwendung AWS-Charge um dieses horizontal skalierte Benchmarking in komprimierter Zeit ohne Erhöhung der Benchmarking-Kosten im Vergleich zu einem linearen Testansatz durchzuführen. Der Code zum Replizieren der Ergebnisse ist in der vorhanden GitHub-Repository vorbereitet für AWS Re:Invent 2021. Das Repository ist umfassend, um Benchmarking auf verschiedenen Beschleunigern durchzuführen. Sie können sich auf den GPU-Aspekt des Codes beziehen, um den Container zu erstellen (Dockerfile-gpu) und beziehen Sie sich dann auf den darin enthaltenen Code Container-Root für spezifische Beispiele für BERT und ResNet50.

Wir haben den vorherigen Ansatz verwendet, um Leistungsstudien für zwei Modelltypen zu entwickeln: Bert-Base-uncased (110 Millionen Parameter, NLP) und ResNet50 (25.6 Millionen Parameter, CV). Die folgende Tabelle fasst die Modelldetails zusammen.

Modelltyp	Modell	Details
NLP	twmkn9/bert-base-uncased-squad2	110 Millionen Parameter Sequenzlänge = 128
CV	ResNet50	25.6 Millionen Parameter

Darüber hinaus verwenden wir zum Benchmarking über Datentypen hinweg (volle, halbe Genauigkeit). torch.cuda.amp, das praktische Methoden zum Umgang mit gemischter Genauigkeit bereitstellt, wenn einige Operationen die verwenden torch.float32 (Float) Datentyp und andere Operationen verwenden torch.float16 (halb). Beispielsweise sind Operatoren wie lineare Schichten und Faltungen mit Float16 viel schneller, während andere wie Reduktionen oft den dynamischen Bereich von Float32 erfordern. Die automatische gemischte Genauigkeit versucht, jeden Operator seinem entsprechenden Datentyp zuzuordnen, um die Laufzeit und den Speicherbedarf des Netzwerks zu optimieren.

Benchmarking-Ergebnisse

Für einen fairen Vergleich haben wir ausgewählt G4dn.4xgroß und G5.4xgroß Instanzen mit ähnlichen Attributen, wie in der folgenden Tabelle aufgeführt.

Beispiel	GPUs	GPU-Speicher (GiB)	vCPUs	Arbeitsspeicher (GiB)	Instanzspeicher (GB)	Netzwerkleistung (Gbit/s)	EBS-Bandbreite (Gbit/s)	Linux On-Demand-Preise (us-east-1)
G5.4xgroß	1	24	16	64	1x 600-NVMe-SSD	bis 25	8	$ 1.204 / Stunde
G4dn.4xgroß	1	16	16	64	1x 225-NVMe-SSD	bis 25	4.75	$ 1.624 / Stunde

In den folgenden Abschnitten vergleichen wir die ML-Inferenzleistung von BERT- und RESNET50-Modellen mit einem Grid-Sweep-Ansatz für bestimmte Batchgrößen (32, 16, 8, 4, 1) und Datentypgenauigkeit (volle und halbe Genauigkeit), um den Durchsatz zu ermitteln vs. Latenzkurve. Darüber hinaus untersuchen wir die Auswirkung des Durchsatzes gegenüber der Batchgröße sowohl für die volle als auch für die halbe Präzision. Schließlich messen wir die Kosten pro Million Inferenzen als Funktion der Chargengröße. Die konsolidierten Ergebnisse dieser Experimente werden später in diesem Beitrag zusammengefasst.

Durchsatz vs. Latenz

Die folgenden Abbildungen vergleichen G4dn- und G5-Instances für NLP- und CV-Workloads mit voller und halber Genauigkeit. Im Vergleich zu G4dn-Instanzen liefert die G5-Instanz einen Durchsatz, der etwa fünfmal höher (volle Genauigkeit) und etwa 2.5-mal höher (halbe Genauigkeit) für ein BERT-Basismodell und etwa 2–2.5-mal höher für ein ResNet50-Modell ist. Insgesamt ist G5 eine bevorzugte Wahl, mit steigenden Chargengrößen für beide Modelle sowohl für volle als auch für gemischte Präzision aus Leistungssicht.

Die folgenden Diagramme vergleichen den Durchsatz und die P95-Latenz bei voller und halber Genauigkeit für BERT.

Die folgenden Diagramme vergleichen Durchsatz und P95-Latenz bei voller und halber Genauigkeit für ResNet50.

Durchsatz und Latenz vs. Batchgröße

Die folgenden Grafiken zeigen den Durchsatz in Abhängigkeit von der Chargengröße. Bei niedrigen Batch-Größen arbeitet der Beschleuniger nicht mit seiner vollen Kapazität, und wenn die Batch-Größe zunimmt, erhöht sich der Durchsatz auf Kosten der Latenz. Die Durchsatzkurve asymptot zu einem Maximalwert, der eine Funktion der Beschleunigerleistung ist. Die Kurve hat zwei unterschiedliche Merkmale: einen ansteigenden Abschnitt und einen flachen asymptotischen Abschnitt. Für ein bestimmtes Modell ist ein leistungsfähiger Beschleuniger (G5) in der Lage, den ansteigenden Abschnitt auf höhere Chargengrößen als G4dn zu strecken und bei einem höheren Durchsatz asymptotisch zu werden. Außerdem gibt es einen linearen Kompromiss zwischen Latenz und Stapelgröße. Wenn die Anwendung latenzgebunden ist, können wir daher die P95-Latenz im Vergleich zur Stapelgröße verwenden, um die optimale Stapelgröße zu bestimmen. Wenn jedoch das Ziel darin besteht, den Durchsatz bei der niedrigsten Latenzzeit zu maximieren, ist es besser, die Stapelgröße entsprechend dem „Knie“ zwischen dem ansteigenden und dem asymptotischen Abschnitt zu wählen, da jede weitere Erhöhung der Stapelgröße denselben Durchsatz bei a zur Folge hätte schlechtere Latenz. Um das beste Preis-Leistungs-Verhältnis zu erzielen und einen höheren Durchsatz bei niedrigster Latenz anzustreben, sollten Sie dieses Optimum besser horizontal über mehrere Inferenzserver skalieren, anstatt nur die Stapelgröße zu erhöhen.

Kosten vs. Chargengröße

In diesem Abschnitt präsentieren wir die Vergleichsergebnisse der Inferenzkosten ($ pro Million Inferenzen) im Vergleich zur Batchgröße. Aus der folgenden Abbildung können wir deutlich erkennen, dass die Kosten (gemessen als Schlussfolgerungen in $ pro Million) bei G5 im Vergleich zu G4dn sowohl (volle als auch halbe Genauigkeit) durchweg niedriger sind.

Die folgende Tabelle fasst Vergleiche von Durchsatz, Latenz und Kosten ($ pro Million Inferenzen) für BERT- und RESNET50-Modelle in beiden Präzisionsmodi für bestimmte Batchgrößen zusammen. Trotz höherer Kosten pro Instanz übertrifft G5 G4dn in allen Aspekten der Inferenzlatenz, des Durchsatzes und der Kosten ($ pro Million Inferenz) für alle Batchgrößen. Kombiniert man die verschiedenen Metriken zu Kosten ($ pro Million Inferenzen), ist das BERT-Modell (32-Batch-Größe, volle Genauigkeit) mit G5 3.7-mal günstiger als G4dn, und mit dem ResNet50-Modell (32-Batch-Größe, volle Genauigkeit) ist es 1.6 mal günstiger als G4dn.

Modell	Batch-Größe	Präzision	Durchsatz (Batchgröße X Anfragen/Sek.)		Latenzzeit (ms)		$/Million Inferenzen (On-Demand)		Kosten-Nutzen (G5 über G4dn)
.	.	.	G5	G4dn	G5	G4dn	G5	G4dn
Bert-Basis-uncased	32	Vollständiger	723	154	44	208	$0.6	$2.2	3.7X
		Kastenwagen/Passagier	870	410	37	79	$0.5	$0.8	1.6X
	16	Vollständiger	651	158	25	102	$0.7	$2.1	3.0X
		Kastenwagen/Passagier	762	376	21	43	$0.6	$0.9	1.5X
	8	Vollständiger	642	142	13	57	$0.7	$2.3	3.3X
		Kastenwagen/Passagier	681	350	12	23	$0.7	$1.0	1.4X
.	1	Vollständiger	160	116	6	9	$2.8	$2.9	1.0X
		Kastenwagen/Passagier	137	102	7	10	$3.3	$3.3	1.0X
ResNet50	32	Vollständiger	941	397	34	82	$0.5	$0.8	1.6X
		Kastenwagen/Passagier	1533	851	21	38	$0.3	$0.4	1.3X
	16	Vollständiger	888	384	18	42	$0.5	$0.9	1.8X
		Kastenwagen/Passagier	1474	819	11	20	$0.3	$0.4	1.3X
	8	Vollständiger	805	340	10	24	$0.6	$1.0	1.7X
		Kastenwagen/Passagier	1419	772	6	10	$0.3	$0.4	1.3X
.	1	Vollständiger	202	164	5	6	$2.2	$2	0.9X
		Kastenwagen/Passagier	196	180	5	6	$2.3	$1.9	0.8X

Zusätzliche Inferenz-Benchmarks

Zusätzlich zu den BERT-Basis- und ResNet50-Ergebnissen in den vorherigen Abschnitten präsentieren wir zusätzliche Benchmarking-Ergebnisse für andere häufig verwendete große NLP- und CV-Modelle in PyTorch. Der Leistungsvorteil von G5 gegenüber G4dn wurde für BERT Large-Modelle mit unterschiedlicher Genauigkeit und Yolo-v5-Modelle für verschiedene Größen vorgestellt. Den Code zum Replizieren des Benchmarks finden Sie unter NVIDIA Deep Learning Beispiele für Tensor Cores. Diese Ergebnisse zeigen den Vorteil der Verwendung von G5 gegenüber G4dn für eine breite Palette von Inferenzaufgaben, die verschiedene Modelltypen umfassen.

Modell	Präzision	Batch-Größe	Sequenzlänge	Durchsatz (gesendet/Sek.)	Durchsatz: G4dn	Beschleunigung über G4dn
BERT-groß	FP16	1	128	93.5	40.31	2.3
BERT-groß	FP16	4	128	264.2	87.4	3.0
BERT-groß	FP16	8	128	392.1	107.5	3.6
BERT-groß	FP32	1	128	68.4	22.67	3.0
BERT-groß		4	128	118.5	32.21	3.7
BERT-groß		8	128	132.4	34.67	3.8

Modell	GFLOPS	Anzahl der Parameter	Vorverarbeitung (ms)	Inferenz (ms)	Inferenz (Non-Max-Unterdrückung) (NMS/Bild)
YOLOv5s	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

Zusammenfassung

In diesem Beitrag haben wir gezeigt, dass für die Inferenz mit großen NLP- und CV-PyTorch-Modellen EC2 G5-Instances im Vergleich zu G4dn-Instances die bessere Wahl sind. Obwohl die stündlichen On-Demand-Kosten für G5-Instances höher sind als für G4dn-Instances, kann ihre höhere Leistung den 2- bis 5-fachen Durchsatz bei jeder Genauigkeit für NLP- und CV-Modelle erreichen, wodurch die Kosten pro Million Inferenzen 1.5- bis 3.5-mal günstiger sind als G4dn-Instanzen. Selbst für latenzgebundene Anwendungen ist G5 2.5- bis 5-mal besser als G4dn für NLP- und CV-Modelle.

Zusammenfassend lässt sich sagen, dass AWS G5-Instances eine ausgezeichnete Wahl für Ihre Inferenzanforderungen sind, sowohl im Hinblick auf die Leistung als auch auf die Kosten pro Inferenz. Die Universalität des CUDA-Frameworks und die Größe und Tiefe des G5-Instance-Pools auf AWS bieten Ihnen eine einzigartige Möglichkeit, Inferenzen in großem Maßstab durchzuführen.

---

Über die Autoren

Ankur Srivastava ist Senior Solutions Architect im ML Frameworks Team. Er konzentriert sich darauf, Kunden mit selbstverwaltetem, verteiltem Training und Inferenz in großem Umfang auf AWS zu unterstützen. Seine Erfahrung umfasst industrielle vorausschauende Wartung, digitale Zwillinge, probabilistische Konstruktionsoptimierung und hat sein Doktorstudium im Maschinenbau an der Rice University und seine Postdoktorandenforschung am Massachusetts Institute of Technology abgeschlossen.

Sundar Ranganathan ist Head of Business Development, ML Frameworks im Amazon EC2-Team. Er konzentriert sich auf umfangreiche ML-Workloads über AWS-Services wie Amazon EKS, Amazon ECS, Elastic Fabric Adapter, AWS Batch und Amazon SageMaker. Seine Erfahrung umfasst Führungspositionen im Produktmanagement und in der Produktentwicklung bei NetApp, Micron Technology, Qualcomm und Mentor Graphics.

Mahadevan Balasubramaniam ist ein Principal Solutions Architect für Autonomous Computing mit fast 20 Jahren Erfahrung im Bereich des physikalisch geprägten Deep Learning, dem Aufbau und der Bereitstellung digitaler Zwillinge für industrielle Systeme im großen Maßstab. Mahadevan promovierte in Maschinenbau am Massachusetts Institute of Technology und hat über 25 Patente und Veröffentlichungen zu seinem Verdienst.

Amr Ragab ist ein Principal Solutions Architect für EC2 Accelerated Platforms for AWS, der sich der Unterstützung von Kunden bei der Ausführung von Rechenlasten in großem Maßstab verschrieben hat. In seiner Freizeit reist er gerne und findet neue Wege, um Technologie in den Alltag zu integrieren.