Amazon MLA-C01: Modellbereitstellung und Inferenz — Lernleitfaden
Teil des AWS Machine Learning Engineer Associate MLA-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Echtzeit-, serverlose, asynchrone und Batch-Endpunkte – Kernkonzept
Echtzeit-Inferenz in Amazon SageMaker ist ein zustandsbehaftetes Servicemodell mit niedriger Latenz, bei dem Sie ein Model, eine EndpointConfig und einen Endpoint erstellen. Dieser weist bereitgestellte Rechenleistung (ml.*-Instanztypen) zu und bleibt verfügbar, um Anfragen über die InvokeEndpoint-API zu bedienen. CreateEndpointConfig akzeptiert ProductionVariants, und jede ProductionVariant definiert ModelName, InitialInstanceCount, InstanceType und InitialVariantWeight. Sie können den Traffic und die Kapazität mit UpdateEndpointWeightsAndCapacities oder UpdateEndpoint ändern. Für Anforderungen mit vorhersagbar niedriger Latenz sind bereitgestellte Echtzeit-Endpunkte die primäre Option und unterstützen Multi-Container-Inferenz-Pipelines, um Preprocessing-, Modell- und Postprocessing-Container zu verketten.
Serverless Inference eliminiert die Instanzverwaltung und wird auf Endpunktebene mit einer ServerlessConfig konfiguriert, die MemorySizeInMB und MaxConcurrency für jede ProductionVariant festlegt. SageMaker verwaltet die Bereitstellung von Containern und skaliert bei Inaktivität auf null, was es ideal für Workloads mit Lastspitzen und geringem Durchsatz macht. Asynchronous Inference ist für Anfragen optimiert, deren Ausführung lange dauert oder bei denen der Client keine synchrone Antwort benötigt. Ein asynchroner Endpunkt wird mit AsyncInferenceConfig in CreateEndpointConfig erstellt (OutputConfig mit S3OutputPath, optionaler ClientConfig und MaxConcurrentInvocationsPerInstance), und Clients rufen InvokeEndpointAsync auf, wobei sie eine S3-Eingabe-URI angeben. Die Ergebnisse werden an den konfigurierten S3-Ausgabeort geschrieben. Batch Transform ist ein separater Job-Typ (CreateTransformJob) für große Offline-Inferenz-Workloads. Die API erfordert TransformInput (S3DataSource mit S3Uri und S3DataType), TransformOutput (S3OutputPath, Accept, AssembleWith) und TransformResources (InstanceType, InstanceCount). Batch Transform eignet sich am besten, wenn der Durchsatz, aber nicht die Latenz entscheidend ist, und unterstützt eine hohe Parallelität über Datensätze hinweg.
Multi-Model-Endpunkte, Inferenz-Pipelines, Shadowing und A/B-Tests – Schlüsseldienste und Konfiguration
Wenn viele Modelle mit niedrigen QPS pro Modell gehostet werden, ermöglichen SageMaker Multi-Model Endpoints (MME) das Hosten von Dutzenden bis Tausenden von in S3 gespeicherten Modell-Artefakten in einem einzigen Container, die bei Bedarf geladen werden. Sie erstellen einen Modell-Server-Container, der das SageMaker Multi-Model-Server-Muster implementiert, oder verwenden ein unterstütztes Framework-Image, laden Modell-Tarballs nach S3 hoch und erstellen eine Model-Ressource, die auf den Container verweist. Zur Aufrufzeit übergeben Sie den Namen des Zielmodells über den InvokeEndpoint-API-Parameter TargetModel (oder den Header X-Amzn-SageMaker-Target-Model), sodass der Server dieses Modell aus S3 in den Speicher lädt. MMEs sparen Speicher und Betriebskosten für große Modellflotten, fügen aber eine Kaltstart-Latenz für Modelle hinzu, die sich noch nicht in der Laufzeitumgebung befinden.
Inferenz-Pipelines werden als Multi-Container-Modelle implementiert, bei denen die Model-Ressource die Container in der richtigen Reihenfolge auflistet. Der Endpunkt leitet Payloads durch den ersten Container (Preprocessing), dann den Modell-Container und schließlich den Postprocessing-Container. Definieren Sie jeden Container mit seiner eigenen ModelDataUrl und Umgebungsvariablen in CreateModel. Für Tests im Canary- oder Blue/Green-Stil verwenden Sie mehrere ProductionVariants in einer EndpointConfig und steuern die Traffic-Aufteilung mit InitialVariantWeight und später über UpdateEndpointWeightsAndCapacities. Ein Shadow-Deployment kann erreicht werden, indem entweder auf der Anwendungsebene eine Kopie jeder Anfrage an einen Shadow-Endpunkt gesendet wird (keine Traffic-Gewichtung auf dem Produktionsendpunkt) oder indem eine ProductionVariant mit geringer Gewichtung erstellt wird, sodass die Endpunkt-Infrastruktur einen Teil des gespiegelten Traffics empfängt. Die Duplizierung von Anfragen auf Anwendungsebene bietet Ihnen eine vollständige Isolation des Experiments und eine unabhängige Beobachtbarkeit.
Für bedarfsgesteuerte und kontinuierliche Überwachung konfigurieren Sie DataCaptureConfig beim Erstellen eines Endpunkts, um Anfrage- und Antwort-Payloads in S3 zu persistieren. Interessante Felder von DataCaptureConfig sind EnableCapture (true), InitialSamplingPercentage, DestinationS3Uri und CaptureOptions (REQUEST, RESPONSE). Die erfassten Daten bilden die Grundlage für die Post-Deployment-Prüfungen von SageMaker Model Monitor und SageMaker Clarify. Sie können mit CreateMonitoringSchedule von Model Monitor Baselines erstellen und Ad-hoc-Processing-Jobs ausführen, die den integrierten Container für die Modellüberwachung verwenden, um Constraints und Drift-Metriken zu berechnen.
Entwurfsmuster und Kompromisse
Wählen Sie provisionierte Echtzeit-Endpunkte, wenn Sie eine Latenz im ein- bis niedrigen zweistelligen Millisekundenbereich benötigen und sich die ständig verfügbare Kapazität leisten können. Wenn die Kosten pro Minute im Leerlauf die wichtigste Einschränkung sind und der Datenverkehr sporadisch ist, reduzieren serverlose Endpunkte den Betriebsaufwand: Konfigurieren Sie ServerlessConfig.MemorySizeInMB und ServerlessConfig.MaxConcurrency für jede Variante und lassen Sie SageMaker automatisch skalieren. Für Workloads mit langlaufenden Inferenzen oder Mustern mit hohem Datenaustausch (Payload) entkoppeln asynchrone Endpunkte die Lebensdauer des Clients von der Rechenleistung; sie erfordern S3 für Ein- und Ausgaben und sind am besten geeignet, wenn Clients den Abschluss per Polling abfragen oder S3-Benachrichtigungen darüber erhalten können.
Multi-Modell-Endpunkte reduzieren die Duplizierung von Arbeitsspeicher und die Komplexität der S3-Objektverwaltung, fügen aber eine Kaltstart-Latenz pro Modell hinzu und erfordern einen Modell-Server, der das On-Demand-Laden von S3 und eine ordnungsgemäße Lebenszyklusverwaltung (Eviction/LRU) beherrscht. Wenn die Latenz pro Modell kritisch ist, hosten Sie „heiße“ Modelle auf dedizierten ProductionVariants und lagern Sie Modelle mit geringem Datenverkehr auf einen MME aus. Inferenz-Pipelines zentralisieren die Vor- und Nachverarbeitungslogik näher am Modell, was den clientseitigen Code reduziert und eine konsistente Transformation zwischen Training und Inferenz sicherstellt. Sie erhöhen jedoch die Startkomplexität des Endpunkts und erfordern ein robustes Container-Contract-Design (Input/Output-Codecs und Content-Types).
A/B-Tests mit den Gewichtungen von ProductionVariant sind für die Aufteilung des Datenverkehrs (Traffic Splitting) und die Erfassung von Offline-Metriken unkompliziert. Wenn Sie jedoch den Datenverkehr spiegeln (Shadowing) möchten, ohne die Produktionsmetriken zu beeinflussen, bevorzugen Sie die Spiegelung auf Anwendungsebene. Für progressive Rollouts und die Automatisierung von Rollbacks integrieren Sie UpdateEndpointWeightsAndCapacities in einen CodePipeline- oder Step Functions-Workflow. Dieser sollte eine automatische Metrikauswertung mittels CloudWatch-Metriken, Model Monitor-Warnungen und eine manuelle Genehmigungsaktion umfassen, die die endgültige Freigabe steuert.
Häufige Fallstricke und Entscheidungskriterien
Ein häufiger operativer Fehler ist die Annahme, dass Model Monitor Probleme mit der Verfügbarkeit von Labels erkennen wird; Model Monitor kann zwar Abweichungen in der Feature-Verteilung und Verstöße gegen die Datenqualität aus erfassten Anfragen erkennen, aber um eine Verschlechterung von Label-basierten Metriken (F1, Recall) zu messen, müssen Sie Ground-Truth-Labels zurück nach S3 in einem Format liefern, das die Monitoring-Jobs verarbeiten können, und einen Monitoring-Job einplanen, der die Vorhersage mit der Wahrheit vergleicht. Ein weiterer Fallstrick ist die falsche Dimensionierung von ServerlessConfig.MemorySizeInMB; zu wenig bereitgestellter Speicher verursacht Drosselung oder Container-Abstürze, während eine Überprovisionierung die Kosten erhöht. Bei Multi-Model-Endpunkten führt die Vernachlässigung eines geeigneten S3-Objektlayouts und -Lebenszyklus (Präfixe, Modell-Manifeste) zu langsameren Kaltstarts und erschwert die Eviction-Richtlinien.
Beim Umgang mit Klassen-Imbalance bei der Betrugserkennung sollten Sie für minimalen operativen Aufwand die Algorithmus-native Gewichtung gegenüber aufwendigen Sampling-Pipelines bevorzugen; zum Beispiel unterstützt XGBoost (SageMaker XGBoost Container) den Hyperparameter ‘scale_pos_weight’, den Sie als negative_examples/positive_examples berechnen und über die Hyperparameters-Map im CreateTrainingJob-Aufruf übergeben. Für manuelle Freigabeprozesse (Deployment Gating) verwenden Sie die SageMaker Model Registry: Erstellen Sie eine ModelPackageGroup, rufen Sie CreateModelPackage auf, um ein Modellpaket zu registrieren, und setzen Sie den Status des Modellpakets auf PendingManualApproval; eine externe manuelle Genehmigungsaktion in CodePipeline oder eine manuelle Bestätigung über Step Functions + SNS kann dann UpdateModelPackage aufrufen, um den ApprovalStatus auf „Approved“ zu setzen, bevor CreateModel oder CreateEndpoint ausgeführt werden.
Praktisches Problem: Anwendungsfallszenario
FraudDetectCo entwickelt ein Online-Betrugserkennungssystem, das Transaktionsprotokolle in S3 und On-Premises-MySQL-Kundenprofiltabellen konsolidieren, ein XGBoost-Modell trainieren, es mit Latenz im Nahezu-Echtzeitbereich bereitstellen, eine manuelle Genehmigungsschleuse für Produktions-Releases durchsetzen und sowohl Datensatzanomalien als auch Modell-Drift bei Bedarf erkennen muss.
Datenaggregation und -vorverarbeitung: Verwenden Sie AWS Database Migration Service (DMS) oder den JDBC-Konnektor von AWS Glue, um die On-Premises-MySQL-Tabellen kontinuierlich nach S3 (Parquet) oder in einen Amazon RDS/Athena-fähigen Data Lake zu replizieren; katalogisieren Sie mit AWS Glue und registrieren Sie Features im Offline-Store des Amazon SageMaker Feature Store, um konsistente Trainings- und Online-Serving-Feature-Lookups zu ermöglichen. Dies zentralisiert die Feature-Lineage und erzwingt S3-Sicherheitsrichtlinien sowie Lake Formation Governance zur Isolierung.
Training und Umgang mit Klassen-Imbalance: Führen Sie SageMaker-Trainingsjobs mit dem integrierten SageMaker XGBoost Container aus. Berechnen Sie das Verhältnis der Trainings-Labels und setzen Sie den XGBoost-Hyperparameter „scale_pos_weight“ in der HyperParameters-Map von CreateTrainingJob, um die Klassen-Imbalance mit minimaler Vorverarbeitung zu behandeln. Verwenden Sie den Pipe-Modus für den Trainingskanal (DataSource mit S3DataSource und S3DataType auf S3Prefix gesetzt und „RecordWrapperType“:„None“ aktivieren, wenn der Pipe-Modus verwendet wird), um die Startzeit und die Daten-Download-Latenz über aufeinanderfolgende Jobs hinweg zu reduzieren.
Modellregistrierung und manuelle Genehmigung: Registrieren Sie trainierte Modelle in der SageMaker Model Registry durch den Aufruf von CreateModelPackage innerhalb einer ModelPackageGroup. Setzen Sie den anfänglichen ApprovalStatus auf PendingManualApproval, integrieren Sie eine AWS CodePipeline, die eine manuelle Genehmigungsaktion (AWS Manual Approval Action) enthält, und rufen Sie nach manueller Bestätigung UpdateModelPackage mit ApprovalStatus=„Approved“ auf, bevor Sie das ModelPackage über CreateModel und CreateEndpointConfig in die Produktion überführen.
Bereitstellung und Inferenztopologie: Stellen Sie das Modell auf einem provisionierten Echtzeit-Endpunkt für Scoring mit geringer Latenz bereit. Wenn später Hunderte von Modellen gehostet werden müssen, evaluieren Sie einen Multi-Model-Endpunkt und verwenden Sie den Parameter TargetModel von InvokeEndpoint, um auf bestimmte in S3 gespeicherte Modelle zu verweisen. Konfigurieren Sie DataCaptureConfig (EnableCapture=true, InitialSamplingPercentage=100, DestinationS3Uri=s3://
<bucket>/captures, CaptureOptions=[‘REQUEST’,‘RESPONSE’]), um Request/Response-Payloads für On-Demand-Analysen zu sammeln.Überwachung und Anomalieerkennung: Planen Sie SageMaker Model Monitor Baselines mit CreateMonitoringSchedule für Datenqualität und Feature-Drift. Für die Anomalieerkennung und Visualisierung auf Datensatzebene speisen Sie die erfassten S3-Daten in Amazon Lookout for Metrics zur automatischen Erkennung von Anomalien und in Amazon QuickSight für Dashboards ein. Führen Sie für die On-Demand-Bewertung von Bias und Drift SageMaker Clarify Processing-Jobs mit den erfassten Daten aus oder starten Sie einen ad-hoc Model Monitor Processing-Job (über CreateProcessingJob), der die gespeicherten Baseline-Constraints anwendet und den Vergleichsbericht erstellt.
Begründung: Dieser Ansatz zentralisiert Features für reproduzierbares Training und Serving mit geringer Latenz, verwendet scale_pos_weight von XGBoost für Klassen-Imbalance mit minimaler Pipeline-Komplexität, erzwingt eine manuelle Genehmigung in der mit CodePipeline integrierten Model Registry, reduziert die Startlatenz des Trainings durch die Verwendung des Pipe-Modus für das Streamen von Trainingsdaten und bietet sowohl eine automatisierte Anomalieerkennung (Lookout for Metrics) als auch On-Demand-Prüfungen auf Fairness/Drift (Clarify + Model Monitor) unter Verwendung der erfassten Inferenzdaten.
← Modellevaluierung und Auswahl · Alle Domänen · MLOps und Modell-Lebenszyklus-Management →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →