Anwendungen für maschinelles Lernen (ML) sind komplex in der Bereitstellung und erfordern häufig die Fähigkeit zur Hyperskalierung sowie Anforderungen an extrem niedrige Latenzen und strenge Kostenbudgets. Anwendungsfälle wie Betrugserkennung, Produktempfehlungen und Verkehrsvorhersagen sind Beispiele, bei denen Millisekunden eine Rolle spielen und für den Geschäftserfolg entscheidend sind. Es müssen strenge Vereinbarungen zum Servicelevel (SLAs) eingehalten werden, und eine typische Anfrage kann mehrere Schritte erfordern, z. B. Vorverarbeitung, Datentransformation, Feature-Engineering, Modellauswahllogik, Modellaggregation und Nachbearbeitung.
Die Bereitstellung von ML-Modellen in großem Maßstab mit optimierten Kosten und Recheneffizienz kann eine entmutigende und umständliche Aufgabe sein. Jedes Modell hat seine eigenen Vorzüge und Abhängigkeiten, basierend auf den externen Datenquellen sowie der Laufzeitumgebung, wie z. B. der CPU-/GPU-Leistung der zugrunde liegenden Rechenressourcen. Eine Anwendung kann mehrere ML-Modelle erfordern, um eine einzelne Inferenzanforderung zu bedienen. In bestimmten Szenarien kann eine Anforderung über mehrere Modelle hinweg fließen. Es gibt keinen einheitlichen Ansatz, und es ist wichtig, dass ML-Experten nach bewährten Methoden suchen, um wiederkehrende Herausforderungen beim ML-Hosting anzugehen. Dies hat zur Entwicklung von Entwurfsmustern für das Hosting von ML-Modellen geführt.
In diesem Beitrag untersuchen wir gängige Entwurfsmuster zum Erstellen von ML-Anwendungen Amazon Sage Maker.
Entwurfsmuster zum Erstellen von ML-Anwendungen
Sehen wir uns die folgenden Entwurfsmuster an, die zum Hosten von ML-Anwendungen verwendet werden können.
Einzelmodellbasierte ML-Anwendungen
Dies ist eine großartige Option, wenn Ihr ML-Anwendungsfall ein einzelnes Modell erfordert, um eine Anfrage zu bedienen. Das Modell wird auf einer dedizierten Recheninfrastruktur bereitgestellt, die basierend auf dem Eingangsdatenverkehr skaliert werden kann. Diese Option ist auch ideal, wenn die Client-Anwendung eine geringe Latenzzeit (in der Größenordnung von Millisekunden oder Sekunden) für die Inferenz benötigt.
Multimodellbasierte ML-Anwendungen
Um das Hosting kostengünstiger zu gestalten, können Sie mit diesem Entwurfsmuster mehrere Modelle in derselben Mandanteninfrastruktur hosten. Mehrere ML-Modelle können die Host- oder Container-Ressourcen gemeinsam nutzen, einschließlich des Zwischenspeicherns der am häufigsten verwendeten ML-Modelle im Arbeitsspeicher, was zu einer besseren Nutzung von Arbeitsspeicher und Rechenressourcen führt. Abhängig von den Modelltypen, die Sie für die Bereitstellung ausgewählt haben, kann das Modell-Co-Hosting die folgenden Methoden verwenden:
- Multi-Model-Hosting – Mit dieser Option können Sie mehrere Modelle mithilfe eines Shared-Serving-Containers auf einem einzigen Endpunkt hosten. Diese Funktion ist ideal, wenn Sie eine große Anzahl ähnlicher Modelle haben, die Sie über einen gemeinsam genutzten Bereitstellungscontainer bereitstellen können, und nicht gleichzeitig auf alle Modelle zugreifen müssen.
- Multi-Container-Hosting – Diese Option ist ideal, wenn Sie mehrere Modelle auf verschiedenen Serving-Stacks mit ähnlichen Ressourcenanforderungen ausführen und wenn einzelne Modelle nicht über ausreichend Datenverkehr verfügen, um die volle Kapazität der Endpunktinstanzen zu nutzen. Multi-Container-Hosting ermöglicht Ihnen die Bereitstellung mehrerer Container, die unterschiedliche Modelle oder Frameworks auf einem einzigen Endpunkt verwenden. Die Modelle können völlig heterogen sein, mit ihrem eigenen unabhängigen Servierstapel.
- Modell-Ensembles – In vielen Produktionsanwendungsfällen kann es oft viele Upstream-Modelle geben, die Eingaben an ein bestimmtes Downstream-Modell liefern. Hier sind Ensembles nützlich. Ensemble-Muster beinhalten das Mischen der Ausgabe von einem oder mehreren Basismodellen, um die Verallgemeinerungsfehler der Vorhersage. Die Basismodelle können vielfältig sein und durch verschiedene Algorithmen trainiert werden. Modellensembles können einzelne Modelle übertreffen, da der Vorhersagefehler des Modells abnimmt, wenn der Ensembleansatz verwendet wird.
Im Folgenden finden Sie häufige Anwendungsfälle von Ensemblemustern und den entsprechenden Entwurfsmusterdiagrammen:
- Scatter-Gather – In einem Scatter-Gather-Muster wird eine Anfrage zur Inferenz an eine Reihe von Modellen weitergeleitet. Ein Aggregator wird dann verwendet, um die Antworten zu sammeln und sie in eine einzige Inferenzantwort zu destillieren. Beispielsweise kann ein Anwendungsfall zur Bildklassifizierung drei verschiedene Modelle verwenden, um die Aufgabe auszuführen. Mit dem Scatter-Gather-Muster können Sie Ergebnisse aus Inferenzen kombinieren, die auf drei verschiedenen Modellen ausgeführt wurden, und das wahrscheinlichste Klassifizierungsmodell auswählen.
- Modellaggregat – In einem Aggregationsmuster werden die Ausgaben mehrerer Modelle gemittelt. Bei Klassifizierungsmodellen werden die Vorhersagen mehrerer Modelle ausgewertet, um die Klasse zu bestimmen, die die meisten Stimmen erhalten hat, und wird als endgültige Ausgabe des Ensembles behandelt. Wenn beispielsweise bei einem Zwei-Klassen-Klassifizierungsproblem zum Klassifizieren einer Reihe von Früchten als Orangen oder Äpfel zwei Modelle für eine Orange und ein Modell für einen Apfel stimmen, dann ist die aggregierte Ausgabe eine Orange. Die Aggregation hilft bei der Bekämpfung von Ungenauigkeiten in einzelnen Modellen und macht die Ausgabe genauer.
- Dynamische Auswahl – Ein weiteres Muster für Ensemble-Modelle besteht darin, die Modellauswahl für die gegebenen Eingabeattribute dynamisch durchzuführen. Wenn beispielsweise in einer bestimmten Eingabe von Bildern von Früchten die Eingabe eine Orange enthält, wird Modell A verwendet, da es auf Orangen spezialisiert ist. Wenn die Eingabe einen Apfel enthält, wird Modell B verwendet, da es auf Äpfel spezialisiert ist.
- ML-Anwendungen für serielle Inferenz – Bei einem seriellen Inferenzmuster, auch bekannt als Inferenzpipeline, müssen Anwendungsfälle 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. Mit einer Inferenzpipeline können Sie denselben Vorverarbeitungscode wiederverwenden, der während des Modelltrainings verwendet wurde, um die für Vorhersagen verwendeten Inferenzanforderungsdaten zu verarbeiten.
- Geschäftslogik – Die Produktion von ML beinhaltet immer Geschäftslogik. Geschäftslogikmuster umfassen alles, was zum Ausführen einer ML-Aufgabe erforderlich ist, bei der es sich nicht um ML-Modellrückschlüsse handelt. Dazu gehört das Laden des Modells aus Amazon Simple Storage-Service (Amazon S3), beispielsweise Datenbanksuchen zur Validierung der Eingabe, Abrufen vorberechneter Features aus dem Feature Store und so weiter. Nachdem diese Geschäftslogikschritte abgeschlossen sind, werden die Eingaben an ML-Modelle weitergeleitet.
ML-Inferenzoptionen
Für die Modellbereitstellung ist es wichtig, ausgehend von Ihrem Anwendungsfall rückwärts zu arbeiten. Wie häufig ist die Vorhersage? Erwarten Sie Live-Datenverkehr zu Ihrer Anwendung und Echtzeit-Antworten an Ihre Kunden? Haben Sie viele Modelle, die für verschiedene Teilmengen von Daten für denselben Anwendungsfall trainiert wurden? Schwankt der Vorhersageverkehr? Ist die Latenz der Inferenz ein Problem? Basierend auf diesen Details können alle vorstehenden Entwurfsmuster mithilfe der folgenden Bereitstellungsoptionen implementiert werden:
- Echtzeit-Inferenz – Echtzeit-Inferenz ist ideal für Inferenz-Workloads, bei denen Sie interaktive Echtzeitanforderungen mit geringer Latenz haben. Echtzeit-ML-Inferenzarbeitslasten können eine auf einem einzigen Modell basierende ML-Anwendung umfassen, bei der eine Anwendung nur ein ML-Modell benötigt, um eine einzelne Anfrage zu bedienen, oder eine auf mehreren Modellen basierende ML-Anwendung, bei der eine Anwendung mehrere ML-Modelle benötigt, um eine einzige zu bedienen Anfrage.
- Inferenz nahezu in Echtzeit (asynchron). – Mit Inferenz nahezu in Echtzeit können Sie eingehende Anfragen in eine Warteschlange stellen. Dies kann zum Ausführen von Inferenz auf Eingaben verwendet werden, die Hunderte von MB groß sind. Es arbeitet nahezu in Echtzeit und ermöglicht es Benutzern, die Eingabe für Rückschlüsse zu verwenden und die Ausgabe vom Endpunkt aus einem S3-Bucket zu lesen. Dies kann besonders in Fällen mit NLP und Computer Vision praktisch sein, wo große Payloads vorhanden sind, die längere Vorverarbeitungszeiten erfordern.
- Batch-Inferenz – Batch-Inferenz kann verwendet werden, um Inferenz offline auf einem großen Datensatz auszuführen. Da die Batch-Inferenz offline ausgeführt wird, bietet sie nicht die niedrigste Latenz. Hier wird die Inferenzanforderung entweder mit einem geplanten oder ereignisbasierten Trigger eines Batch-Inferenzjobs verarbeitet.
- Serverlose Inferenz – Serverlose Inferenz ist ideal für Workloads, die Leerlaufzeiten zwischen Verkehrsschüben haben und einige zusätzliche Sekunden Latenz (Kaltstart) für den ersten Aufruf nach einer Leerlaufzeit tolerieren können. Zum Beispiel ein Chatbot-Dienst oder eine Anwendung, um Formulare zu verarbeiten oder Daten aus Dokumenten zu analysieren. In diesem Fall möchten Sie möglicherweise eine Online-Inferenzoption, die in der Lage ist, basierend auf dem Volumen der Inferenzanforderungen automatisch Rechenkapazität bereitzustellen und zu skalieren. Und während der Leerlaufzeit sollte es in der Lage sein, die Rechenkapazität vollständig abzuschalten, damit Sie nicht belastet werden. Die serverlose Inferenz nimmt Ihnen die undifferenzierte Schwerstarbeit bei der Auswahl und Verwaltung von Servern ab, indem sie automatisch Rechenressourcen startet und sie je nach Datenverkehr ein- und ausskaliert.
Verwenden Sie Fitnessfunktionen, um die richtige ML-Inferenzoption auszuwählen
Die Entscheidung für die richtige Hosting-Option ist wichtig, da sie sich auf die Endbenutzer auswirkt, die von Ihren Anwendungen gerendert werden. Zu diesem Zweck leihen wir uns das Konzept von aus Fitnessfunktionen, das von Neal Ford und seinen Kollegen vom AWS-Partner ThoughtWorks in ihrer Arbeit geprägt wurde Aufbau evolutionärer Architekturen. Fitnessfunktionen bieten eine vorschreibende Bewertung verschiedener Hosting-Optionen basierend auf den Zielen des Kunden. Fitnessfunktionen helfen Ihnen, die notwendigen Daten zu erhalten, um die geplante Weiterentwicklung Ihrer Architektur zu ermöglichen. Sie legen messbare Werte fest, um zu beurteilen, wie nah Ihre Lösung an der Erreichung Ihrer gesetzten Ziele ist. Fitnessfunktionen können und sollten angepasst werden, wenn sich die Architektur weiterentwickelt, um einen gewünschten Änderungsprozess zu steuern. Dies bietet Architekten ein Werkzeug, um ihre Teams zu führen und gleichzeitig die Autonomie des Teams zu wahren.
Es gibt fünf wichtige Fitnessfunktionen, die Kunden bei der Auswahl der richtigen ML-Inferenzoption zum Hosten ihrer ML-Modelle und -Anwendungen wichtig sind.
Fitnessfunktion | Beschreibung |
Kosten |
Die Bereitstellung und Wartung eines ML-Modells und einer ML-Anwendung auf einem skalierbaren Framework ist ein kritischer Geschäftsprozess, und die Kosten können stark variieren, abhängig von den Entscheidungen über die Modell-Hosting-Infrastruktur, Hosting-Option, ML-Frameworks, ML-Modelleigenschaften, Optimierungen, Skalierungsrichtlinien, und mehr. Die Workloads müssen die Hardware-Infrastruktur optimal auslasten, damit die Kosten im Rahmen bleiben. Diese Fitnessfunktion bezieht sich speziell auf die Infrastrukturkosten, die Teil der Gesamtbetriebskosten (Total Cost of Ownership, TCO) sind. Die Infrastrukturkosten sind die kombinierten Kosten für Speicher, Netzwerk und Rechenleistung. Es ist auch wichtig, andere Komponenten der Gesamtbetriebskosten zu verstehen, darunter Betriebskosten sowie Sicherheits- und Compliance-Kosten. Betriebskosten sind die kombinierten Kosten für Betrieb, Überwachung und Wartung der ML-Infrastruktur. Die Betriebskosten werden berechnet als die Anzahl der erforderlichen Ingenieure basierend auf jedem Szenario und dem Jahresgehalt der Ingenieure, aggregiert über einen bestimmten Zeitraum. Kunden, die selbstverwaltete ML-Lösungen auf verwenden Amazon Elastic Compute-Cloud (Amazon EC2), Amazon Elastic Container-Service (Amazon ECS) und Amazon Elastic Kubernetes-Service (Amazon EKS) müssen Betriebswerkzeuge selbst erstellen. Kunden, die SageMaker verwenden, entstehen deutlich weniger Gesamtbetriebskosten. SageMaker-Inferenz ist ein vollständig verwalteter Dienst und bietet sofort einsatzbereite Funktionen zum Bereitstellen von ML-Modellen für Inferenz. Sie müssen keine Instanzen bereitstellen, den Instanzzustand überwachen, Sicherheitsupdates oder Patches verwalten, Betriebsmetriken ausgeben oder eine Überwachung für Ihre ML-Inferenz-Workloads erstellen. Es verfügt über integrierte Funktionen, um eine hohe Verfügbarkeit und Ausfallsicherheit zu gewährleisten. SageMaker unterstützt die Sicherheit mit End-to-End-Verschlüsselung im Ruhezustand und bei der Übertragung, einschließlich der Verschlüsselung des Root-Volumes und Amazon Elastic Block-Shop (Amazon EBS) Volumen, Amazon Virtual Private Cloud (Amazon VPC)-Unterstützung, AWS PrivateLink, vom Kunden verwaltete Schlüssel, AWS Identity and Access Management and (IAM) feinkörnige Zugriffskontrolle, AWS CloudTrail Audits, knotenübergreifende Verschlüsselung für Schulungen, Tag-basierte Zugriffskontrolle, Netzwerkisolierung und Interactive Application Proxy. Alle diese Sicherheitsfunktionen werden in SageMaker standardmäßig bereitgestellt und können Unternehmen über einen Zeitraum von 3 Jahren Dutzende von Entwicklungsmonaten an Engineering-Aufwand ersparen. SageMaker ist ein HIPAA-fähiger Dienst und ist nach PCI, SOC, GDPR und ISO zertifiziert. SageMaker unterstützt auch FIPS-Endpunkte. Weitere Informationen zu TCO finden Sie unter Die Gesamtbetriebskosten von Amazon SageMaker. |
Inferenzlatenz | Viele ML-Modelle und -Anwendungen sind latenzkritisch, bei denen die Inferenzlatenz innerhalb der durch ein Service-Level-Ziel festgelegten Grenzen liegen muss. Die Inferenzlatenz hängt von einer Vielzahl von Faktoren ab, darunter Modellgröße und -komplexität, Hardwareplattform, Softwareumgebung und Netzwerkarchitektur. Bei größeren und komplexeren Modellen kann es beispielsweise länger dauern, die Inferenz auszuführen. |
Durchsatz (Transaktionen pro Sekunde) | Für die Modellinferenz ist die Optimierung des Durchsatzes entscheidend für die Leistungsoptimierung und das Erreichen des Geschäftsziels der ML-Anwendung. Da wir in allen Aspekten von ML, einschließlich Low-Level-Implementierungen mathematischer Operationen im Chipdesign, weiterhin schnell vorankommen, spielen hardwarespezifische Bibliotheken eine größere Rolle bei der Leistungsoptimierung. Verschiedene Faktoren wie Nutzlastgröße, Netzwerk-Hops, Art der Hops, Modelldiagrammfunktionen, Operatoren im Modell und das CPU-, GPU- und Speicherprofil der Modell-Hosting-Instanzen wirken sich auf den Durchsatz des ML-Modells aus. |
Skalierung der Konfigurationskomplexität | Es ist entscheidend, dass die ML-Modelle oder -Anwendungen auf einem skalierbaren Framework ausgeführt werden, das die Anforderungen unterschiedlichen Datenverkehrs bewältigen kann. Es ermöglicht auch die maximale Nutzung von CPU- und GPU-Ressourcen und verhindert eine übermäßige Bereitstellung von Rechenressourcen. |
Erwartetes Verkehrsmuster | ML-Modelle oder -Anwendungen können unterschiedliche Verkehrsmuster aufweisen, die von kontinuierlichem Live-Verkehr in Echtzeit bis hin zu periodischen Spitzen von Tausenden von Anfragen pro Sekunde und von seltenen, unvorhersehbaren Anfragemustern bis hin zu Offline-Batch-Anfragen bei größeren Datensätzen reichen. Es wird empfohlen, ausgehend vom erwarteten Verkehrsmuster rückwärts zu arbeiten, um die richtige Hosting-Option für Ihr ML-Modell auszuwählen. |
Bereitstellen von Modellen mit SageMaker
SageMaker ist ein vollständig verwalteter AWS-Service, der jedem Entwickler und Datenwissenschaftler die Möglichkeit bietet, ML-Modelle schnell und in großem Umfang zu erstellen, zu trainieren und bereitzustellen. Mit SageMaker-Inferenz können Sie Ihre ML-Modelle auf gehosteten Endpunkten bereitstellen und Inferenzergebnisse erhalten. SageMaker bietet eine große Auswahl an Hardware und Funktionen, um Ihre Workload-Anforderungen zu erfüllen, sodass Sie über 70 Instance-Typen mit Hardwarebeschleunigung auswählen können. SageMaker kann mithilfe einer neuen Funktion namens SageMaker Inference Recommender auch Empfehlungen für Inferenzinstanztypen bereitstellen, falls Sie sich nicht sicher sind, welche für Ihre Arbeitslast am besten geeignet ist.
Sie können Bereitstellungsoptionen auswählen, die Ihren Anwendungsfällen am besten entsprechen, z. B. Echtzeit-Inferenz, asynchrone, Batch- und sogar serverlose Endpunkte. Darüber hinaus bietet SageMaker verschiedene Bereitstellungsstrategien wie Canary, blau / grün, Schattenund A/B-Tests für die Modellbereitstellung sowie eine kostengünstige Bereitstellung mit mehreren Modellen, mehreren Container-Endpunkten und elastischer Skalierung. Mit SageMaker-Inferenz können Sie die Leistungsmetriken für Ihre Endpunkte in anzeigen Amazon CloudWatch, Endpunkte automatisch skalieren basierend auf dem Datenverkehr, und aktualisieren Sie Ihre Modelle in der Produktion, ohne die Verfügbarkeit zu verlieren.
SageMaker bietet vier Optionen zum Bereitstellen Ihres Modells, damit Sie mit dem Treffen von Vorhersagen beginnen können:
- Echtzeit-Inferenz – Dies ist für Workloads mit Latenzanforderungen im Millisekundenbereich, Payload-Größen bis zu 6 MB und Verarbeitungszeiten von bis zu 60 Sekunden geeignet.
- Batch-Transformation – Dies ist ideal für Offline-Vorhersagen für große Datenmengen, die im Voraus verfügbar sind.
- Asynchrone Inferenz – Dies ist für Workloads konzipiert, die keine Latenzanforderungen von weniger als einer Sekunde, Payload-Größen von bis zu 1 GB und Verarbeitungszeiten von bis zu 15 Minuten haben.
- Serverlose Inferenz – Mit serverloser Inferenz können Sie schnell ML-Modelle für Inferenz bereitstellen, ohne die zugrunde liegende Infrastruktur konfigurieren oder verwalten zu müssen. Darüber hinaus zahlen Sie nur für die Rechenkapazität, die zum Verarbeiten von Inferenzanforderungen verwendet wird, was ideal für intermittierende Workloads ist.
Das folgende Diagramm kann Ihnen dabei helfen, die Bereitstellungsoptionen des SageMaker-Hostingmodells zusammen mit den zugehörigen Fitnessfunktionsauswertungen zu verstehen.
Sehen wir uns die einzelnen Bereitstellungsoptionen genauer an.
Echtzeit-Inferenz in SageMaker
SageMaker-Echtzeit-Inferenz wird empfohlen, wenn Sie anhaltenden Datenverkehr haben und eine niedrigere und konsistente Latenz für Ihre Anforderungen mit Nutzlastgrößen von bis zu 6 MB und Verarbeitungszeiten von bis zu 60 Sekunden benötigen. Sie stellen Ihr Modell für SageMaker-Hosting-Services bereit und erhalten einen Endpunkt, der für Inferenzen verwendet werden kann. Diese Endpunkte werden vollständig verwaltet und unterstützen die automatische Skalierung. Echtzeit-Inferenz ist beliebt für Anwendungsfälle, in denen Sie eine synchrone Antwort mit geringer Latenz und vorhersagbaren Verkehrsmustern erwarten, wie z. B. personalisierte Empfehlungen für Produkte und Dienstleistungen oder Anwendungsfälle zur Erkennung von Transaktionsbetrug.
Typischerweise sendet eine Clientanwendung Anforderungen an den SageMaker-HTTPS-Endpunkt, um Inferenzen von einem bereitgestellten Modell zu erhalten. Sie können mehrere Varianten eines Modells auf demselben SageMaker-HTTPS-Endpunkt bereitstellen. Dies ist nützlich, um Variationen eines Modells in der Produktion zu testen. Mit der automatischen Skalierung können Sie die Anzahl der für ein Modell bereitgestellten Instanzen als Reaktion auf Änderungen Ihrer Arbeitslast dynamisch anpassen.
Die folgende Tabelle enthält Anleitungen zur Bewertung der Echtzeit-Inferenz von SageMaker basierend auf den Fitnessfunktionen.
Fitnessfunktion | Beschreibung |
Kosten |
Echtzeit-Endpunkte bieten eine synchrone Antwort auf Inferenzanforderungen. Da der Endpunkt immer ausgeführt wird und verfügbar ist, um eine synchrone Inferenzantwort in Echtzeit bereitzustellen, zahlen Sie für die Nutzung der Instanz. Die Kosten können sich schnell summieren, wenn Sie mehrere Endpunkte bereitstellen, insbesondere wenn die Endpunkte die zugrunde liegenden Instanzen nicht vollständig nutzen. Durch die Auswahl der richtigen Instanz für Ihr Modell können Sie sicherstellen, dass Sie die leistungsfähigste Instanz zu den niedrigsten Kosten für Ihre Modelle haben. Die automatische Skalierung wird empfohlen, um die Kapazität je nach Datenverkehr dynamisch anzupassen, um eine konstante und vorhersehbare Leistung zu möglichst niedrigen Kosten aufrechtzuerhalten. SageMaker erweitert den Zugriff auf Graviton2- und Graviton3-basierte ML-Instanzfamilien. AWS Graviton Prozessoren werden von Amazon Web Services unter Verwendung von 64-Bit-Arm-Neoverse-Kernen speziell entwickelt, um das beste Preis-Leistungs-Verhältnis für Ihre Cloud-Workloads zu bieten, die auf Amazon EC2 ausgeführt werden. Mit Graviton-basierten Instanzen haben Sie mehr Optionen zur Optimierung von Kosten und Leistung bei der Bereitstellung Ihrer ML-Modelle auf SageMaker. SageMaker unterstützt auch Inf1-Instanzen, die eine leistungsstarke und kostengünstige ML-Inferenz bietet. Mit 1–16 AWS Inferentia-Chips pro Instanz können Inf1-Instanzen in der Leistung skalieren und einen bis zu dreimal höheren Durchsatz und bis zu 50 % niedrigere Kosten pro Inferenz im Vergleich zu den AWS-GPU-basierten Instanzen liefern. Um Inf1-Instanzen in SageMaker zu verwenden, können Sie Ihre trainierten Modelle mit kompilieren Amazon SageMaker Neo und wählen Sie die Inf1-Instanzen aus, um das kompilierte Modell auf SageMaker bereitzustellen. Sie können auch erkunden Sparpläne für SageMaker um von Kosteneinsparungen von bis zu 64 % im Vergleich zum On-Demand-Preis zu profitieren. Wenn Sie einen Endpunkt erstellen, fügt SageMaker jeder ML-Recheninstanz, die den Endpunkt hostet, ein EBS-Speichervolume hinzu. Die Größe des Speichervolumens hängt vom Instance-Typ ab. Die zusätzlichen Kosten für Echtzeit-Endpunkte umfassen die Kosten für bereitgestellten Speicher in GB pro Monat sowie GB-Daten, die in der Endpunktinstanz verarbeitet und GB-Daten verarbeitet werden. |
Inferenzlatenz | Echtzeit-Inferenz ist ideal, wenn Sie einen dauerhaften Endpunkt mit Latenzanforderungen im Millisekundenbereich benötigen. Es unterstützt Payload-Größen von bis zu 6 MB und Verarbeitungszeiten von bis zu 60 Sekunden. |
Durchsatz |
Ein idealer Wert für den Inferenzdurchsatz hängt von Faktoren wie Modell, Modelleingabegröße, Stapelgröße und Endpunktinstanztyp ab. Überprüfen Sie als Best Practice die CloudWatch-Metriken für Eingabeanforderungen und Ressourcennutzung und wählen Sie den geeigneten Instance-Typ aus, um einen optimalen Durchsatz zu erzielen. Eine Geschäftsanwendung kann entweder durchsatzoptimiert oder latenzoptimiert sein. Beispielsweise kann dynamisches Batching dazu beitragen, den Durchsatz für latenzempfindliche Apps mithilfe von Echtzeit-Inferenz zu erhöhen. Es gibt jedoch Grenzen für die Stapelgröße, ohne die die Inferenzlatenz beeinträchtigt werden könnte. Die Inferenzlatenz nimmt zu, wenn Sie die Stapelgröße erhöhen, um den Durchsatz zu verbessern. Daher ist Echtzeit-Inferenz eine ideale Option für latenzempfindliche Anwendungen. SageMaker bietet Optionen für asynchrone Inferenz und Batch-Transformation, die für einen höheren Durchsatz im Vergleich zur Echtzeit-Inferenz optimiert sind, wenn die Geschäftsanwendungen eine etwas höhere Latenz tolerieren können. |
Skalierung der Konfigurationskomplexität |
Unterstützung von SageMaker-Endpunkten in Echtzeit automatische Skalierung aus der Kiste. Wenn die Arbeitslast zunimmt, bringt die automatische Skalierung mehr Instanzen online. Wenn die Arbeitslast abnimmt, entfernt die automatische Skalierung unnötige Instanzen und hilft Ihnen so, Ihre Rechenkosten zu senken. Ohne Auto Scaling müssen Sie für Spitzenverkehr oder die Nichtverfügbarkeit des Risikomodells vorsorgen. Wenn der Datenverkehr zu Ihrem Modell den ganzen Tag über nicht konstant ist, wird überschüssige ungenutzte Kapazität vorhanden sein. Dies führt zu geringer Auslastung und Verschwendung von Ressourcen. Mit SageMaker können Sie basierend auf dem erwarteten Datenverkehrsmuster verschiedene Skalierungsoptionen konfigurieren. Einfache Skalierung oder Zielverfolgungsskalierung ist ideal, wenn Sie basierend auf einer bestimmten CloudWatch-Metrik skalieren möchten. Sie können dies tun, indem Sie eine bestimmte Metrik auswählen und Schwellenwerte festlegen. Die empfohlenen Metriken für diese Option sind durchschnittlich Wenn Sie eine erweiterte Konfiguration benötigen, können Sie eine schrittweise Skalierungsrichtlinie festlegen, um die Anzahl der zu skalierenden Instanzen basierend auf der Größe der Alarmverletzung dynamisch anzupassen. Dies hilft Ihnen, eine aggressivere Reaktion zu konfigurieren, wenn die Nachfrage ein bestimmtes Niveau erreicht. Sie können eine geplante Skalierungsoption verwenden, wenn Sie wissen, dass der Bedarf einem bestimmten Zeitplan für den Tag, die Woche, den Monat oder das Jahr folgt. Auf diese Weise können Sie einen einmaligen Zeitplan oder einen wiederkehrenden Zeitplan oder Cron-Ausdrücke zusammen mit Start- und Endzeiten angeben, die die Grenzen für den Beginn und das Ende der automatischen Skalierungsaktion bilden. Weitere Einzelheiten finden Sie unter Konfigurieren von Autoscaling-Inferenzendpunkten in Amazon SageMaker und Belastungstest und Optimierung eines Amazon SageMaker-Endpunkts mit automatischer Skalierung. |
Verkehrsmuster | Echtzeit-Inferenz ist ideal für Workloads mit einem kontinuierlichen oder regelmäßigen Datenverkehrsmuster. |
Asynchrone Inferenz in SageMaker
Die asynchrone Inferenz von SageMaker ist eine neue Funktion in SageMaker, die eingehende Anforderungen in eine Warteschlange stellt und sie asynchron verarbeitet. Diese Option ist ideal für Anfragen mit großen Nutzlastgrößen (bis zu 1 GB), langen Verarbeitungszeiten (bis zu 15 Minuten) und Latenzanforderungen nahezu in Echtzeit. Beispiele für Workloads für asynchrone Inferenz sind Gesundheitsunternehmen, die hochauflösende biomedizinische Bilder oder Videos wie Echokardiogramme verarbeiten, um Anomalien zu erkennen. Diese Anwendungen empfangen zu unterschiedlichen Tageszeiten eingehenden Datenverkehr und erfordern eine kostengünstige Verarbeitung in nahezu Echtzeit. Die Verarbeitungszeiten für diese Anfragen können in der Größenordnung von Minuten liegen, sodass keine Echtzeit-Inferenz ausgeführt werden muss. Stattdessen können Eingabenutzlasten asynchron von einem Objektspeicher wie Amazon S3 mit automatischer Warteschlangenbildung und einem vordefinierten Parallelitätsschwellenwert verarbeitet werden. Bei der Verarbeitung platziert SageMaker die Inferenzantwort am zuvor zurückgegebenen Amazon S3-Speicherort. Sie können optional auswählen, ob Sie Erfolgs- oder Fehlerbenachrichtigungen per erhalten möchten Amazon Simple Notification Service (Amazon SNS).
Die folgende Tabelle enthält Anleitungen zur Bewertung der asynchronen SageMaker-Inferenz basierend auf den Fitnessfunktionen.
Fitnessfunktion | Beschreibung |
Kosten | Asynchrone Inferenz ist eine gute Wahl für kostensensitive Workloads mit großen Nutzlasten und Burst-Traffic. Durch asynchrone Inferenz können Sie Kosten sparen, indem Sie die Anzahl der Instanzen automatisch auf null skalieren, wenn keine Anforderungen zu verarbeiten sind, sodass Sie nur bezahlen, wenn Ihr Endpunkt Anforderungen verarbeitet. Anfragen, die empfangen werden, wenn keine Instanzen vorhanden sind, werden zur Verarbeitung in die Warteschlange gestellt, nachdem der Endpunkt hochskaliert wurde. |
Inferenzlatenz | Asynchrone Inferenz ist ideal für Latenzanforderungen nahezu in Echtzeit. Die Anfragen werden in eine Warteschlange gestellt und verarbeitet, sobald die Rechenleistung verfügbar ist. Dies führt in der Regel zu einer Latenz von mehreren zehn Millisekunden. |
Durchsatz | Asynchrone Inferenz ist ideal für nicht latenzempfindliche Anwendungsfälle, da Anwendungen keine Kompromisse beim Durchsatz eingehen müssen. Anforderungen werden während Datenverkehrsspitzen nicht verworfen, da der asynchrone Inferenzendpunkt Anforderungen in eine Warteschlange stellt, anstatt sie zu verwerfen. |
Skalierung der Konfigurationskomplexität |
SageMaker unterstützt automatische Skalierung für asynchronen Endpunkt. Im Gegensatz zu in Echtzeit gehosteten Endpunkten unterstützen asynchrone Inferenzendpunkte das Herunterskalieren von Instanzen auf null, indem die Mindestkapazität auf null gesetzt wird. Für asynchrone Endpunkte empfiehlt SageMaker dringend, dass Sie eine Richtlinienkonfiguration für die Zielverfolgungsskalierung für ein bereitgestelltes Modell (Variante) erstellen. Für Anwendungsfälle, die eine Kaltstartstrafe von einigen Minuten tolerieren können, können Sie optional die Anzahl der Endpunktinstanzen auf null herunterskalieren, wenn keine ausstehenden Anforderungen vorhanden sind, und wieder hochskalieren, wenn neue Anforderungen eintreffen, sodass Sie nur für die Dauer bezahlen, die die Endpunkte verarbeiten Anfragen aktiv. |
Verkehrsmuster | Asynchrone Endpunkte stellen eingehende Anfragen in eine Warteschlange und verarbeiten sie asynchron. Sie sind eine gute Option für intermittierende oder seltene Verkehrsmuster. |
Batch-Inferenz in SageMaker
Die SageMaker-Batch-Transformation ist ideal für Offline-Vorhersagen für große Datenmengen, die im Voraus verfügbar sind. Die Batch-Transformationsfunktion ist eine leistungsstarke Methode mit hohem Durchsatz zum Transformieren von Daten und Generieren von Inferenzen. Es ist ideal für Szenarien, in denen Sie mit großen Datenstapeln arbeiten, keine Latenzzeiten von weniger als einer Sekunde benötigen oder die Trainingsdaten sowohl vorverarbeiten als auch transformieren müssen. Kunden in bestimmten Bereichen wie Werbung und Marketing oder Gesundheitswesen müssen häufig Offline-Prognosen für Hyperscale-Datensätze treffen, bei denen ein hoher Durchsatz häufig das Ziel des Anwendungsfalls ist und die Latenz kein Problem darstellt.
Wenn ein Batch-Transformationsjob gestartet wird, initialisiert SageMaker Compute-Instanzen und verteilt die Inferenzarbeitslast zwischen ihnen. Die Ressourcen werden freigegeben, wenn die Jobs abgeschlossen sind, sodass Sie nur für das bezahlen, was während der Ausführung Ihres Jobs verwendet wurde. Wenn der Job abgeschlossen ist, speichert SageMaker die Vorhersageergebnisse in einem von Ihnen angegebenen S3-Bucket. Batch-Inferenzaufgaben sind normalerweise gute Kandidaten für die horizontale Skalierung. Jeder Worker innerhalb eines Clusters kann mit einer anderen Teilmenge von Daten arbeiten, ohne dass Informationen mit anderen Workern ausgetauscht werden müssen. AWS bietet mehrere Speicher- und Rechenoptionen, die eine horizontale Skalierung ermöglichen. Beispiele für Workloads für die SageMaker-Batch-Transformation sind Offline-Anwendungen wie Banking-Anwendungen zur Vorhersage von Kundenabwanderungen, bei denen die regelmäßige Ausführung eines Offline-Jobs geplant werden kann.
Die folgende Tabelle enthält Anleitungen zur Bewertung der SageMaker-Batch-Transformation basierend auf den Fitnessfunktionen.
Fitnessfunktion | Beschreibung |
Kosten | Mit der SageMaker-Batch-Transformation können Sie Vorhersagen für große oder kleine Batch-Datasets ausführen. Der von Ihnen gewählte Instance-Typ wird Ihnen basierend auf der Nutzungsdauer in Rechnung gestellt. SageMaker verwaltet die Bereitstellung von Ressourcen zu Beginn des Jobs und gibt sie frei, wenn der Job abgeschlossen ist. Es fallen keine zusätzlichen Datenverarbeitungskosten an. |
Inferenzlatenz | Sie können ereignisbasierte oder geplante Aufrufe verwenden. Die Latenz kann abhängig von der Größe der Inferenzdaten, der Jobparallelität, der Komplexität des Modells und der Kapazität der Compute-Instanz variieren. |
Durchsatz |
Batch-Transformationsaufträge können für eine Reihe von Datensätzen ausgeführt werden, von Daten im Petabyte-Bereich bis hin zu sehr kleinen Datensätzen. Es besteht keine Notwendigkeit, größere Datensätze in kleine Datenblöcke zu skalieren. Sie können Batch-Transformationsjobs beschleunigen, indem Sie optimale Werte für Parameter wie z MaxPayloadInMB, MaxConcurrentTransforms, oder BatchStrategie. Der ideale Wert für Die Stapelverarbeitung kann den Durchsatz erhöhen und Ihre Ressourcen optimieren, da sie hilft, eine größere Anzahl von Inferenzen in einer bestimmten Zeit auf Kosten der Latenz abzuschließen. Um die Modellbereitstellung für einen höheren Durchsatz zu optimieren, lautet die allgemeine Richtlinie, die Stapelgröße zu erhöhen, bis der Durchsatz abnimmt. |
Skalierung der Konfigurationskomplexität | Die SageMaker-Batch-Transformation wird für latenzunabhängige Offline-Inferenzen verwendet. |
Verkehrsmuster | Für Offline-Inferenz wird ein Batch-Transformationsjob geplant oder mithilfe eines ereignisbasierten Triggers gestartet. |
Serverlose Inferenz in SageMaker
Die serverlose SageMaker-Inferenz ermöglicht Ihnen die Bereitstellung von ML-Modellen für die Inferenz, ohne die zugrunde liegende Infrastruktur konfigurieren oder verwalten zu müssen. Basierend auf der Menge der Inferenzanforderungen, die Ihr Modell erhält, stellt die serverlose SageMaker-Inferenz automatisch Rechenkapazität bereit, skaliert und deaktiviert sie. Infolgedessen zahlen Sie nur für die Rechenzeit zum Ausführen Ihres Inferenzcodes und die verarbeitete Datenmenge, nicht für Leerlaufzeiten. Sie können die integrierten Algorithmen von SageMaker und Container, die das ML-Framework bereitstellen, verwenden, um Ihr Modell an einem serverlosen Inferenzendpunkt bereitzustellen, oder Sie können Ihren eigenen Container verwenden. Wenn der Datenverkehr vorhersehbar und stabil wird, können Sie problemlos von einem serverlosen Inferenz-Endpunkt auf einen SageMaker-Echtzeit-Endpunkt aktualisieren, ohne Änderungen an Ihrem Container-Image vornehmen zu müssen. Mit serverloser Inferenz profitieren Sie auch von anderen SageMaker-Funktionen, einschließlich integrierter Metriken wie Aufrufanzahl, Fehler, Latenz, Hostmetriken und Fehler in CloudWatch.
Die folgende Tabelle enthält Anleitungen zur Bewertung der serverlosen Inferenz von SageMaker basierend auf den Fitnessfunktionen.
Fitnessfunktion | Beschreibung |
Kosten | Bei einem Pay-as-you-run-Modell ist die serverlose Inferenz eine kostengünstige Option, wenn Sie seltene oder intermittierende Datenverkehrsmuster haben. Sie zahlen nur für die Dauer, für die der Endpunkt die Anfrage verarbeitet, und können daher Kosten sparen, wenn das Datenverkehrsmuster intermittierend ist. |
Inferenzlatenz |
Serverlose Endpunkte bieten eine niedrige Inferenzlatenz (in der Größenordnung von Millisekunden bis Sekunden) mit der Fähigkeit, basierend auf den Nutzungsmustern innerhalb von Sekunden von zehn auf Tausende von Inferenzen zu skalieren, was sie ideal für ML-Anwendungen mit intermittierendem oder unvorhersehbarem Datenverkehr macht. Da serverlose Endpunkte Rechenressourcen nach Bedarf bereitstellen, kann es bei Ihrem Endpunkt beim ersten Aufruf nach einer Leerlaufzeit zu einigen zusätzlichen Sekunden Latenz (Kaltstart) kommen. Die Kaltstartzeit hängt von Ihrer Modellgröße, der Dauer des Herunterladens Ihres Modells und der Startzeit Ihres Containers ab. |
Durchsatz | Beim Konfigurieren Ihres serverlosen Endpunkts können Sie die Speichergröße und die maximale Anzahl gleichzeitiger Aufrufe angeben. Die serverlose Inferenz von SageMaker weist Rechenressourcen automatisch proportional zu dem von Ihnen ausgewählten Arbeitsspeicher zu. Wenn Sie eine größere Speichergröße wählen, hat Ihr Container Zugriff auf mehr vCPUs. In der Regel sollte die Speichergröße mindestens so groß sein wie Ihre Modellgröße. Die Speichergrößen, die Sie wählen können, sind 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB und 6144 MB. Unabhängig von der gewählten Speichergröße stehen serverlosen Endpunkten 5 GB kurzlebiger Festplattenspeicher zur Verfügung. |
Skalierung der Konfigurationskomplexität | Serverlose Endpunkte starten automatisch Rechenressourcen und skalieren sie je nach Datenverkehr ein und aus, wodurch die Notwendigkeit entfällt, Instanztypen auszuwählen oder Skalierungsrichtlinien zu verwalten. Dadurch entfällt das undifferenzierte schwere Heben der Auswahl und Verwaltung von Servern. |
Verkehrsmuster | Serverlose Inferenz ist ideal für Workloads mit seltenen oder intermittierenden Datenverkehrsmustern. |
Modellieren Sie Hosting-Entwurfsmuster in SageMaker
SageMaker-Inferenzendpunkte verwenden Docker-Container zum Hosten von ML-Modellen. Mit Containern können Sie Software in standardisierte Einheiten packen, die konsistent auf jeder Plattform laufen, die Docker unterstützt. Dies gewährleistet plattformübergreifende Portabilität, unveränderliche Infrastrukturbereitstellungen und einfacheres Änderungsmanagement und CI/CD-Implementierungen. SageMaker bietet vorgefertigte verwaltete Container für beliebte Frameworks wie Apache MXNet, TensorFlow, PyTorch, Sklearn und Hugging Face. Eine vollständige Liste der verfügbaren SageMaker-Container-Images finden Sie unter Verfügbare Deep-Learning-Container-Images. Falls SageMaker keinen unterstützten Container hat, können Sie auch Ihren eigenen Container (BYOC) erstellen und Ihr eigenes benutzerdefiniertes Image pushen, indem Sie die Abhängigkeiten installieren, die für Ihr Modell erforderlich sind.
Um ein Modell auf SageMaker bereitzustellen, benötigen Sie einen Container (SageMaker Managed Framework Containers oder BYOC) und eine Recheninstanz zum Hosten des Containers. SageMaker unterstützt mehrere erweiterte Optionen für gängige Designmuster zum Hosten von ML-Modellen, bei denen Modelle in einem einzelnen Container gehostet oder gemeinsam in einem gemeinsam genutzten Container gehostet werden können.
Eine Echtzeit-ML-Anwendung kann ein einzelnes Modell oder mehrere Modelle verwenden, um eine einzelne Vorhersageanforderung zu bedienen. Das folgende Diagramm zeigt verschiedene Inferenzszenarien für eine ML-Anwendung.
Lassen Sie uns eine geeignete SageMaker-Hosting-Option für jedes der vorangehenden Inferenzszenarien untersuchen. Sie können sich auf die Fitnessfunktionen beziehen, um zu beurteilen, ob dies die richtige Option für den jeweiligen Anwendungsfall ist.
Hosten einer auf einem einzelnen Modell basierenden ML-Anwendung
Je nach Bereitstellungsszenario gibt es mehrere Optionen zum Hosten von Einzelmodell-basierten ML-Anwendungen mit SageMaker-Hostingdiensten.
Einzelmodell-Endpunkt
SageMaker Single-Model-Endpunkte ermöglichen es Ihnen, ein Modell in einem Container zu hosten, der auf dedizierten Instances für geringe Latenz und hohen Durchsatz gehostet wird. Diese Endpunkte werden vollständig verwaltet und unterstützen die automatische Skalierung. Sie können den Einzelmodell-Endpunkt als bereitgestellten Endpunkt konfigurieren, an den Sie die Konfiguration der Endpunktinfrastruktur wie Instanztyp und -anzahl übergeben, oder als serverlosen Endpunkt, an dem SageMaker automatisch Rechenressourcen startet und sie je nach Datenverkehr ein- und ausskaliert, wodurch die Notwendigkeit entfällt um Instance-Typen auszuwählen oder Skalierungsrichtlinien zu verwalten. Serverlose Endpunkte sind für Anwendungen mit intermittierendem oder unvorhersehbarem Datenverkehr.
Das folgende Diagramm zeigt Endpunktrückschlussszenarien mit einem einzelnen Modell.
Die folgende Tabelle enthält Anleitungen zur Bewertung von Fitnessfunktionen für einen bereitgestellten Einzelmodell-Endpunkt. Informationen zu Fitnessfunktionsbewertungen für serverlose Endpunkte finden Sie im Abschnitt über serverlose Endpunkte in diesem Beitrag.
Fitnessfunktion | Beschreibung |
Kosten | Die Nutzung des von Ihnen gewählten Instance-Typs wird Ihnen in Rechnung gestellt. Da der Endpunkt immer läuft und verfügbar ist, können sich die Kosten schnell summieren. Durch die Auswahl der richtigen Instanz für Ihr Modell können Sie sicherstellen, dass Sie die leistungsfähigste Instanz zu den niedrigsten Kosten für Ihre Modelle haben. Die automatische Skalierung wird empfohlen, um die Kapazität je nach Datenverkehr dynamisch anzupassen, um eine konstante und vorhersehbare Leistung zu möglichst niedrigen Kosten aufrechtzuerhalten. |
Inferenzlatenz | Ein Einzelmodell-Endpunkt bietet interaktive, synchrone Inferenz in Echtzeit mit Latenzanforderungen im Millisekundenbereich. |
Durchsatz | Der Durchsatz kann von verschiedenen Faktoren beeinflusst werden, z. B. Modelleingabegröße, Stapelgröße, Endpunktinstanztyp usw. Es wird empfohlen, die CloudWatch-Metriken für Eingabeanforderungen und Ressourcennutzung zu überprüfen und den geeigneten Instance-Typ auszuwählen, um einen optimalen Durchsatz zu erzielen. SageMaker bietet Funktionen zum Verwalten von Ressourcen und zum Optimieren der Inferenzleistung beim Bereitstellen von ML-Modellen. Du kannst Optimieren Sie die Modellleistung mit Neo, oder verwenden Sie Inf1-Instanzen für einen besseren Durchsatz Ihrer von SageMaker gehosteten Modelle mit einer GPU-Instanz für Ihren Endpunkt. |
Skalierung der Konfigurationskomplexität | Automatische Skalierung wird standardmäßig unterstützt. SageMaker empfiehlt die Auswahl eines geeigneten Skalierungskonfiguration durch Aufführung Belastungstests. |
Verkehrsmuster | Ein Einzelmodell-Endpunkt ist ideal für Workloads mit vorhersagbaren Datenverkehrsmustern. |
Co-Hosting mehrerer Modelle
Wenn Sie es mit einer großen Anzahl von Modellen zu tun haben, kann die Bereitstellung jedes Modells auf einem einzelnen Endpunkt mit einem dedizierten Container und einer Instanz zu einer erheblichen Kostensteigerung führen. Darüber hinaus wird es auch schwierig, so viele Modelle in der Produktion zu verwalten, insbesondere wenn Sie nicht alle Modelle gleichzeitig aufrufen müssen, aber dennoch jederzeit verfügbar sein müssen. Das Co-Hosting mehrerer Modelle auf denselben zugrunde liegenden Rechenressourcen erleichtert die skalierbare Verwaltung von ML-Bereitstellungen und senkt Ihre Hosting-Kosten durch eine erhöhte Nutzung des Endpunkts und seiner zugrunde liegenden Rechenressourcen. SageMaker unterstützt erweiterte Modell-Co-Hosting-Optionen wie Multi-Model-Endpoint (MME) für homogene Modelle und Multi-Container-Endpoint (MCE) für heterogene Modelle. Homogene Modelle verwenden dasselbe ML-Framework auf einem Shared-Service-Container, während heterogene Modelle es Ihnen ermöglichen, mehrere Serving-Container bereitzustellen, die unterschiedliche Modelle oder Frameworks auf einem einzigen Endpunkt verwenden.
Das folgende Diagramm zeigt Modell-Co-Hosting-Optionen mit SageMaker.
SageMaker-Endpunkte mit mehreren Modellen
SageMaker MMEs ermöglichen es Ihnen, mehrere Modelle mit einem Shared-Serving-Container auf einem einzigen Endpunkt zu hosten. Dies ist eine skalierbare und kostengünstige Lösung zur Bereitstellung einer großen Anzahl von Modellen, die denselben Anwendungsfall, dasselbe Framework oder dieselbe Inferenzlogik bedienen. MMEs können Anforderungen basierend auf dem vom Anrufer aufgerufenen Modell dynamisch bedienen. Es reduziert auch den Bereitstellungsaufwand, da SageMaker das Laden von Modellen in den Speicher und deren Skalierung basierend auf den Datenverkehrsmustern zu ihnen verwaltet. Diese Funktion ist ideal, wenn Sie eine große Anzahl ähnlicher Modelle haben, die Sie über einen gemeinsam genutzten Bereitstellungscontainer bereitstellen können, und nicht gleichzeitig auf alle Modelle zugreifen müssen. Endpunkte mit mehreren Modellen ermöglichen auch die gemeinsame Nutzung von Arbeitsspeicherressourcen über Ihre Modelle hinweg. Dies funktioniert am besten, wenn die Modelle in Größe und Aufruflatenz ziemlich ähnlich sind, sodass MMEs die Instanzen über alle Modelle hinweg effektiv nutzen können. SageMaker MMEs unterstützen das Hosten von CPU- und GPU-gestützten Modellen. Durch die Verwendung von GPU-gestützten Modellen können Sie Ihre Modellbereitstellungskosten durch eine erhöhte Nutzung des Endpunkts und seiner zugrunde liegenden beschleunigten Recheninstanzen senken. Einen realen Anwendungsfall von MMEs finden Sie unter So skalieren Sie maschinelle Lerninferenz für mandantenfähige SaaS-Anwendungsfälle.
Die folgende Tabelle enthält eine Anleitung zur Bewertung der Fitnessfunktionen für MMEs.
Fitnessfunktion | Beschreibung |
Kosten |
MMEs ermöglichen die Verwendung eines Shared-Serving-Containers, um Tausende von Modellen auf einem einzigen Endpunkt zu hosten. Dies reduziert die Hosting-Kosten erheblich, indem die Endpunktauslastung im Vergleich zur Verwendung von Einzelmodell-Endpunkten verbessert wird. Wenn Sie beispielsweise 10 Modelle mit einer ml.c5.large-Instanz bereitzustellen haben, basierend auf SageMaker-Preise, betragen die Kosten für 10 persistente Endpunkte mit einem Modell: 10 * 0.102 USD = 1.02 USD pro Stunde. Dagegen erzielen wir mit einem MME, der die 10 Modelle hostet, eine 10-fache Kosteneinsparung: 1 * 0.102 USD = 0.102 USD pro Stunde. |
Inferenzlatenz |
Standardmäßig speichern MMEs häufig verwendete Modelle im Arbeitsspeicher und auf der Festplatte, um Inferenzen mit geringer Latenz zu ermöglichen. Die zwischengespeicherten Modelle werden nur dann entladen oder von der Festplatte gelöscht, wenn ein Container nicht mehr genügend Arbeitsspeicher oder Speicherplatz hat, um ein neues Zielmodell aufzunehmen. MMEs ermöglichen Lazy Loading von Modellen, was bedeutet, dass Modelle beim ersten Aufruf in den Speicher geladen werden. Dadurch wird die Speicherauslastung optimiert; Es verursacht jedoch Reaktionszeitspitzen beim ersten Laden, was zu einem Kaltstartproblem führt. Daher eignen sich MMEs auch gut für Szenarien, die gelegentliche kaltstartbedingte Latenzstrafen tolerieren können, die beim Aufrufen selten verwendeter Modelle auftreten. Um die Latenz- und Durchsatzziele von ML-Anwendungen zu erfüllen, werden GPU-Instanzen gegenüber CPU-Instanzen bevorzugt (angesichts der Rechenleistung, die GPUs bieten). Mit MME-Unterstützung für GPU können Sie Tausende von Deep-Learning-Modellen hinter einem SageMaker-Endpunkt bereitstellen. MMEs können mehrere Modelle auf einem GPU-Kern ausführen, GPU-Instanzen hinter einem Endpunkt über mehrere Modelle hinweg gemeinsam nutzen und Modelle basierend auf dem eingehenden Datenverkehr dynamisch laden und entladen. Damit können Sie deutlich Kosten sparen und die beste Preisleistung erzielen. Wenn Ihr Anwendungsfall deutlich höhere Transaktionen pro Sekunde (TPS) oder Latenzanforderungen erfordert, empfehlen wir, die Modelle auf dedizierten Endpunkten zu hosten. |
Durchsatz |
Ein idealer Wert für den MME-Inferenzdurchsatz hängt von Faktoren wie Modell, Nutzlastgröße und Endpunktinstanztyp ab. Eine größere Menge an Instanzspeicher ermöglicht es Ihnen, mehr Modelle zu laden und bereit zu sein, Inferenzanforderungen zu bedienen. Sie müssen keine Zeit damit verschwenden, das Modell zu laden. Eine höhere Anzahl an vCPUs ermöglicht es Ihnen, mehr eindeutige Modelle gleichzeitig aufzurufen. MMEs laden und entladen das Modell dynamisch in den und aus dem Instanzspeicher, was sich auf die E/A-Leistung auswirken kann. SageMaker MMEs mit GPU arbeiten mit NVIDIA Triton-Inferenzserver, eine Open-Source-Inferenzserversoftware, die den Inferenzserverprozess vereinfacht und eine hohe Inferenzleistung bietet. SageMaker lädt das Modell auf einer GPU-beschleunigten Instanz in den Speicher des NVIDIA Triton-Containers und bedient die Inferenzanforderung. Der GPU-Kern wird von allen Modellen in einer Instanz gemeinsam genutzt. Wenn das Modell bereits im Containerspeicher geladen ist, werden die nachfolgenden Anforderungen schneller bedient, da SageMaker es nicht erneut herunterladen und laden muss. Bei erfolgreichen Produktionsbereitstellungen wird eine ordnungsgemäße Leistungsprüfung und -analyse empfohlen. SageMaker stellt CloudWatch-Metriken für Endpunkte mit mehreren Modellen bereit, damit Sie die Endpunktnutzung und die Cache-Trefferrate bestimmen können, um Ihren Endpunkt zu optimieren. |
Skalierung der Konfigurationskomplexität | SageMaker-Endpunkte mit mehreren Modellen unterstützen die automatische Skalierung vollständig, die Replikationen von Modellen verwaltet, um sicherzustellen, dass Modelle basierend auf Verkehrsmustern skaliert werden. Es wird jedoch ein ordnungsgemäßer Lasttest empfohlen, um die optimale Größe der Instanzen für die automatische Skalierung des Endpunkts zu bestimmen. Die richtige Größe der MME-Flotte ist wichtig, um zu vermeiden, dass zu viele Modelle entladen werden. Das Laden von Hunderten von Modellen auf einigen wenigen größeren Instanzen kann in einigen Fällen zu einer Drosselung führen, und die Verwendung von mehr und kleineren Instanzen könnte bevorzugt werden. Um die Vorteile der automatischen Modellskalierung in SageMaker nutzen zu können, stellen Sie sicher, dass Sie dies getan haben automatische Skalierung der Instanz eingerichtet um zusätzliche Instanzkapazität bereitzustellen. Richten Sie Ihre Skalierungsrichtlinie auf Endpunktebene entweder mit benutzerdefinierten Parametern oder mit Aufrufen pro Minute (empfohlen) ein, um der Endpunktflotte weitere Instanzen hinzuzufügen. Die Aufrufraten, die zum Auslösen eines Autoskalierungsereignisses verwendet werden, basieren auf dem aggregierten Satz von Vorhersagen über den gesamten Satz von Modellen, die vom Endpunkt bereitgestellt werden. |
Verkehrsmuster | MMEs sind ideal, wenn Sie eine große Anzahl von Modellen ähnlicher Größe haben, die Sie über einen gemeinsam genutzten Bereitstellungscontainer bedienen können und nicht gleichzeitig auf alle Modelle zugreifen müssen. |
SageMaker Multi-Container-Endpunkte
SageMaker MCEs Unterstützung der Bereitstellung von bis zu 15 Containern, die unterschiedliche Modelle oder Frameworks auf einem einzigen Endpunkt verwenden, und deren Aufruf unabhängig oder nacheinander für Inferenz mit geringer Latenz und Kosteneinsparungen. Die Modelle können völlig heterogen sein, mit ihrem eigenen unabhängigen Servierstapel. Durch das sichere Hosten mehrerer Modelle aus verschiedenen Frameworks auf einer einzigen Instanz können Sie bis zu 90 % Kosten einsparen.
Die MCE-Aufrufmuster lauten wie folgt:
- Inferenzpipelines – Container in einer MME können in einer linearen Sequenz aufgerufen werden, auch bekannt als a serielle Inferenzpipeline. Sie werden normalerweise verwendet, um Vorverarbeitung, Modellrückschluss und Nachverarbeitung in unabhängige Container zu trennen. Die Ausgabe des aktuellen Containers wird als Eingabe an den nächsten übergeben. Sie werden in SageMaker als einzelnes Pipeline-Modell dargestellt. Eine Inferenzpipeline kann als MME bereitgestellt werden, wobei einer der Container in der Pipeline Anforderungen basierend auf dem aufgerufenen Modell dynamisch bedienen kann.
- Direkter Aufruf - Mit direkter Aufruf, kann eine Anfrage an einen bestimmten Rückschlusscontainer gesendet werden, der auf einem MCE gehostet wird.
Die folgende Tabelle enthält eine Anleitung zur Bewertung der Fitnessfunktionen für MCEs.
Fitnessfunktion | Beschreibung |
Kosten | MCEs ermöglichen es Ihnen, bis zu 15 verschiedene ML-Container auf einem einzigen Endpunkt auszuführen und sie unabhängig voneinander aufzurufen, wodurch Sie Kosten sparen. Diese Option ist ideal, wenn Sie mehrere Modelle auf verschiedenen Bereitstellungsstapeln mit ähnlichen Ressourcenanforderungen ausführen und wenn einzelne Modelle nicht über ausreichend Datenverkehr verfügen, um die volle Kapazität der Endpunktinstanzen zu nutzen. MCEs sind daher kostengünstiger als ein Einzelmodell-Endpunkt. MCEs bieten eine synchrone Inferenzantwort, was bedeutet, dass der Endpunkt immer verfügbar ist und Sie für die Betriebszeit der Instanz bezahlen. Die Kosten können sich je nach Anzahl und Art der Instanzen summieren. |
Inferenzlatenz | MCEs eignen sich ideal zum Ausführen von ML-Apps mit unterschiedlichen ML-Frameworks und Algorithmen für jedes Modell, auf die selten zugegriffen wird, die aber dennoch eine Inferenz mit geringer Latenz erfordern. Die Modelle sind immer für Inferenz mit geringer Latenz verfügbar und es gibt kein Kaltstartproblem. |
Durchsatz | MCEs sind auf bis zu 15 Container auf einem Multi-Container-Endpunkt beschränkt, und GPU-Inferenz wird aufgrund von Ressourcenkonflikten nicht unterstützt. Für Endpunkte mit mehreren Containern, die den direkten Aufrufmodus verwenden, stellt SageMaker nicht nur Metriken auf Instanzebene bereit, wie dies bei anderen gängigen Endpunkten der Fall ist, sondern unterstützt auch Metriken pro Container. Überprüfen Sie als Best Practice die CloudWatch-Metriken für Eingabeanforderungen und Ressourcennutzung und wählen Sie den geeigneten Instance-Typ aus, um einen optimalen Durchsatz zu erzielen. |
Skalierung der Konfigurationskomplexität | MCEs unterstützen die automatische Skalierung. Um jedoch die automatische Skalierung zu konfigurieren, wird empfohlen, dass das Modell in jedem Container eine ähnliche CPU-Auslastung und Latenz bei jeder Inferenzanforderung aufweist. Dies wird empfohlen, denn wenn sich der Datenverkehr zum Endpunkt mit mehreren Containern von einem Modell mit niedriger CPU-Auslastung zu einem Modell mit hoher CPU-Auslastung verschiebt, das Gesamtaufrufvolumen jedoch gleich bleibt, wird der Endpunkt nicht skaliert und es sind möglicherweise nicht genügend Instanzen vorhanden um alle Anforderungen an das Modell mit hoher CPU-Auslastung zu verarbeiten. |
Verkehrsmuster | MCEs sind ideal für Workloads mit kontinuierlichen oder regelmäßigen Datenverkehrsmustern, zum Hosten von Modellen über verschiedene Frameworks (wie TensorFlow, PyTorch oder Sklearn), die möglicherweise nicht über ausreichend Datenverkehr verfügen, um die volle Kapazität einer Endpunktinstanz auszuschöpfen. |
Hosten einer auf mehreren Modellen basierenden ML-Anwendung
Viele Geschäftsanwendungen müssen mehrere ML-Modelle verwenden, um ihren Verbrauchern eine einzige Vorhersageanfrage zu stellen. Zum Beispiel ein Einzelhandelsunternehmen, das seinen Benutzern Empfehlungen geben möchte. Die ML-Anwendung möchte in diesem Anwendungsfall möglicherweise verschiedene benutzerdefinierte Modelle verwenden, um verschiedene Produktkategorien zu empfehlen. Wenn das Unternehmen die Empfehlungen durch die Verwendung individueller Benutzerinformationen personalisieren möchte, steigt die Anzahl der benutzerdefinierten Modelle weiter an. Das Hosten jedes benutzerdefinierten Modells auf einer separaten Compute-Instanz ist nicht nur unerschwinglich, sondern führt auch zu einer Unterauslastung der Hosting-Ressourcen, wenn nicht alle Modelle häufig verwendet werden. SageMaker bietet effiziente Hosting-Optionen für Multi-Modell-basierte ML-Anwendungen.
Das folgende Diagramm zeigt Hosting-Optionen für mehrere Modelle für einen einzelnen Endpunkt mit SageMaker.
Serielle Inferenzpipeline
Eine Inferenzpipeline ist ein SageMaker-Modell, das aus einer linearen Folge von 2–15 Containern besteht, die Anfragen nach Inferenzen auf Daten verarbeiten. Sie verwenden eine Inferenzpipeline, um eine beliebige Kombination aus vortrainierten, in SageMaker integrierten Algorithmen und Ihren eigenen benutzerdefinierten Algorithmen, die in Docker-Containern verpackt sind, zu definieren und bereitzustellen. Sie können eine Inferenzpipeline verwenden, um Vorverarbeitungs-, Vorhersage- und Nachverarbeitungsaufgaben für Data Science zu kombinieren. Die Ausgabe eines Containers wird als Eingabe an den nächsten weitergegeben. Beim Definieren der Container für ein Pipelinemodell geben Sie auch die Reihenfolge an, in der die Container ausgeführt werden. Sie werden in SageMaker als einzelnes Pipeline-Modell dargestellt. Die Inferenzpipeline kann als MME bereitgestellt werden, wobei einer der Container in der Pipeline Anforderungen basierend auf dem aufgerufenen Modell dynamisch bedienen kann. Sie können auch eine ausführen Batch-Transformation Job mit einer Inferenzpipeline. Inferenzpipelines werden vollständig verwaltet.
Die folgende Tabelle enthält Anleitungen zur Bewertung der Fitnessfunktionen für das Hosten von ML-Modellen mithilfe einer seriellen Inferenzpipeline.
Fitnessfunktion | Beschreibung |
Kosten | Die serielle Inferenzpipeline ermöglicht es Ihnen, bis zu 15 verschiedene ML-Container auf einem einzigen Endpunkt auszuführen, was zu einer Kosteneffizienz beim Hosten der Inferenzcontainer führt. Für die Nutzung dieser Funktion fallen keine zusätzlichen Kosten an. Sie zahlen nur für die Instanzen, die auf einem Endpunkt ausgeführt werden. Die Kosten können sich je nach Anzahl und Art der Instanzen summieren. |
Inferenzlatenz | Wenn eine ML-Anwendung als Inferenzpipeline bereitgestellt wird, verlassen die Daten zwischen verschiedenen Modellen den Containerraum nicht. Feature-Verarbeitung und Inferenzen werden mit geringer Latenz ausgeführt, da sich die Container auf denselben EC2-Instances befinden. |
Durchsatz | Innerhalb eines Inferenzpipelinemodells verarbeitet SageMaker Aufrufe als eine Folge von HTTP-Anforderungen. Der erste Container in der Pipeline bearbeitet die anfängliche Anfrage, dann wird die Zwischenantwort als Anfrage an den zweiten Container gesendet und so weiter für jeden Container in der Pipeline. SageMaker gibt die endgültige Antwort an den Client zurück. Der Durchsatz hängt von Faktoren wie Modell, Modelleingabegröße, Stapelgröße und Endpunktinstanztyp ab. Überprüfen Sie als Best Practice die CloudWatch-Metriken für Eingabeanforderungen und Ressourcennutzung und wählen Sie den geeigneten Instance-Typ aus, um einen optimalen Durchsatz zu erzielen. |
Skalierung der Konfigurationskomplexität | Serielle Inferenzpipelines unterstützen die automatische Skalierung. Um jedoch die automatische Skalierung zu konfigurieren, wird empfohlen, dass das Modell in jedem Container eine ähnliche CPU-Auslastung und Latenz bei jeder Inferenzanforderung aufweist. Dies wird empfohlen, denn wenn sich der Datenverkehr zum Endpunkt mit mehreren Containern von einem Modell mit niedriger CPU-Auslastung zu einem Modell mit hoher CPU-Auslastung verschiebt, das Gesamtaufrufvolumen jedoch gleich bleibt, wird der Endpunkt nicht skaliert und es sind möglicherweise nicht genügend Instanzen vorhanden alle Anforderungen an das Modell mit hoher CPU-Auslastung verarbeiten. |
Verkehrsmuster |
Serielle Inferenzpipelines sind ideal für vorhersagbare Verkehrsmuster mit Modellen, die sequenziell auf demselben Endpunkt ausgeführt werden. |
Bereitstellen von Modellensembles (Triton DAG):
SageMaker bietet eine Integration mit NVIDIA Triton-Inferenzserver bis Triton Inference Server-Container. Diese Container umfassen NVIDIA Triton Inference Server, Unterstützung für gängige ML-Frameworks und nützliche Umgebungsvariablen, mit denen Sie die Leistung von SageMaker optimieren können. Mit NVIDIA Triton-Container-Images können Sie ganz einfach ML-Modelle bereitstellen und von den Leistungsoptimierungen, dem dynamischen Batching und der Multi-Framework-Unterstützung von NVIDIA Triton profitieren. Triton trägt dazu bei, die Auslastung von GPU und CPU zu maximieren, wodurch die Inferenzkosten weiter gesenkt werden.
Wenn in geschäftlichen Anwendungsfällen, in denen ML-Anwendungen mehrere Modelle verwenden, um eine Vorhersageanforderung zu bedienen, jedes Modell ein anderes Framework verwendet oder auf einer separaten Instanz gehostet wird, kann dies zu einer erhöhten Arbeitsbelastung und Kosten sowie einer Erhöhung der Gesamtlatenz führen. SageMaker NVIDIA Triton Inference Server unterstützt die Bereitstellung von Modellen aus allen wichtigen Frameworks, wie TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT und Python/C++-Modellformaten und mehr. Das Triton-Modellensemble stellt eine Pipeline aus einem oder mehreren Modellen oder Vorverarbeitungs- und Nachverarbeitungslogik sowie die Verbindung von Eingabe- und Ausgabetensoren zwischen ihnen dar. Eine einzelne Inferenzanforderung an ein Ensemble löst die Ausführung der gesamten Pipeline aus. Triton verfügt außerdem über mehrere integrierte Planungs- und Stapelalgorithmen, die einzelne Inferenzanforderungen kombinieren, um den Inferenzdurchsatz zu verbessern. Diese Scheduling- und Batching-Entscheidungen sind für den Client, der die Inferenz anfordert, transparent. Die Modelle können für maximale Flexibilität und zur Unterstützung heterogener Rechenanforderungen auf CPUs oder GPUs ausgeführt werden.
Das Hosten mehrerer GPU-unterstützter Modelle auf Endpunkten mit mehreren Modellen wird durch die unterstützt SageMaker Triton Inferenzserver. Der NVIDIA Triton Inference Server wurde um die Implementierung eines erweitert MME-API-Vertrag, zur Integration mit MMEs. Sie können den NVIDIA Triton Inference Server verwenden, der eine Modell-Repository-Konfiguration für verschiedene Framework-Backends erstellt, um eine MME mit automatischer Skalierung bereitzustellen. Mit dieser Funktion können Sie Hunderte von hyperpersonalisierten Modellen skalieren, die fein abgestimmt sind, um einzigartigen Endbenutzererfahrungen in KI-Anwendungen gerecht zu werden. Sie können diese Funktion auch verwenden, um die erforderliche Preisleistung für Ihre Inferenzanwendung mit fraktionierten GPUs zu erzielen. Weitere Informationen finden Sie unter Führen Sie mehrere Deep-Learning-Modelle auf der GPU mit Amazon SageMaker-Multimodell-Endpunkten aus.
Die folgende Tabelle enthält Anleitungen zur Bewertung der Fitnessfunktionen für das Hosten von ML-Modellen mithilfe von MMEs mit GPU-Unterstützung in Triton-Inferenzcontainern. Informationen zu Einzelmodell-Endpunkten und serverlosen Endpunkt-Eignungsfunktionsbewertungen finden Sie in den früheren Abschnitten in diesem Beitrag.
Fitnessfunktion | Beschreibung |
Kosten | SageMaker MMEs mit GPU-Unterstützung, die Triton Inference Server verwenden, bieten eine skalierbare und kostengünstige Möglichkeit, eine große Anzahl von Deep-Learning-Modellen hinter einem SageMaker-Endpunkt bereitzustellen. Bei MMEs teilen sich mehrere Modelle die GPU-Instanz hinter einem Endpunkt. Auf diese Weise können Sie die linear steigenden Kosten für das Hosten mehrerer Modelle durchbrechen und die Infrastruktur für alle Modelle wiederverwenden. Sie zahlen für die Betriebszeit der Instanz. |
Inferenzlatenz |
SageMaker mit Triton Inference Server wurde speziell entwickelt, um den Durchsatz und die Hardwareauslastung mit extrem niedriger (einstelliger 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. Mit MME-Unterstützung für GPU mit SageMaker Triton Inference Server können Sie Tausende von Deep-Learning-Modellen hinter einem SageMaker-Endpunkt bereitstellen. SageMaker lädt das Modell auf einer GPU-beschleunigten Instanz in den Speicher des NVIDIA Triton-Containers und bedient die Inferenzanforderung. Der GPU-Kern wird von allen Modellen in einer Instanz gemeinsam genutzt. Wenn das Modell bereits im Containerspeicher geladen ist, werden die nachfolgenden Anforderungen schneller bedient, da SageMaker es nicht erneut herunterladen und laden muss. |
Durchsatz |
MMEs bieten Funktionen zum gleichzeitigen Ausführen mehrerer Deep-Learning- oder ML-Modelle auf der GPU mit Triton Inference Server. Auf diese Weise können Sie das hochleistungsfähige Inferenz-Serving von NVIDIA Triton mit mehreren Frameworks problemlos mit der vollständig verwalteten Modellbereitstellung von SageMaker verwenden. Triton unterstützt alle NVIDIA GPU-, x86-, Arm®-CPU- und AWS Inferentia-basierten Inferenzen. Es bietet dynamisches Batching, gleichzeitige Läufe, optimale Modellkonfiguration, Modellensemble und Streaming von Audio- und Videoeingaben, um Durchsatz und Nutzung zu maximieren. Andere Faktoren wie Netzwerk- und Nutzlastgröße können eine minimale Rolle bei dem Overhead spielen, der mit der Inferenz verbunden ist. |
Skalierung der Konfigurationskomplexität |
MMEs können mithilfe einer automatischen Skalierungsrichtlinie horizontal skalieren und zusätzliche GPU-Recheninstanzen basierend auf Metriken wie z Mit dem Triton-Inferenzserver können Sie ganz einfach einen benutzerdefinierten Container erstellen, der Ihr Modell mit Triton enthält, und ihn zu SageMaker bringen. SageMaker Inference verarbeitet die Anfragen und skaliert den Container automatisch, wenn die Nutzung zunimmt, wodurch die Modellbereitstellung mit Triton auf AWS einfacher wird. |
Verkehrsmuster |
MMEs sind ideal für vorhersagbare Verkehrsmuster mit Modellen, die als DAGs auf demselben Endpunkt ausgeführt werden. SageMaker kümmert sich um das Traffic-Shaping zum MME-Endpunkt und behält optimale Modellkopien auf GPU-Instanzen bei, um die beste Preisleistung zu erzielen. Es leitet den Datenverkehr weiterhin zu der Instanz weiter, in der das Modell geladen wird. Wenn die Instanzressourcen aufgrund hoher Auslastung ihre Kapazitätsgrenze erreichen, entlädt SageMaker die am wenigsten verwendeten Modelle aus dem Container, um Ressourcen zum Laden häufiger verwendeter Modelle freizugeben. |
Best Practices
Berücksichtigen Sie die folgenden Best Practices:
- Hohe Kohäsion und geringe Kopplung zwischen Modellen – Hosten Sie die Modelle in demselben Container, der eine hohe Kohäsion aufweist (für die Funktionalität eines einzelnen Unternehmens), und kapseln Sie sie zusammen, um Upgrades und Verwaltbarkeit zu vereinfachen. Entkoppeln Sie diese Modelle gleichzeitig voneinander (hosten Sie sie in einem anderen Container), sodass Sie ein Modell problemlos aktualisieren können, ohne andere Modelle zu beeinträchtigen. Hosten Sie mehrere Modelle, die unterschiedliche Container hinter einem Endpunkt verwenden, und rufen Sie diese unabhängig voneinander auf, oder fügen Sie Modellvorverarbeitungs- und Nachverarbeitungslogik als serielle Inferenzpipeline hinzu.
- Inferenzlatenz – Gruppieren Sie die Modelle, die von einzelnen Geschäftsfunktionen gesteuert werden, und hosten Sie sie in einem einzigen Container, um die Anzahl der Hops und damit die Gesamtlatenz zu minimieren. Es gibt andere Vorbehalte, z. B. wenn die gruppierten Modelle mehrere Frameworks verwenden; Sie können sich auch dafür entscheiden, in mehreren Containern zu hosten, aber auf demselben Host auszuführen, um die Latenz zu reduzieren und die Kosten zu minimieren.
- ML-Modelle mit hoher Kohäsion logisch gruppieren – Die logische Gruppe kann aus Modellen bestehen, die homogen (z. B. alle XGBoost-Modelle) oder heterogen (z. B. einige XGBoost und einige BERT) sind. Es kann aus Modellen bestehen, die von mehreren Geschäftsfunktionalitäten gemeinsam genutzt werden, oder kann spezifisch für die Erfüllung nur einer Geschäftsfunktionalität sein.
- Geteilte Modelle – Wenn die logische Gruppe aus gemeinsam genutzten Modellen besteht, spielen die einfache Aktualisierung der Modelle und die Latenz eine wichtige Rolle bei der Architektur der SageMaker-Endpunkte. Wenn beispielsweise die Latenz Priorität hat, ist es besser, alle Modelle in einem einzelnen Container hinter einem einzelnen SageMaker-Endpunkt zu platzieren, um mehrere Hops zu vermeiden. Der Nachteil ist, dass, wenn eines der Modelle aktualisiert werden muss, dies dazu führt, dass alle relevanten SageMaker-Endpunkte aktualisiert werden, die dieses Modell hosten.
- Nicht geteilte Modelle – Wenn die logische Gruppe nur aus geschäftsfunktionsspezifischen Modellen besteht und nicht mit anderen Gruppen geteilt wird, werden die Verpackungskomplexität und die Latenzdimensionen zu Schlüsselfaktoren, die es zu erreichen gilt. Es ist ratsam, diese Modelle in einem einzelnen Container hinter einem einzelnen SageMaker-Endpunkt zu hosten.
- Effiziente Nutzung der Hardware (CPU, GPU) – Gruppieren Sie CPU-basierte Modelle und hosten Sie sie auf demselben Host, damit Sie die CPU effizient nutzen können. Gruppieren Sie auf ähnliche Weise GPU-basierte Modelle, damit Sie sie effizient verwenden und skalieren können. Es gibt hybride Workloads, die sowohl CPU als auch GPU auf demselben Host erfordern. Das Hosten der Nur-CPU- und Nur-GPU-Modelle auf demselben Host sollte durch hohe Kohäsions- und Anwendungslatenzanforderungen vorangetrieben werden. Darüber hinaus sind Kosten, Skalierbarkeit und Explosionsradius beim Aufprall im Falle eines Ausfalls die wichtigsten Dimensionen, die es zu untersuchen gilt.
- Fitnessfunktionen – Verwenden Sie Fitnessfunktionen als Richtlinie für die Auswahl einer ML-Hosting-Option.
Zusammenfassung
Wenn es um ML-Hosting geht, gibt es keinen einheitlichen Ansatz. ML-Praktiker müssen das richtige Designmuster auswählen, um ihre Herausforderungen beim ML-Hosting zu bewältigen. Die Bewertung der Fitnessfunktionen bietet eine Anleitung zur Auswahl der richtigen ML-Hosting-Option.
Weitere Einzelheiten zu den einzelnen Hosting-Optionen finden Sie in den folgenden Beiträgen dieser Reihe:
Über die Autoren
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.
Deepali Rajale ist AI/ML Specialist Technical Account Manager bei Amazon Web Services. Sie arbeitet mit Unternehmenskunden zusammen und bietet technische Anleitungen zur Implementierung von Lösungen für maschinelles Lernen mit Best Practices. In ihrer Freizeit geht sie gerne wandern, Filme schauen und mit Familie und Freunden rumhängen.
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.
- SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
- Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
- Quelle: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- Fähigkeit
- Fähig
- Über uns
- beschleunigt
- Zugang
- Zugriff
- zugänglich
- unterbringen
- Konto
- genau
- Erreichen
- Erreichen
- über
- Action
- aktiv
- Zusatz
- Zusätzliche
- zusätzlich
- Adresse
- vorantreiben
- advanced
- Vorteil
- Marketings
- beeinflussen
- Nach der
- Anhäufung
- Aggregator
- aggressiv
- Vereinbarungen
- AI
- AI / ML
- Alarm
- Algorithmen
- Alle
- Zulassen
- erlaubt
- bereits
- immer
- Amazon
- Amazon EC2
- Amazon Sage Maker
- Amazon Web Services
- Betrag
- Analyse
- analysieren
- und
- und Infrastruktur
- jährlich
- Ein anderer
- Apache
- Bienen
- Apple
- Anwendung
- Anwendungen
- Ansatz
- angemessen
- Apps
- Architektur
- ARM
- künstlich
- künstliche Intelligenz
- Aspekte
- Bewertung
- damit verbundenen
- Attribute
- Audio-
- Audits
- Auto
- Automatisiert
- automatische
- Im Prinzip so, wie Sie es von Google Maps kennen.
- Verfügbarkeit
- verfügbar
- durchschnittlich
- AWS
- Zurück
- unterstützt
- Bankinggg
- Base
- basierend
- weil
- werden
- wird
- Bevor
- hinter
- Sein
- Nutzen
- BESTE
- Best Practices
- Besser
- zwischen
- biomedizinische
- Blockieren
- Ausleihen
- Grenzen
- Box
- Verletzung
- Break
- bringen
- Brings
- Budgets
- bauen
- Building
- erbaut
- eingebaut
- Geschäft
- Geschäftsanwendungen
- Business Process
- Unternehmen
- Cache-Speicher
- berechnet
- rufen Sie uns an!
- namens
- Anrufer
- Kandidaten
- Fähigkeiten
- Kapazität
- österreichische Unternehmen
- Häuser
- Fälle
- Kategorien
- Ursachen
- sicher
- Zertifzierte
- Herausforderungen
- Übernehmen
- Änderungen
- Charakteristik
- berechnet
- Chatbot
- aus der Ferne überprüfen
- Chip
- Wahl
- Entscheidungen
- Auswählen
- Auswahl
- Klasse
- Einstufung
- klassifizieren
- Auftraggeber
- Kunden
- Menu
- Cloud
- Cluster
- Code
- geprägt
- Kopien
- sammeln
- Bekämpfung
- Kombination
- kombinieren
- kombiniert
- gemeinsam
- Unternehmen
- Unternehmen
- verglichen
- abschließen
- uneingeschränkt
- Komplex
- Komplexität
- Compliance
- Komponenten
- zusammengesetzt
- Kompromiss
- Rechenleistung
- Berechnen
- Computer
- Computer Vision
- Computing
- konzept
- Hautpflegeprobleme
- Wettbewerber
- Konfiguration
- Verbindung
- konsistent
- verbraucht
- KUNDEN
- Container
- Behälter
- enthält
- fortsetzen
- weiter
- kontinuierlich
- Smartgeräte App
- Kernbereich
- Dazugehörigen
- Kosten
- Einsparmaßnahmen
- kostengünstiger
- Kosten
- könnte
- erstellen
- schafft
- kritischem
- wichtig
- Strom
- Original
- Kunde
- Kunden
- TAG
- technische Daten
- Datenverarbeitung
- Datenwissenschaft
- Datenwissenschaftler
- Datenbase
- Datensätze
- Tag
- Behandlung
- Entscheidungen
- gewidmet
- tief
- tiefe Lernen
- Standard
- Definition
- Übergeben
- Demand
- Anforderungen
- Demokratisierung
- Abhängig
- hängt
- einsetzen
- Einsatz
- Bereitstellen
- Einsatz
- Implementierungen
- Design
- Designmuster
- entworfen
- Detail
- Details
- Entdeckung
- Bestimmen
- Entwickler:in / Unternehmen
- Entwicklung
- Diagramme
- anders
- schwer
- Größe
- Direkt
- deutlich
- verteilt
- Verteiltes rechnen
- verschieden
- Docker
- Unterlagen
- Tut nicht
- Domains
- Nicht
- nach unten
- herunterladen
- Nachteil
- angetrieben
- fallen gelassen
- Abwurf
- im
- dynamisch
- jeder
- Früher
- einfacher
- leicht
- Effektiv
- effektiv
- Wirksamkeit
- Wirkungsgrade
- effizient
- effizient
- Anstrengung
- entweder
- eliminieren
- ermöglichen
- ermöglicht
- Verschlüsselung
- End-to-End
- Endpunkt
- Entwicklung
- Ingenieure
- genug
- gewährleisten
- sorgt
- Unternehmen
- Unternehmen
- Ganz
- Arbeitsumfeld
- Fehler
- Fehler
- insbesondere
- Bewerten
- Auswertungen
- Sogar
- Event
- alles
- Evolution
- Beispiel
- Beispiele
- Austausch-
- Exponate
- erwarten
- erwartet
- ERFAHRUNGEN
- Erfahrungen
- ERKUNDEN
- Ausdrücke
- extern
- extra
- Gesicht
- Faktoren
- Scheitern
- ziemlich
- Familien
- Familie
- beschleunigt
- Merkmal
- Eigenschaften
- Fütterung
- wenige
- Finale
- Vorname
- erstes Mal
- Fitness
- FLOTTE
- Flexibilität
- Fluss
- schwanken
- konzentriert
- Folgende
- folgt
- Ford
- unten stehende Formular
- Formen
- fraktioniert
- Unser Ansatz
- Gerüste
- Betrug
- Betrugserkennung
- Frei
- Frequenz
- häufig
- Freunde
- für
- Obst
- voller
- voll
- Funktion
- Funktionsumfang
- Funktionalität
- Funktionen
- weiter
- DSGVO
- Allgemeines
- erzeugt
- Erzeugung
- bekommen
- ABSICHT
- gegeben
- Kundenziele
- Ziele
- gut
- GPU
- GPUs
- Graph
- groß
- mehr
- sehr
- Gruppe an
- Gruppen
- Wachsen Sie über sich hinaus
- Guide
- Griff
- Griffe
- praktisch
- Hardware
- mit
- Gesundheit
- Gesundheitswesen
- Hilfe
- Unternehmen
- hilft
- hier
- High
- Hohe Leistungsfähigkeit
- hochauflösenden
- höher
- Hit
- Horizontale
- Gastgeber
- gehostet
- Hosting
- Hostingkosten
- Hosting-Dienste
- Ultraschall
- aber
- HTML
- HTTPS
- hunderte
- Hybrid
- ideal
- Identitätsschutz
- Leerlauf
- Image
- Bildklassifizierung
- Bilder
- unveränderlich
- Impact der HXNUMXO Observatorien
- wirkt
- Einfluss hat
- implementieren
- umgesetzt
- Umsetzung
- wichtig
- zu unterstützen,
- Verbesserung
- in
- das
- Dazu gehören
- Einschließlich
- Eingehende
- Erhöhung
- hat
- Steigert
- zunehmend
- unabhängig
- unabhängig
- Krankengymnastik
- Information
- Infrastruktur
- Anfangs-
- innovativ
- innovative Technologien
- Varianten des Eingangssignals:
- Installieren
- Instanz
- beantragen müssen
- integrieren
- Integration
- Intelligenz
- interaktive
- beteiligen
- ISO
- Isolierung
- IT
- Job
- Jobs
- Wesentliche
- Tasten
- Wissen
- bekannt
- grosse
- größer
- Latency
- starten
- startet
- Start
- führen
- führenden
- umwandeln
- LERNEN
- lernen
- Verlassen
- geführt
- Niveau
- Bibliotheken
- Facelift
- Limitiert
- Grenzen
- Liste
- leben
- Belastung
- Laden
- Belastungen
- Standorte
- Lang
- länger
- aussehen
- verlieren
- Los
- Sneaker
- Maschine
- Maschinelles Lernen
- gemacht
- Main
- halten
- unterhält
- Dur
- um
- MACHT
- Making
- verwalten
- verwaltet
- Management
- Manager
- Managed
- flächendeckende Gesundheitsprogramme
- viele
- Marketing
- mathematisch
- Materie
- Maximieren
- maximal
- Mittel
- Triff
- Memory
- Methode
- Methoden
- Metrisch
- Metrik
- könnte
- minimal
- Minimum
- Minuten
- Vermischung
- ML
- Model
- Modell
- für
- Überwachen
- Überwachung
- Monat
- Monat
- mehr
- vor allem warme
- motiviert
- Filme
- Multi-Modell-Endpunkt
- mehrere
- Vielzahl
- Natur
- notwendig,
- Need
- Bedürfnisse
- Netzwerk
- Neu
- weiter
- Nlp
- Benachrichtigung
- Benachrichtigungen
- Anzahl
- Nvidia
- Objekt
- Ziel
- beschaffen
- gelegentlich
- bieten
- Angebote
- Offline-Bereich.
- EINEM
- Online
- Open-Source-
- betreiben
- arbeitet
- die
- Betriebs-
- Einkauf & Prozesse
- Betreiber
- optimal
- Optimierung
- Optimieren
- optimiert
- Verbessert
- Optimierung
- Option
- Optionen
- Orange
- Auftrag
- Organisationen
- Andere
- hervorragend
- Gesamt-
- besitzen
- Eigentum
- Paket
- Verpackung
- Parameter
- Teil
- besondere
- Partner
- Bestanden
- leidenschaftlich
- Patches
- Schnittmuster
- Muster
- AUFMERKSAMKEIT
- Haupt
- Ausführen
- Leistung
- Durchführung
- Zeit
- periodisch
- Zeiträume
- Personalisierung
- Personalisiert
- wählen
- Pipeline
- Ort
- Länder/Regionen
- geplant
- Pläne
- Plattform
- Plattformen
- Plato
- Datenintelligenz von Plato
- PlatoData
- Play
- erfahren
- Politik durchzulesen
- Datenschutzrichtlinien
- Beliebt
- möglich
- Post
- BLOG-POSTS
- Werkzeuge
- Praxis
- Praktiken
- Vorhersagbar
- Vorhersage
- Prognose
- Prognosen
- bevorzugt
- vorher
- Preis
- Principal
- Prioritätsliste
- privat
- Aufgabenstellung:
- Probleme
- Prozessdefinierung
- Verarbeitet
- anpassen
- Verarbeitung
- Prozessoren
- Produkt
- Produkt-Manager
- Produktion
- Produkte
- Profil
- ordnungsgemäße
- die
- vorausgesetzt
- bietet
- Bereitstellung
- Bereitstellung
- Stellvertreter
- Zweck
- Push
- Pytorch
- schnell
- Angebot
- Bereich
- schnell
- Bewerten
- Honorar
- erreichen
- Erreicht
- Lesen Sie mehr
- bereit
- echt
- realen Welt
- Echtzeit
- erhalten
- Received
- erhält
- empfehlen
- Software Empfehlungen
- Empfehlungen
- empfohlen
- empfehlen
- empfiehlt
- wiederkehrend
- Veteran
- reduziert
- bezieht sich
- Ungeachtet
- regulär
- bezogene
- Mitteilungen
- relevant
- bleibt bestehen
- Quelle
- vertreten
- representiert
- Anforderung
- Zugriffe
- erfordern
- falls angefordert
- Anforderung
- Voraussetzungen:
- erfordert
- Ressourcen
- Downloads
- Antwort
- REST
- Folge
- was zu
- Die Ergebnisse
- Einzelhandel
- Rückgabe
- Überprüfen
- Risiko
- Rollen
- Wurzel
- Straße
- Regel
- Führen Sie
- Laufen
- SaaS
- sagemaker
- SageMaker-Inferenz
- Gehalt
- gleich
- Speichern
- Einsparung
- Ersparnisse
- skalierbaren
- Skalieren
- Waage
- Skalierung
- Szenarien
- Zeitplan
- vorgesehen
- Wissenschaft
- Wissenschaftler
- Zweite
- Sekunden
- Abschnitt
- Abschnitte
- sicher
- Sicherheitdienst
- Auswahl
- Auswahl
- Senior
- empfindlich
- Reihenfolge
- seriell
- Modellreihe
- brauchen
- Serverlos
- Fertige Server
- dient
- Leistungen
- Dienst
- kompensieren
- Einstellung
- mehrere
- Gestaltung
- Teilen
- von Locals geführtes
- Schichten
- sollte
- Konzerte
- signifikant
- bedeutend
- ähnlich
- Ähnlich
- Einfacher
- Single
- Größe
- Größen
- klein
- kleinere
- So
- Software
- Lösung
- Lösungen
- einige
- Quellen
- Raumfahrt
- Spezialist
- spezialisiert
- spezifisch
- speziell
- angegeben
- Geschwindigkeit
- Ausgabe
- Spikes
- stabil
- Stapel
- Stacks
- Anfang
- begonnen
- beginnt
- Anfang
- Startups
- stetig
- Schritt
- Shritte
- Immer noch
- Stoppt
- Lagerung
- speichern
- Strategien
- Streaming
- Streng
- starker
- Folge
- Erfolg
- erfolgreich
- so
- ausreichend
- geeignet
- Support
- Unterstützte
- Unterstützt
- Schwall
- Tabelle
- Nehmen
- nimmt
- Target
- gezielt
- Aufgabe
- und Aufgaben
- Team
- Teams
- TechCrunch
- Technische
- Technologies
- Mieter
- Tensorfluss
- Test
- Testen
- Das
- ihr
- sich
- damit
- deswegen
- Tausende
- nach drei
- Schwelle
- Durch
- während
- Durchsatz
- Zeit
- mal
- zu
- gemeinsam
- auch
- Werkzeug
- Gesamt
- tps
- Tracking
- der Verkehr
- Training
- trainiert
- Ausbildung
- Transaktion
- Transaktionen
- Transformieren
- Transformation
- Transformieren
- Transit
- transparent
- auslösen
- Triton
- WENDE
- Typen
- typisch
- typisch
- für
- zugrunde liegen,
- verstehen
- einzigartiges
- Einheiten
- unberechenbar
- ungenutzt
- Aktualisierung
- Updates
- mehr Stunden
- Upgrade
- Betriebszeit
- Anwendungsbereich
- -
- Anwendungsfall
- Mitglied
- Nutzer
- gewöhnlich
- Nutzen
- seit
- BESTÄTIGEN
- Wert
- Werte
- Variante
- verschiedene
- Video
- Videos
- Anzeigen
- Assistent
- Seh-
- Volumen
- Abstimmung
- Stimmen
- Abfall / Verschnitt
- Netz
- Web-Services
- Woche
- Was
- Was ist
- welche
- während
- breit
- Große Auswahl
- werden wir
- .
- ohne
- Arbeiten
- gearbeitet
- Arbeiter
- Arbeiter
- arbeiten,
- Werk
- weltweit wie ausgehandelt und gekauft ausgeführt wird.
- würde
- XGBoost
- Jahr
- Du
- Ihr
- Zephyrnet
- Null