Erzielen Sie mit Amazon SageMaker Multi-Model-Endpunkten mit GPU eine hohe Leistung im großen Maßstab für die Modellbereitstellung

Amazon Sage Maker Endpunkte mit mehreren Modellen (MMEs) bieten eine skalierbare und kostengünstige Möglichkeit, eine große Anzahl von Modellen für maschinelles Lernen (ML) bereitzustellen. Es gibt Ihnen die Möglichkeit, mehrere ML-Modelle in einem einzigen Serving-Container hinter einem einzigen Endpunkt bereitzustellen. Von dort aus verwaltet SageMaker das Laden und Entladen der Modelle und skaliert Ressourcen in Ihrem Namen basierend auf Ihren Datenverkehrsmustern. Sie profitieren von der gemeinsamen Nutzung und Wiederverwendung von Hosting-Ressourcen und einem geringeren Betriebsaufwand für die Verwaltung einer großen Anzahl von Modellen.

Im November 2022, MMEs haben Unterstützung für GPU hinzugefügts, mit dem Sie mehrere Modelle auf einem einzelnen GPU-Gerät ausführen und GPU-Instanzen hinter einem einzelnen Endpunkt skalieren können. Dies erfüllt die starke MME-Nachfrage nach Deep Neural Network (DNN)-Modellen, die von beschleunigter Berechnung mit GPUs profitieren. Dazu gehören Computer Vision (CV), Natural Language Processing (NLP) und generative KI-Modelle. Die Gründe für die Nachfrage sind unter anderem:

• DNN-Modelle sind in der Regel groß und komplex und wachsen weiterhin schnell. Am Beispiel von NLP-Modellen überschreiten viele von ihnen Milliarden von Parametern, was erfordert, dass GPUs Anforderungen an geringe Latenz und hohen Durchsatz erfüllen.
• Wir haben einen erhöhten Bedarf für die Anpassung dieser Modelle beobachtet, um einzelnen Benutzern hyperpersonalisierte Erfahrungen zu bieten. Da die Menge dieser Modelle zunimmt, wird eine einfachere Lösung benötigt, um viele Modelle in großem Umfang bereitzustellen und zu operationalisieren.
• GPU-Instanzen sind teuer und Sie möchten diese Instanzen so oft wie möglich wiederverwenden, um die GPU-Auslastung zu maximieren und die Betriebskosten zu senken.

Obwohl all diese Gründe auf MMEs mit GPU als ideale Option für DNN-Modelle hindeuten, wird empfohlen, Belastungstests durchzuführen, um die richtige Endpunktkonfiguration zu finden, die Ihre Anwendungsfallanforderungen erfüllt. Viele Faktoren können die Ergebnisse der Lasttests beeinflussen, z. B. Instance-Typ, Anzahl der Instances, Modellgröße und Modellarchitektur. Darüber hinaus können Lasttests dazu beitragen, die Auto Scaling-Strategien mit den richtigen Metriken anstelle von iterativen Trial-and-Error-Methoden zu steuern.

Aus diesen Gründen haben wir diesen Beitrag zusammengestellt, um Ihnen zu helfen, ordnungsgemäße Lasttests auf MMEs mit GPU durchzuführen und die beste Konfiguration für Ihren ML-Anwendungsfall zu finden. Wir teilen unsere Lasttestergebnisse für einige der beliebtesten DNN-Modelle in NLP und CV, die mit MMEs auf verschiedenen Instance-Typen gehostet werden. Wir fassen die Erkenntnisse und Schlussfolgerungen aus unseren Testergebnissen zusammen, um Ihnen zu helfen, eine fundierte Entscheidung zur Konfiguration Ihrer eigenen Bereitstellungen zu treffen. Dabei teilen wir auch unseren empfohlenen Ansatz zur Durchführung von Belastungstests für MMEs auf der GPU. Die empfohlenen Tools und Techniken bestimmen die optimale Anzahl von Modellen, die pro Instance-Typ geladen werden können, und helfen Ihnen, das beste Preis-Leistungs-Verhältnis zu erzielen.

Lösungsüberblick

Eine Einführung in MMEs und MMEs mit GPU finden Sie unter Erstellen Sie einen Endpunkt mit mehreren Modellen und Führen Sie mehrere Deep-Learning-Modelle auf der GPU mit Amazon SageMaker-Multimodell-Endpunkten aus. Für den Kontext des Lasttests in diesem Beitrag können Sie unseren Beispielcode von herunterladen GitHub Repo um die Ergebnisse zu reproduzieren oder als Vorlage zum Benchmarken Ihrer eigenen Modelle zu verwenden. Das Repo enthält zwei Notebooks: eines für Lasttests von CV-Modellen und ein weiteres für NLP. Mehrere Modelle unterschiedlicher Größe und Architektur wurden auf verschiedenen Arten von GPU-Instanzen getestet: ml.g4dn.2xlarge, ml.g5.2xlarge und ml.p3.2xlarge. Dies sollte einen angemessenen Querschnitt der Leistung über die folgenden Metriken für jede Instanz und jeden Modelltyp bieten:

• Maximale Anzahl von Modellen, die in den GPU-Speicher geladen werden können
• End-to-End-Antwortlatenz, die auf der Clientseite für jede Inferenzabfrage beobachtet wurde
• Maximaler Durchsatz von Abfragen pro Sekunde, die der Endpunkt fehlerfrei verarbeiten kann
• Max. aktuelle Benutzer pro Instanz, bevor eine fehlgeschlagene Anforderung festgestellt wird

Die folgende Tabelle listet die getesteten Modelle auf.

In der folgenden Tabelle sind die getesteten GPU-Instanzen aufgeführt.

Wie bereits erwähnt, ist die Codebeispiel kann auf andere Modelle und Instanztypen übernommen werden.

Beachten Sie, dass MMEs derzeit nur einzelne GPU-Instanzen unterstützen. Eine Liste der unterstützten Instance-Typen finden Sie unter Unterstützte Algorithmen, Frameworks und Instanzen.

Das Benchmarking-Verfahren besteht aus den folgenden Schritten:

1. Rufen Sie ein vorab trainiertes Modell von einem Modell-Hub ab.
2. Bereiten Sie das Modellartefakt für die Bereitstellung auf SageMaker-MMEs vor (siehe Führen Sie mehrere Deep-Learning-Modelle auf der GPU mit Amazon SageMaker-Multimodell-Endpunkten aus für mehr Details).
3. Stellen Sie eine SageMaker-MME auf einer GPU-Instanz bereit.
4. Bestimmen Sie die maximale Anzahl von Modellen, die innerhalb eines bestimmten Schwellenwerts in den GPU-Speicher geladen werden können.
5. Verwenden Sie das Locust Load Testing Framework, um Datenverkehr zu simulieren, der zufällig auf die Instanz geladene Modelle aufruft.
6. Sammeln Sie Daten und analysieren Sie die Ergebnisse.
7. Wiederholen Sie optional die Schritte 2–6, nachdem Sie das Modell in TensorRT kompiliert haben.

Die Schritte 4 und 5 rechtfertigen einen tieferen Einblick. Modelle innerhalb einer SageMaker-GPU-MME werden dynamisch in den Arbeitsspeicher geladen. Daher laden wir in Schritt 4 ein erstes Modellartefakt in hoch Amazon Simple Storage-Service (Amazon S3) und rufen Sie das Modell auf, um es in den Arbeitsspeicher zu laden. Nach dem ersten Aufruf messen wir die Menge des verbrauchten GPU-Speichers, erstellen eine Kopie des ursprünglichen Modells, rufen die Kopie des Modells auf, um sie in den Speicher zu laden, und messen erneut die Gesamtmenge des verbrauchten GPU-Speichers. Dieser Vorgang wird wiederholt, bis ein bestimmter Prozentsatz der GPU-Speicherauslastung erreicht ist. Für den Benchmark haben wir den Schwellenwert auf 90 % festgelegt, um einen angemessenen Speicherpuffer für Rückschlüsse auf größere Stapel bereitzustellen oder etwas Platz zum Laden anderer, weniger häufig verwendeter Modelle zu lassen.

Benutzerverkehr simulieren

Nachdem wir die Anzahl der Modelle ermittelt haben, können wir einen Belastungstest mit dem durchführen Locust-Lasttest-Framework. Der Lasttest simuliert Benutzeranfragen an zufällige Modelle und misst automatisch Metriken wie Antwortlatenz und Durchsatz.

Locust unterstützt benutzerdefinierte Lasttestformen, mit denen Sie benutzerdefinierte Datenverkehrsmuster definieren können. Die Form, die in diesem Benchmark verwendet wurde, ist in der folgenden Tabelle dargestellt. In den ersten 30 Sekunden wird der Endpunkt mit 10 gleichzeitigen Benutzern aufgewärmt. Nach 30 Sekunden werden neue Benutzer mit einer Rate von zwei pro Sekunde erzeugt, wobei nach 20 Sekunden 40 gleichzeitige Benutzer erreicht werden. Der Endpunkt wird dann kontinuierlich mit 20 gleichzeitigen Benutzern bis zur 60-Sekunden-Marke bewertet, an welchem ​​Punkt Locust wieder damit beginnt, die Anzahl der Benutzer mit zwei pro Sekunde auf 40 gleichzeitige Benutzer hochzufahren. Dieses Muster aus Hochfahren und stetigem Testen wird wiederholt, bis der Endpunkt auf 200 gleichzeitige Benutzer hochgefahren ist. Abhängig von Ihrem Anwendungsfall möchten Sie möglicherweise die Lasttestform in locust_benchmark_sm.py anpassen, um Ihre erwarteten Verkehrsmuster genauer widerzuspiegeln. Wenn Sie beispielsweise beabsichtigen, größere Sprachmodelle zu hosten, ist ein Auslastungstest mit 200 gleichzeitigen Benutzern für ein Modell, das auf einer einzelnen Instanz gehostet wird, möglicherweise nicht durchführbar, und Sie möchten daher möglicherweise die Anzahl der Benutzer reduzieren oder die Anzahl der Instanzen erhöhen. Sie können auch die Dauer des Belastungstests verlängern, um die Stabilität des Endpunkts über einen längeren Zeitraum genauer einzuschätzen.

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

Beachten Sie, dass wir den Endpunkt nur mit homogenen Modellen bewertet haben, die alle auf einer konsistenten Bereitstellungsbasis mit PyTorch oder TensorRT ausgeführt werden. Dies liegt daran, dass MMEs am besten zum Hosten vieler Modelle mit ähnlichen Eigenschaften wie Speicherverbrauch und Antwortzeit geeignet sind. Die Benchmarking-Vorlagen in der GitHub Repo kann immer noch verwendet werden, um zu bestimmen, ob die Bereitstellung heterogener Modelle auf MMEs die gewünschte Leistung und Stabilität erbringen würde.

Benchmark-Ergebnisse für CV-Modelle

Verwenden Sie das Notebook cv-benchmark.ipynb, um Belastungstests für Computer-Vision-Modelle auszuführen. Sie können den vorab trainierten Modellnamen und die Parameter des Instance-Typs an Leistungslasttests für verschiedene Modell- und Instance-Typ-Kombinationen anpassen. Wir haben bewusst drei CV-Modelle in verschiedenen Größenbereichen vom kleinsten bis zum größten getestet: resnet50 (25 M), convnext_base (88 M) und vit_large_patch16_224 (304M). Möglicherweise müssen Sie den Code anpassen, wenn Sie ein Modell außerhalb dieser Liste auswählen. Darüber hinaus setzt das Notebook die Eingangsbildform standardmäßig auf einen 224 x 224 x 3-Bildtensor. Denken Sie daran, die Eingabeform entsprechend anzupassen, wenn Sie Modelle vergleichen müssen, die ein Bild unterschiedlicher Größe aufnehmen.

Nachdem Sie das gesamte Notebook durchlaufen haben, erhalten Sie mehrere Leistungsanalyse-Visualisierungen. Die ersten beiden beschreiben die Modellleistung im Hinblick auf die Zunahme gleichzeitiger Benutzer. Die folgenden Abbildungen sind Beispielvisualisierungen, die für die generiert wurden ResNet50 Modell, das auf ml.g4dn.2xlarge ausgeführt wird und PyTorch (links) mit TensorRT (rechts) vergleicht. Die oberen Liniendiagramme zeigen die Latenz und den Durchsatz des Modells auf der Y-Achse, wobei die zunehmende Anzahl gleichzeitiger Client-Worker auf der X-Achse widergespiegelt wird. Die unteren Balkendiagramme zeigen die Anzahl erfolgreicher und fehlgeschlagener Anfragen.

Bei der Betrachtung aller von uns getesteten Computer-Vision-Modelle haben wir Folgendes festgestellt:

• Bei größeren Modellen (resnet50 > convnext_base > vit_large_patch16_224).
• Die Latenz erhöht sich proportional zur Anzahl der Benutzer, wenn mehr Anforderungen auf dem Inferenzserver in die Warteschlange gestellt werden.
• Große Modelle verbrauchen mehr Rechenressourcen und können ihre maximalen Durchsatzgrenzen mit weniger Benutzern erreichen als ein kleineres Modell. Dies wird mit der beobachtet vit_large_patch16_224 Modell, das die erste fehlgeschlagene Anfrage bei 140 gleichzeitigen Benutzern aufzeichnete. Da es deutlich größer als die beiden anderen getesteten Modelle war, hatte es auch die meisten fehlgeschlagenen Anfragen bei höherer Parallelität. Dies ist ein klares Signal dafür, dass der Endpunkt über eine einzelne Instanz hinaus skaliert werden muss, wenn mehr als 140 gleichzeitige Benutzer unterstützt werden sollen.

Am Ende des Notebook-Laufs erhalten Sie außerdem einen zusammenfassenden Vergleich der PyTorch- und TensorRT-Modelle für jede der vier Schlüsselmetriken. Aus unseren Benchmark-Tests ging hervor, dass die CV-Modelle nach der TensorRT-Kompilierung alle eine Steigerung der Modellleistung verzeichneten. Unter unserer ResNet50 Modell als Beispiel, sank die Latenz um 32 %, während der Durchsatz um 18 % stieg. Obwohl die maximale Anzahl gleichzeitiger Benutzer für gleich geblieben ist ResNet50, verzeichneten die beiden anderen Modelle eine 14-prozentige Verbesserung der Anzahl gleichzeitiger Benutzer, die sie unterstützen können. Die TensorRT-Leistungsverbesserung ging jedoch zu Lasten einer höheren Speicherauslastung, was dazu führte, dass weniger Modelle von MMEs geladen wurden. Die Auswirkungen sind eher für Modelle, die ein Convolutional Neural Network (CNN) verwenden. Tatsächlich verbrauchte unser ResNet50-Modell von PyTorch zu TensorRT ungefähr doppelt so viel GPU-Speicher, was zu 50 % weniger geladenen Modellen führte (46 gegenüber 23). Wir diagnostizieren dieses Verhalten weiter im folgenden Abschnitt.

Benchmark-Ergebnisse für NLP-Modelle

Verwenden Sie für die NLP-Modelle das Notebook nlp-benchmark.ipynb, um den Auslastungstest auszuführen. Die Einrichtung des Notebooks sollte sehr ähnlich aussehen. Wir haben zwei NLP-Modelle getestet: bert-base-uncased (109M) und roberta-large (335M). Das vorab trainierte Modell und der Tokenizer werden beide vom Hugging Face-Hub heruntergeladen, und die Testnutzlast wird vom Tokenizer unter Verwendung einer Beispielzeichenfolge generiert. Die maximale Sequenzlänge ist standardmäßig auf 128 eingestellt. Wenn Sie längere Zeichenfolgen testen müssen, denken Sie daran, diesen Parameter anzupassen. Beim Durchlaufen des NLP-Notizbuchs werden dieselben Visualisierungen generiert: Pytorch (links) vs. TensorRT (rechts).

Von diesen haben wir noch mehr Leistungsvorteile von TensorRT für NLP-Modelle beobachtet. Unter der roberta-large Modell auf einer ml.g4dn.2xlarge-Instanz verringerte sich beispielsweise die Inferenzlatenz dramatisch von 180 Millisekunden auf 56 Millisekunden (eine Verbesserung um 70 %), während sich der Durchsatz um 406 % von 33 Anfragen pro Sekunde auf 167 verbesserte. Außerdem die maximale Anzahl gleichzeitiger Benutzer um 50 % gestiegen; Fehlgeschlagene Anfragen wurden nicht beobachtet, bis wir 180 gleichzeitige Benutzer erreichten, verglichen mit 120 beim ursprünglichen PyTorch-Modell. In Bezug auf die Speicherauslastung haben wir gesehen, dass ein Modell weniger für TensorRT geladen wurde (von neun Modellen auf acht). Die negativen Auswirkungen sind jedoch viel geringer im Vergleich zu dem, was wir bei den CNN-basierten Modellen beobachtet haben.

Analyse der Speicherauslastung

Die folgende Tabelle zeigt die vollständige Analyse der Auswirkungen auf die Speicherauslastung von PyTorch zu TensorRT. Wir haben bereits erwähnt, dass CNN-basierte Modelle stärker negativ beeinflusst werden. Der ResNet50 model hatte eine über 50 % geringere Anzahl von Modellen, die über alle drei GPU-Instance-Typen geladen wurden. Convnext_base hatte eine noch größere Reduzierung bei etwa 70 % auf der ganzen Linie. Andererseits sind die Auswirkungen auf die Transformatormodelle gering oder gemischt. vit_large_patch16_224 und roberta-large hatte eine durchschnittliche Reduzierung von etwa 20 % bzw. 3 %, während bert-base-uncased Hatte eine Verbesserung von etwa 40%.

Betrachtet man alle Datenpunkte als Ganzes in Bezug auf die überlegene Leistung in Bezug auf Latenz, Durchsatz und Zuverlässigkeit und die geringen Auswirkungen auf die maximale Anzahl geladener Modelle, empfehlen wir das TensorRT-Modell für transformatorbasierte Modellarchitekturen. Für CNNs glauben wir, dass weitere Kosten-Leistungs-Analysen erforderlich sind, um sicherzustellen, dass der Leistungsvorteil die Kosten für zusätzliche Hosting-Infrastruktur aufwiegt.

In den folgenden Tabellen sind unsere vollständigen Benchmark-Ergebnisse für alle Metriken für alle drei GPU-Instanztypen aufgeführt.

Die folgende Tabelle fasst die Ergebnisse für alle Instance-Typen zusammen. Die ml.g5.2xlarge-Instanz bietet die beste Leistung, während die ml.p3.2xlarge-Instanz im Allgemeinen unterdurchschnittlich abschneidet, obwohl sie die teuerste der drei ist. Die g5- und g4dn-Instances zeigen den besten Wert für Inferenz-Workloads.

Aufräumen

Bereinigen Sie nach Abschluss des Auslastungstests die generierten Ressourcen, um zusätzliche Gebühren zu vermeiden. Die Hauptressourcen sind die SageMaker-Endpunkte und Modellartefaktdateien in Amazon S3. Um es Ihnen leicht zu machen, haben die Notebook-Dateien den folgenden Bereinigungscode, der Ihnen beim Löschen hilft:

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

Zusammenfassung

In diesem Beitrag haben wir unsere Testergebnisse und Analysen für verschiedene tiefe neuronale Netzwerkmodelle geteilt, die auf SageMaker-Multimodell-Endpunkten mit GPU ausgeführt werden. Die von uns geteilten Ergebnisse und Erkenntnisse sollten einen angemessenen Querschnitt der Leistung über verschiedene Metriken und Instanztypen hinweg bieten. Dabei haben wir auch unseren empfohlenen Ansatz zum Ausführen von Benchmark-Tests für SageMaker-MMEs mit GPU vorgestellt. Die von uns bereitgestellten Tools und Beispielcodes können Ihnen helfen, Ihre Benchmark-Tests schnell zu starten und eine fundiertere Entscheidung darüber zu treffen, wie Sie Hunderte von DNN-Modellen auf beschleunigter Rechenhardware kostengünstig hosten können. Um mit dem Benchmarking Ihrer eigenen Modelle mit MME-Unterstützung für GPU zu beginnen, beziehen Sie sich auf Unterstützte Algorithmen, Frameworks und Instanzen und für GitHub Repo für weitere Beispiele und Dokumentation.

Über die Autoren

James Wu ist Senior AI/ML Specialist Solution Architect bei AWS. Unterstützung von Kunden bei der Entwicklung und Erstellung von KI/ML-Lösungen. Die Arbeit von James deckt ein breites Spektrum von ML-Anwendungsfällen ab, wobei sein Hauptinteresse auf Computer Vision, Deep Learning und der Skalierung von ML im gesamten Unternehmen liegt. Bevor er zu AWS kam, war James über 10 Jahre lang Architekt, Entwickler und Technologieführer, davon 6 Jahre im Ingenieurwesen und 4 Jahre in der Marketing- und Werbebranche.

Vikram Elango ist AI/ML Specialist Solutions Architect bei Amazon Web Services mit Sitz in Virginia, USA. Vikram unterstützt Kunden aus der Finanz- und Versicherungsbranche mit Design und Vordenkertum bei der Erstellung und Bereitstellung von Anwendungen für maschinelles Lernen in großem Maßstab. Derzeit konzentriert er sich auf die Verarbeitung natürlicher Sprache, verantwortungsbewusste KI, Inferenzoptimierung und Skalierung von ML im gesamten Unternehmen. In seiner Freizeit reist er gerne, wandert, kocht und campt mit seiner Familie.

Simon Zamarin ist ein AI / ML Solutions Architect, dessen Hauptaugenmerk darauf liegt, Kunden dabei zu helfen, Wert aus ihren Datenbeständen zu ziehen. In seiner Freizeit verbringt Simon gerne Zeit mit seiner Familie, liest Science-Fiction und arbeitet an verschiedenen DIY-Hausprojekten.

Saurabh Trikande ist Senior Product Manager für Amazon SageMaker Inference. Er arbeitet leidenschaftlich gerne mit Kunden zusammen und ist motiviert von dem Ziel, maschinelles Lernen zu demokratisieren. Er konzentriert sich auf die Kernherausforderungen im Zusammenhang mit der Bereitstellung komplexer ML-Anwendungen, mandantenfähigen ML-Modellen, Kostenoptimierungen und der leichteren Bereitstellung von Deep-Learning-Modellen. In seiner Freizeit wandert Saurabh gerne, lernt etwas über innovative Technologien, folgt TechCrunch und verbringt Zeit mit seiner Familie.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/