Amazon MLA-C01: Kostenoptimierung für ML-Workloads — Lernleitfaden

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

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.

Grundkonzept: Wo Kosten entstehen und welche Hebel Sie haben

Die Kosten für Machine-Learning-Workloads lassen sich auf drei grundlegende Bereiche zurückführen: Rechenleistung für Training und Inferenz, Speicher und Datenübertragung für Datensätze und Checkpoints sowie Betriebsaufwand durch nicht ausgelastete oder schlecht provisionierte Infrastruktur. Das Training ist oft der größte Einzelposten, wenn Sie große Modelle trainieren oder viele Experimente durchführen. Die Inferenzkosten dominieren, wenn Sie Modelle in großem Maßstab bereitstellen oder niedrige Latenzzeiten für interaktive Anwendungen benötigen. Die zentralen Optimierungshebel sind die Wahl der Instanzfamilie und -größe, die Kaufoptionen (On-Demand vs. Spot vs. Savings Plans), die Modell-Lebenszyklusmuster (Batch vs. Echtzeit vs. Serverless) und Laufzeitoptimierungen wie Modellkompilierung, Caching und Instanzkonsolidierung.

Operative Techniken setzen diese Hebel in die Praxis um. Nutzen Sie Managed Spot Training mit Checkpointing, um die Kosten für das Trainings-Computing im Vergleich zu On-Demand um bis zu 70 % zu senken. Kombinieren Sie dies jedoch mit Checkpointing (Parameter CheckpointConfig → S3Uri bei CreateTrainingJob) und setzen Sie das Flag EnableManagedSpotTraining bei CreateTrainingJob auf true, damit Jobs nach Unterbrechungen wieder aufgenommen werden können. Passen Sie die Instanzgrößen an (Right-Sizing), indem Sie die tatsächliche CPU/GPU/IO-Nutzung profilieren (CloudWatch-Metriken wie GPUUtilization, HostCPUUtilization und Profiler-Traces von SageMaker Debugger), und wechseln Sie dann zu Compute-Familien, die den Workload-Eigenschaften entsprechen (ml.c5/ml.c6 für CPU, ml.g5/ml.p4 für GPU, ml.r5 für speicherintensive Workloads). Bevorzugen Sie für die Inferenz kostenproportionale Modelle: Verwenden Sie Serverless Inference (CreateEndpointConfig Produktionsvariante mit ServerlessConfig → MemorySizeInMB und MaxConcurrency) für Workloads mit Lastspitzen und geringem Durchsatz; nutzen Sie Multi-Modell-Endpunkte oder Modellkompilierung (SageMaker Neo), um den Instanzbedarf für viele kleine Modelle zu reduzieren; und verschieben Sie große oder latenzunempfindliche Workloads zu asynchronen oder Batch-Transformationen (AsyncInferenceConfig und Batch Transform).

Wichtige Services und Konfiguration

Amazon SageMaker bietet explizite Stellschrauben zur Kostenkontrolle. Für niedrigere Trainingskosten verwenden Sie Managed Spot Training: Setzen Sie in der CreateTrainingJob-API EnableManagedSpotTraining=true, fügen Sie CheckpointConfig.S3Uri hinzu und setzen Sie MaxWaitTimeInSeconds > MaxRuntimeInSeconds, um die Akquise von Spot-Kapazität zu ermöglichen. Im SageMaker Python SDK können Sie estimator.use_spot_instances=True, estimator.max_wait und estimator.checkpoint_s3_uri auf den S3-Speicherort für Checkpoints setzen. Für reproduzierbar niedrige Latenz bei aufeinanderfolgenden Trainingsjobs halten Sie Container warm, indem Sie SageMaker Processing oder Trainings-Container auf persistent provisionierter Infrastruktur nutzen, wenn die Experimentierkadenz dies erfordert. Andernfalls reduzieren Sie die Startzeit von Containern durch die Verwendung kleinerer Container-Images, vorgefertigter SageMaker-Container oder die Wiederverwendung einer persistenten Trainingsinstanz in einer Entwicklungsumgebung.

Zur Kostenkontrolle bei der Inferenz unterstützt CreateEndpointConfig/UpdateEndpointConfig mehrere Strategien. Verwenden Sie ServerlessConfig in ProductionVariants, damit SageMaker die Skalierung verwaltet und pro Aufruf und Arbeitsspeicher anstatt nach vollen Instanzstunden abrechnet; ServerlessConfig erfordert die Werte MemorySizeInMB und MaxConcurrency. Für gleichmäßige Workloads mit hohem Durchsatz verwenden Sie Provisioned Instances und wenden Sie Application Auto Scaling Target-Tracking-Richtlinien auf den Endpunkt an, um eine Überprovisionierung zu vermeiden. Multi-Modell-Endpunkte reduzieren die Kosten, wenn Sie viele selten genutzte Modelle hosten, indem sie sich einen einzigen Container teilen und Modell-Artefakte bei Bedarf aus S3 laden. Für Empfehlungen zur Modellgröße rufen Sie CreateInferenceRecommendationsJob im Inference Recommender auf, der eine Anleitung zu Instanztyp, Batch-Größe und Latenz/Durchsatz liefert.

Zahlungsverpflichtungen (Billing Commitments) werden am besten mit SageMaker Savings Plans oder AWS Compute Savings Plans gehandhabt. Erwerben Sie einen Savings Plan über die AWS Billing-Konsole, um sich für eine Laufzeit von 1 oder 3 Jahren auf einen Betrag von $/Stunde festzulegen; dies rabattiert On-Demand SageMaker Compute (Training und Hosting) über alle Instanzfamilien hinweg. Beachten Sie, dass Savings Plans für die On-Demand-Nutzung gelten und nicht für Spot, kombinieren Sie also die Strategien: Kaufen Sie Savings Plans für die grundlegende, stetige Auslastung und nutzen Sie Spot für Training mit Lastspitzen oder für experimentelles Training.

Designmuster und Kompromisse

Das Muster Managed Spot + Checkpointing ist die erste Wahl für lange oder große verteilte Trainingsläufe. Es erfordert nur minimale Code-Änderungen: Aktivieren Sie EnableManagedSpotTraining, geben Sie CheckpointConfig.S3Uri an und legen Sie eine angemessene MaxWaitTimeInSeconds fest, um die Spot-Planung zu tolerieren. Der Kompromiss besteht in einer höheren Komplexität bei Neustarts und einer etwas längeren Gesamtlaufzeit (Wall-Clock-Time), wenn Spot-Unterbrechungen häufig auftreten; der Vorteil ist eine drastische Kostenreduzierung. Für iteratives Experimentieren, bei dem die Startlatenz zwischen aufeinanderfolgenden Jobs wichtig ist, sollten Sie eine „warme“ Entwicklungsumgebung vorhalten: Verwenden Sie kleinere, bereitgestellte ml.m5- oder ml.c5-Instanzen mit vorgeladenen Daten im NVMe/lokalen Cache oder führen Sie viele Experimente als lokale Verarbeitungsjobs auf derselben Instanz mit SageMaker Processing oder Studio-Notebooks aus. Dies erhöht die Grundkosten, reduziert aber die Gesamtzykluszeit.

Wählen Sie für die Inferenz je nach Traffic-Muster zwischen serverlosen und bereitgestellten Endpunkten. Serverless Inference (ServerlessConfig) macht die Kapazitätsplanung überflüssig und ist die kostengünstigste Option für intermittierenden, unvorhersehbaren Traffic, da Sie pro Aufruf und Speicherzuweisung bezahlen. Der Kompromiss sind Kaltstartlatenz und Größenbeschränkungen; für strikte SLAs mit geringer Latenz sollten Sie bereitgestellte Instanzen mit Autoscaling bevorzugen und eine Modelloptimierung mit SageMaker Neo in Betracht ziehen, um die Anzahl der Instanzen zu reduzieren. Wenn viele Modelle gehostet werden müssen, der Traffic pro Modell aber gering ist, konsolidieren Multi-Model-Endpunkte die Festplatten- und Speichernutzung und senken die Kosten pro Modell auf Kosten eines etwas längeren Kaltstarts für ein nicht geladenes Modell.

Right-Sizing sollte auf Beobachtung basieren, nicht auf Schätzungen. Verwenden Sie das Profiling von SageMaker Debugger und CloudWatch, um GPUUtilization und DiskReadOps zu sammeln; führen Sie dann einen Inference Recommender-Job (CreateInferenceRecommendationsJob) aus, um die Instanzklasse/-typ und die Leistung zu validieren. Wenn die Latenzanforderungen des Modells eng sind, ziehen Sie eine Modellquantisierung oder die Kompilierung mit SageMaker Neo oder die Verwendung von Elastic Inference-Beschleunigern in Betracht, um CPU-Instanzen eine fraktionierte GPU-Inferenz hinzuzufügen. Mit Elastic Inference können Sie einen kleinen Beschleuniger an eine CPU-Instanz anhängen, was im Vergleich zu vollständigen GPU-Instanzen bei bestimmten Modellen die Kosten senkt.

Häufige Fallstricke und Entscheidungskriterien

Ein häufiger Fehler ist die Anwendung einer einzigen Kostenoptimierungsstrategie auf alle Workloads. Savings Plans sind leistungsstark für eine konstante Grundauslastung, sollten aber mit Spot für experimentelle Workloads und Serverless für Inferenz mit Lastspitzen kombiniert werden. Gehen Sie nicht davon aus, dass Spot kostenlos ist – es erfordert Checkpointing und eine fehlertolerante Trainingslogik; konfigurieren Sie

undefined

.CheckpointConfig und EnableManagedSpotTraining und berechnen Sie eine MaxWaitTimeInSeconds, die widerspiegelt, wie lange Sie einen verzögerten Start akzeptieren. Ein weiterer Fallstrick ist die Vernachlässigung der Telemetrie: Ohne Profiling (SageMaker Debugger, CloudWatch und Inference Recommender) riskieren Sie eine Überprovisionierung oder die Wahl einer Instanzfamilie mit nicht aufeinander abgestimmten CPU-, GPU- und Speichereigenschaften. Schließlich vereinfacht die Serverless-Inferenz die Kosten, kann aber unvorhersehbare Kaltstarts mit sich bringen; messen Sie die End-to-End-Latenz bei Verwendung von ServerlessConfig und greifen Sie bei strengen SLAs auf provisionierte Endpunkte mit Autoscaling zurück.

Praktisches Problem: Anwendungsszenario

Unternehmen: FinSight Analytics. Herausforderung: FinSight muss eine Pipeline zur Betrugserkennung aufbauen, die häufig auf in S3 gespeicherten Transaktionsprotokollen und Kundenprofilen trainiert wird, die Daten isoliert hält, eine Modellversions-Governance mit manueller Genehmigung vor der Produktionsbereitstellung unterstützt, die Trainingskosten für das nächtliche Neutraining reduziert, die Startlatenz pro Job bei schnellen Experimenten minimiert und einen latenzarmen Echtzeit-Endpunkt bereitstellt, der kostensensitiv auf stark schwankenden Traffic reagiert.

1. Zentralisierte, sichere Daten- und Modellregistrierung. Speichern Sie Daten in einem gesicherten S3-Bucket mit Standardverschlüsselung und Bucket-Richtlinien, die den Zugriff auf die SageMaker-Ausführungsrolle beschränken. Registrieren Sie Modelle in der SageMaker Model Registry; verwenden Sie den SageMaker Pipelines RegisterModel-Schritt, um Modellpakete zu erstellen, bei denen ModelApprovalStatus standardmäßig auf “PendingManualApproval” gesetzt ist. Implementieren Sie den menschlichen Workflow für die manuelle Genehmigung, indem Sie eine SageMaker Pipeline erstellen, die ein Modellpaket und einen manuellen Genehmigungsschritt ausgibt; wenn autorisierte Prüfer die Validierung abgeschlossen haben, rufen sie boto3 sagemaker.update_model_package(ModelPackageName=..., ModelApprovalStatus='Approved') auf, um die Bereitstellung zu ermöglichen. Begründung: Die Model Registry bietet eine zentralisierte Versionierung, und ModelApprovalStatus lässt sich für minimalen benutzerdefinierten Betriebsaufwand direkt in die SageMaker-APIs integrieren.

2. Kosteneffizientes nächtliches Neutraining. Verwenden Sie verwaltetes Spot-Training, indem Sie Trainingsjobs mit EnableManagedSpotTraining=true erstellen, CheckpointConfig.S3Uri einbeziehen, um den Zustand des Optimierers zu persistieren, und MaxRuntimeInSeconds sowie MaxWaitTimeInSeconds entsprechend festlegen, damit Jobs bei Spot-Unterbrechungen fortgesetzt werden können. Kombinieren Sie dies mit dem Kauf eines Savings Plans für die Grundlast, der so bemessen ist, dass er die durchschnittlichen On-Demand-Trainings-/Inferenzstunden abdeckt, um die konstanten Kosten zu senken, und nutzen Sie Spot für Experimente, bei denen Unterbrechungen tolerierbar sind. Begründung: Verwaltetes Spot reduziert die Rechenkosten mit minimalen Code-Änderungen; Savings Plans gelten für die On-Demand-Grundlast, um vorhersehbare Ausgaben zu senken.

3. Reduzierung der Startlatenz für Experimente. Für interaktive Experimentierzyklen unterhalten Sie ein persistentes Entwicklungsumgebungs-Profil (eine ml.c5 oder ml.m5) in SageMaker Studio oder eine kleine dedizierte Notebook-Instanz mit vorgeladenen Datensätzen auf EBS/NVMe und verwenden diese Umgebung für viele schnelle Trainingsdurchläufe wieder. Für nächtliche Produktionsjobs verwenden Sie weiterhin verwaltetes Spot mit Checkpointing. Begründung: Eine persistente Umgebung vermeidet Kaltstarts von Containern und verbessert die Iterationsgeschwindigkeit, während die Kosteneinsparungen für intensive Durchläufe erhalten bleiben.

4. Latenzarme, kostensensitive Echtzeit-Inferenz. Stellen Sie das genehmigte Modell auf einem provisionierten Endpunkt für eine niedrige Basislatenz bereit und fügen Sie dem Endpunkt eine Application Auto Scaling-Richtlinie hinzu, um in Zeiten außerhalb der Spitzenlast herunterzuskalieren. Für unvorhersehbare Traffic-Spitzen platzieren Sie eine Serverless-Inferenzoption für Modelle mit geringem Volumen oder verwenden Sie asynchrone Inferenz (AsyncInferenceConfig mit S3 OutputConfig) für intensive Batch-Scoring-Aufgaben, die nicht in Echtzeit erfolgen müssen. Wenden Sie vor der Bereitstellung die SageMaker Neo-Kompilierung auf das Modell an, um den CPU/GPU-Footprint zu reduzieren. Begründung: Die Kombination aus provisioniert und Autoscaling bietet eine niedrige, konstante Latenz und Kostenkontrolle; Serverless- oder asynchrone Endpunkte bewältigen Workloads mit Lastspitzen oder im Batch-Modus kosteneffizienter, und Neo reduziert die Anforderungen an die Instanz.

Dieser Ansatz kombiniert EnableManagedSpotTraining mit CheckpointConfig zur Reduzierung der Trainingskosten, SageMaker Model Registry und UpdateModelPackage für manuelle Genehmigungen, eine persistente Entwicklungsumgebung für reduzierte Startlatenz und eine Mischung aus provisionierten, serverless und kompilierten Modellen zur Optimierung der Inferenzkosten.

← Generative KI und Foundation Models · Alle Domänen · Computer Vision →

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

Amazon durchsuchen →