Erzielen Sie Hyperscale-Leistung für die Modellbereitstellung mit NVIDIA Triton Inference Server auf Amazon SageMaker

Anwendungen für maschinelles Lernen (ML) sind komplex in der Bereitstellung und erfordern oft mehrere ML-Modelle, um eine einzelne Inferenzanforderung zu bedienen. Eine typische Anfrage kann über mehrere Modelle hinweg fließen und Schritte wie Vorverarbeitung, Datentransformationen, Modellauswahllogik, Modellaggregation und Nachverarbeitung umfassen. Dies hat zur Entwicklung gängiger Entwurfsmuster wie serieller Inferenzpipelines, Ensembles (Scatter Gather) und Geschäftslogik-Workflows geführt, was dazu führte, dass der gesamte Workflow der Anfrage als gerichteter azyklischer Graph (DAG) realisiert wurde. Wenn Arbeitsabläufe jedoch komplexer werden, führt dies zu einer Erhöhung der Gesamtreaktionszeiten oder Latenzzeiten dieser Anwendungen, was sich wiederum auf das gesamte Benutzererlebnis auswirkt. Wenn diese Komponenten außerdem auf verschiedenen Instanzen gehostet werden, erhöht die zusätzliche Netzwerklatenz zwischen diesen Instanzen die Gesamtlatenz. Betrachten Sie ein Beispiel für einen beliebten ML-Anwendungsfall für einen virtuellen Assistenten im Kundensupport. Eine typische Anfrage muss möglicherweise mehrere Schritte durchlaufen, darunter Spracherkennung, Verarbeitung natürlicher Sprache (NLP), Verfolgung des Dialogstatus, Dialogrichtlinie, Textgenerierung und schließlich Text-to-Speech. Um die Benutzerinteraktion personalisierter zu gestalten, können Sie außerdem moderne, transformatorbasierte NLP-Modelle wie verschiedene Versionen von verwenden BERT, BART und GPT. Das Endergebnis sind lange Reaktionszeiten für diese Modellensembles und ein schlechtes Kundenerlebnis.

Ein gängiges Muster, um kürzere Antwortzeiten zu erzielen, ohne den Gesamtdurchsatz zu beeinträchtigen, besteht darin, diese Modelle zusammen mit der darin eingebetteten einfachen Geschäftslogik auf derselben Instanz zu hosten. Diese Modelle können außerdem in einzelnen oder mehreren Containern auf derselben Instanz gekapselt werden, um laufende Prozesse zu isolieren und die Latenz niedrig zu halten. Darüber hinaus hängt die Gesamtlatenz auch von der Logik der Inferenzanwendung, Modelloptimierungen, der zugrunde liegenden Infrastruktur (einschließlich Rechenleistung, Speicher und Netzwerk) und dem zugrunde liegenden Webserver ab, der Inferenzanforderungen entgegennimmt. NVIDIA Triton-Inferenzserver ist eine Open-Source-Inferenzbereitstellungssoftware mit Funktionen zur Maximierung des Durchsatzes und der Hardwareauslastung bei extrem niedriger Inferenzlatenz (einstellige Millisekunden). Es bietet umfassende Unterstützung für ML-Frameworks (einschließlich TensorFlow, PyTorch, ONNX, XGBoost und NVIDIA TensorRT) und Infrastruktur-Backends, einschließlich GPUs, CPUs usw AWS-Inferenz. Darüber hinaus ist Triton Inference Server integriert Amazon Sage Maker, ein vollständig verwalteter End-to-End-ML-Dienst, der Echtzeit-Inferenzoptionen bietet, einschließlich Single und Multi-Modell Hosting. Zu diesen Inferenzoptionen gehört das Hosten mehrerer Modelle innerhalb desselben Containers hinter einem einzelner Endpunkt, und Hosting mehrere Modelle mit mehreren Behältern hinter einem einzelnen Endpunkt.

Im November 2021 haben wir es bekannt gegeben die Integration von Triton Inference Server auf SageMaker. AWS hat eng mit NVIDIA zusammengearbeitet, damit Sie das Beste aus beiden Welten nutzen und die Modellbereitstellung mit Triton auf AWS einfacher gestalten können.

In diesem Beitrag betrachten wir Best Practices für die skalierte Bereitstellung von Transformer-Modellen auf GPUs mithilfe von Triton Inference Server auf SageMaker. Zunächst beginnen wir mit einer Zusammenfassung der wichtigsten Konzepte rund um die Latenz in SageMaker und einem Überblick über Richtlinien zur Leistungsoptimierung. Als Nächstes geben wir einen Überblick über Triton und seine Funktionen sowie Beispielcode für die Bereitstellung auf SageMaker. Abschließend führen wir Auslastungstests mit durch SageMaker-Inferenz-Empfehler und fassen die Erkenntnisse und Schlussfolgerungen aus Lasttests eines beliebten Transformatormodells zusammen, die von Hugging Face bereitgestellt wurden.

Sie können das überprüfen Notizbuch Früher haben wir mithilfe des Codes selbst Modelle bereitgestellt und Auslastungstests durchgeführt GitHub.

Leistungsoptimierung und Optimierung für die Modellbereitstellung auf SageMaker

Die Leistungsoptimierung und -optimierung ist ein empirischer Prozess, der häufig mehrere Iterationen umfasst. Die Anzahl der abzustimmenden Parameter ist kombinatorisch und der Satz von Konfigurationsparameterwerten ist nicht unabhängig voneinander. Verschiedene Faktoren wirken sich auf die optimale Parameteroptimierung aus, darunter Payload-Größe, Typ und Anzahl der ML-Modelle im Inferenz-Anforderungsflussdiagramm, Speichertyp, Compute-Instanztyp, Netzwerkinfrastruktur, Anwendungscode, Softwarelaufzeit und -konfiguration für Inferenzdienste und mehr.

Wenn Sie SageMaker für die Bereitstellung von ML-Modellen verwenden, müssen Sie eine Recheninstanz mit dem besten Preis-Leistungs-Verhältnis auswählen. Dies ist ein komplizierter und iterativer Prozess, der wochenlange Experimente erfordern kann. Zunächst müssen Sie aus über 70 Optionen den richtigen ML-Instanztyp auswählen, basierend auf den Ressourcenanforderungen Ihrer Modelle und der Größe der Eingabedaten. Als Nächstes müssen Sie das Modell für den ausgewählten Instanztyp optimieren. Schließlich müssen Sie die Infrastruktur bereitstellen und verwalten, um Lasttests durchzuführen und die Cloud-Konfiguration für optimale Leistung und Kosten abzustimmen. All dies kann die Modelleinführung und die Markteinführung verzögern. Darüber hinaus müssen Sie die Kompromisse zwischen Latenz, Durchsatz und Kosten bewerten, um die optimale Bereitstellungskonfiguration auszuwählen. SageMaker-Inferenz-Empfehler wählt automatisch den richtigen Recheninstanztyp, die richtige Instanzanzahl, die richtigen Containerparameter und Modelloptimierungen für die Inferenz aus, um den Durchsatz zu maximieren, die Latenz zu reduzieren und die Kosten zu minimieren.

Echtzeit-Inferenz und Latenz in SageMaker

SageMaker-Echtzeit-Inferenz ist ideal für Inferenz-Workloads, bei denen Sie Anforderungen an Echtzeit, Interaktivität und geringe Latenz haben. Es gibt vier am häufigsten verwendete Metriken zur Überwachung der Inferenzanfragelatenz für SageMaker-Inferenzendpunkte

• Containerlatenz – Die Zeit, die benötigt wird, um die Anfrage zu senden, die Antwort aus dem Container des Modells abzurufen und die Inferenz im Container abzuschließen. Diese Metrik ist in Amazon CloudWatch als Teil verfügbar Aufrufmetriken veröffentlicht von SageMaker.
• Modelllatenz – Die Gesamtzeit aller SageMaker-Container in einer Inferenzpipeline. Diese Metrik ist in Amazon CloudWatch als Teil verfügbar Aufrufmetriken veröffentlicht von SageMaker.
• Overhead-Latenz – Gemessen vom Zeitpunkt, an dem SageMaker die Anfrage empfängt, bis zur Rückgabe einer Antwort an den Client, abzüglich der Modelllatenz. Diese Metrik ist in Amazon CloudWatch als Teil verfügbar Aufrufmetriken veröffentlicht von SageMaker.
• Ende-zu-Ende-Latenz – Gemessen von dem Zeitpunkt an, an dem der Client die Inferenzanforderung sendet, bis er eine Antwort zurückerhält. Kunden können dies als benutzerdefinierte Metrik in Amazon CloudWatch veröffentlichen.

Das folgende Diagramm veranschaulicht diese Komponenten.

Containerlatenz hängt von mehreren Faktoren ab; die folgenden gehören zu den wichtigsten:

• Zugrunde liegendes Protokoll (HTTP(s)/gRPC), das für die Kommunikation mit dem Inferenzserver verwendet wird
• Overhead im Zusammenhang mit der Erstellung neuer TLS-Verbindungen
• Deserialisierungszeit der Anforderungs-/Antwortnutzlast
• Fordern Sie Warteschlangen- und Stapelfunktionen an, die vom zugrunde liegenden Inferenzserver bereitgestellt werden
• Fordern Sie Planungsfunktionen an, die vom zugrunde liegenden Inferenzserver bereitgestellt werden
• Zugrunde liegende Laufzeitleistung des Inferenzservers
• Leistung von Vorverarbeitungs- und Nachverarbeitungsbibliotheken vor dem Aufruf der Modellvorhersagefunktion
• Zugrunde liegende ML-Framework-Back-End-Leistung
• Modellspezifische und hardwarespezifische Optimierungen

In diesem Beitrag konzentrieren wir uns hauptsächlich auf die Optimierung der Containerlatenz sowie des Gesamtdurchsatzes und der Kosten. Insbesondere untersuchen wir die Leistungsoptimierung des Triton Inference Servers, der in einem SageMaker-Container ausgeführt wird.

Anwendungsfallübersicht

Die Bereitstellung und Skalierung von NLP-Modellen in einer Produktionsumgebung kann eine große Herausforderung darstellen. NLP-Modelle sind oft sehr groß und enthalten Millionen von Modellparametern. Um die strengen Leistungs- und Skalierbarkeitsanforderungen von NLP-Anwendungen in Produktionsqualität zu erfüllen, sind optimale Modellkonfigurationen erforderlich.

In diesem Beitrag vergleichen wir einen NLP-Anwendungsfall mit einem SageMaker-Echtzeitendpunkt, der auf einem Triton Inference Server-Container basiert, und empfehlen Optimierungen zur Leistungsoptimierung für unseren ML-Anwendungsfall. Wir verwenden ein großes, vorab trainiertes, transformatorbasiertes Hugging Face BERT groß ohne Gehäuse Modell, das etwa 336 Millionen Modellparameter hat. Der für das binäre Klassifizierungsmodell verwendete Eingabesatz wird aufgefüllt und auf eine maximale Eingabesequenzlänge von 512 Tokens gekürzt. Der Inferenzlasttest simuliert 500 Aufrufe pro Sekunde (maximal 30,000 Aufrufe pro Minute) und ModelLatency von weniger als 0.5 Sekunden (500 Millisekunden).

Die folgende Tabelle fasst unsere Benchmark-Konfiguration zusammen.

NVIDIA Triton-Inferenzserver

Der Triton Inference Server wurde speziell entwickelt, um eine skalierbare, schnelle und einfache Bereitstellung von Modellen in der Produktion zu ermöglichen. Triton unterstützt eine Vielzahl wichtiger KI-Frameworks, darunter TensorFlow, TensorRT, PyTorch, XGBoost und ONNX. Mit dem benutzerdefinierten Python- und C++-Backend können Sie Ihre Inferenz-Workload auch für individuellere Anwendungsfälle implementieren.

Am wichtigsten ist, dass Triton ein einfaches konfigurationsbasiertes Setup zum Hosten Ihrer Modelle bietet, das eine Vielzahl von Leistungsoptimierungsfunktionen bietet, die Sie mit geringem Programmieraufwand nutzen können.

Triton erhöht die Inferenzleistung durch Maximierung der Hardwareauslastung mit verschiedenen Optimierungstechniken (gleichzeitige Modellläufe und dynamische Stapelverarbeitung werden am häufigsten verwendet). Das Finden der optimalen Modellkonfigurationen aus verschiedenen Kombinationen dynamischer Batchgrößen und der Anzahl gleichzeitiger Modellinstanzen ist der Schlüssel zum Erreichen von Echtzeitinferenzen im Rahmen einer kostengünstigen Bereitstellung mit Triton.

Dynamische Stapelverarbeitung

Viele Praktiker neigen dazu, die Inferenz nacheinander auszuführen, wenn der Server mit mehreren unabhängigen Anforderungen aufgerufen wird. Obwohl die Einrichtung einfacher ist, ist es normalerweise nicht die beste Vorgehensweise, die Rechenleistung der GPU zu nutzen. Um dieses Problem zu lösen, bietet Triton die integrierten Optimierungen von dynamisches Batching diese unabhängigen Inferenzanforderungen auf der Serverseite zu kombinieren, um dynamisch einen größeren Stapel zu bilden und so den Durchsatz zu erhöhen. Das folgende Diagramm veranschaulicht die Triton-Laufzeitarchitektur.

In der vorherigen Architektur erreichen alle Anforderungen zuerst den dynamischen Batcher, bevor sie in die eigentlichen Modell-Scheduler-Warteschlangen gelangen, um auf Rückschlüsse zu warten. Mit können Sie Ihre bevorzugten Chargengrößen für die dynamische Stapelverarbeitung festlegen bevorzugte_Batch_Größe Einstellungen in der Modellkonfiguration. (Beachten Sie, dass die gebildete Chargengröße kleiner sein muss als max_batch_size das Modell unterstützt.) Sie können auch konfigurieren max_queue_delay_microseconds um die maximale Verzögerungszeit im Batcher anzugeben, um auf andere Anforderungen zu warten, um dem Batch beizutreten, basierend auf Ihren Latenzanforderungen.

Der folgende Codeausschnitt zeigt, wie Sie diese Funktion mit Modellkonfigurationsdateien hinzufügen können, um die dynamische Stapelverarbeitung mit einer bevorzugten Stapelgröße von 16 für die eigentliche Inferenz festzulegen. Mit den aktuellen Einstellungen wird die Modellinstanz sofort aufgerufen, wenn die bevorzugte Batch-Größe von 16 erreicht ist oder die Verzögerungszeit von 100 Mikrosekunden abgelaufen ist, seit die erste Anforderung den dynamischen Batcher erreicht hat.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Gleichzeitige Ausführung von Modellen

Eine weitere wesentliche Optimierung, die Triton bietet, um die Hardwareauslastung ohne zusätzlichen Latenz-Overhead zu maximieren, ist gleichzeitige Modellausführung, wodurch mehrere Modelle oder mehrere Kopien desselben Modells parallel ausgeführt werden können. Diese Funktion ermöglicht es Triton, mehrere Inferenzanfragen gleichzeitig zu verarbeiten, was den Inferenzdurchsatz erhöht, indem ansonsten ungenutzte Rechenleistung auf der Hardware genutzt wird.

Die folgende Abbildung zeigt, wie Sie mit nur wenigen Zeilen Codeänderungen problemlos verschiedene Modellbereitstellungsrichtlinien konfigurieren können. Konfiguration A (links) zeigt beispielsweise, dass Sie dieselbe Konfiguration von zwei Modellinstanzen von übertragen können bert-large-uncased an alle verfügbaren GPUs. Im Gegensatz dazu zeigt Konfiguration B (Mitte) eine andere Konfiguration nur für GPU 0, ohne die Richtlinien auf den anderen GPUs zu ändern. Sie können auch Instanzen verschiedener Modelle auf einer einzelnen GPU bereitstellen, wie in Konfiguration C (rechts) gezeigt.

In Konfiguration C kann die Recheninstanz zwei gleichzeitige Anforderungen für das DistilGPT-2-Modell und sieben gleichzeitige Anforderungen für das verarbeiten bert-large-uncased Modell parallel. Mit diesen Optimierungen können die Hardwareressourcen besser für den Bereitstellungsprozess genutzt werden, wodurch der Durchsatz verbessert und eine bessere Kosteneffizienz für Ihre Arbeitslast erzielt wird.

TensorRT

NVIDIA TensorRT ist ein SDK für leistungsstarke Deep-Learning-Inferenz, das nahtlos mit Triton zusammenarbeitet. TensorRT, das alle wichtigen Deep-Learning-Frameworks unterstützt, umfasst einen Inferenzoptimierer und eine Laufzeit, die eine geringe Latenz und einen hohen Durchsatz für die Ausführung von Inferenzen mit riesigen Datenmengen durch leistungsstarke Optimierungen bietet.

TensorRT optimiert das Diagramm, um den Speicherbedarf zu minimieren, indem unnötiger Speicher freigegeben und effizient wiederverwendet wird. Darüber hinaus fusioniert die TensorRT-Kompilierung die spärlichen Operationen innerhalb des Modelldiagramms, um einen größeren Kernel zu bilden, um den Overhead mehrerer kleiner Kernel-Starts zu vermeiden. Durch die Kernel-Autooptimierung können Sie die Hardware voll ausnutzen, indem Sie den besten Algorithmus auf Ihrer Ziel-GPU auswählen. CUDA-Streams ermöglichen die parallele Ausführung von Modellen, um Ihre GPU-Auslastung für beste Leistung zu maximieren. Zu guter Letzt kann die Quantisierungstechnik die Mixed-Precision-Beschleunigung der Tensorkerne vollständig nutzen, um das Modell in FP32, TF32, FP16 und INT8 auszuführen und so die beste Inferenzleistung zu erzielen.

Triton auf SageMaker-Hosting

SageMaker-Hosting Dienste sind eine Reihe von SageMaker-Funktionen, die darauf abzielen, die Bereitstellung und Bereitstellung von Modellen zu vereinfachen. Es bietet eine Vielzahl von Optionen zum einfachen Bereitstellen, automatischen Skalieren, Überwachen und Optimieren von ML-Modellen, die auf verschiedene Anwendungsfälle zugeschnitten sind. Das bedeutet, dass Sie Ihre Bereitstellungen für alle Arten von Nutzungsmustern optimieren können, von persistent und immer verfügbar mit serverlosen Optionen bis hin zu vorübergehenden, lang andauernden oder Batch-Inferenz-Anforderungen.

Unter dem Dach des SageMaker-Hostings befindet sich auch eine Reihe von SageMaker-Inferenz-Deep-Learning-Containern (DLCs), die mit der entsprechenden Modellserversoftware für das entsprechende unterstützte ML-Framework vorgefertigt sind. Dadurch können Sie eine hohe Inferenzleistung erzielen, ohne dass ein Modellserver eingerichtet werden muss, was häufig der komplexeste technische Aspekt der Modellbereitstellung ist und im Allgemeinen nicht zu den Fähigkeiten eines Datenwissenschaftlers gehört. Der Triton-Inferenzserver ist jetzt verfügbar verfügbar auf SageMaker Deep Learning Containern (DLC).

Diese Breite an Optionen, Modularität und Benutzerfreundlichkeit verschiedener Bereitstellungs-Frameworks macht SageMaker und Triton zu einer leistungsstarken Kombination.

SageMaker Inference Recommender zum Benchmarking von Testergebnissen

Wir verwenden SageMaker Inference Recommender, um unsere Experimente durchzuführen. SageMaker Inference Recommender bietet zwei Arten von Jobs: Standardjobs und erweiterte Jobs, wie im folgenden Diagramm dargestellt.

Der Standardjob bietet Empfehlungen zu Instanztypen mit nur dem Modell und einer Beispielnutzlast zum Benchmarking. Neben Instanzempfehlungen bietet der Dienst auch Laufzeitparameter, die die Leistung verbessern. Die Empfehlungen des Standardjobs sollen die Instanzensuche eingrenzen. In einigen Fällen könnte es sich um die Instanzfamilie handeln, in anderen um die spezifischen Instanztypen. Die Ergebnisse des Standardjobs werden dann in den erweiterten Job eingespeist.

Der erweiterte Job bietet mehr Steuerelemente zur weiteren Feinabstimmung der Leistung. Diese Steuerungen simulieren die realen Umgebungs- und Produktionsanforderungen. Zu diesen Kontrollen gehört das Verkehrsmuster, das darauf abzielt, das Anforderungsmuster für die Benchmarks bereitzustellen. Mithilfe der mehreren Phasen des Verkehrsmusters können Sie Rampen oder einen gleichmäßigen Verkehr festlegen. Zum Beispiel ein InitialNumberOfUsers von 1, SpawnRate von 1 und DauerInSekunden von 600 kann zu einem Rampenverkehr von 10 Minuten mit einem gleichzeitigen Benutzer am Anfang und 1 am Ende führen. Zusätzlich zu den Bedienelementen MaxInvocations und ModelLatencyThresholds Legen Sie den Produktionsschwellenwert fest. Wenn also einer der Schwellenwerte überschritten wird, stoppt das Benchmarking.

Schließlich Empfehlungsmetriken umfassen Durchsatz, Latenz bei maximalem Durchsatz und Kosten pro Inferenz, sodass sie leicht verglichen werden können.

Wir verwenden den erweiterten Auftragstyp von SageMaker Inference Recommender, um unsere Experimente durchzuführen, um zusätzliche Kontrolle über die Verkehrsmuster zu erlangen und die Konfiguration des Bereitstellungscontainers zu optimieren.

Versuchsaufbau

Wir verwenden die benutzerdefinierte Lasttestfunktion von SageMaker Inference Recommender, um das in unserem Anwendungsfall beschriebene NLP-Profil zu vergleichen. Wir definieren zunächst die folgenden Voraussetzungen in Bezug auf das NLP-Modell und die ML-Aufgabe. SageMaker Inference Recommender verwendet diese Informationen, um ein Inferenz-Docker-Image abzurufen Amazon Elastic Container-Registrierung (Amazon ECR) und registrieren Sie das Modell bei der SageMaker-Modellregistrierung.

Die Verkehrsmusterkonfigurationen im SageMaker Inference Recommender ermöglichen es uns, verschiedene Phasen für den benutzerdefinierten Auslastungstest zu definieren. Der Auslastungstest beginnt mit zwei Erstbenutzern und erzeugt jede Minute zwei neue Benutzer für eine Gesamtdauer von 25 Minuten (1500 Sekunden), wie im folgenden Code dargestellt:

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

Wir experimentieren mit Lasttests desselben Modells in zwei verschiedenen Zuständen. Die PyTorch-basierten Experimente verwenden das standardmäßige, unveränderte PyTorch-Modell. Für die TensorRT-basierten Experimente konvertieren wir das PyTorch-Modell zuvor in eine TensorRT-Engine.

Wir wenden bei diesen beiden Modellen unterschiedliche Kombinationen der Leistungsoptimierungsfunktionen an, die in der folgenden Tabelle zusammengefasst sind.

Testergebnisse und Beobachtungen

Wir haben Lasttests für drei Instanztypen innerhalb derselben g4dn-Familie durchgeführt: ml.g4dn.xlarge, ml.g4dn.2xlarge und ml.g4dn.12xlarge. Alle g4dn-Instance-Typen haben Zugriff auf NVIDIA T4 Tensor Core-GPUs und Intel Cascade Lake-Prozessoren der 2. Generation. Die Logik hinter der Wahl der Instanztypen bestand darin, sowohl eine Instanz mit nur einer verfügbaren GPU als auch eine Instanz mit Zugriff auf mehrere GPUs zu haben – vier im Fall von ml.g4dn.12xlarge. Darüber hinaus wollten wir testen, ob eine Erhöhung der vCPU-Kapazität auf der Instanz mit nur einer verfügbaren GPU zu einer Verbesserung des Kosten-Leistungs-Verhältnisses führen würde.

Gehen wir zunächst die Beschleunigung der einzelnen Optimierung durch. Die folgende Grafik zeigt, dass die TensorRT-Optimierung eine Reduzierung der Modelllatenz um 50 % im Vergleich zur nativen Optimierung in PyTorch auf der ml.g4dn.xlarge-Instanz bietet. Diese Latenzreduzierung erhöht sich auf den Multi-GPU-Instanzen von ml.g4dn.12xlarge auf mehr als das Dreifache. Unterdessen ist die Durchsatzverbesserung um 30 % auf beiden Instanzen konsistent, was zu einer besseren Kosteneffizienz nach der Anwendung von TensorRT-Optimierungen führt.

Mit dynamischer Stapelverarbeitung können wir bei Verwendung der gleichen Hardwarearchitektur bei allen Experimentinstanzen von ml.g2dn.xlarge, ml.g4dn.4xlarge und ml.g2dn.4xlarge eine nahezu zweifache Verbesserung des Durchsatzes erzielen, ohne dass sich die Latenz merklich erhöht.

In ähnlicher Weise können wir durch die gleichzeitige Modellausführung eine etwa 3- bis 4-fache Verbesserung des Durchsatzes erzielen, indem wir die GPU-Auslastung auf der ml.g4dn.xlarge-Instanz maximieren, und eine etwa 2-fache Verbesserung sowohl auf der ml.g4dn.2xlarge-Instanz als auch auf der Multi-GPU-Instanz von ml. g4dn.12xlarge.. Diese Durchsatzsteigerung erfolgt ohne Overhead in der Latenz.

Besser noch: Wir können alle diese Optimierungen integrieren, um die beste Leistung zu erzielen und dabei die Hardware-Ressourcen optimal zu nutzen. Die folgende Tabelle und Grafiken fassen die Ergebnisse unserer Experimente zusammen.

[1] Die anfängliche Instanzanzahl in der obigen Tabelle ist die empfohlene Anzahl von Instanzen, die mit einer Autoskalierungsrichtlinie verwendet werden sollen, um die Durchsatz- und Latenzanforderungen für Ihre Arbeitslast aufrechtzuerhalten.

[2] Die Kosten pro Stunde in der obigen Tabelle werden basierend auf der Anzahl der anfänglichen Instanzen und dem Preis für den Instanztyp berechnet.

Die Ergebnisse bestätigen hauptsächlich die Auswirkungen, die von verschiedenen Leistungsoptimierungsfunktionen erwartet wurden:

• Die TensorRT-Kompilierung hat die zuverlässigste Auswirkung auf alle Instanztypen. Die Transaktionen pro Minute und Instanz stiegen um 30–35 %, mit einer konsistenten Kostenreduzierung von etwa 25 % im Vergleich zur Leistung der TensorRT-Engine im Vergleich zum Standard-PyTorch-BERT (pt-base). Die erhöhte Leistung der TensorRT-Engine wird durch die anderen getesteten Leistungsoptimierungsfunktionen verstärkt und genutzt.
• Durch das Laden von zwei Modellen auf jede GPU (Instanzgruppe) wurden alle gemessenen Metriken nahezu verdoppelt. Die Aufrufe pro Minute und Instanz stiegen um etwa 80–90 %, was zu einer Kostenreduzierung im Bereich von 50 % führte, fast so, als ob wir zwei GPUs verwenden würden. In der Tat, Amazon CloudWatch Die Metriken für unsere Experimente zu g4dn.2xlarge (als Beispiel) bestätigen, dass sich sowohl die CPU- als auch die GPU-Auslastung verdoppeln, wenn wir eine Instanzgruppe aus zwei Modellen konfigurieren.

Weitere Tipps zur Leistungs- und Kostenoptimierung

Der in diesem Beitrag vorgestellte Benchmark hat nur an der Oberfläche der möglichen Funktionen und Techniken gekratzt, die Sie mit Triton zur Verbesserung der Inferenzleistung verwenden können. Diese reichen von Datenvorverarbeitungstechniken wie dem Senden binärer Nutzlasten an den Modellserver oder Nutzlasten mit größeren Stapeln bis hin zu nativen Triton-Funktionen wie den folgenden:

• Aufwärmen des ModellsDies verhindert anfängliche, langsame Inferenzanfragen, indem das Modell vollständig initialisiert wird, bevor die erste Inferenzanfrage empfangen wird.
• Antwortcache, das wiederholte Anfragen zwischenspeichert.
• Modell-Ensemble, wodurch Sie eine Pipeline aus einem oder mehreren Modellen und die Verbindung von Eingabe- und Ausgabetensoren zwischen diesen Modellen erstellen können. Dies eröffnet die Möglichkeit, dem Verarbeitungsablauf für jede Anfrage Vorverarbeitungs- und Nachverarbeitungsschritte oder sogar Rückschlüsse auf andere Modelle hinzuzufügen.

Wir gehen davon aus, diese Techniken und Funktionen in einem zukünftigen Beitrag zu testen und zu vergleichen. Bleiben Sie also auf dem Laufenden!

Zusammenfassung

In diesem Beitrag haben wir einige Parameter untersucht, die Sie verwenden können, um die Leistung Ihres SageMaker-Echtzeitendpunkts für die Bereitstellung von PyTorch-BERT-Modellen mit Triton Inference Server zu maximieren. Wir haben SageMaker Inference Recommender verwendet, um die Benchmarking-Tests zur Feinabstimmung dieser Parameter durchzuführen. Diese Parameter hängen im Wesentlichen mit der TensorRT-basierten Modelloptimierung zusammen, was zu einer Verbesserung der Antwortzeiten um fast 50 % im Vergleich zur nicht optimierten Version führt. Darüber hinaus führte die gleichzeitige Ausführung von Modellen und die Verwendung der dynamischen Stapelung von Triton zu einer Durchsatzsteigerung von fast 70 %. Die Feinabstimmung dieser Parameter führte insgesamt auch zu einer Reduzierung der Inferenzkosten.

Der beste Weg, die richtigen Werte abzuleiten, ist durch Experimentieren. Um jedoch mit dem Aufbau empirischer Kenntnisse zur Leistungsoptimierung und -optimierung zu beginnen, können Sie die Kombinationen verschiedener Triton-bezogener Parameter und deren Auswirkungen auf die Leistung von ML-Modellen und SageMaker ML-Instanzen beobachten.

SageMaker bietet die Tools, um die undifferenzierte Schwerarbeit in jeder Phase des ML-Lebenszyklus zu beseitigen und so das schnelle Experimentieren und Erkunden zu erleichtern, das zur vollständigen Optimierung Ihrer Modellbereitstellungen erforderlich ist.

Das für Lasttests und Bereitstellung verwendete Notebook finden Sie unter GitHub. Sie können Triton-Konfigurationen und SageMaker Inference Recommender-Einstellungen so aktualisieren, dass sie optimal zu Ihrem Anwendungsfall passen, um kostengünstige Inferenz-Workloads mit der besten Leistung zu erzielen.

Über die Autoren

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.

Joao Moura ist ein KI/ML-Spezialist für Lösungsarchitekten bei Amazon Web Services. Er konzentriert sich hauptsächlich auf NLP-Anwendungsfälle und hilft Kunden bei der Optimierung der Schulung und Bereitstellung von Deep-Learning-Modellen. Er ist außerdem ein aktiver Befürworter von Low-Code-ML-Lösungen und ML-spezialisierter Hardware.

Mohan Gandhi ist Senior Software Engineer bei AWS. Er ist seit 9 Jahren bei AWS und hat an verschiedenen AWS-Services wie EMR, EFA und RDS auf Outposts gearbeitet. Derzeit konzentriert er sich auf die Verbesserung der SageMaker Inference Experience. In seiner Freizeit wandert er gerne und läuft Marathons.

Dhawal Patel ist Principal Machine Learning Architect bei AWS. Er hat mit Organisationen von großen Unternehmen bis hin zu mittelständischen Startups an Problemen im Zusammenhang mit verteiltem Computing und künstlicher Intelligenz gearbeitet. Er konzentriert sich auf Deep Learning, einschließlich NLP- und Computer Vision-Domänen. Er hilft Kunden, hochleistungsfähige Modellinferenz auf SageMaker zu erreichen.

Santosh Bhavani ist Senior Technical Product Manager beim Amazon SageMaker Elastic Inference-Team. Er konzentriert sich darauf, SageMaker-Kunden dabei zu helfen, die Inferenz und Bereitstellung von Modellen zu beschleunigen. In seiner Freizeit reist er gerne, spielt Tennis und trinkt viel Pu'er-Tee.

Jiahong Liu ist Solution Architect im Cloud Service Provider-Team bei NVIDIA. Er unterstützt Kunden bei der Einführung von Lösungen für maschinelles Lernen und KI, die NVIDIA Accelerated Computing nutzen, um ihre Trainings- und Inferenzherausforderungen zu bewältigen. In seiner Freizeit beschäftigt er sich gerne mit Origami, DIY-Projekten und spielt Basketball.

• Coinsmart. Europas beste Bitcoin- und Krypto-Börse.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. DEN FREIEN ZUGANG.
• CryptoHawk. Altcoin-Radar. Kostenlose Testphase.
• Quelle: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/