Amazon MLS-C01: Deployment, Inferenz & Serving (ML-Implementierung & Betrieb) — Lernleitfaden

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Teil des AWS Machine Learning Specialty MLS-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Deployment-Muster und Bereitstellungsoptionen

Die Wahl der Modellbereitstellung ist ein Kompromiss zwischen Latenz, Kosten, Durchsatz und betrieblicher Komplexität. Echtzeit-Endpunkte von SageMaker (provisioniert oder serverless) bieten Latenzen im Bereich von unter 100 ms bis zu wenigen Sekunden, die für interaktive APIs geeignet sind. Wählen Sie Instanzfamilien wie ml.c5/m5 für CPU-Modelle, ml.g4dn oder ml.p3 für GPU-Modelle oder ml.inf1 für kostengünstige Inferentia-Inferenz mit hohem Durchsatz. Asynchrone Inferenz und Batch Transform eignen sich für Anwendungsfälle mit großen Batches oder variabler Latenz: Batch Transform ist ideal für große Offline-Jobs (teilen Sie große S3-Objekte in Shards auf und verwenden Sie bei Bedarf ml.m5/c5- oder GPU-Instanzen), während SageMaker Asynchronous Inference größere Payloads mit Queuing für Near-Real-Time-Batch-Verarbeitung unterstützt. Multi-Model-Endpunkte hosten viele Modelle hinter einem einzigen Container und reduzieren den Speicher-Overhead, indem sie Modelle bei Bedarf laden. Sie eignen sich am besten, wenn die Modelle klein sind, moderate Kaltstartkosten haben und die Zugriffsmuster sporadisch sind. Wählen Sie SageMaker Serverless Inference für unvorhersehbare Workloads mit geringem Durchsatz, um die Instanzverwaltung zu vermeiden. Achten Sie auf Kaltstarts und begrenzte Laufzeiten. Wichtige Entscheidungskriterien sind Latenz-SLOs, Kosten pro Aufruf, Gleichzeitigkeitsmuster, Modellgröße und Kaltstart-Toleranz. Eine häufige Fehlerquelle ist die Verwendung von Echtzeit-Endpunkten für Batch-Workloads mit extrem hohem Volumen – dies ist teuer. Verwenden Sie stattdessen Batch Transform, Async Inference oder rufen Sie Endpunkte über Batching und gleichzeitige Worker auf.

Skalierung, Traffic Shaping und Kostenoptimierung

Autoscaling, Traffic Shifting und Kostenkontrolle müssen gemeinsam mit der Deployment-Topologie entworfen werden. Verwenden Sie Application Auto Scaling, um SageMaker-Endpunktvarianten mit Target-Tracking-Richtlinien zu skalieren, die auf Aufrufmetriken oder benutzerdefinierten CloudWatch-Metriken basieren. Definieren Sie sinnvolle Mindest-/Maximalkapazitäten und Cooldowns, um „Thrashing“ (Überlastung durch ständiges Skalieren) zu vermeiden. Für Blue/Green-Deployments und Canary-Rollouts verwenden Sie Multi-Variant-Endpunkte oder EndpointConfig-Updates mit prozentualer Traffic-Aufteilung und schrittweisen Erhöhungen. Integrieren Sie AWS CodeDeploy, um das Traffic Shifting zu automatisieren. Zu den Kostenoptimierungen gehören Model Pruning, Quantisierung (FP16 oder int8), das Kompilieren mit SageMaker Neo oder AWS Neuron für Inf1 und die Verlagerung von nicht latenzkritischen Workloads zu Batch Transform oder Serverless Inference. Spot-Instanzen reduzieren die Trainingskosten, sind aber nicht für Echtzeit-Endpunkte anwendbar. Wählen Sie stattdessen die richtige Größe der Instanztypen (CPU vs. GPU vs. Inferentia) und konsolidieren Sie Modelle gegebenenfalls mit Multi-Model-Endpunkten. Achten Sie auf Fehlerquellen wie Überprovisionierung bei der Verwendung von Target-Tracking ohne Kenntnis des Durchsatzes pro Instanz oder die Annahme, dass Multi-Model-Endpunkte Speicherlimits aufheben – das Laden von Modellen erfordert weiterhin Speicher und kann die Latenz erhöhen. Komprimieren Sie außerdem Modell-Artefakte (ONNX, TF SavedModel mit gz) und verwenden Sie Lazy-Loading-Strategien, um Speicherplatz und Kaltstartzeiten zu reduzieren.

Edge, Inferenz mit geringer Latenz und Platzierung der Vor-/Nachverarbeitung

Für Umgebungen mit extrem niedriger Latenz oder ohne Konnektivität deployen Sie Modelle auf AWS IoT Greengrass (v2) oder verwenden Sie SageMaker Edge Manager, um Modelle auf Edge-Geräten zu paketieren und zu überwachen. Kompilieren Sie mit SageMaker Neo oder AWS IoT Greengrass-Komponenten und verwenden Sie Quantisierung, um die Speicher-/CPU-Beschränkungen einzuhalten. Platzieren Sie die Vorverarbeitung und Merkmalsextraktion dort, wo sie die End-to-End-Latenz und die Kosten minimiert: Einfache Filter können in der Geräte-Firmware oder in Greengrass Lambda ausgeführt werden, während Batching und aufwändige Transformationen auf ein Edge-Gateway oder in die Cloud gehören. Für die Verarbeitung von Streaming-Ereignisfenstern (z. B. gleitende 10-Minuten-Fenster) nutzen Sie Amazon Kinesis Data Streams oder Amazon MSK für die Datenerfassung, Kinesis Data Analytics oder Flink/Apache Spark für Windowing und Aggregation und leiten Sie die zusammengefassten Merkmale an einen SageMaker-Endpunkt oder ein schlankes On-Edge-Modell weiter. Dies reduziert den Netzwerk-Egress und die Häufigkeit der Modellaufrufe. Hüten Sie sich vor Fehlerquellen wie dem Ignorieren der Modellversionierung auf Edge-Geräten oder der unzureichenden Bereitstellung von Gerätespeicher für Modell-Artefakte. Bei serverseitigen Microservices sollten Sie die Vorverarbeitung (API Gateway + Lambda oder ALB + Fargate) am selben Ort platzieren (Colocation), um den Overhead durch Kaltstarts zu vermeiden und die an das Modell gesendeten Payload-Größen zu reduzieren.

Überwachung, Auditing, Governance und Datenhandhabung

Der operative Betrieb von ML erfordert eine kontinuierliche Überwachung des Modellzustands und Data Governance. Verwenden Sie SageMaker Model Monitor, um eine Baseline für Trainingsdaten mit einem DataQualityJob zu erstellen und eine kontinuierliche Überwachung zu konfigurieren, um Datenabweichungen (Data Drift), Regressionen der Modellqualität, fehlende Werte und benutzerdefinierte Einschränkungen zu erkennen. Aktivieren Sie DataCaptureConfig auf Endpunkten, um Ein- und Ausgaben in S3 zu erfassen und Model Monitor-Jobs auszulösen. Für die Nachverfolgung und das Auditing auf Feature-Ebene (Lineage) verwenden Sie Amazon SageMaker Feature Store (Online- und Offline-Speicher) in Kombination mit AWS Glue Data Catalog und CloudTrail, um den Zugriff auf Datensätze und deren Transformationen zu verfolgen. Amazon Macie und Glue/SageMaker Processing-Jobs können PII vor dem Training erkennen und unkenntlich machen. Zu den Fallstricken bei der Verschlüsselung gehört SSE-KMS: Wenn S3-Objekte mit einem vom Kunden verwalteten CMK verschlüsselt sind, stellen Sie sicher, dass die SageMaker-Ausführungsrolle die Berechtigungen kms:Decrypt und kms:GenerateDataKey besitzt und die CMK-Richtlinie den Zugriff gewährt. Stellen Sie außerdem sicher, dass S3-Bucket-Richtlinien und VPC-Endpunkte den Zugriff nicht blockieren. Bei großen täglichen S3-Objekten (z. B. 100 GB) sollten Sie die Aufnahme als einzelne Datei vermeiden – partitionieren Sie sie stattdessen in viele kleinere Objekte, speichern Sie sie im Parquet-Format und komprimieren Sie sie, und verwenden Sie Athena/Glue für die Schemaerkennung. Häufige Fehler sind unzureichende Überwachungszeitpläne, das Versäumnis, eine korrekte Baseline für Model Monitor zu erstellen, und das Vergessen, allen Service-Prinzipalen (SageMaker, Glue, Lambda), die eine Entschlüsselung benötigen, KMS-Zugriff zu gewähren.

Praktisches Problem: Anwendungsfallszenario

Szenario: Streamlytic Media betreibt eine Podcast-Analyseplattform auf AWS. Sie verwenden Kinesis Data Streams, um Benutzerereignisse aufzunehmen, aggregierte Features in S3 zu speichern und Modelle in SageMaker für die Echtzeit-Vorhersage des Engagements zu hosten. Die Daten enthalten gelegentlich PII und sind mit einem kundenverwalteten SSE-KMS-Schlüssel verschlüsselt.

Herausforderung: Bereitstellung von Vorhersagen mit geringer Latenz für ein gleitendes 10-Minuten-Ereignisfenster, Unkenntlichmachen von PII vor dem Modelltraining, Sicherstellen, dass SageMaker verschlüsselte S3-Daten lesen kann, und Implementierung einer kontinuierlichen Überwachung auf Feature-Drift.

Empfohlener Ansatz:

1. Erstellen Sie einen Kinesis Data Stream zur Aufnahme von Ereignissen, führen Sie Kinesis Data Analytics (Flink) aus, um gleitende 10-Minuten-Fenster zu verwalten, und geben Sie aggregierte Features stündlich partitioniert im Parquet-Format in S3 aus.
2. Erkennen und machen Sie PII unkenntlich, indem Sie Amazon Macie zur Erkennung und einen SageMaker Processing-Job (oder AWS Glue-Job) zur Anwendung deterministischer Unkenntlichmachung/Tokenisierung verwenden; speichern Sie die Ergebnisse für das Training in einem Offline-Speicher des Feature Store.
3. Weisen Sie der SageMaker-Ausführungsrolle die Berechtigungen kms:Decrypt und kms:GenerateDataKey für den CMK zu, fügen Sie die Rolle zur Schlüsselrichtlinie des CMK hinzu und stellen Sie sicher, dass die S3-Bucket-Richtlinie oder der VPC-Endpunkt den Zugriff für SageMaker erlaubt.
4. Stellen Sie das Modell als SageMaker-Echtzeit-Endpunkt auf ml.inf1-Instanzen bereit, aktivieren Sie DataCaptureConfig, erstellen Sie eine Model Monitor-Baseline aus den Trainingsdaten und konfigurieren Sie eine kontinuierliche Überwachung mit Alarmen an CloudWatch.

Begründung: Die Streaming-Aggregation mit Kinesis + Flink minimiert das Ereignisvolumen und die Latenz; die Unkenntlichmachung zum Zeitpunkt der Verarbeitung wahrt den Datenschutz und die Compliance; explizite KMS-Berechtigungen verhindern Zugriffsfehler; Inferentia-gestützte Endpunkte und Model Monitor schaffen eine Balance zwischen niedrigen Inferenzkosten und betrieblicher Beobachtbarkeit.

← Training · Alle Domänen · Sicherheit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →