Einführung des Amazon SageMaker Serverless Inference Benchmarking Toolkit

Serverlose Amazon SageMaker-Inferenz ist eine speziell entwickelte Inferenzoption, mit der Sie Modelle für maschinelles Lernen (ML) einfach bereitstellen und skalieren können. Es bietet ein Pay-per-Use-Modell, das sich ideal für Dienste eignet, bei denen Endpunktaufrufe selten und unvorhersehbar sind. Im Gegensatz zu einem Echtzeit-Hosting-Endpunkt, der von einer langlebigen Instanz unterstützt wird, werden Rechenressourcen für serverlose Endpunkte nach Bedarf bereitgestellt, wodurch die Notwendigkeit entfällt, Instanztypen auszuwählen oder Skalierungsrichtlinien zu verwalten.

Die folgende allgemeine Architektur veranschaulicht, wie ein serverloser Endpunkt funktioniert. Ein Client ruft einen Endpunkt auf, der von einer von AWS verwalteten Infrastruktur unterstützt wird.

Serverlose Endpunkte sind jedoch anfällig für Kaltstarts im Sekundenbereich und eignen sich daher besser für intermittierende oder unvorhersehbare Workloads.

Um festzustellen, ob ein serverloser Endpunkt aus Kosten- und Leistungssicht die richtige Bereitstellungsoption ist, haben wir die entwickelt SageMaker Serverless Inference Benchmarking Toolkit, das verschiedene Endpunktkonfigurationen testet und die optimalste mit einer vergleichbaren Echtzeit-Hosting-Instanz vergleicht.

In diesem Beitrag stellen wir das Toolkit vor und geben einen Überblick über dessen Konfiguration und Outputs.

Lösungsüberblick

Sie können das Toolkit von herunterladen und installieren GitHub Repo. Der Einstieg ist einfach: Installieren Sie einfach die Bibliothek, erstellen Sie eine SageMaker-Modell, und geben Sie den Namen Ihres Modells zusammen mit einer Datei im JSON-Zeilenformat an, die einen Beispielsatz von Aufrufparametern enthält, einschließlich des Nutzlasttexts und des Inhaltstyps. Eine Komfortfunktion wird bereitgestellt, um eine Liste von Beispielaufrufargumenten in eine JSON-Zeilendatei oder eine Pickle-Datei für binäre Nutzlasten wie Bilder, Video oder Audio zu konvertieren.

Installieren Sie das Toolkit

Installieren Sie zuerst die Benchmarking-Bibliothek mit pip in Ihrer Python-Umgebung:

pip install sm-serverless-benchmarking

Sie können den folgenden Code von einer ausführen Amazon SageMaker-Studio Beispiel, SageMaker-Notebook-Instanz, oder jede Instanz mit Programmgesteuerter Zugriff zu AWS und den entsprechenden AWS Identity and Access Management and (IAM)-Berechtigungen. Die erforderlichen IAM-Berechtigungen sind in dokumentiert GitHub Repo. Weitere Anleitungen und Beispielrichtlinien für IAM finden Sie unter So funktioniert Amazon SageMaker mit IAM. Dieser Code führt einen Benchmark mit einem Standardsatz von Parametern auf einem Modell aus, das eine CSV-Eingabe mit zwei Beispieldatensätzen erwartet. Es empfiehlt sich, einen repräsentativen Satz von Beispielen bereitzustellen, um zu analysieren, wie der Endpunkt mit verschiedenen Eingabenutzlasten funktioniert.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

Darüber hinaus können Sie den Benchmark als SageMaker-Verarbeitungsjob ausführen, was eine zuverlässigere Option für länger laufende Benchmarks mit einer großen Anzahl von Aufrufen sein kann. Siehe folgenden Code:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Beachten Sie, dass dies zusätzliche Kosten für die Ausführung einer ml.m5.large SageMaker-Verarbeitungsinstanz für die Dauer des Benchmarks verursacht.

Beide Methoden akzeptieren eine Reihe von zu konfigurierenden Parametern, z. B. eine Liste von Speicherkonfigurationen zum Benchmarken und die Häufigkeit, mit der jede Konfiguration aufgerufen wird. In den meisten Fällen sollten die Standardoptionen als Ausgangspunkt ausreichen, aber beziehen Sie sich auf die GitHub Repo für eine vollständige Liste und Beschreibungen der einzelnen Parameter.

Benchmarking-Konfiguration

Bevor Sie sich damit befassen, was der Benchmark tut und welche Ergebnisse er erzeugt, ist es wichtig, einige Schlüsselkonzepte zu verstehen, wenn es um die Konfiguration serverloser Endpunkte geht.

Es gibt zwei wichtige Konfigurationsoptionen: MemorySizeInMB und MaxConcurrency. MemorySizeInMB konfiguriert die Speichermenge, die der Instanz zugewiesen wird, und kann 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB oder 6144 MB betragen. Die Anzahl der vCPUs skaliert auch proportional zur Menge des zugewiesenen Arbeitsspeichers. Das MaxConcurrency Der Parameter passt an, wie viele gleichzeitige Anfragen ein Endpunkt bedienen kann. Mit einer MaxConcurrency von 1 kann ein serverloser Endpunkt jeweils nur eine einzige Anfrage verarbeiten.

Zusammenfassend lässt sich sagen, dass die MemorySizeInMB Der Parameter stellt einen Mechanismus für die vertikale Skalierbarkeit bereit, mit dem Sie Arbeitsspeicher und Rechenressourcen anpassen können, um größere Modelle zu bedienen MaxConcurrency bietet einen Mechanismus für horizontale Skalierbarkeit, der es Ihrem Endpunkt ermöglicht, mehr gleichzeitige Anforderungen zu verarbeiten.

Die Kosten für den Betrieb eines Endpunkts werden weitgehend durch die Speichergröße bestimmt, und es fallen keine Kosten im Zusammenhang mit der Erhöhung der maximalen Parallelität an. Es gibt jedoch ein Kontolimit pro Region für maximale Parallelität über alle Endpunkte hinweg. Beziehen auf SageMaker-Endpunkte und Kontingente für die neuesten Grenzwerte.

Benchmarking-Ergebnisse

Vor diesem Hintergrund besteht das Ziel des Benchmarkings eines serverlosen Endpunkts darin, die kostengünstigste und zuverlässigste Speichergrößeneinstellung und die minimale maximale Parallelität zu ermitteln, die Ihre erwarteten Datenverkehrsmuster verarbeiten kann.

Standardmäßig führt das Tool zwei Benchmarks aus. Der erste ist ein Stabilitäts-Benchmark, der einen Endpunkt für jede der angegebenen Speicherkonfigurationen bereitstellt und jeden Endpunkt mit den bereitgestellten Beispielnutzlasten aufruft. Das Ziel dieses Benchmarks ist es, die effektivste und stabilste MemorySizeInMB-Einstellung zu ermitteln. Der Benchmark erfasst die Aufruflatenzen und berechnet die erwarteten Kosten pro Aufruf für jeden Endpunkt. Anschließend werden die Kosten mit denen einer ähnlichen Echtzeit-Hosting-Instanz verglichen.

Wenn das Benchmarking abgeschlossen ist, generiert das Tool mehrere Ausgaben in der angegebenen result_save_path Verzeichnis mit folgender Verzeichnisstruktur:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

Das benchmarking_report Verzeichnis enthält einen konsolidierten Bericht mit allen zusammenfassenden Ergebnissen, die wir in diesem Beitrag skizzieren. Zusätzliche Verzeichnisse enthalten Roh- und Zwischenausgaben, die Sie für zusätzliche Analysen verwenden können. Beziehen Sie sich auf die GitHub Repo für eine detailliertere Beschreibung jedes Ausgabeartefakts.

Sehen wir uns einige tatsächliche Benchmarking-Ergebnisse für einen Endpunkt an, der ein MobileNetV2-TensorFlow-Modell für maschinelles Sehen bedient. Wenn Sie dieses Beispiel reproduzieren möchten, lesen Sie die Beispiel Notizbücher Verzeichnis im GitHub-Repo.

Die erste Ausgabe innerhalb des konsolidierten Berichts ist eine zusammenfassende Tabelle, die jeweils die minimale, mittlere, mittlere und maximale Latenzmetrik enthält MemorySizeInMB erfolgreiche Konfiguration der Speichergröße. Wie in der folgenden Tabelle gezeigt, beträgt die durchschnittliche Aufruflatenz (invocation_latency_mean) verbesserte sich weiter, als die Speicherkonfiguration auf 3072 MB erhöht wurde, verbesserte sich danach jedoch nicht mehr.

Zusätzlich zu den beschreibenden Statistiken auf hoher Ebene wird ein Diagramm bereitgestellt, das die Verteilung der Latenz zeigt, wie sie vom Client für jede der Speicherkonfigurationen beobachtet wird. Auch hier können wir feststellen, dass die 1024-MB-Konfiguration nicht so leistungsfähig ist wie die anderen Optionen, aber es gibt keinen wesentlichen Unterschied in der Leistung bei Konfigurationen von 2048 und höher.

Amazon CloudWatch Metriken, die jeder Endpunktkonfiguration zugeordnet sind, werden ebenfalls bereitgestellt. Eine Schlüsselkennzahl ist hier ModelSetupTime, die misst, wie lange es gedauert hat, das Modell zu laden, wenn der Endpunkt in einem kalten Zustand aufgerufen wurde. Die Metrik wird möglicherweise nicht immer im Bericht angezeigt, da ein Endpunkt in einem warmen Zustand gestartet wird. EIN cold_start_delay -Parameter ist verfügbar, um die Anzahl der Sekunden anzugeben, die vor dem Starten des Benchmarks auf einem bereitgestellten Endpunkt in den Ruhezustand vergehen soll. Das Festlegen dieses Parameters auf eine höhere Zahl, z. B. 600 Sekunden, sollte die Wahrscheinlichkeit eines Cold-State-Aufrufs erhöhen und die Chancen verbessern, diese Metrik zu erfassen. Darüber hinaus ist es viel wahrscheinlicher, dass diese Metrik mit dem Benchmark für gleichzeitige Aufrufe erfasst wird, den wir später in diesem Abschnitt besprechen.

Die folgende Tabelle zeigt die von CloudWatch erfassten Metriken für jede Speicherkonfiguration.

Das nächste Diagramm zeigt die Kompromisse zwischen Leistung und Kosten verschiedener Speicherkonfigurationen. Eine Zeile zeigt die geschätzten Kosten für das Aufrufen des Endpunkts von 1 Million Mal, und die andere zeigt die durchschnittliche Antwortlatenz. Diese Metriken können Ihnen bei der Entscheidung helfen, welche Endpunktkonfiguration am kostengünstigsten ist. In diesem Beispiel sehen wir, dass die durchschnittliche Latenz nach 2048 MB abflacht, während die Kosten weiter steigen, was darauf hindeutet, dass für dieses Modell eine Speichergrößenkonfiguration von 2048 am optimalsten wäre.

Das Endergebnis des Kosten- und Stabilitäts-Benchmarks ist eine empfohlene Speicherkonfiguration zusammen mit einer Tabelle, in der die Kosten für den Betrieb eines serverlosen Endpunkts mit denen einer vergleichbaren SageMaker-Hosting-Instance verglichen werden. Basierend auf den gesammelten Daten hat das Tool festgestellt, dass die Konfiguration mit 2048 MB die optimale für dieses Modell ist. Obwohl die 3072-Konfiguration eine um etwa 10 Millisekunden bessere Latenz bietet, ist dies mit einem Kostenanstieg von 30 % von 4.55 USD auf 5.95 USD pro 1 Million Anforderungen verbunden. Darüber hinaus zeigt die Ausgabe, dass ein serverloser Endpunkt Einsparungen von bis zu 88.72 % gegenüber einer vergleichbaren Echtzeit-Hosting-Instanz bieten würde, wenn es weniger als 1 Million monatliche Aufrufanfragen gibt, und mit einem Echtzeit-Endpunkt nach 8.5 Millionen Anfragen die Gewinnschwelle erreicht.

Die zweite Art von Benchmark ist optional und testet verschiedene MaxConcurency Einstellungen unter verschiedenen Verkehrsmustern. Dieser Benchmark wird normalerweise mit dem Optimum ausgeführt MemorySizeInMB Konfiguration aus dem Stabilitätsbenchmark. Die beiden Schlüsselparameter für diesen Benchmark sind eine Liste von MaxConcurency zu testende Einstellungen zusammen mit einer Liste von Client-Multiplikatoren, die die Anzahl der simulierten gleichzeitigen Clients bestimmen, mit denen der Endpunkt getestet wird.

Zum Beispiel durch das Setzen von concurrency_benchmark_max_conc parameter zu [4, 8] und concurrency_num_clients_multiplier bis [1, 1.5, 2] werden zwei Endpunkte gestartet: einer mit MaxConcurency von 4 und die anderen 8. Jeder Endpunkt wird dann mit einem (MaxConcurency x-Multiplikator) Anzahl simulierter gleichzeitiger Clients, was für den Endpunkt mit einer Gleichzeitigkeit von 4 in Lasttest-Benchmarks mit 4, 6 und 8 gleichzeitigen Clients übersetzt wird.

Die erste Ausgabe dieses Benchmarks ist eine Tabelle, die die zugehörigen Latenzmetriken, Drosselungsausnahmen und Transaktionen pro Sekunde (TPS) anzeigt MaxConcurrency Konfiguration mit unterschiedlicher Anzahl gleichzeitiger Clients. Diese Metriken helfen bei der Bestimmung der geeigneten MaxConcurrency Einstellung, um die erwartete Verkehrslast zu bewältigen. In der folgenden Tabelle sehen wir, dass ein mit einer maximalen Gleichzeitigkeit von 8 konfigurierter Endpunkt bis zu 16 gleichzeitige Clients mit nur zwei Drosselungsausnahmen von 2,500 Aufrufen mit durchschnittlich 24 Transaktionen pro Sekunde verarbeiten konnte.

Der nächste Satz von Ausgaben enthält jeweils ein Diagramm MaxConcurrency Einstellung, die die Verteilung der Latenz unter verschiedenen Lasten zeigt. In diesem Beispiel können wir sehen, dass ein Endpunkt mit a MaxConcurrency Die Einstellung 4 konnte alle Anforderungen mit bis zu 8 gleichzeitigen Clients mit einer minimalen Erhöhung der Aufruflatenz erfolgreich verarbeiten.

Die endgültige Ausgabe enthält jeweils eine Tabelle mit CloudWatch-Metriken MaxConcurrency Aufbau. Im Gegensatz zur vorherigen Tabelle, die die Verteilung der Latenz für jede Speicherkonfiguration zeigt, die möglicherweise nicht immer den Kaltstart anzeigt ModelSetupTime Metrik, wird diese Metrik aufgrund der größeren Anzahl von Aufrufanforderungen und einer größeren Anzahl in dieser Tabelle mit weitaus größerer Wahrscheinlichkeit angezeigt MaxConcurrency.

Zusammenfassung

In diesem Beitrag haben wir das SageMaker Serverless Inference Benchmarking Toolkit vorgestellt und einen Überblick über dessen Konfiguration und Ergebnisse gegeben. Das Tool kann Ihnen helfen, eine fundiertere Entscheidung in Bezug auf serverlose Inferenz zu treffen, indem es verschiedene Konfigurationen mit realistischen Datenverkehrsmustern auslastet. Probieren Sie das Benchmarking-Toolkit mit Ihren eigenen Modellen aus, um sich selbst von der Leistung und den Kosteneinsparungen zu überzeugen, die Sie durch die Bereitstellung eines serverlosen Endpunkts erwarten können. Bitte wende dich an die GitHub Repo für zusätzliche Dokumentation und Beispiel-Notebooks.

Zusätzliche Ressourcen

Über die Autoren

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.

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 dabei, eine leistungsstarke Modellinferenz auf SageMaker zu erreichen.

Rishabh Ray Chaudhury ist Senior Product Manager bei Amazon SageMaker und konzentriert sich auf Machine-Learning-Inferenz. Er engagiert sich leidenschaftlich für Innovationen und den Aufbau neuer Erfahrungen für Machine-Learning-Kunden auf AWS, um ihre Workloads zu skalieren. In seiner Freizeit reist und kocht er gerne. Sie finden ihn auf LinkedIn.