Entwurfsmuster für serielle Inferenz auf Amazon SageMaker

Da maschinelles Lernen (ML) zum Mainstream wird und eine breitere Akzeptanz findet, werden ML-gestützte Anwendungen immer häufiger eingesetzt, um eine Reihe komplexer Geschäftsprobleme zu lösen. Die Lösung dieser komplexen Geschäftsprobleme erfordert oft die Verwendung mehrerer ML-Modelle. Diese Modelle können nacheinander kombiniert werden, um verschiedene Aufgaben auszuführen, wie z. B. Vorverarbeitung, Datentransformation, Modellauswahl, Inferenzgenerierung, Inferenzkonsolidierung und Nachbearbeitung. Unternehmen benötigen flexible Optionen, um diese komplexen ML-Workflows zu orchestrieren. Serielle Inferenzpipelines sind ein solches Entwurfsmuster, um diese Workflows in einer Reihe von Schritten anzuordnen, wobei jeder Schritt die von den vorherigen Schritten generierte Ausgabe anreichert oder weiterverarbeitet und die Ausgabe an den nächsten Schritt in der Pipeline weiterleitet.

Darüber hinaus sollten diese seriellen Inferenzpipelines Folgendes bieten:

• Flexible und kundenspezifische Implementierung (Abhängigkeiten, Algorithmen, Geschäftslogik usw.)
• Wiederholbar und konsistent für die Produktionsimplementierung
• Undifferenziertes schweres Heben durch Minimierung des Infrastrukturmanagements

In diesem Beitrag betrachten wir einige gängige Anwendungsfälle für serielle Inferenz-Pipelines und gehen einige Implementierungsoptionen für jeden dieser Anwendungsfälle durch Amazon Sage Maker. Wir diskutieren auch Überlegungen für jede dieser Implementierungsoptionen.

Die folgende Tabelle fasst die verschiedenen Anwendungsfälle für serielle Inferenz, Überlegungen zur Implementierung und Optionen zusammen. Diese werden in diesem Beitrag besprochen.

In den folgenden Abschnitten gehen wir detaillierter auf jeden Anwendungsfall ein.

Serielle Inferenzpipeline mit Inferenzcontainern

Anwendungsfälle für serielle Inferenzpipelines müssen eingehende Daten vorverarbeiten, bevor ein vortrainiertes ML-Modell zum Generieren von Inferenzen aufgerufen wird. Darüber hinaus müssen die generierten Inferenzen in einigen Fällen möglicherweise weiter verarbeitet werden, damit sie problemlos von nachgelagerten Anwendungen verwendet werden können. Dies ist ein häufiges Szenario für Anwendungsfälle, in denen eine Streaming-Datenquelle in Echtzeit verarbeitet werden muss, bevor ein Modell daran angepasst werden kann. Dieser Anwendungsfall kann sich jedoch auch für Batchrückschlüsse manifestieren.

SageMaker bietet eine Option zum Anpassen von Inferenzcontainern und zum Erstellen einer seriellen Inferenzpipeline. Inferenzcontainer verwenden die SageMaker-Inferenz-Toolkit und darauf aufgebaut sind SageMaker Multi Model Server (MMS), das einen flexiblen Mechanismus zur Bereitstellung von ML-Modellen bereitstellt. Das folgende Diagramm veranschaulicht ein Referenzmuster zum Implementieren einer seriellen Rückschlusspipeline mithilfe von Rückschlusscontainern.

SageMaker MMS erwartet ein Python-Skript, das die folgenden Funktionen implementiert, um das Modell zu laden, Eingabedaten vorzuverarbeiten, Vorhersagen aus dem Modell zu erhalten und die Ausgabedaten nachzubearbeiten:

• input_fn () – Verantwortlich für die Deserialisierung und Vorverarbeitung der Eingabedaten
• model_fn () – Verantwortlich für das Laden des trainierten Modells von Artefakten in Amazon Simple Storage-Service (Amazon S3)
• Predict_FN () – Verantwortlich für die Generierung von Inferenzen aus dem Modell
• output_fn () – Verantwortlich für die Serialisierung und Nachbearbeitung der Ausgabedaten (Inferenzen)

Ausführliche Schritte zum Anpassen eines Inferenzcontainers finden Sie unter Anpassen Ihres eigenen Inferenzcontainers.

Inferenzcontainer sind ein ideales Entwurfsmuster für Anwendungsfälle von seriellen Inferenzpipelines mit den folgenden Hauptüberlegungen:

• Hoher Zusammenhalt – Die Verarbeitungslogik und das entsprechende Modell treiben einzelne Geschäftsfunktionen an und müssen am selben Ort angeordnet sein
• Niedrige Gesamtlatenz – Die verstrichene Zeit zwischen dem Stellen einer Inferenzanfrage und dem Empfangen der Antwort

In einer seriellen Inferenzpipeline sind die Verarbeitungslogik und das Modell in demselben einzelnen Container gekapselt, sodass ein Großteil der Aufrufe im Container verbleibt. Dies trägt dazu bei, die Gesamtzahl der Hops zu reduzieren, was zu einer besseren Gesamtlatenz und Reaktionsfähigkeit der Pipeline führt.

Auch für Anwendungsfälle, in denen eine einfache Implementierung ein wichtiges Kriterium ist, können Inferenzcontainer hilfreich sein, wobei verschiedene Verarbeitungsschritte der Pipeline innerhalb desselben Containers untergebracht werden können.

Serielle Inferenzpipeline mit einer SageMaker-Inferenzpipeline

Eine weitere Variation des Anwendungsfalls der seriellen Inferenzpipeline erfordert eine klarere Entkopplung zwischen den verschiedenen Schritten in der Pipeline (z. B. Datenvorverarbeitung, Inferenzerzeugung, Datennachverarbeitung sowie Formatierung und Serialisierung). Dies kann verschiedene Gründe haben:

• Die Entkoppelung – Verschiedene Schritte der Pipeline haben einen klar definierten Zweck und müssen aufgrund der zugrunde liegenden Abhängigkeiten auf separaten Containern ausgeführt werden. Dies trägt auch dazu bei, die Pipeline gut strukturiert zu halten.
• Frameworks – Verschiedene Schritte der Pipeline verwenden spezifische zweckdienliche Frameworks (z. B. scikit oder Spark ML) und müssen daher auf separaten Containern ausgeführt werden.
• Ressourcenisolation – Verschiedene Schritte der Pipeline haben unterschiedliche Ressourcenverbrauchsanforderungen und müssen daher für mehr Flexibilität und Kontrolle in separaten Containern ausgeführt werden.

Darüber hinaus können für etwas komplexere serielle Inferenzpipelines mehrere Schritte erforderlich sein, um eine Anforderung zu verarbeiten und eine Inferenz zu erzeugen. Aus betrieblicher Sicht kann es daher vorteilhaft sein, diese Schritte für eine bessere Funktionsisolierung in separaten Containern zu hosten und einfachere Upgrades und Erweiterungen zu ermöglichen (einen Schritt ändern, ohne andere Modelle oder Verarbeitungsschritte zu beeinträchtigen).

Wenn Ihr Anwendungsfall mit einigen dieser Überlegungen übereinstimmt, a SageMaker-Inferenzpipeline bietet eine einfache und flexible Option zum Erstellen einer seriellen Inferenzpipeline. Das folgende Diagramm veranschaulicht ein Referenzmuster zur Implementierung einer seriellen Inferenzpipeline mit mehreren Schritten, die auf dedizierten Containern mit einer SageMaker-Inferenzpipeline gehostet werden.

Eine SageMaker-Inferenzpipeline besteht aus einer linearen Folge von 2–15 Containern, die Anfragen nach Inferenzen auf Daten verarbeiten. Die Inferenzpipeline bietet die Option, vortrainierte, in SageMaker integrierte Algorithmen oder benutzerdefinierte Algorithmen zu verwenden, die in Docker-Containern verpackt sind. Die Container werden auf derselben zugrunde liegenden Instanz gehostet, was dazu beiträgt, die Gesamtlatenz zu reduzieren und die Kosten zu minimieren.

Das folgende Code-Snippet zeigt, wie mehrere Verarbeitungsschritte und Modelle kombiniert werden können, um eine serielle Inferenzpipeline zu erstellen.

Wir beginnen mit dem Erstellen und Spezifizieren von Spark ML- und XGBoost-basierten Modellen, die wir als Teil der Pipeline verwenden möchten:

from sagemaker.model import Model
from sagemaker.pipeline_model import PipelineModel
from sagemaker.sparkml.model import SparkMLModel
sparkml_data = 's3://{}/{}/{}'.format(s3_model_bucket, s3_model_key_prefix, 'model.tar.gz')
sparkml_model = SparkMLModel(model_data=sparkml_data)
xgb_model = Model(model_data=xgb_model.model_data, image=training_image)

Die Modelle werden dann innerhalb der Pipeline-Modelldefinition sequentiell angeordnet:

model_name = 'serial-inference-' + timestamp_prefix
endpoint_name = 'serial-inference-ep-' + timestamp_prefix
sm_model = PipelineModel(name=model_name, role=role, models=[sparkml_model, xgb_model])

Die Inferenz-Pipeline wird dann hinter einem Endpunkt für Echtzeit-Inferenz bereitgestellt, indem der Typ und die Anzahl der Host-ML-Instanzen angegeben werden:

sm_model.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge', endpoint_name=endpoint_name)

Die gesamte zusammengesetzte Inferenzpipeline kann als SageMaker-Modell betrachtet werden, das Sie verwenden können, um entweder Echtzeitvorhersagen zu treffen oder Batchtransformationen direkt ohne externe Vorverarbeitung zu verarbeiten. Innerhalb eines Inferenz-Pipeline-Modells behandelt SageMaker Aufrufe als eine Folge von HTTP-Anforderungen, die von einer externen Anwendung stammen. Der erste Container in der Pipeline verarbeitet die anfängliche Anfrage, führt einige Verarbeitungen durch und sendet dann die Zwischenantwort als Anfrage an den zweiten Container in der Pipeline. Dies geschieht für jeden Container in der Pipeline und gibt schließlich die endgültige Antwort an die aufrufende Clientanwendung zurück.

SageMaker-Inferenzpipelines werden vollständig verwaltet. Wenn die Pipeline bereitgestellt wird, installiert SageMaker alle definierten Container auf allen und führt sie aus Amazon Elastic Compute-Cloud (Amazon EC2)-Instances, die als Teil des Endpunkt- oder Batch-Transformationsjobs bereitgestellt werden. Da sich die Container am gleichen Ort befinden und auf derselben EC2-Instance gehostet werden, wird außerdem die Gesamtlatenz der Pipeline reduziert.

Serielles Modellensemble unter Verwendung einer SageMaker-Inferenzpipeline

Ein Ensemble-Modell ist ein Ansatz in ML, bei dem mehrere ML-Modelle kombiniert und als Teil des Inferenzprozesses verwendet werden, um endgültige Inferenzen zu generieren. Die Beweggründe für Ensemble-Modelle könnten u. a. die Verbesserung der Genauigkeit, die Reduzierung der Modellempfindlichkeit gegenüber bestimmten Eingabemerkmalen und die Reduzierung der Bias einzelner Modelle umfassen. In diesem Beitrag konzentrieren wir uns auf die Anwendungsfälle im Zusammenhang mit einem Ensemble serieller Modelle, bei denen mehrere ML-Modelle nacheinander als Teil einer seriellen Inferenzpipeline kombiniert werden.

Betrachten wir ein spezifisches Beispiel im Zusammenhang mit einem Serienmodell-Ensemble, bei dem wir die hochgeladenen Bilder eines Benutzers basierend auf bestimmten Themen oder Themen gruppieren müssen. Diese Pipeline könnte aus drei ML-Modellen bestehen:

• Modell 1 – Akzeptiert ein Bild als Eingabe und bewertet die Bildqualität basierend auf Bildauflösung, Ausrichtung und mehr. Dieses Modell versucht dann, die Bildqualität hochzuskalieren und sendet die verarbeiteten Bilder, die einen bestimmten Qualitätsschwellenwert erfüllen, an das nächste Modell (Modell 2).
• Modell 2 – Akzeptiert Bilder, die durch Modell 1 validiert wurden und funktioniert Bilderkennung zum Identifizieren von Objekten, Orten, Personen, Text und anderen benutzerdefinierten Aktionen und Konzepten in Bildern. Die Ausgabe von Modell 2, die identifizierte Objekte enthält, wird an Modell 3 gesendet.
• Modell 3 – Akzeptiert die Ausgabe von Modell 2 und führt Aufgaben zur Verarbeitung natürlicher Sprache (NLP) aus, z. B. Themenmodellierung zum Gruppieren von Bildern basierend auf Themen. Beispielsweise könnten Bilder basierend auf dem Ort oder identifizierten Personen gruppiert werden. Die Ausgabe (Gruppierungen) wird an die Clientanwendung zurückgesendet.

Das folgende Diagramm veranschaulicht ein Referenzmuster zur Implementierung mehrerer ML-Modelle, die auf einem seriellen Modellensemble gehostet werden, mithilfe einer SageMaker-Inferenzpipeline.

Wie bereits erwähnt, wird die SageMaker-Inferenzpipeline verwaltet, was es Ihnen ermöglicht, sich auf die Auswahl und Entwicklung des ML-Modells zu konzentrieren und gleichzeitig das undifferenzierte schwere Heben zu reduzieren, das mit dem Erstellen der seriellen Ensemble-Pipeline verbunden ist.

Darüber hinaus sind einige der zuvor erörterten Überlegungen zur Entkopplung, Algorithmus- und Rahmenauswahl für die Modellentwicklung und -bereitstellung auch hier relevant. Da beispielsweise jedes Modell in einem separaten Container gehostet wird, können Sie flexibel das ML-Framework auswählen, das am besten zu jedem Modell und Ihrem gesamten Anwendungsfall passt. Darüber hinaus können Sie unter dem Gesichtspunkt der Entkopplung und des Betriebs einzelne Stufen viel einfacher weiter aufrüsten oder modifizieren, ohne andere Modelle zu beeinträchtigen.

Die SageMaker-Inferenzpipeline ist ebenfalls in die integriert SageMaker-Modellregistrierung für Modellkatalogisierung, Versionierung, Metadatenverwaltung und gesteuerte Bereitstellung in Produktionsumgebungen, um konsistente operative Best Practices zu unterstützen. Die SageMaker-Inferenzpipeline ist ebenfalls integriert Amazon CloudWatch um die Überwachung der Multi-Container-Modelle in Inferenz-Pipelines zu ermöglichen. Sie können auch Einblick in erhalten Echtzeitmetriken um Aufrufe und Latenzzeiten für jeden Container in der Pipeline besser zu verstehen, was bei der Fehlerbehebung und Ressourcenoptimierung hilft.

Serielle Inferenzpipeline (mit gezieltem Modellaufruf von einer Gruppe) unter Verwendung einer SageMaker-Inferenzpipeline

SageMaker-Endpunkte mit mehreren Modellen (MMEs) bieten eine kostengünstige Lösung zur Bereitstellung einer großen Anzahl von ML-Modellen hinter einem einzigen Endpunkt. Die Beweggründe für die Verwendung von Endpunkten mit mehreren Modellen könnten das Aufrufen eines bestimmten benutzerdefinierten Modells basierend auf Anforderungsmerkmalen (z. B. Herkunft, geografischer Standort, Benutzerpersonalisierung usw.) oder einfach das Hosten mehrerer Modelle hinter demselben Endpunkt umfassen, um eine Kostenoptimierung zu erreichen.

Wenn Sie mehrere Modelle auf einem einzigen Multi-Modell-fähigen Endpunkt bereitstellen, teilen sich alle Modelle die Rechenressourcen und den Container für die Modellbereitstellung. Die SageMaker-Inferenzpipeline kann auf einem MME bereitgestellt werden, wo einer der Container in der Pipeline Anforderungen basierend auf dem spezifischen aufgerufenen Modell dynamisch bedienen kann. Aus Pipeline-Perspektive haben die Modelle identische Vorverarbeitungsanforderungen und erwarten denselben Funktionssatz, sind jedoch darauf trainiert, sich an einem bestimmten Verhalten auszurichten. Das folgende Diagramm veranschaulicht anhand eines Referenzmusters, wie diese integrierte Pipeline funktionieren würde.

Bei MMEs sollte die Inferenzanforderung, die von der Clientanwendung stammt, das Zielmodell angeben, das aufgerufen werden muss. Der erste Container in der Pipeline verarbeitet die ursprüngliche Anforderung, führt einige Verarbeitungsschritte aus und sendet dann die Zwischenantwort als Anforderung an den zweiten Container in der Pipeline, der mehrere Modelle hostet. Basierend auf dem in der Inferenzanforderung angegebenen Zielmodell wird das Modell aufgerufen, um eine Inferenz zu erzeugen. Die generierte Inferenz wird zur weiteren Verarbeitung an den nächsten Container in der Pipeline gesendet. Dies geschieht für jeden nachfolgenden Container in der Pipeline, und schließlich gibt SageMaker die endgültige Antwort an die aufrufende Clientanwendung zurück.

Mehrere Modellartefakte werden in einem S3-Bucket beibehalten. Wenn ein bestimmtes Modell aufgerufen wird, lädt SageMaker es dynamisch in den Container, der den Endpunkt hostet. Wenn das Modell bereits in den Speicher des Containers geladen ist, ist der Aufruf schneller, da SageMaker das Modell nicht von Amazon S3 herunterladen muss. Wenn die Speicherauslastung der Instanz hoch ist und ein neues Modell aufgerufen wird und daher geladen werden muss, werden nicht verwendete Modelle aus dem Speicher entladen. Die entladenen Modelle verbleiben jedoch im Speichervolumen der Instanz und können später wieder in den Speicher des Containers geladen werden, ohne erneut aus dem S3-Bucket heruntergeladen zu werden.

Eine der wichtigsten Überlegungen bei der Verwendung von MMEs ist das Verständnis des Modellaufruflatenzverhaltens. Wie bereits erwähnt, werden Modelle beim Aufrufen dynamisch in den Speicher des Containers der Instanz geladen, die den Endpunkt hostet. Daher kann der Modellaufruf länger dauern, wenn er zum ersten Mal aufgerufen wird. Wenn sich das Modell bereits im Speicher des Instanzcontainers befindet, sind die nachfolgenden Aufrufe schneller. Wenn die Speicherauslastung einer Instanz hoch ist und ein neues Modell geladen werden muss, werden nicht verwendete Modelle entladen. Wenn das Speichervolumen der Instanz voll ist, werden nicht verwendete Modelle aus dem Speichervolumen gelöscht. SageMaker verwaltet das Laden und Entladen der Modelle vollständig, ohne dass Sie bestimmte Aktionen ausführen müssen. Es ist jedoch wichtig, dieses Verhalten zu verstehen, da es Auswirkungen auf die Modellaufruflatenz und damit auf die gesamte Ende-zu-Ende-Latenz hat.

Pipeline-Hosting-Optionen

SageMaker bietet mehrere Instanztyp Optionen zur Auswahl für die Bereitstellung von ML-Modellen und den Aufbau von Inferenz-Pipelines, basierend auf Ihrem Anwendungsfall, Durchsatz und Ihren Kostenanforderungen. Sie können beispielsweise CPU- oder GPU-optimierte Instanzen auswählen, um serielle Inferenzpipelines für einen einzelnen Container oder über mehrere Container hinweg zu erstellen. Es gibt jedoch manchmal Anforderungen, bei denen Flexibilität und Unterstützung für die Ausführung von Modellen auf CPU- oder GPU-basierten Instanzen innerhalb derselben Pipeline für zusätzliche Flexibilität erwünscht sind.

Sie können jetzt NVIDIA Triton Inference Server verwenden, um Modelle für die Inferenz auf SageMaker für heterogene Rechenanforderungen bereitzustellen. Kasse Stellen Sie schnelle und skalierbare KI mit NVIDIA Triton Inference Server in Amazon SageMaker bereit für weitere Details.

Zusammenfassung

Wenn Unternehmen neue Lösungen entdecken und entwickeln, die auf ML basieren, sollten die Tools, die für die Orchestrierung dieser Pipelines erforderlich sind, flexibel genug sein, um sie basierend auf einem bestimmten Anwendungsfall zu unterstützen und gleichzeitig die laufenden Betriebskosten zu vereinfachen und zu reduzieren. SageMaker bietet mehrere Optionen zum Entwerfen und Erstellen dieser seriellen Inferenz-Workflows, basierend auf Ihren Anforderungen.

Wir freuen uns darauf, von Ihnen zu hören, welche Anwendungsfälle Sie mit seriellen Inferenzpipelines erstellen. Wenn Sie Fragen oder Feedback haben, teilen Sie diese bitte in den Kommentaren mit.

Über die Autoren

Rahul Sharma ist Senior Solutions Architect bei AWS Data Lab und unterstützt AWS-Kunden beim Entwerfen und Erstellen von KI/ML-Lösungen. Bevor er zu AWS kam, war Rahul mehrere Jahre im Finanz- und Versicherungssektor tätig und half Kunden beim Aufbau von Daten- und Analyseplattformen.

Anand Prakash ist Senior Solutions Architect bei AWS Data Lab. Anand konzentriert sich darauf, Kunden beim Design und Aufbau von KI/ML-, Datenanalyse- und Datenbanklösungen zu unterstützen, um ihren Weg zur Produktion zu beschleunigen.

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.

Saurabh Trikande ist Senior Product Manager für Amazon SageMaker Inference. Er arbeitet leidenschaftlich gerne mit Kunden zusammen und macht maschinelles Lernen zugänglicher. In seiner Freizeit wandert Saurabh gerne, lernt etwas über innovative Technologien, folgt TechCrunch und verbringt Zeit mit seiner Familie.