Amazon MLS-C01: Training, Verteiltes Training & Hyperparameter-Optimierung — 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.

Trainingsjobs, Container und Übergänge zum Cloud-Training mit minimalem Codeaufwand

Bei der Verlagerung von Trainings-Workloads in SageMaker ist das oberste Designziel, das Umschreiben von Modellcode zu vermeiden und gleichzeitig sicherzustellen, dass die Container-Laufzeitumgebung die erwarteten SageMaker-Umgebungsvariablen und Channel-Pfade bereitstellt. Verwenden Sie den SageMaker Script Mode mit dem Framework-spezifischen Estimator (PyTorch, TensorFlow, XGBoost), damit dasselbe Trainingsskript mit minimalen Änderungen lokal und in der Cloud ausgeführt werden kann: Lesen Sie Daten aus

undefined

, schreiben Sie das Modell in

undefined

und berücksichtigen Sie

undefined

/

undefined

/

undefined

. Für benutzerdefinierte Umgebungen erstellen Sie ein Docker-Image, das die offiziellen AWS Deep Learning Containers (oder das SageMaker Training Toolkit) erweitert, und pushen Sie es nach Amazon ECR. Stellen Sie sicher, dass der Entry Point des Containers den Trainingsvertrag von SageMaker einhält. Wählen Sie Instanztypen basierend auf dem Rechenprofil aus: CPU-gebundene Jobs auf ml.c5/m5-Familien, GPU-Training auf ml.p3-, ml.p4d-, g4dn- oder g5-Instanzen. Wählen Sie die Instanzgröße nach Arbeitsspeicher und dem Verhältnis von GPU zu CPU. Häufige Fallstricke sind hartcodierte lokale Dateipfade, die Annahme eines einzelnen Hosts (was bei verteilten Jobs zu Fehlern führt) und das Nicht-Deklarieren des Training-Input-Modus (Pipe vs. File), was die I/O-Leistung beeinträchtigt. Für Reproduzierbarkeit und Kostenvorhersehbarkeit aktivieren Sie Managed Spot Training erst, nachdem Sie robustes Checkpointing hinzugefügt und

undefined

undefined

gesetzt haben, um Unterbrechungen durch Spot-Instanzen zu ermöglichen.

Verteilte Trainingsmuster, Dateneingabemodi und Speicheroptionen

Verteiltes Deep Learning erfordert eine Abstimmung zwischen Modellparallelität, Datenparallelität und der I/O-Architektur. Für Multi-GPU-Single-Host- und Multi-Host-Training verwenden Sie die nativen Primitive der Frameworks –

undefined

oder TensorFlows

undefined

– oder nutzen Sie die

undefined

-Bibliotheken von SageMaker:

undefined

für die datenparallele Skalierung und

undefined

oder DeepSpeed für sehr große Transformer-Modelle. Verwenden Sie S3 als kanonischen Speicher für große Datensätze, aber vermeiden Sie viele kleine S3-GET-Anfragen: Konsolidieren Sie entweder Dateien in weniger Archive, verwenden Sie geshardete RecordIO/TFRecord-Dateien oder binden Sie ein POSIX-Dateisystem an. Wählen Sie den Pipe-Modus, um Trainingsdaten für große Datensätze direkt aus S3 zu streamen, um die lokale Festplattennutzung und die Startzeit zu reduzieren. Verwenden Sie den File-Modus, wenn das Training wahlfreien Zugriff (Random Access) erfordert oder wenn Sie den gesamten Datensatz auf einem EBS-Volume benötigen. Für hohen Durchsatz und POSIX-Semantik über mehrere Instanzen hinweg, mounten Sie Amazon FSx for Lustre oder Amazon EFS. FSx eignet sich besser für hochleistungsfähige parallele Lesezugriffe. Häufige Fehltritte sind das Versäumnis, Daten über Hosts hinweg zu sharden (was zu Duplikaten führt), die Überschätzung des S3-Durchsatzes pro Instanz und das Ignorieren von Skalierungsregeln für Batch-Größe und Lernrate bei zunehmender Parallelität.

Spot-Training, Checkpointing und Strategien zur Kostenoptimierung

Managed Spot Training kann die Kosten drastisch senken, wenn Ihr Trainingsdesign Unterbrechungen toleriert. Konfigurieren Sie Managed Spot über den SageMaker Estimator (

undefined

), und fügen Sie Checkpointing hinzu: Geben Sie eine persistente

undefined

und ein lokales

undefined

an und speichern Sie Checkpoints häufig genug, um den Zeitaufwand für die Wiederholung von Arbeit zu begrenzen. Setzen Sie

undefined

deutlich über

undefined

, damit der Job unterbrochene Instanzen innerhalb des Spot-Fensters erneut versuchen kann. Implementieren Sie für Frameworks atomare Checkpoint-Schreibvorgänge und eine robuste Logik zur Wiederaufnahme, die den neuesten S3-Checkpoint prüft, den Zustand von Optimizer und Scheduler wiederherstellt und dann das Training fortsetzt. Die Checkpoint-Frequenz sollte einen Ausgleich zwischen dem Schreib-Overhead und potenziell verschwendeter Rechenleistung schaffen. Bei langen Epochen oder sehr großen Modellen sollten Checkpoints mitten in der Epoche durch Snapshots der Gradientenakkumulation oder schrittbasierte Speicherungen erstellt werden. Zu den Kostenfallen gehören das Vergessen, Checkpoints in S3 zu persistieren (was bei einer Unterbrechung einen vollständigen Neustart verursacht), die Verwendung von ephemerem Instanzspeicher und das Setzen von

undefined

gleich

undefined

, was Wiederholungsversuche verhindert. Kombinieren Sie Spot-Training mit Mixed Precision (AMP) für zusätzliche Einsparungen bei der Rechenleistung und mit kleineren Checkpoint-Payloads (nur Gewichte + Optimizer speichern), um die S3-Schreibkosten und die Latenz bei der Wiederaufnahme zu reduzieren.

Hyperparameter-Optimierung, Tuning-Strategien und praktische Entscheidungskriterien

Effektive HPO kombiniert Suchstrategie, Ressourcenzuweisung und Early Stopping. Der HyperparameterTuner von SageMaker unterstützt die zufällige (Random) und Bayes’sche (Bayesian) Suche mit konfigurierbaren Bereichen für ContinuousParameter, IntegerParameter und CategoricalParameter. Beginnen Sie bei großen Suchräumen mit einer zufälligen Suche, um breit zu explorieren, und führen Sie dann eine Bayes’sche Optimierung durch, um vielversprechende Bereiche zu nutzen. Verwenden Sie Early-Stopping-Methoden wie Hyperband oder das in SageMaker integrierte Early Stopping, um Budget zu schonen, und nutzen Sie Warm-Start-Tuning, um Ergebnisse aus verwandten Experimenten wiederzuverwenden. Wählen Sie Zielmetriken sorgfältig aus (Validierungs-AUC bei unausgewogenen Aufgaben, F1 bei klassen-unausgewogener Betrugserkennung, benutzerdefinierte kostengewichtete Metriken für Szenarien mit Lagerfehlbeständen). Häufige Fallstricke sind übermäßig weite Bereiche, die zu vielen fehlgeschlagenen Jobs führen, die Verwendung von kategorischer Kodierung für im Wesentlichen kontinuierliche Hyperparameter und die Nicht-Skalierung von ressourcenbewusster HPO: kurze Sondierungs-Jobs auf kleineren Instanzen, um grobe Bereiche zu finden, gefolgt von längeren Läufen auf GPU-Instanzen voller Größe. Stimmen Sie beim verteilten Training sowohl algorithmische Hyperparameter (Lernrate, Batch-Größe) als auch Stellschrauben auf Systemebene (Schritte zur Gradientenakkumulation, Anzahl der Daten-Shards) ab. Instrumentieren Sie mit SageMaker Debugger und verwenden Sie CloudWatch-Metriken, um verrauschte Messungen zu erkennen. Bei hoher Varianz erhöhen Sie die Anzahl der Wiederholungen pro Konfiguration oder verwenden Sie eine medianbasierte Auswahl.

Praktisches Problem: Anwendungsfallszenario

Szenario: FinRetailer führt Tausende von 30-Tage-Bedarfsprognosen pro SKU in SageMaker durch. Das Unternehmen speichert jahrelange tägliche CSVs in S3 und benötigt eine hohe Genauigkeit für Artikel mit seltener Nachfrage („Tail-Demand“), während die Inferenzlatenz bei Batch-Scoring-Jobs akzeptabel bleiben muss.

Herausforderung: Prognose von Tausenden von Zeitreihen mit langen Historien und unausgewogener Wichtigkeit (Fehlbestände kosten mehr als Überbestände), bei gleichzeitiger Minimierung der Rechenkosten und Beibehaltung der Genauigkeit bei seltenen Ereignissen mit hoher Nachfrage.

Empfohlener Ansatz:

1. Verwenden Sie den integrierten SageMaker DeepAR-Algorithmus oder ein benutzerdefiniertes temporales PyTorch-Modell (Transformer-basiert), das in einem Script Mode Estimator verpackt ist. Speichern Sie die Trainingsdaten als geshardete RecordIO/TFRecord-Dateien und verwenden Sie den File-Modus mit FSx for Lustre für ein Multi-Instanz-Training mit hohem Durchsatz.
2. Beginnen Sie mit verteiltem Training auf kleineren Instanzen (smddp oder Horovod), um die Modellarchitektur und die Hyperparameter abzustimmen. Verwenden Sie dabei den HyperparameterTuner mit Bayes’scher Suche und Early Stopping. Definieren Sie als Ziel einen gewichteten Quantilsverlust, der eine Unterprognose stärker bestraft.
3. Aktivieren Sie verwaltetes Spot-Training mit checkpoint_s3_uri und häufigen, schrittbasierten Checkpoints. Setzen Sie max_wait > max_run, um Unterbrechungen zu tolerieren und mit dem neuesten S3-Checkpoint fortzufahren.
4. Führen Sie für die Produktionsinferenz das Batch-Scoring über Multi-Model-Endpunkte oder asynchrone Batch-Transform-Jobs auf rechenoptimierten Instanzen durch. Wenden Sie Nachverarbeitungs-Geschäftsregeln und einen kalibrierten Schwellenwert an, der die Kosten für Fehlbestände berücksichtigt.

Begründung: Die Verwendung von DeepAR/Transformer-Architekturen verarbeitet viele Zeitreihen effizient. Geshardete Binärformate und FSx reduzieren I/O-Engpässe beim verteilten Training. Die Bayes’sche HPO mit einer maßgeschneiderten Zielsetzung fokussiert die Suche auf betriebliche Kostenmetriken. Spot-Training mit Checkpointing reduziert die Kosten, ohne den Fortschritt zu beeinträchtigen.

← Zeitreihen · Alle Domänen · Deployment →

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

Amazon durchsuchen →