Ausführen und Optimieren von Multi-Modell-Inferenzen mit Amazon SageMaker-Multi-Modell-Endpunkten

Amazon Sage Maker Multi-Model-Endpunkt (MME) ermöglicht es Ihnen, mehrere Modelle kostengünstig in einem einzigen Endpunkt bereitzustellen und zu hosten und den Endpunkt dann horizontal zu skalieren, um Skalierung zu erreichen. Wie in der folgenden Abbildung dargestellt, ist dies eine effektive Technik zum Implementieren der Mandantenfähigkeit von Modellen in Ihrer Infrastruktur für maschinelles Lernen (ML). Wir haben gesehen, dass SaaS-Unternehmen (Software as a Service) diese Funktion nutzen, um Hyperpersonalisierung in ihren ML-Modellen anzuwenden und gleichzeitig niedrigere Kosten zu erzielen.

Einen allgemeinen Überblick über die Funktionsweise von MME erhalten Sie im AWS Summit-Video Skalierung von ML auf die nächste Stufe: Hosten von Tausenden von Modellen auf SageMaker. Weitere Informationen zu den hyperpersonalisierten, mandantenfähigen Anwendungsfällen, die MME ermöglicht, finden Sie unter So skalieren Sie maschinelle Lerninferenz für mandantenfähige SaaS-Anwendungsfälle.

Im Rest dieses Beitrags tauchen wir tiefer in die technische Architektur von SageMaker MME ein und teilen Best Practices zur Optimierung Ihrer Endpunkte mit mehreren Modellen.

Anwendungsfälle, die am besten für MME geeignet sind

SageMaker-Endpunkte mit mehreren Modellen eignen sich gut zum Hosten einer großen Anzahl von Modellen, die Sie über einen Shared-Serving-Container bereitstellen können, und Sie müssen nicht gleichzeitig auf alle Modelle zugreifen. Abhängig von der Größe des Endpunktinstanzspeichers kann ein Modell gelegentlich aus dem Speicher entladen werden, um ein neues Modell zu laden, um die effiziente Nutzung des Speichers zu maximieren. Daher muss Ihre Anwendung gelegentliche Latenzspitzen bei entladenen Modellen tolerieren.

MME ist auch für Co-Hosting-Modelle konzipiert, die dasselbe ML-Framework verwenden, da sie den gemeinsam genutzten Container zum Laden mehrerer Modelle verwenden. Wenn Sie also eine Mischung aus ML-Frameworks in Ihrer Modellflotte haben (z. B. PyTorch und TensorFlow), sind dedizierte SageMaker-Endpunkte oder Multi-Container-Hosting die bessere Wahl.

Schließlich ist MME für Anwendungen geeignet, die eine gelegentliche Kaltstart-Latenzstrafe tolerieren können, da Modelle beim ersten Aufruf geladen werden und selten verwendete Modelle zugunsten des Ladens neuer Modelle aus dem Speicher ausgelagert werden können. Wenn Sie also eine Mischung aus häufig und selten aufgerufenen Modellen haben, kann ein Endpunkt mit mehreren Modellen diesen Datenverkehr effizient mit weniger Ressourcen und höheren Kosteneinsparungen bedienen.

Wir haben auch einige Szenarien gesehen, in denen Kunden einen MME-Cluster mit ausreichend aggregierter Speicherkapazität für alle ihre Modelle bereitstellen, wodurch Modell-Offloads insgesamt vermieden werden und dennoch Kosteneinsparungen aufgrund der gemeinsamen Inferenzinfrastruktur erzielt werden.

Modell Servierbehälter

Wenn Sie das SageMaker Inference Toolkit oder einen vorgefertigten SageMaker Model Serving Container verwenden, der mit MME kompatibel ist, verfügt Ihr Container über die Multi-Model-Server (JVM-Prozess) läuft. Der einfachste Weg, Multi Model Server (MMS) in Ihren Model-Serving-Container zu integrieren, ist die Verwendung SageMaker-Modell Servierbehälter kompatibel mit MME (suchen Sie nach denen mit Job Type=inference und CPU/GPU=CPU). MMS ist ein benutzerfreundliches Open-Source-Tool zur Bereitstellung von Deep-Learning-Modellen. Es stellt eine REST-API mit einem Webserver bereit, um mehrere Modelle auf einem einzigen Host bereitzustellen und zu verwalten. Es ist jedoch nicht zwingend erforderlich, MMS zu verwenden; Sie könnten Ihren eigenen Modellserver implementieren, solange er die implementiert Von MME benötigte APIs.

Bei Verwendung als Teil der MME-Plattform werden alle Vorhersage-, Lade- und Entlade-API-Aufrufe an MMS oder Ihren eigenen Modellserver durch den MME-Datenebenen-Controller geleitet. API-Aufrufe vom Data Plane Controller erfolgen nur über den lokalen Host, um unbefugten Zugriff von außerhalb der Instanz zu verhindern. Einer der Hauptvorteile von MMS besteht darin, dass es eine standardisierte Schnittstelle zum Laden, Entladen und Aufrufen von Modellen mit Kompatibilität mit einer Vielzahl von Deep-Learning-Frameworks ermöglicht.

Erweiterte Konfiguration von MMS

Wenn Sie sich für die Verwendung von MMS für die Modellbereitstellung entscheiden, ziehen Sie die folgenden erweiterten Konfigurationen in Betracht, um die Skalierbarkeit und den Durchsatz Ihrer MME-Instanzen zu optimieren.

Erhöhen Sie die Inferenzparallelität pro Modell

MMS erstellt einen oder mehrere Python-Worker-Prozesse pro Modell basierend auf dem Wert von default_workers_per_model Konfigurationsparameter. Diese Python-Worker verarbeiten jede einzelne Inferenzanforderung, indem sie alle von Ihnen bereitgestellten Vorverarbeitungs-, Vorhersage- und Nachverarbeitungsfunktionen ausführen. Weitere Informationen finden Sie unter benutzerdefinierter Dienstleister GitHub Repo.

Wenn mehr als ein Modellarbeiter vorhanden ist, erhöht sich die Parallelität von Vorhersagen, die von einem bestimmten Modell bedient werden können. Wenn jedoch eine große Anzahl von Modellen auf einer Instanz mit einer großen Anzahl von CPUs gehostet wird, sollten Sie einen Lasttest Ihrer MME durchführen, um den optimalen Wert zu finden default_workers_per_model um eine Erschöpfung des Arbeitsspeichers oder der CPU-Ressourcen zu verhindern.

Design für Verkehrsspitzen

Jeder MMS-Prozess innerhalb einer Endpunktinstanz hat eine Anforderungswarteschlange, die mit konfiguriert werden kann job_queue_size Parameter (Standard ist 100). Dies bestimmt die Anzahl der Anfragen, die MMS in die Warteschlange stellt, wenn alle Worker-Prozesse beschäftigt sind. Verwenden Sie diesen Parameter, um die Reaktionsfähigkeit Ihrer Endpunktinstanzen zu optimieren, nachdem Sie sich für die optimale Anzahl von Workern pro Modell entschieden haben.

Bei einem optimalen Arbeiter-Modell-Verhältnis sollte der Standardwert von 100 für die meisten Fälle ausreichen. In Fällen, in denen der Anfrageverkehr zum Endpunkt ungewöhnlich stark ansteigt, können Sie die Größe der Warteschlange jedoch reduzieren, wenn Sie möchten, dass der Endpunkt schnell ausfällt, um die Kontrolle an die Anwendung zu übergeben, oder die Warteschlangengröße erhöhen, wenn Sie möchten, dass der Endpunkt die Spitze absorbiert .

Maximieren Sie die Arbeitsspeicherressourcen pro Instanz

Wenn Sie mehrere Worker-Prozesse pro Modell verwenden, lädt jeder Worker-Prozess standardmäßig seine eigene Kopie des Modells. Dies kann den verfügbaren Instanzspeicher für andere Modelle reduzieren. Sie können die Speicherauslastung optimieren, indem Sie ein einziges Modell zwischen Worker-Prozessen teilen, indem Sie den Konfigurationsparameter festlegen preload_model=true. Hier tauschen Sie reduzierte Inferenzparallelität (aufgrund einer einzelnen Modellinstanz) mit mehr Speichereffizienz aus. Diese Einstellung zusammen mit mehreren Worker-Prozessen kann eine gute Wahl für Anwendungsfälle sein, in denen die Modelllatenz gering ist, Sie aber eine umfangreichere Vor- und Nachverarbeitung (durch die Worker-Prozesse) pro Inferenzanforderung haben.

Legen Sie Werte für erweiterte MMS-Konfigurationen fest

MMS verwendet eine config.properties-Datei zum Speichern von Konfigurationen. MMS verwendet die folgende Reihenfolge, um diese Datei config.properties zu finden:

1. Besitzt das MMS_CONFIG_FILE Umgebungsvariable gesetzt ist, lädt MMS die Konfiguration aus der Umgebungsvariable.
2. Besitzt das --mms-config Parameter an MMS übergeben wird, lädt es die Konfiguration aus dem Parameter.
3. Wenn da ein ... ist config.properties im aktuellen Ordner, wo der Benutzer MMS startet, lädt es die config.properties Datei aus dem aktuellen Arbeitsverzeichnis.

Wenn keine der oben genannten Angaben gemacht werden, lädt MMS die integrierte Konfiguration mit Standardwerten.

Das Folgende ist ein Befehlszeilenbeispiel zum Starten von MMS mit einer expliziten Konfigurationsdatei:

multi-model-server --start --mms-config /home/mms/config.properties

Wichtige Metriken zur Überwachung Ihrer Endgeräteleistung

Die wichtigsten Metriken, die Ihnen bei der Optimierung Ihres MME helfen können, beziehen sich normalerweise auf die CPU- und Speicherauslastung und die Inferenzlatenz. Die Metriken auf Instanzebene werden von MMS ausgegeben, während die Latenzmetriken von MME stammen. In diesem Abschnitt besprechen wir die typischen Metriken, die Sie verwenden können, um Ihre MME zu verstehen und zu optimieren.

Metriken auf Endpunktinstanzebene (MMS-Metriken)

Von dem Liste der MMS-Metriken, CPUUtilization und MemoryUtilization können Ihnen dabei helfen, zu beurteilen, ob Ihre Instanz oder der MME-Cluster die richtige Größe hat. Wenn beide Metriken Prozentsätze zwischen 50 und 80 % aufweisen, dann hat Ihr MME die richtige Größe.

In der Regel ist eine niedrige CPUUtilization und eine hohe MemoryUtilization ein Hinweis auf einen überdimensionierten MME-Cluster, da dies darauf hinweist, dass selten aufgerufene Modelle nicht entladen werden. Dies könnte daran liegen, dass eine höhere als die optimale Anzahl von Endpunktinstanzen für die MME bereitgestellt wird und daher mehr als der optimale Gesamtspeicher verfügbar ist, damit Modelle, auf die selten zugegriffen wird, im Speicher verbleiben. Umgekehrt bedeutet eine nahezu 100-prozentige Auslastung dieser Metriken, dass Ihr Cluster unterversorgt ist, sodass Sie Ihre Richtlinie für die automatische Skalierung des Clusters anpassen müssen.

Metriken auf Plattformebene (MME-Metriken)

Von dem vollständige Liste der MME-Metriken, ist ModelCacheHit eine wichtige Metrik, die Ihnen helfen kann, die Latenz Ihrer Inferenzanforderung zu verstehen. Diese Metrik zeigt das durchschnittliche Verhältnis von Aufrufanforderungen, für die das Modell bereits in den Arbeitsspeicher geladen wurde. Wenn dieses Verhältnis niedrig ist, weist dies darauf hin, dass Ihr MME-Cluster nicht ausreichend bereitgestellt ist, da im MME-Cluster wahrscheinlich nicht genügend aggregierte Speicherkapazität für die Anzahl eindeutiger Modellaufrufe vorhanden ist, was dazu führt, dass Modelle häufig aus dem Speicher entladen werden.

Lehren aus der Praxis und Strategien zur Optimierung von MME

Wir haben die folgenden Empfehlungen von einigen der groß angelegten Anwendungen von MME bei einer Reihe von Kunden gesehen.

Die horizontale Skalierung bei kleineren Instanzen ist besser als die vertikale Skalierung bei größeren Instanzen

Es kann zu Drosselungen bei Modellaufrufen kommen, wenn hohe Anforderungen pro Sekunde (RPS) auf weniger Endpunktinstanzen ausgeführt werden. Es gibt interne Beschränkungen für die Anzahl der Aufrufe pro Sekunde (Laden und Entladen, die gleichzeitig auf einer Instanz stattfinden können), und daher ist es immer besser, eine höhere Anzahl kleinerer Instanzen zu haben. Das Ausführen einer höheren Anzahl kleinerer Instances bedeutet eine höhere Gesamtkapazität dieser Limits für den Endpunkt.

Ein weiterer Vorteil der horizontalen Skalierung mit kleineren Instanzen besteht darin, dass Sie das Risiko der Erschöpfung der Instanz-CPU- und Speicherressourcen verringern, wenn Sie MMS mit höheren Parallelitätsstufen zusammen mit einer höheren Anzahl von Modellen im Speicher ausführen (wie zuvor in diesem Beitrag beschrieben).

Das Vermeiden von Schlägen ist eine gemeinsame Verantwortung

Prügel in MME ist, wenn Modelle häufig aus dem Speicher entladen und aufgrund von unzureichendem Speicher neu geladen werden, entweder in einer einzelnen Instanz oder insgesamt im Cluster.

Aus Nutzungssicht sollten Sie einzelne Endpunktinstanzen richtig dimensionieren und die Gesamtgröße des MME-Clusters richtig dimensionieren, um sicherzustellen, dass genügend Speicherkapazität pro Instanz und auch insgesamt für den Cluster für Ihren Anwendungsfall verfügbar ist. Die Router-Flotte der MME-Plattform wird auch den Cache-Treffer maximieren.

Seien Sie nicht aggressiv, wenn Sie zu viele Modelle auf weniger, größere Speicherinstanzen packen

Arbeitsspeicher ist nicht die einzige Ressource auf der Instanz, die es zu beachten gilt. Andere Ressourcen wie die CPU können ein einschränkender Faktor sein, wie aus den folgenden Lasttestergebnissen hervorgeht. In einigen anderen Fällen haben wir auch beobachtet, dass andere Kernel-Ressourcen wie Prozess-IDs auf einer Instanz erschöpft sind, weil zu viele Modelle geladen wurden und das zugrunde liegende ML-Framework (z. B. TensorFlow) Threads pro Modell hervorbrachte, die ein Vielfaches der verfügbaren waren vCPUs.

Der folgende Leistungstest zeigt ein Beispiel für eine CPU-Einschränkung, die sich auf die Modelllatenz auswirkt. In diesem Test erzeugte ein einzelner Instanz-Endpunkt mit einer großen Instanz, obwohl er mehr als genug Speicher hatte, um alle vier Modelle im Speicher zu halten, vergleichsweise schlechtere Modelllatenzen unter Last im Vergleich zu einem Endpunkt mit vier kleineren Instanzen.

Latenz des Einzelinstanz-Endpunktmodells

Einzelinstanz-Endpunkt-CPU- und -Speicherauslastung

Endpunktmodelllatenz für vier Instanzen

CPU- und Speicherauslastung von Endpunkten mit vier Instanzen

Um sowohl Leistung als auch Kosteneffizienz zu erreichen, sollten Sie Ihren MME-Cluster mit einer höheren Anzahl kleinerer Instanzen richtig dimensionieren, die Ihnen insgesamt die optimale Arbeitsspeicher- und CPU-Kapazität bieten, während Sie mit weniger, aber größeren Arbeitsspeicherinstanzen relativ kostengünstig sind.

Mentales Modell zur Optimierung von MME

Es gibt vier Schlüsselmetriken, die Sie bei der richtigen Dimensionierung Ihres MME immer berücksichtigen sollten:

• Die Anzahl und Größe der Modelle
• Die Anzahl eindeutiger Modelle, die zu einem bestimmten Zeitpunkt aufgerufen wurden
• Instanztyp und -größe
• Die Instanzanzahl hinter dem Endpunkt

Beginnen Sie mit den ersten beiden Punkten, denn sie informieren den dritten und vierten. Wenn beispielsweise nicht genügend Instanzen hinter dem Endpunkt für die Anzahl oder Größe Ihrer eindeutigen Modelle vorhanden sind, ist der aggregierte Arbeitsspeicher für den Endpunkt niedrig und Sie sehen eine niedrigere Cache-Trefferquote und Thrashing auf Endpunktebene, da die MME lädt und entlädt Modelle häufig in den und aus dem Speicher.

Wenn die Aufrufe für eindeutige Modelle höher sind als der aggregierte Speicher aller Instanzen hinter dem Endpunkt, sehen Sie einen niedrigeren Cache-Treffer. Dies kann auch passieren, wenn die Größe von Instanzen (insbesondere Speicherkapazität) zu klein ist.

Die vertikale Skalierung mit sehr großen Speicherinstanzen könnte ebenfalls zu Problemen führen, da die Modelle zwar in den Speicher passen, andere Ressourcen wie CPU- und Kernelprozesse sowie Thread-Limits jedoch erschöpft sein könnten. Führen Sie Lasttests für die horizontale Skalierung in der Vorproduktion durch, um die optimale Anzahl und Größe von Instanzen für Ihre MME zu erhalten.

Zusammenfassung

In diesem Beitrag haben Sie ein tieferes Verständnis der MME-Plattform erhalten. Sie haben erfahren, für welche technischen Anwendungsfälle MME geeignet ist, und die Architektur der MME-Plattform überprüft. Sie haben ein tieferes Verständnis dafür gewonnen, welche Rolle jede Komponente innerhalb der MME-Architektur spielt und welche Komponenten Sie direkt auf die Leistung beeinflussen können. Schließlich haben Sie sich die Konfigurationsparameter genauer angesehen, die Sie anpassen können, um MME für Ihren Anwendungsfall zu optimieren, und die Metriken, die Sie überwachen sollten, um eine optimale Leistung aufrechtzuerhalten.

Um mit MME zu beginnen, überprüfen Sie Amazon SageMaker Multi-Model-Endpunkte mit XGBoost und Hosten Sie mehrere Modelle in einem Container hinter einem Endpunkt.

Über den Autor

Syed Jaffry ist Principal Solutions Architect bei AWS. Er arbeitet mit einer Reihe von Unternehmen aus mittelständischen Organisationen, Großunternehmen, Finanzdienstleistern und ISVs zusammen, um ihnen beim Aufbau und Betrieb kosteneffizienter und skalierbarer KI/ML-Anwendungen in der Cloud zu helfen.

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.