Was sich mit der neuen Funktion ändert
AWS Batch bietet nun Kontingentverwaltung und Präemption für SageMaker-Trainingsjobs. Unternehmen können damit Rechenkapazität auf Teams oder Projekte aufteilen und Prioritäten für bestimmte Jobs festlegen. Neue Beschleuniger kommen dadurch nicht hinzu: Die Funktion organisiert die Nutzung der verfügbaren Kapazität auf der AWS-Infrastruktur.
Laut AWS kann jede Jobwarteschlange bis zu 20 gemeinsame Kontingente enthalten. Diese fungieren als virtuelle Warteschlangen mit dedizierten Kapazitätsgrenzen und konfigurierbaren Regeln für die gemeinsame Ressourcennutzung. Die Integration erfolgt über das Modul aws_batch im SageMaker Python SDK, wie AWS in der am 25. März 2026 veröffentlichten Ankündigung beschreibt.
Der mögliche Nutzen liegt vor allem im operativen Bereich: Teams können Kapazität strukturierter zuteilen und die Zeit verkürzen, in der ungenutzte Ressourcen einem Kontingent vorbehalten bleiben. AWS beziffert jedoch weder mögliche Einsparungen noch Leistungssteigerungen oder Änderungen der Wartezeiten. Das Ergebnis hängt von Bedarf, Konfiguration und verfügbarer Kapazität ab.
Wie Kapazität verteilt und verliehen wird
Ein gemeinsames Kontingent steht für einen Kapazitätsanteil, der einem Team oder Projekt zugeordnet ist. AWS beschreibt es als virtuelle Warteschlange mit dedizierten Grenzen und weist zugleich darauf hin, dass sich die gemeinsame Nutzung von Ressourcen konfigurieren lässt. Ein Kontingent sollte daher nicht als dauerhaft reservierter Rechner verstanden werden, sondern als Regel zur Kapazitätsverwaltung innerhalb des Warteschlangensystems.
Nutzt ein Kontingent nicht seine gesamte zugewiesene Kapazität, kann AWS Batch anderen Kontingenten deren Nutzung ermöglichen. AWS zufolge stellt der Dienst verliehene Kapazität automatisch wieder her, wenn der ursprüngliche Eigentümer Jobs einreicht. Das beschreibt die Zuteilung zwischen Kontingenten, garantiert aber nicht, dass ein Job, der die geliehene Kapazität nutzt, abgeschlossen ist, bevor diese wieder benötigt wird.
Bei Teams mit unterschiedlichen Arbeitszeiten oder Auslastungszyklen könnte das Verleihen die Nutzung ansonsten brachliegender Ressourcen verbessern. Das ist eine mögliche Folge des Mechanismus, keine garantierte Einsparung. Fordern mehrere Teams gleichzeitig GPUs an, bestimmen weiterhin Kontingente, Prioritäten und verfügbare Ressourcen, welche Jobs vorankommen.
Was die einzelnen Mechanismen bedeuten
Die Begriffe beschreiben Planungsentscheidungen. Sie bedeuten weder, dass zusätzliche physische Kapazität entsteht, noch dass jeder Job sofort Ressourcen erhält.
| Mechanismus | Was er ermöglicht | Was dadurch nicht automatisch bestätigt ist |
|---|---|---|
| Gemeinsames Kontingent | Kapazitätsgrenzen und Ressourcennutzung nach Team oder Projekt organisieren. | Dass Kapazität jederzeit reserviert oder verfügbar ist. |
| Kapazität verleihen | Anderen Kontingenten die Nutzung ungenutzter Ressourcen ermöglichen und die Kapazität zurückholen, wenn der Eigentümer sie benötigt. | Dass ein Job, der die Kapazität ausleiht, Ressourcen unbegrenzt behalten kann. |
| Präemption | Jobs mit höherer Priorität nach der Konfiguration vor Jobs mit niedrigerer Priorität bevorzugen. | Dass der verdrängte Job automatisch fortgesetzt wird oder seinen Zustand behält. |
Wie die Präemption funktioniert
Mit der Präemption können bestimmte Jobs mit höherer Priorität vor Jobs mit niedrigerer Priorität geschoben werden. AWS zufolge kann dies sowohl zwischen gemeinsamen Kontingenten als auch innerhalb desselben Kontingents geschehen. Außerdem lassen sich Jobprioritäten nach der Einreichung ändern, um Präemptionsentscheidungen zu beeinflussen.
Der Dienst ermöglicht auch die Konfiguration von Grenzen für Präemptionswiederholungen. Damit lässt sich festlegen, wie oft ein betroffener Job nach einer Präemption erneut versucht werden kann. Die Ankündigung beschreibt jedoch weder alle möglichen Ergebnisse noch, wie der Trainingszustand erhalten bleibt. Es sollte nicht davon ausgegangen werden, dass ein verdrängter Job beim letzten Checkpoint weiterläuft: Dieses Verhalten hängt von den Funktionen des jeweiligen Workflows ab und wird in den veröffentlichten Angaben nicht bestätigt.
Eine hohe Priorität bedeutet in der Praxis eine bevorzugte Planung, keine Garantie für die sofortige Ausführung. Verfügbare physische Kapazität, andere Warteschlangen und die konfigurierten Regeln können weiterhin beeinflussen, wann ein Job startet. Vor dem Einsatz sollte geprüft werden, wie Prioritäten mit Trainingsdauer und Wiederholungsrichtlinien zusammenspielen.
Ablauf einer Entscheidung in einer gemeinsamen Warteschlange
Praktisches Schema der von AWS beschriebenen Mechanismen. Die konkreten Ergebnisse hängen von der Konfiguration der jeweiligen Organisation ab.
- 01Ein SageMaker-Trainingsjob wird an eine AWS-Batch-Warteschlange mit gemeinsamen Kontingenten übermittelt.
- 02AWS Batch weist Kapazität entsprechend den konfigurierten Grenzen und Regeln für die gemeinsame Nutzung zu.
- 03Ist in einem Kontingent Kapazität ungenutzt, kann ein anderes Kontingent sie nach diesen Regeln verwenden.
- 04Trifft ein Job mit höherer Priorität ein, kann der Dienst ihn Jobs mit niedrigerer Priorität vorziehen.
- 05Verliehene Kapazität kann an das Eigentümerkontingent zurückgehen, wenn dieses Jobs einreicht; die Grenzen für Präemptionswiederholungen werden separat konfiguriert.
Verfügbarkeit und Integration
AWS kündigte die Funktion am 25. März 2026 an und gibt an, dass sie in allen Regionen verfügbar ist, in denen auch AWS Batch verfügbar ist. Die geografische Verfügbarkeit ist damit an den Umfang des Hauptdienstes gebunden. Daraus folgt nicht, dass AWS Batch in jeder AWS-Region angeboten wird.
Die angegebene Integration erfolgt über das Modul aws_batch im SageMaker Python SDK. Die Ankündigung bezieht sich ausdrücklich auf SageMaker-Trainingsjobs. Sie liefert keine Grundlage dafür, die Funktion auf beliebige Batch-Workloads oder sämtliche Arten von SageMaker-Jobs auszuweiten.
Allgemein ist AWS Batch ein verwalteter Dienst, der Batch-Workloads auf verschiedenen AWS-Rechenoptionen plant und ausführt. Dieser Kontext zeigt, wo die Kontingentverwaltung angesiedelt ist, erlaubt aber keine Rückschlüsse auf technische Einzelheiten der neuen Funktion, die in der Ankündigung nicht genannt werden – etwa sämtliche Berechtigungen, Kosten oder geltenden Grenzen.
Was vor einer Einführung geprüft werden sollte
Die Funktion kann nützlich sein, wenn mehrere Teams Rechenkapazität gemeinsam verwenden und ihr Bedarf schwankt. Kontingente helfen, den Zugang zu organisieren; das Verleihen kann ungenutzte Kapazität verringern, und Prioritäten können betriebliche Dringlichkeit abbilden. Ob sich der Einsatz lohnt, hängt davon ab, wie sich der Bedarf verteilt und welche Regeln eine Organisation festlegt.
Die verfügbaren Angaben nennen nicht die erforderlichen Berechtigungen, die anfallenden Kosten, den Umgang mit dem Zustand eines präemptierten Jobs oder sämtliche Konfigurationsgrenzen. Auch Vergleichsergebnisse, mit denen sich Einsparungen oder Leistungssteigerungen abschätzen ließen, werden nicht vorgelegt. Diese Punkte müssen anhand der jeweils geltenden Betriebsdokumentation geklärt und mit repräsentativen Workloads getestet werden. Präemption sollte nicht mit einer verlustfreien Unterbrechung und Fortsetzung gleichgesetzt werden.
Für die Bewertung können Teams zunächst festlegen, wer Eigentümer jedes Kontingents ist, welche Jobs verdrängt werden dürfen und wie viele Wiederholungsversuche akzeptabel sind. Außerdem lässt sich die Ressourcennutzung auf Ebene der Warteschlange, des Kontingents und des einzelnen Jobs beobachten; AWS zufolge ist eine solche Überwachung möglich. Klare Regeln helfen, Prioritäten an tatsächlichen Bedürfnissen auszurichten, statt einen dauerhaften Wettbewerb zwischen Teams zu erzeugen.
Fragen für die betriebliche Bewertung
Diese Fragen helfen dabei, die angekündigten Funktionen in konkrete Bewertungskriterien für die eigene Organisation zu übersetzen.
| Bereich | Praktische Frage |
|---|---|
| Zuteilung | Welches Team oder Projekt ist Eigentümer des jeweiligen Kontingents, und welche Grenze wird benötigt? |
| Prioritäten | Welche Jobs dürfen andere überholen, und wer darf ihre Priorität ändern? |
| Wiederholungen | Wie viele Präemptionswiederholungen sind für die jeweiligen Trainingsarten akzeptabel? |
| Jobzustand | Kann der Trainingsworkflow eine Unterbrechung verkraften, und von welchem Checkpoint aus lässt er sich wiederaufnehmen? |
| Kosten und Berechtigungen | Welche Kosten und Berechtigungen gelten für die konkrete verwendete Konfiguration? |
| Überwachung | Wie werden Ressourcennutzung und Auswirkungen der Richtlinien auf Warteschlangen-, Kontingent- und Jobebene überprüft? |
Offene Fragen
- Die Ankündigung erläutert nicht, wie der Zustand von Jobs erhalten oder wiederhergestellt wird, die von einer Präemption betroffen sind. Eine verlustfreie Fortsetzung ab einem Checkpoint sollte daher nicht vorausgesetzt werden.
- Die verfügbaren Angaben enthalten keine vollständige Beschreibung der Berechtigungen, Kosten oder Konfigurationsgrenzen, die für eine konkrete Implementierung gelten können.
- AWS beziffert weder mögliche Einsparungen noch Leistungsänderungen oder Wartezeiten. Diese Ergebnisse hängen von Workload und Konfiguration ab.
Weiter entdecken
Verwendete Quellen
Korrekturen und Transparenz
Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.
Korrektur vorschlagen