Amazon SageMaker-Instanzpräferenzlisten ersetzen manuelle GPU-Wiederholungsversuche, aber keine Kapazitätsplanung

Amazon hat Amazon SageMaker-Instanzpräferenzlisten eingeführt. Damit kann eine Trainingsanfrage bis zu fünf priorisierte Rechenoptionen enthalten, statt an einen festen Instanztyp gebunden zu sein. SageMaker AI prüft diese Optionen in der angegebenen Reihenfolge und startet die erste Konfiguration mit verfügbarer Kapazität.

Die Änderung zielt auf ein anhaltendes Betriebsproblem. GPU-gestützte SageMaker-Trainingsjobs können ausstehend bleiben, wenn die angeforderte Hardware nicht verfügbar ist. Teams reagierten bislang, indem sie Kapazitäten überwachten, Jobs erneut einreichten oder Skripte pflegten, die alternative Konfigurationen ausprobierten.

AWS verlagert diese Wiederholungsentscheidung nun in den verwalteten Scheduler. Die Funktion schafft jedoch keine GPU-Kapazität und beweist auch nicht, dass verschiedene Beschleuniger einen Workload korrekt ausführen. Ihr Nutzen hängt davon ab, ob Teams ihren Trainingscode, ihre Leistungsziele und ihre Kostenkontrollen tatsächlich hardwareflexibel gestalten können.

Diese Unterscheidung setzt eine bekannte Cloud-Praxis unter Druck: einen Instanztyp als unveränderliche Eigenschaft jedes Jobs zu behandeln. Google Cloud stellt bereits flexible Beschleunigeranfragen über seinen Dynamic Workload Scheduler in eine Warteschlange. Nutzer von Azure Machine Learning planen ebenfalls anhand regionaler, familiespezifischer Rechenquoten. AWS macht deklarierte Hardwareflexibilität nun zu einem zentralen Bestandteil einzelner SageMaker-Jobs.

Was AWS mit Amazon SageMaker-Instanzpräferenzlisten geändert hat

Eine SageMaker-Anfrage kann nun mehrere akzeptable Rechenkonfigurationen ausdrücken, ohne einen externen Wiederholungs-Controller zu benötigen.

AWS kündigte die Funktion am 15. September 2026 sowohl für Trainings- als auch für Verarbeitungsjobs an. Sie ist laut der Mitteilung zur regionalen Verfügbarkeit des Unternehmens über SageMaker-APIs, SDKs, Kommandozeilentools und die Konsole in jeder AWS-Region verfügbar, in der SageMaker AI angeboten wird.

Eine Präferenzliste umfasst zwei bis fünf Instanztypen in Prioritätsreihenfolge. SageMaker validiert die Liste, führt einen In-Memory-Durchlauf aus und wählt die erste Konfiguration mit verfügbarer Kapazität. Nur eine der aufgeführten Konfigurationen führt den Job aus.

Ist keine Option sofort verfügbar, wechselt der Job in eine ereignisgesteuerte Warteschlange. SageMaker versucht es erneut, wenn sich Kapazitäten ändern, statt dass ein Client-Prozess den Dienst abfragen und Anfragen erneut einreichen muss. Die gesamte Wartezeit lässt sich mit MaxPendingTimeInSeconds begrenzen.

Dieses Zeitlimit gilt für die gesamte Präferenzliste und nicht separat für jede Option. AWS erklärt außerdem, dass es nur greift, wenn mindestens eine aufgeführte Konfiguration beschleunigte Rechenleistung aus Familien wie ml.p, ml.g oder ml.trn nutzt.

Dieses Verhalten ist wichtig, weil eine Präferenz mehr ist als ein alternativer Instanzname. Teams können jeder Option eine andere Instanzanzahl zuweisen. Ein Job könnte zwei ml.g6.48xlarge-Knoten bevorzugen, aber vier ml.g5.48xlarge-Knoten akzeptieren, wenn diese zweite Konfiguration einen ausreichenden Gesamtdurchsatz bietet.

AWS erlaubt zwei Zählmodelle. Ein gemeinsames ResourceConfig.InstanceCount kann für jede Präferenz gelten, oder jede Präferenz kann ihre eigene Anzahl definieren. Diese Ansätze zu mischen ist ungültig, wie die API-Referenz erläutert.

Die Funktion ist zudem mit SageMaker Flexible Training Plans verknüpft, die unterstützte GPU-Kapazität für einen festgelegten Zeitraum reservieren. Ein Trainingsjob kann eine passende planbasierte Konfiguration an erster Stelle setzen und anschließend On-Demand-Alternativen aufführen. Falls die reservierte Option nicht bereitgestellt werden kann, durchläuft SageMaker die verbleibenden Präferenzen.

Diese Integration ist auf das Training beschränkt. Verarbeitungsjobs erhalten denselben priorisierten Fallback-Mechanismus, können Präferenzen jedoch nicht mit Flexible Training Plans verknüpfen.

Der Anwendungsfall für die Verarbeitung bleibt dennoch bedeutend. SageMaker Processing führt verwaltete Infrastruktur für Datenaufbereitung, Feature Engineering, Evaluierung und verwandte Arbeiten aus. Diese Jobs tolerieren oft eine größere Hardwarebandbreite als eng optimierte verteilte Trainingsjobs.

AWS stellt die Änderung in seinem Launch-Beitrag als Alternative zu manuellen Wiederholungsschleifen und Skripten zur Kapazitätsüberwachung dar. Das ist der deutlichste unmittelbare Vorteil. Eine Pipeline übermittelt einen Job, während SageMaker die Kapazitätssuche innerhalb der deklarierten Grenzen übernimmt.

Der Scheduler wählt keine beliebige Maschine aus, die er als gleichwertig betrachtet. Er folgt der Reihenfolge des Kunden. Das erhält eine nützliche Aufgabenteilung: Betreiber entscheiden, welche Konfigurationen gültig sind, und SageMaker entscheidet, welche gültige Option zuerst starten kann.

Dies ist eine kleine API-Änderung mit größerer betrieblicher Bedeutung. Infrastrukturflexibilität kann nun mit der Jobdefinition transportiert werden, statt in umgebendem Orchestrierungscode zu leben.

Warum SageMaker-GPU-Kapazität zu einem Scheduler-Problem wurde

Die knappe Ressource ist nicht mehr nur eine GPU, sondern die passende Cluster-Konfiguration in der richtigen Region zum richtigen Zeitpunkt.

KI-Trainingsteams sprechen häufig über Beschleuniger als austauschbare Einheiten, doch Cloud-Kapazität ist auf Instanzfamilien, Größen, Regionen, Verfügbarkeitspools, Quoten und Reservierungsmodelle verteilt. Ein Kunde kann berechtigt sein, eine Maschine anzufordern, ohne dass diese Maschine sofort zugewiesen werden kann.

Diese Fragmentierung führt zu umständlicher Fehlerbehandlung. Eine Pipeline kann technisch korrekt sein und dennoch Stunden verlieren, weil ihre ausgewählte Konfiguration nicht starten kann. Ein Ingenieur muss dann entscheiden, ob er warten, die Hardware ändern, die Knotenzahl anpassen oder den Workload verlagern soll.

Vor Präferenzlisten nannten SageMaker-Trainingsjobs bei der Übermittlung einen Instanztyp. Teams, die Alternativen akzeptierten, mussten diese Flexibilität an anderer Stelle kodieren. Einige bauten Wiederholungsfunktionen rund um API-Fehler. Andere übermittelten mehrere Varianten und brachen die übrigen ab, nachdem eine gestartet war.

Beide Muster verursachen Koordinationsaufwand. Mehrere aktive Anfragen können Beobachtbarkeit und Abbruch erschweren. Sequenzielle Wiederholungsskripte benötigen Zustandsverwaltung, Backoff-Regeln, Zeitlimitbehandlung, Berechtigungen und Schutz vor doppelter Ausführung.

Die Kapazitätsüberwachung wird außerdem zu einem weiteren Produktionssystem. Das Team muss sie bei Änderungen des SDK-Verhaltens pflegen, ihre Ausfälle sichtbar machen und sicherstellen, dass ein neu gestarteter Controller nicht denselben teuren Job zweimal startet.

Amazon SageMaker-Instanzpräferenzlisten übernehmen einen Teil dieser Steuerungsebene. Die Jobanfrage enthält eine begrenzte Menge akzeptabler Ergebnisse, und der verwaltete Dienst trifft die Auswahl, sobald Kapazität gefunden wird.

Dieses Modell spiegelt wider, wie viele reale Workloads funktionieren. Fine-Tuning, Evaluierung, Vorverarbeitung und Modellexperimente haben oft eine bevorzugte Konfiguration statt einer mathematisch zwingend erforderlichen Konfiguration. Ein Team könnte neuere GPUs wegen ihrer Geschwindigkeit bevorzugen, aber ältere GPUs akzeptieren, wenn die Startzeit wichtiger ist.

Dasselbe Prinzip gilt für die Knotenzahl. Zwei schnellere Knoten und vier langsamere Knoten können mitunter ein ähnliches Fertigstellungsziel erreichen. Sie sind nicht zwangsläufig gleichwertig, aber Entwickler können sie testen und beide als akzeptabel deklarieren.

AWS ist nicht allein damit, Knappheit in eine Scheduling-Schnittstelle zu überführen. Der Flex-start-Modus von Google Cloud stellt Beschleunigeranfragen in die Warteschlange, bis alle erforderlichen Ressourcen verfügbar sind. Google positioniert ihn für Trainingsjobs, die einen flexiblen Startzeitpunkt tolerieren können.

Die Mechanismen unterscheiden sich. Das Google-Modell betont die Bereitstellung einer angeforderten Beschleunigerzuweisung und Laufzeit. AWS ermöglicht es einem SageMaker-Job, eine priorisierte Reihe von Typen und Anzahlen zu durchlaufen. Beide Ansätze fordern Kunden dazu auf, Flexibilität auszudrücken, statt Kapazitäten wiederholt abzufragen.

Azure Machine Learning legt einen weiteren Teil der Einschränkung offen. Seine Rechenquoten werden nach Region und VM-Familie verwaltet, mit separaten Limits für die Nutzung von Workspace und Abonnement. Je nach Abonnement können GPU-Familien ohne standardmäßige dedizierte Core-Quote beginnen.

Diese Systeme zeigen, warum sich die Verfügbarkeit von Beschleunigern nicht auf eine Katalogseite reduzieren lässt. Eine aufgeführte Instanz kann unterstützt sein und dennoch für ein bestimmtes Konto, einen Standort, eine Jobgröße oder ein Zeitfenster nicht verfügbar sein.

Für AWS-Kunden entsteht der unmittelbare Druck bei Teams, die eigene Bereitstellungslogik pflegen. Wenn ein Wiederholungsdienst lediglich SageMaker-Instanztypen durchläuft, überschneidet sich seine zentrale Funktion nun mit der Plattform.

Die Funktion setzt außerdem starre interne Standards unter Druck, die für jedes Modell genau einen Instanztyp genehmigen. Diese Standards vereinfachten Benchmarking und Governance, machen aber jede Kapazitätsknappheit zu einem Blocker. Teams haben nun einen Grund, mehrere Konfigurationen für jeden Workload zu zertifizieren.

Dies beseitigt die Orchestrierung nicht. Pipelines benötigen weiterhin Abhängigkeiten, Artefaktverfolgung, Fehlerrichtlinien und Validierung nach dem Lauf. Die Änderung verkleinert den Aufgabenbereich der Orchestrierung, indem sie eine wiederkehrende Entscheidung – welche akzeptable Konfiguration starten kann – in SageMaker selbst verlagert.

Flexibilität ersetzt Wiederholungslogik, nicht Kapazitätsgrenzen

Der Mechanismus verbessert die Suche nach verfügbarer Infrastruktur, kann aber keine Infrastruktur bereitstellen, die nicht existiert.

Wenn ein Job eingeht, validiert SageMaker seine Konfiguration und Präferenzliste anhand unterstützter Ressourcen und Limits. Der Scheduler prüft die Optionen dann einmal in ihrer deklarierten Reihenfolge. Die erste verfügbare Option gewinnt und beginnt mit der Bereitstellung.

Sind alle Optionen nicht verfügbar, wartet die ereignisgesteuerte Warteschlange auf eine relevante Kapazitätsänderung. Das ist effizienter als kontinuierliches Kunden-Polling, bleibt aber dennoch eine Warteschlange. Ein Job kann ausstehend bleiben, bis sein Zeitlimit abläuft.

Diese Grenze ist bei der Bewertung von AWS’ Aussage wichtig, die Funktion helfe Jobs, früher zu starten. Der Vergleich bezieht sich auf einen Job, der an eine nicht verfügbare Konfiguration gebunden ist, oder auf ein langsameres, kundenseitig verwaltetes Wiederholungssystem. AWS hat keine unabhängigen Benchmarks veröffentlicht, die Verbesserungen der medianen Startzeit über Regionen, Instanzfamilien oder Clustergrößen hinweg zeigen.

Eine Liste kombiniert auch keine Teilkapazität aus mehreren Einträgen. Wenn eine Präferenz acht Knoten anfordert, muss SageMaker diese ausgewählte Konfiguration bereitstellen können. Das System wählt eine vollständige Präferenz, statt einen heterogenen Cluster aus verfügbaren Fragmenten zusammenzustellen.

Damit unterscheiden sich Instanzpräferenzen von SageMaker-Heterogeneous-Clustern. Ein heterogener Cluster führt bewusst mehrere Instanzgruppen innerhalb eines Trainingsjobs aus. Eine Präferenzliste steht für sich gegenseitig ausschließende Alternativen, von denen nur eine zur Rechenumgebung des Jobs wird.

Diese Unterscheidung schützt die Konsistenz der Ausführung. Verteilte Trainings-Frameworks erwarten in der Regel eine bekannte Topologie, sobald der Job startet. Eine vordefinierte Konfiguration auszuwählen ist einfacher, als Hardwarearchitekturen, Netzwerkeigenschaften und Speicherprofile dynamisch zu mischen.

Die Integration von Training Plans fügt eine weitere Entscheidungsebene hinzu. Eine Präferenz kann auf einen passenden reservierten Plan verweisen, während spätere Einträge On-Demand-Kapazität verwenden. AWS bewertet die reservierte Option zuerst, wenn Betreiber sie an die erste Stelle setzen.

Diese Reihenfolge gibt Organisationen eine direkte Möglichkeit, vorausbezahlte Kapazitäten zu bevorzugen, ohne sie zum einzigen Ausführungsweg eines Jobs zu machen. Der Fallback kann jedoch das wirtschaftliche Ergebnis verändern. Eine On-Demand-Alternative kann andere effektive Kosten verursachen, und eine größere Anzahl von Knoten kann diesen Unterschied verstärken.

Die Funktion scheint auch kein Ersatz für Managed Spot Training zu sein. Managed Spot Training adressiert einen anderen Zielkonflikt, indem unterbrechbare EC2-Spot-Kapazitäten genutzt werden. AWS zufolge kann dieser Ansatz die Rechenkosten senken, während Unterbrechungen die Fertigstellungszeit verlängern und Checkpointing erforderlich machen können.

Instanzpräferenzen betreffen vor allem die anfängliche Kapazitätsauswahl über akzeptable Konfigurationen hinweg. Spot Training betrifft hingegen das Beschaffungsmodell und das Unterbrechungsrisiko, nachdem ein Workload Rechenkapazität erhalten hat. Teams müssen diese Dimensionen getrennt bewerten.

Am besten eignet sich daher ein neustartempfindlicher, aber hardwareflexibler Job. Denkbar ist etwa eine nächtliche Evaluierungspipeline, die auf mehreren GPU-Generationen laufen kann. Es ist wichtig, das morgendliche Reporting-Fenster nicht zu verpassen, aber der absolut schnellste Beschleuniger ist nicht erforderlich.

Das Team kann mehrere Konfigurationen zertifizieren, sie nach der bevorzugten Balance aus Laufzeit und erwarteten Kosten ordnen und anschließend eine maximale Wartezeit festlegen. SageMaker wählt innerhalb dieses getesteten Rahmens aus.

Große Pretraining-Läufe sind ein schwierigerer Fall. Ihre Kommunikationsmuster, Speicheranforderungen, Checkpoint-Verhalten und Topologie können auf einen bestimmten Beschleuniger und ein bestimmtes Interconnect abgestimmt sein. Ein nominell unterstützter Fallback könnte den Job langsamer, teurer oder instabil machen.

Der neue Scheduler kann nicht entscheiden, ob dieser Fallback wissenschaftlich oder wirtschaftlich weiterhin valide ist. Dieses Urteil bleibt beim Verantwortlichen für den Workload.

Amazon SageMaker-Instanzpräferenzlisten sind daher deklarativ, nicht im umfassenden Sinn adaptiv. SageMaker reagiert auf Kapazitätssignale, benchmarked jedoch weder das Modell noch schreibt es verteilte Einstellungen um oder optimiert die Liste gegen eine Deadline.

Das ist dennoch bedeutsam. Managed Services schaffen Mehrwert, wenn sie eine wiederkehrende, klar abgegrenzte Verantwortung von jedem Kunden übernehmen und sie einmal implementieren. Kapazitäts-Fallback passt in dieses Muster, sofern der Kunde ehrliche Kompatibilitätsgrenzen vorgibt.

Kompatibilität und Kosten bleiben Verantwortung der Betreiber

Das größte Risiko besteht nicht darin, dass SageMaker die falsche Präferenz auswählt, sondern darin, dass ein Team eine unsichere Präferenz als akzeptabel deklariert.

AWS warnt ausdrücklich davor, dass SageMaker die Kompatibilität über verschiedene Instanztypen hinweg nicht validiert. Der Service stellt nicht fest, ob ein Container jede GPU-Architektur unterstützt, ob seine Treiber passen oder ob seine verteilte Konfiguration Elastic Fabric Adapter-Netzwerk erfordert.

Ein Job kann daher die Anfragevalidierung bestehen und trotzdem nach der Bereitstellung scheitern. Das kostet Startzeit und kann den erwarteten Nutzen des automatischen Fallbacks schmälern.

Dem Verhalten der Frameworks gebührt besondere Aufmerksamkeit. CUDA-Fähigkeiten, Bibliotheken für kollektive Kommunikation, Mixed-Precision-Formate, Compiler-Ausgaben und gerätespezifische Kernel können sich zwischen Beschleunigergenerationen unterscheiden. Bei H100-Hardware getestete Container sollten nicht automatisch als identisch funktionierend auf A100- oder L40S-Hardware gelten.

Auch Speicher bildet eine Grenze. Ein Workload, der auf einen Beschleuniger passt, kann den Gerätespeicher eines anderen überschreiten, selbst wenn der theoretische Gesamtdurchsatz ähnlich erscheint. Eine höhere Knotenzahl löst Beschränkungen beim Speicher pro Gerät nicht automatisch.

Auch die verteilte Topologie beeinflusst die Leistung. Zwei Knoten mit hoher Bandbreite durch vier langsamere Knoten zu ersetzen, verändert Kommunikationsvolumen, Synchronisierungsaufwand und Fehleranfälligkeit. Eine gleiche GPU-Anzahl oder eine angenäherte Rechenschätzung garantiert keine gleiche Fertigstellungszeit.

Die Beispiele von AWS verdeutlichen die Absicht, nicht jedoch eine universelle Gleichwertigkeitsformel. Ein Beispiel nennt zwei ml.g6.48xlarge-Instanzen vor vier ml.g5.48xlarge-Instanzen. Der Kunde muss entscheiden, ob diese Beziehung für sein Modell, seine Batch-Größe, sein Netzwerkmuster und seinen Software-Stack gilt.

Teams sollten jede aufgeführte Konfiguration mit demselben Container-Image, Datenpfad und Distributed Launcher benchmarken, die auch in der Produktion verwendet werden. Der daraus entstehende Freigabenachweis sollte Laufzeit, Konvergenzprüfungen, Auslastung, Fehlerrate und Output-Validierung enthalten.

Auch die Kostenpolitik erfordert dieselbe Disziplin. Die Präferenzreihenfolge drückt Priorität aus, keine Budgetobergrenze. Ein Fallback mit mehr Instanzen kann früher starten und dennoch eine höhere Gesamtrechnung verursachen als die bevorzugte Option.

Umgekehrt kann ältere Hardware länger laufen und eine scheinbare Einsparung pro Instanz zunichtemachen. Entscheidend ist das vollständige Ergebnis des Jobs, einschließlich Startverzögerung, Ausführungszeit, Wiederholungen, Speicher und möglicher Auswirkungen auf nachgelagerte Deadlines.

Der Launch schafft zudem eine Anforderung an die Beobachtbarkeit. Teams müssen festhalten, welche Präferenz ausgewählt wurde, wie lange der Job wartete, warum Alternativen in dieser Reihenfolge angeordnet waren und ob die tatsächliche Leistung dem Benchmark entsprach.

Ohne diese Aufzeichnungen wird die automatische Auswahl undurchsichtig. Ingenieure könnten stärkere Schwankungen bei Laufzeit oder Kosten sehen, ohne zu erkennen, dass sich die zugrunde liegende Instanzfamilie zwischen den Läufen geändert hat.

Auch Governance-Regeln müssen möglicherweise angepasst werden. AWS unterstützt Identitätsrichtlinien, die SageMaker-Instanztypen beschränken. Die genehmigte Präferenzliste einer Organisation muss mit diesen Kontrollen, Account-Quoten und regionaler Verfügbarkeit vereinbar bleiben.

Reservierte Kapazität führt zu einem weiteren möglichen Missverständnis. Eine Flexible Training Plan-Präferenz kann eine stärkere Kapazitätszusage bieten, doch ein Fallback verwandelt eine nicht verfügbare Reservierung nicht in zusätzliche reservierte Kapazität. Er verschiebt den Job auf einen separat akzeptablen On-Demand-Pfad.

Processing-Jobs benötigen eine eigene Prüfung. Ein CPU-Fallback kann für einige Transformationen sinnvoll sein, kann die Fertigstellungszeit aber auch drastisch verändern. Teams sollten keine CPU-Option aufnehmen, nur weil die API dies zulässt.

Das Fehlen veröffentlichter Felddaten ist derzeit die größte Unsicherheit. AWS hat den Scheduling-Ablauf und die Konfigurationsregeln beschrieben, doch Kunden verfügen noch nicht über breite Evidenz zu Startzeitgewinnen unter verschiedenen Knappheitsbedingungen.

Sinnvolle Messungen sollten die Funktion mit der bestehenden Ausgangsbasis jedes Teams vergleichen. Dazu gehören die Zeit von der Übermittlung bis zur Ausführung, der Anteil der Jobs, die einen Fallback verwenden, Timeout-Raten, der gesamte Rechenverbrauch und operative Vorfälle durch Konfigurationsänderungen.

Diese Messungen werden zeigen, ob SageMaker GPU-Kapazitätsflexibilität echte operative Last beseitigt oder Variabilität lediglich in eine weniger sichtbare Ebene verlagert.

Drei Signale werden zeigen, ob die Funktion in der Praxis funktioniert

Die Akzeptanz sollte anhand der Jobergebnisse bewertet werden, nicht danach, wie viele Teams einen zweiten Instanztyp zu ihrer Konfiguration hinzufügen.

Das erste Signal ist die Fallback-Häufigkeit in Verbindung mit der Startzeit. Teams sollten messen, wie oft SageMaker etwas unterhalb der ersten Präferenz auswählt und wie sich dies auf die Latenz zwischen Übermittlung und Start auswirkt.

Eine hohe Fallback-Rate bei kürzeren Wartezeiten würde die zentrale Aussage von AWS stützen. Sie würde zeigen, dass im größeren Pool Kapazität vorhanden ist, selbst wenn der bevorzugte Typ begrenzt ist.

Eine hohe Fallback-Rate ohne kürzere Wartezeiten würde diese These schwächen. Das könnte bedeuten, dass die aufgeführten Alternativen denselben regionalen Engpass teilen, die angeforderten Cluster zu groß sind oder die ereignisgesteuerte Warteschlange die Bereitstellung für diesen Workload nicht wesentlich verbessert.

Das zweite Signal sind Leistungs- und Kostenschwankungen zwischen den ausgewählten Konfigurationen. Jeder Fallback sollte mit Laufzeit, Auslastung, Abschlussstatus und gesamtem Ressourcenverbrauch verknüpft werden.

Stabile Ergebnisse würden das Argument stärken, Infrastruktur als Präferenzmenge zu behandeln. Große Abweichungen würden zeigen, dass die Alternativen nicht wirklich gleichwertig waren, selbst wenn jede Konfiguration den Container technisch ausführen konnte.

Das ist besonders für wiederkehrende Pipelines wichtig. Ein Team mag einen langsameren Lauf während eines dringenden Experiments akzeptieren, aber dauerhafte Unvorhersehbarkeit in einem täglichen Produktionszeitplan ablehnen.

Das dritte Signal ist, wie AWS die Funktion und ihre begleitende Telemetrie erweitert. Kunden sollten auf detailliertere Auswahlereignisse, klarere Erklärungen zu ausstehenden Zuständen, Tools für kostenbewusste Reihenfolgen und eine breitere Integration mit Pipeline-Kontrollen achten.

Auch Unterstützung für differenziertere Richtlinien wäre relevant. Betreiber könnten letztlich Vorgaben wie eine Deadline, eine Ausgabengrenze oder die Anforderung wünschen, dass der Durchsatz eines Fallbacks innerhalb eines getesteten Bereichs bleibt. Die aktuelle geordnete Liste kodiert diese Urteile manuell.

Reaktionen von Wettbewerbern liefern unterstützenden Kontext, doch die entscheidenden Belege werden aus dem Kundenbetrieb stammen. Google behandelt Beschleunigerknappheit bereits über Dynamic Workload Scheduler als Scheduling-Problem. Azure macht die Quotenbeschränkungen sichtbar, die bestimmen, ob verwaltete Jobs laufen können.

Der besondere Ansatz von AWS besteht darin, mehrere akzeptable Konfigurationen direkt in eine SageMaker-Training- oder Processing-Anfrage aufzunehmen. Wenn Kunden schnellere Starts ohne inakzeptable Varianz erreichen, wird dieses Modell für Managed-ML-Plattformen schwer zu ignorieren sein.

Der kurzfristige Test ist unkompliziert. Wählen Sie einen hardwareflexiblen Workload aus, benchmarken Sie jede Kandidatenkonfiguration und definieren Sie eine maximale Wartezeit, bevor Sie den automatischen Fallback aktivieren. Vergleichen Sie anschließend mindestens mehrere Läufe mit dem bisherigen Wiederholungsprozess.

Halten Sie den gewählten Instanztyp, die Warteschlangendauer, die Ausführungszeit, den Abschlussstatus und die gesamte Ressourcennutzung fest. Betrachten Sie einen erfolgreichen Start nicht als das vollständige Ergebnis.

Amazon SageMaker-Instanzpräferenzlisten machen den Umgang mit Kapazität weniger manuell, belohnen jedoch Vorbereitung. Teams, die ihre Alternativen validieren, können anfälligen Infrastrukturcode entfernen. Teams, die spekulative Fallbacks eintragen, automatisieren möglicherweise nur die Entdeckung von Inkompatibilitäten.

Die nützliche Frage lautet nicht, ob fünf Optionen besser sind als eine. Sie lautet, ob Ihre Organisation fünf wirklich akzeptable Ergebnisse definieren, sie bewusst priorisieren und messen kann, was geschieht, wenn SageMaker zwischen ihnen auswählt.