Amazon SageMaker AI führt priorisierte Instanzlisten für Trainings- und Processing-Jobs ein

SageMaker führt priorisierte Instanzlisten für Trainings- und Processing-Jobs ein

Amazon SageMaker AI führt Instance preference lists für Trainings- und Processing-Jobs ein. Nutzer können bei der Job-Erstellung eine geordnete Liste von bis zu fünf akzeptablen Instanztypen angeben. SageMaker wertet diese Liste in Prioritätsreihenfolge aus und startet den Job auf dem ersten Instanztyp, für den ausreichend Kapazität verfügbar ist. Bisher musste für einen Trainingsjob ein einzelner Instanztyp festgelegt werden; war dieser ausgelastet, blieb nur manuelles Ausprobieren anderer Typen. Die neue Funktion automatisiert diesen Fallback und soll so die Job-Einreichung vereinfachen. Sie richtet sich an Teams, die Modelle trainieren oder Daten verarbeiten und dabei auf bestimmte GPU- oder CPU-Typen angewiesen sind. Statt bei Kapazitätsengpässen manuell andere Instanztypen zu testen, genügt eine einmalige Liste. Die Reihenfolge der Liste bestimmt die Priorität: Der erste Eintrag hat die höchste Priorität. Die Angabe erfolgt über das Feld InstancePreferences in der SageMaker-API.

Funktionsweise und technische Einschränkungen

Das Feld InstancePreferences ist gegenseitig exklusiv mit den Feldern InstanceType, InstanceGroups, InstancePlacementConfig und EnableManagedSpotTraining. Diese Exklusivität ist technisch notwendig, weil InstancePreferences eine alternative Auswahlmethode darstellt: Es ersetzt die Angabe eines einzelnen Instanztyps (InstanceType) oder einer heterogenen Cluster-Konfiguration (InstanceGroups) durch eine priorisierte Liste. Eine gleichzeitige Angabe würde zu widersprüchlichen Anweisungen führen, welcher Instanztyp für den Job verwendet werden soll. InstancePlacementConfig betrifft die Platzierung innerhalb von UltraServers und ist mit der flexiblen Auswahl über mehrere Typen nicht kombinierbar. EnableManagedSpotTraining wiederum aktiviert verwaltete Spot-Kapazität, die ein anderes Preismodell mit Unterbrechungsrisiko darstellt. InstancePreferences unterstützt daher ausschließlich Flexible Training Plans (FTP) und On-Demand-Kapazität, da die automatische Fallback-Logik für garantierte, nicht unterbrechbare Kapazität konzipiert ist. Innerhalb einer InstancePreferences-Liste darf jeder Instanztyp nur einmal vorkommen. Diese Einschränkung verhindert Mehrdeutigkeit in der Prioritätsreihenfolge: Würde ein Typ mehrfach gelistet, wäre unklar, welche Position bei der Kapazitätsprüfung maßgeblich ist. Die unterstützten Instanztypen umfassen zahlreiche GPU- und CPU-Typen, darunter ml.g4dn, ml.g5, ml.g6, ml.p3, ml.p4, ml.p5, ml.trn1 und ml.trn2 sowie weitere. Die gültigen Werte reichen von kleineren CPU-Instanzen wie ml.m5.large bis zu großen GPU-Instanzen wie ml.p5.48xlarge oder ml.trn2.48xlarge. Die Liste ist auf maximal fünf Einträge begrenzt, um die Auswahl überschaubar zu halten und die Evaluierungszeit bei der Job-Erstellung zu begrenzen.

AWS verspricht weniger Wartezeit und manuelle Arbeit

Nach Angaben von AWS reduziere das Feature Wartezeiten und ermögliche es Teams, sich wieder auf die Modellentwicklung zu konzentrieren. Es mache es schneller, GPU-Ressourcen zu sichern und mit dem Training zu beginnen. Zudem entferne es manuelle Retry-Schleifen, komplexe Monitoring-Skripte und zusätzlichen Zeitaufwand für Systeme zur Job-Einreichung. AWS begründet dies damit, dass die automatische Fallback-Logik die Notwendigkeit manueller Eingriffe bei Kapazitätsengpässen beseitige. Diese Aussagen sind Herstellerangaben und nicht unabhängig verifiziert. Ob sich die versprochenen Zeitersparnisse in der Praxis bestätigen, ist offen. Unabhängige Benchmarks oder Nutzerberichte liegen bislang nicht vor.