Erzielen Sie Hosting mit geringer Latenz für entscheidungsbaumbasierte ML-Modelle auf NVIDIA Triton Inference Server auf Amazon SageMaker

Die Bereitstellung von Modellen für maschinelles Lernen (ML) kann für Unternehmen heute sehr hohe Leistungs- und Latenzanforderungen haben. Anwendungsfälle wie Betrugserkennung und Anzeigenplatzierung sind Beispiele, bei denen es auf Millisekunden ankommt und entscheidend für den Geschäftserfolg ist. Es müssen strenge Vereinbarungen zum Servicelevel (SLAs) eingehalten werden, und eine typische Anfrage kann mehrere Schritte erfordern, z. B. Vorverarbeitung, Datentransformation, Modellauswahllogik, Modellaggregation und Nachbearbeitung. In der Größenordnung bedeutet dies oft, ein riesiges Datenverkehrsvolumen bei gleichzeitig geringer Latenz aufrechtzuerhalten. Zu den gängigen Designmustern gehören serielle Inferenzpipelines, Ensembles (Scatter-Gather) und Geschäftslogik-Workflows, die dazu führen, dass der gesamte Workflow der Anfrage als Directed Acyclic Graph (DAG) realisiert wird. Wenn Workflows jedoch komplexer werden, kann dies zu einer Verlängerung der Gesamtreaktionszeiten führen, was sich wiederum negativ auf die Endbenutzererfahrung auswirken und die Geschäftsziele gefährden kann. Triton kann diese Anwendungsfälle adressieren, bei denen mehrere Modelle in einer Pipeline mit miteinander verbundenen Eingabe- und Ausgabetensoren zusammengesetzt sind, und hilft Ihnen, diese Workloads zu bewältigen.

Wenn Sie Ihre Ziele in Bezug auf die ML-Modellinferenz bewerten, können viele Optionen in Betracht gezogen werden, aber nur wenige sind so leistungsfähig und bewährt wie Amazon Sage Maker mit Triton Inferenzserver. SageMaker mit Triton Inference Server ist bei vielen Kunden eine beliebte Wahl, da es speziell entwickelt wurde, um den Durchsatz und die Hardwareauslastung mit einer extrem niedrigen (einstelligen Millisekunde) Inferenzlatenz zu maximieren. Es verfügt über eine breite Palette unterstützter ML-Frameworks (einschließlich TensorFlow, PyTorch, ONNX, XGBoost und NVIDIA TensorRT) und Infrastruktur-Backends, einschließlich NVIDIA-GPUs, CPUs und AWS-Inferenz. Darüber hinaus ist Triton Inference Server in SageMaker integriert, einem vollständig verwalteten End-to-End-ML-Dienst, der Echtzeit-Inferenzoptionen für das Hosting von Modellen bietet.

In diesem Beitrag führen wir die Bereitstellung einer Betrugserkennungs-Ensemble-Workload für SageMaker mit Triton Inference Server durch.

Lösungsüberblick

Es ist für jedes Projekt unerlässlich, eine Liste der Anforderungen und eine Aufwandsschätzung zu haben, um die Gesamtkosten des Projekts ungefähr abschätzen zu können. Es ist wichtig, den Return on Investment (ROI) zu schätzen, der die Entscheidung einer Organisation stützt. Einige Überlegungen, die beim Verschieben einer Workload nach Triton zu berücksichtigen sind, sind:

Die Aufwandsschätzung ist der Schlüssel in der Softwareentwicklung, und ihre Messung basiert oft auf unvollständigen, unsicheren und verrauschten Eingaben. ML-Workloads sind nicht anders. Mehrere Faktoren wirken sich auf eine Architektur für ML-Inferenz aus, von denen einige umfassen:

• Clientseitiges Latenzbudget – Es gibt die maximal akzeptable Wartezeit für den clientseitigen Roundtrip für eine Inferenzantwort an, die üblicherweise in Perzentilen ausgedrückt wird. Für Workloads, die ein Latenzbudget von fast mehreren zehn Millisekunden erfordern, könnten Netzwerkübertragungen teuer werden, sodass die Verwendung von Modellen am Rand besser geeignet wäre.
• Größe der Datennutzlastverteilung – Nutzlast, oft bezeichnet als Nachrichtentext, sind die vom Client an das Modell übermittelten Anfragedaten sowie die vom Modell an den Client übermittelten Antwortdaten. Die Nutzlastgröße hat oft einen großen Einfluss auf die Latenz und sollte berücksichtigt werden.
• Datei Format – Dies gibt an, wie die Nutzdaten an das ML-Modell gesendet werden. Das Format kann für Menschen lesbar sein, z. B. JSON und CSV, es gibt jedoch auch binäre Formate, die häufig komprimiert und kleiner sind. Dies ist ein Kompromiss zwischen Komprimierungs-Overhead und Übertragungsgröße, was bedeutet, dass CPU-Zyklen und Latenz zum Komprimieren oder Dekomprimieren hinzugefügt werden, um über das Netzwerk übertragene Bytes einzusparen. Dieser Beitrag zeigt, wie Sie sowohl JSON- als auch Binärformate verwenden.
• Erforderlicher Software-Stack und Komponenten – Ein Stack ist eine Sammlung von Komponenten, die zusammenarbeiten, um eine ML-Anwendung zu unterstützen, einschließlich Betriebssystem, Laufzeiten und Softwareschichten. Triton verfügt über integrierte beliebte ML-Frameworks namens Backends, wie ONNX, TensorFlow, FIL, OpenVINO, natives Python und andere. Sie können auch a schreiben benutzerdefiniertes Backend für Ihre selbstgebauten Komponenten. In diesem Beitrag geht es um ein XGBoost-Modell und eine Datenvorverarbeitung, die wir auf die von NVIDIA bereitgestellten FIL- bzw. Python Triton-Backends migrieren.

All diese Faktoren sollten eine wichtige Rolle bei der Bewertung der Leistung Ihrer Workloads spielen, aber in diesem Anwendungsfall konzentrieren wir uns auf die Arbeit, die erforderlich ist, um Ihre ML-Modelle zu verschieben, damit sie in SageMaker mit Triton Inference Server gehostet werden. Insbesondere verwenden wir ein Beispiel für ein Ensemble zur Betrugserkennung, das aus einem XGBoost-Modell mit in Python geschriebener Vorverarbeitungslogik besteht.

NVIDIA Triton-Inferenzserver

Triton Inference Server wurde von Grund auf so konzipiert, dass Teams trainierte KI-Modelle von jedem Framework auf GPU- oder CPU-basierten Infrastrukturen bereitstellen, ausführen und skalieren können. Darüber hinaus wurde es optimiert, um leistungsstarke Inferenz in großem Maßstab mit Funktionen wie dynamischem Batching, gleichzeitigen Läufen, optimaler Modellkonfiguration, Modellensemble und Unterstützung für Streaming-Eingaben zu bieten.

Das folgende Diagramm zeigt ein Beispiel für eine NVIDIA Triton-Ensemble-Pipeline.

Workloads sollten die Funktionen berücksichtigen, die Triton zusammen mit SageMaker-Hosting bietet, um die angebotenen Vorteile zu maximieren. Beispielsweise unterstützt Triton sowohl HTTP als auch a C-API, die bei Bedarf Flexibilität sowie Nutzlastoptimierung ermöglichen. Wie bereits erwähnt, unterstützt Triton mehrere beliebte Frameworks, darunter TensorFlow, PyTorch, ONNX, XGBoost und NVIDIA TensorRT. Diese Frameworks werden durch Triton-Backends unterstützt, und in dem seltenen Fall, dass ein Backend Ihren Anwendungsfall nicht unterstützt, Mit Triton können Sie Ihre eigenen implementieren und einfach integrieren.

Das folgende Diagramm zeigt ein Beispiel der NVIDIA Triton-Architektur.

NVIDIA Triton auf SageMaker

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 der Satz von SageMaker-Inferenz-Deep-Learning-Containern (DLCs), die mit der entsprechenden Modellserversoftware für ihr entsprechendes unterstütztes ML-Framework vorinstalliert sind. Dadurch können Sie eine hohe Inferenzleistung ohne Modellserver-Setup erzielen, was oft der komplexeste technische Aspekt der Modellbereitstellung ist und im Allgemeinen nicht zu den Fähigkeiten eines Datenwissenschaftlers gehört. Triton Inference Server ist jetzt verfügbar auf SageMaker-DLCs.

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

NVIDIA FIL-Backend-Unterstützung

Mit der Version 22.05 von Triton, NVIDIA unterstützt jetzt Waldmodelle, die von mehreren beliebten ML-Frameworks trainiert werden, darunter XGBoost, LightGBM, Scikit-learn und cuML. Wenn Sie das FIL-Back-End für Triton verwenden, sollten Sie sicherstellen, dass die von Ihnen bereitgestellten Modellartefakte unterstützt werden. Beispielsweise unterstützt FIL model_type xgboost, xgboost_json, lightgbm, oder treelite_checkpoint, die angibt, ob das bereitgestellte Modell im XGBoost-Binärformat, im XGBoost-JSON-Format, im LightGBM-Textformat oder im Treelite-Binärformat vorliegt.

Diese Backend-Unterstützung ist für uns in unserem Beispiel unerlässlich, da FIL XGBoost-Modelle unterstützt. Die einzige zu prüfende Überlegung besteht darin, sicherzustellen, dass das von uns bereitgestellte Modell Binär- oder JSON-Formate unterstützt.

Neben der Sicherstellung, dass Sie das richtige Modellformat haben, sollten andere Überlegungen angestellt werden. Das FIL-Backend für Triton bietet konfigurierbare Optionen für Entwickler, um ihre Workloads zu optimieren und die Modellausführungsleistung zu optimieren. Die Konfiguration dynamic_batching ermöglicht es Triton, clientseitige Anforderungen zu speichern und sie auf der Serverseite zu bündeln, um die parallele Berechnung von FIL effizient zu nutzen, um den gesamten Stapel zusammenzuschließen. Die Option max_queue_delay_microseconds bietet eine ausfallsichere Kontrolle darüber, wie lange Triton wartet, um eine Charge zu bilden. FIL wird mit Shapley Explainer geliefert, der durch die Konfiguration aktiviert werden kann treeshap_output; Sie sollten jedoch bedenken, dass Shapley-Ausgaben aufgrund ihrer Ausgabegröße die Leistung beeinträchtigen. Ein weiterer wichtiger Aspekt ist storage_type um zwischen Speicherbedarf und Laufzeit abzuwägen. Beispielsweise kann die Verwendung von Speicher als SPARSE den Speicherverbrauch reduzieren, während DENSE die Ausführungsleistung Ihres Modells auf Kosten einer höheren Speichernutzung reduzieren kann. Die Entscheidung für die jeweils beste Wahl hängt von Ihrer Workload und Ihrem Latenzbudget ab, daher empfehlen wir Ihnen, sich alle Optionen genauer anzusehen Häufig gestellte Fragen zum FIL-Backend und für Liste der in FIL verfügbaren Konfigurationen.

Schritte zum Hosten eines Modells auf Triton

Sehen wir uns unseren Anwendungsfall zur Betrugserkennung als Beispiel dafür an, was beim Verschieben einer Workload zu Triton zu beachten ist.

Identifizieren Sie Ihre Arbeitsbelastung

In diesem Anwendungsfall haben wir ein Betrugserkennungsmodell, das während des Bezahlvorgangs eines Einzelhandelskunden verwendet wird. Die Inferenzpipeline verwendet einen XGBoost-Algorithmus mit Vorverarbeitungslogik, die eine Datenvorbereitung für die Vorverarbeitung umfasst.

Identifizieren Sie aktuelle und angestrebte Leistungskennzahlen und andere möglicherweise zutreffende Ziele

Sie werden möglicherweise feststellen, dass Ihre End-to-End-Inferenzzeit zu lange dauert, um akzeptabel zu sein. Ihr Ziel könnte es sein, bei gleichem Anfragevolumen und entsprechendem Durchsatz von mehreren zehn Millisekunden Latenz auf eine einstellige Latenz zu kommen. Sie stellen fest, dass der Großteil der Zeit von der Datenvorverarbeitung und dem XGBoost-Modell verbraucht wird. Andere Faktoren wie die Größe des Netzwerks und der Nutzdaten spielen eine minimale Rolle bei dem Overhead, der mit der Ende-zu-Ende-Inferenzzeit verbunden ist.

Arbeiten Sie rückwärts, um festzustellen, ob Triton Ihren Workload basierend auf Ihren Anforderungen hosten kann

Um festzustellen, ob Triton Ihre Anforderungen erfüllen kann, sollten Sie zwei Hauptbereiche beachten. Die erste besteht darin, sicherzustellen, dass Triton mit einer akzeptablen Front-End-Option wie HTTP oder C-API dienen kann.

Wie bereits erwähnt, ist es auch wichtig festzustellen, ob Triton ein Backend unterstützt, das Ihre Artefakte bedienen kann. Triton unterstützt eine Reihe von Backends die maßgeschneidert sind, um verschiedene Frameworks wie PyTorch und TensorFlow zu unterstützen. Stellen Sie sicher, dass Ihre Modelle unterstützt werden und dass Sie das richtige Modellformat haben, das Triton erwartet. Überprüfen Sie dazu zunächst, welche Modellformate das Triton-Backend unterstützt. In vielen Fällen erfordert dies keine Änderungen am Modell. In anderen Fällen muss Ihr Modell möglicherweise in ein anderes Format umgewandelt werden. Je nach Quell- und Zielformat bestehen verschiedene Möglichkeiten, wie z. B. das Transformieren a Python-Pickle-Datei zur Verwendung des binären Checkpoint-Formats von Treelite.

Für diesen Anwendungsfall ermitteln wir die FIL-Backend das XGBoost-Modell unterstützen kann, ohne dass Änderungen erforderlich sind, und dass wir die verwenden können Python-Backend für die Vorverarbeitung. Mit der Ensemble-Funktion von Triton können Sie Ihre Arbeitslast weiter optimieren, indem Sie kostspielige Netzwerkaufrufe zwischen Hosting-Instanzen vermeiden.

Erstellen Sie einen Plan und schätzen Sie den Aufwand ab, der erforderlich ist, um Triton für das Hosting zu verwenden

Lassen Sie uns über den Plan sprechen, Ihre Modelle zu Triton zu verschieben. Jede Triton-Bereitstellung erfordert Folgendes:

• Modellartefakte, die von Triton-Backends benötigt werden
• Triton-Konfigurationsdateien
• Ein Modell-Repository-Ordner mit der richtigen Struktur

Wir zeigen ein Beispiel dafür, wie diese Bereitstellungsabhängigkeiten später in diesem Beitrag erstellt werden.

Führen Sie den Plan aus und validieren Sie die Ergebnisse

Nachdem Sie die erforderlichen Dateien und Artefakte im ordnungsgemäß strukturierten Modellrepository erstellt haben, müssen Sie Ihre Bereitstellung optimieren und testen, um zu bestätigen, dass Sie jetzt Ihre Zielmetriken erreicht haben.

An dieser Stelle können Sie SageMaker-Inferenz-Empfehler um zu bestimmen, welcher Endpunkt-Instance-Typ basierend auf Ihren Anforderungen am besten für Sie geeignet ist. Darüber hinaus stellt Triton Tools bereit, um Build-Optimierungen vorzunehmen, um eine bessere Leistung zu erzielen.

Sytemimplementierung

Sehen wir uns nun die Implementierungsdetails an. Dafür haben wir zwei Notebooks vorbereitet, die exemplarisch zeigen, was zu erwarten ist. Das erstes Notizbuch zeigt das Training des angegebenen XGBoost-Modells sowie die Vorverarbeitungslogik, die sowohl für die Trainings- als auch für die Inferenzzeit verwendet wird. Das zweites Notizbuch zeigt, wie wir die Artefakte vorbereiten, die für den Einsatz auf Triton benötigt werden.

Das erste Notizbuch zeigt ein vorhandenes Notizbuch Ihrer Organisation, das die verwendet SCHNELLE Suite von Bibliotheken und dem RAPIDS Conda-Kernel. Diese Instance wird auf einem von AWS bereitgestellten G4DN-Instance-Typ ausgeführt, der durch die Verwendung von NVIDIA T4-Prozessoren GPU-beschleunigt wird.

Vorverarbeitungsaufgaben in diesem Beispiel profitieren von der GPU-Beschleunigung und nutzen stark die cuML- und cuDF-Bibliotheken. Ein Beispiel dafür finden Sie im folgenden Code, in dem wir die Codierung von kategorialen Labels mit cuML zeigen. Wir generieren auch eine label_encoders.pkl Datei, die wir verwenden können, um die Encoder zu serialisieren und sie für die Vorverarbeitung während der Inferenzzeit zu verwenden.

Das erste Notebook schließt mit dem Training unseres XGBoost-Modells und dem entsprechenden Speichern der Artefakte ab.

In diesem Szenario war der Trainingscode bereits vorhanden und es sind keine Änderungen für das Modell zum Trainingszeitpunkt erforderlich. Obwohl wir die GPU-Beschleunigung für die Vorverarbeitung während des Trainings verwendet haben, planen wir außerdem, CPUs für die Vorverarbeitung zur Inferenzzeit zu verwenden. Wir erklären mehr später im Beitrag.

Lassen Sie uns nun zum zweiten Notebook übergehen und uns daran erinnern, was wir für eine erfolgreiche Triton-Bereitstellung benötigen.

Zunächst benötigen wir die von Backends benötigten Modellartefakte. Die Dateien, die wir für dieses Ensemble erstellen müssen, umfassen:

• Vorverarbeitungsartefakte (model.py, label_encoders.pkl)
• XGBoost-Modellartefakte (xgboost.json)

Das Python-Backend in Triton erfordert, dass wir eine Conda-Umgebung als Abhängigkeit verwenden. In diesem Fall verwenden wir das Python-Backend, um die Rohdaten vorzuverarbeiten, bevor wir sie in das XGBoost-Modell einspeisen, das im FIL-Backend ausgeführt wird. Obwohl wir ursprünglich RAPIDS cuDF- und cuML-Bibliotheken verwendet haben, um die Datenvorverarbeitung durchzuführen (wie zuvor unter Verwendung unserer GPU erwähnt), verwenden wir hier Pandas und Scikit-learn als Vorverarbeitungsabhängigkeiten für die Inferenzzeit (unter Verwendung unserer CPU). Wir tun dies aus drei Gründen:

• Um zu zeigen, wie Sie eine Conda-Umgebung für Ihre Abhängigkeiten erstellen und wie Sie sie in die Format erwartet von Tritons Python-Backend.
• Indem wir zeigen, wie das Vorverarbeitungsmodell im Python-Backend auf der CPU ausgeführt wird, während das XGBoost-Modell auf der GPU im FIL-Backend ausgeführt wird, veranschaulichen wir, wie jedes Modell in der Ensemble-Pipeline von Triton auf einem anderen Framework-Backend und auf unterschiedlicher Hardware mit unterschiedlichem ausgeführt werden kann Konfigurationen.
• Es zeigt, wie die RAPIDS-Bibliotheken (cuDF, cuML) mit ihren CPU-Gegenstücken (Pandas, Scikit-learn) kompatibel sind. So können wir zeigen, wie LabelEncoders In cuML erstellte Dateien können in Scikit-learn verwendet werden und umgekehrt. Beachten Sie, dass Sie, wenn Sie erwarten, große Mengen tabellarischer Daten während der Inferenzzeit vorzuverarbeiten, immer noch RAPIDS zur GPU-Beschleunigung verwenden können.

Denken Sie daran, dass wir die erstellt haben label_encoders.pkl Datei im ersten Notizbuch. Für die Kategoriecodierung gibt es nichts weiter zu tun, als sie in unsere aufzunehmen model.py Datei zur Vorverarbeitung.

Um die vom Triton-Python-Backend benötigte model.py-Datei zu erstellen, halten wir uns an die vom Backend benötigte Formatierung und schließen Sie unsere Python-Logik ein, um den eingehenden Tensor zu verarbeiten und den zuvor erwähnten Label-Encoder zu verwenden. Sie können die überprüfen Datei zur Vorverarbeitung verwendet.

Für das XGBoost-Modell muss nichts weiter getan werden. Wir haben das Modell im ersten Notebook trainiert und das FIL-Backend von Triton erfordert keinen zusätzlichen Aufwand für XGBoost-Modelle.

Als nächstes benötigen wir die Triton-Konfigurationsdateien. Jedes Modell im Triton-Ensemble benötigt a config.pbtxt Datei. Darüber hinaus erstellen wir auch eine config.pbtxt Datei für das gesamte Ensemble. Diese Dateien ermöglichen es Triton, Metadaten über das Ensemble mit Informationen wie den von uns erwarteten Eingaben und Ausgaben zu kennen, und helfen bei der Definition des DAG, der dem Ensemble zugeordnet ist.

Um schließlich ein Modell auf Triton bereitzustellen, benötigen wir unseren Modell-Repository-Ordner, um die richtige Ordnerstruktur zu haben. Triton hat spezifische Anforderungen an das Layout des Modellrepositorys. Innerhalb des Modell-Repository-Verzeichnisses der obersten Ebene hat jedes Modell sein eigenes Unterverzeichnis, das die Informationen für das entsprechende Modell enthält. Jedes Modellverzeichnis in Triton muss mindestens ein numerisches Unterverzeichnis haben, das eine Version des Modells darstellt. Für unseren Anwendungsfall sollte die resultierende Struktur wie folgt aussehen.

Nachdem wir diese drei Voraussetzungen haben, erstellen wir eine komprimierte Datei als Verpackung für die Bereitstellung und laden sie in hoch Amazon Simple Storage-Service (Amazon S3).

Wir können jetzt ein SageMaker-Modell aus dem Modell-Repository erstellen, das wir im vorherigen Schritt auf Amazon S3 hochgeladen haben.

In diesem Schritt stellen wir auch die zusätzliche Umgebungsvariable bereit SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, der den Namen des von Triton zu ladenden Modells angibt. Der Wert dieses Schlüssels sollte mit dem Ordnernamen im Modellpaket übereinstimmen, das auf Amazon S3 hochgeladen wurde. Bei einem Einzelmodell ist diese Variable optional. Bei Ensemble-Modellen muss dieser Schlüssel angegeben werden, damit Triton in SageMaker gestartet werden kann.

Zusätzlich können Sie einstellen SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT und SAGEMAKER_TRITON_THREAD_COUNT zur Optimierung der Fadenzahlen. Beide Konfigurationswerte helfen dabei, die Anzahl der Threads zu optimieren, die auf Ihren CPUs ausgeführt werden, sodass Sie möglicherweise eine bessere Auslastung erzielen können, indem Sie diese Werte für CPUs mit einer größeren Anzahl von Kernen erhöhen. In den meisten Fällen funktionieren die Standardwerte oft gut, aber es kann sich lohnen, zu experimentieren, um zu sehen, ob für Ihre Workloads weitere Effizienz erzielt werden kann.

Mit dem vorherigen Modell erstellen wir eine Endpunktkonfiguration, in der wir den Typ und die Anzahl der Instanzen angeben können, die wir im Endpunkt haben möchten.

Zuletzt verwenden wir die vorherige Endpunktkonfiguration, um einen neuen SageMaker-Endpunkt zu erstellen, und warten, bis die Bereitstellung abgeschlossen ist. Der Status ändert sich zu InService nachdem die Bereitstellung erfolgreich war.

Das ist es! Ihr Endpunkt ist jetzt zum Testen und Validieren bereit. An dieser Stelle möchten Sie möglicherweise verschiedene Tools verwenden, um Ihre Instance-Typen und -Konfigurationen zu optimieren, um die bestmögliche Leistung zu erzielen. Die folgende Abbildung zeigt ein Beispiel für die Gewinne, die durch die Verwendung des FIL-Backends für ein XGBoost-Modell auf Triton erzielt werden können.

Zusammenfassung

In diesem Beitrag haben wir Sie durch die Bereitstellung einer XGBoost-Ensemble-Workload für SageMaker mit Triton Inference Server geführt. Das Verschieben von Workloads nach Triton auf SageMaker kann eine vorteilhafte Kapitalrendite sein. Wie bei jeder Technologieeinführung sind ein Überprüfungsprozess und -plan der Schlüssel, und wir haben einen fünfstufigen Prozess detailliert beschrieben, der Sie durch das führt, was Sie beim Verschieben Ihrer Workloads beachten sollten. Darüber hinaus haben wir uns eingehend mit den Schritten befasst, die zum Bereitstellen eines Ensembles erforderlich sind, das die Python-Vorverarbeitung und ein XGBoost-Modell auf Triton auf SageMaker verwendet.

SageMaker bietet die Tools, um das undifferenzierte Heavy Lifting aus jeder Phase des ML-Lebenszyklus zu entfernen, wodurch das schnelle Experimentieren und Erkunden erleichtert wird, das zur vollständigen Optimierung Ihrer Modellimplementierungen erforderlich ist. SageMaker-Hosting-Unterstützung für Triton Inference Server ermöglicht Workloads mit geringer Latenz und hohen Transaktionen pro Sekunde (TPS).

Die für dieses Beispiel verwendeten Notebooks finden Sie auf GitHub.

---

Über den Autor

James Park ist Lösungsarchitekt bei Amazon Web Services. Er arbeitet mit Amazon.com zusammen, um Technologielösungen auf AWS zu entwerfen, zu entwickeln und bereitzustellen, und hat ein besonderes Interesse an KI und maschinellem Lernen. In seiner Freizeit sucht er gerne nach neuen Kulturen, neuen Erfahrungen und hält sich über die neuesten Technologietrends auf dem Laufenden.

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.

Kshitiz Gupta ist Lösungsarchitekt bei NVIDIA. Es macht ihm Spaß, Cloud-Kunden über die GPU-KI-Technologien von NVIDIA aufzuklären und sie bei der Beschleunigung ihrer Anwendungen für maschinelles Lernen und Deep Learning zu unterstützen. Außerhalb der Arbeit geht er gerne laufen, wandern und Wildtiere beobachten.

Bruno Aguiar de Melo ist Softwareentwicklungsingenieur bei Amazon.com, wo er Wissenschaftsteams beim Erstellen, Bereitstellen und Freigeben von ML-Workloads unterstützt. Er interessiert sich für instrumentelle und kontrollierbare Aspekte innerhalb der ML-Modellierungs-/Designphase, die berücksichtigt und gemessen werden müssen, mit der Erkenntnis, dass die Modellausführungsleistung genauso wichtig ist wie die Modellqualitätsleistung, insbesondere in Anwendungsfällen mit eingeschränkter Latenz. In seiner Freizeit genießt er Wein, Gesellschaftsspiele und Kochen.

Eliuth Triana ist Developer Relations Manager bei NVIDIA. Er verbindet Amazon- und AWS-Produktleiter, Entwickler und Wissenschaftler mit NVIDIA-Technologen und Produktleitern, um Amazon ML/DL-Workloads, EC2-Produkte und AWS-KI-Services zu beschleunigen. Außerdem ist Eliuth leidenschaftlicher Mountainbiker, Skifahrer und Pokerspieler.