Entwickler können jetzt ihren eigenen KI-Trainingscode auf SageMaker schreiben

AWS erweitert Amazon SageMaker AI um serverlose Trainingssitzungen, in denen Entwickler ihre eigenen Post-Training-Schleifen schreiben und ausführen können, ohne GPU-Infrastruktur bereitstellen oder betreiben zu müssen. Die Funktion richtet sich an Teams, die benutzerdefinierte Verlustfunktionen, Belohnungssignale, Präferenzoptimierung oder mehrstufiges Reinforcement Learning benötigen, statt eines festen Fine-Tuning-Verfahrens.

Die Änderung verschiebt die Abstraktionsgrenze von SageMaker. Entwickler kontrollieren weiterhin die Python-Logik, die bestimmt, wie ein Modell abgetastet, bewertet und aktualisiert wird, während AWS GPU-Zuweisung, verteilte Ausführung, Fehlerbehebung und Checkpoint-Speicherung übernimmt. Für Entwickler von KI-Systemen entsteht damit ein Mittelweg zwischen stark vorgegebenem Managed Fine-Tuning und dem direkten Betrieb eines Trainingsclusters.

AWS kündigte die Funktion in zwei Beiträgen im Machine Learning Blog an. Auch The AI Economy berichtete über die Entwicklung, obwohl der verfügbare Agenturbeitrag keine zusätzlichen technischen Details oder unabhängigen Leistungsnachweise enthält.

Was sich durch SageMaker-Trainingssitzungen ändert

Herkömmliche Managed-Services zur Modellanpassung verlangen in der Regel, dass Nutzer ein Modell auswählen, Daten bereitstellen und eine bekannte Trainingsmethode konfigurieren. Das reduziert den Infrastrukturaufwand, kann Forscher und Engineering-Teams jedoch einschränken, wenn ein Projekt ein neues Ziel oder eine maßgeschneiderte Trainingssequenz erfordert.

SageMaker AI-Trainingssitzungen machen Operationen auf niedrigerer Ebene über das SageMaker Python SDK zugänglich. AWS beschreibt Aufrufe wie forward_backward(), optim_step() und sample() als Bausteine, die Entwickler zu überwachtem Fine-Tuning, Reinforcement Learning, Präferenzoptimierung oder anderen Verfahren kombinieren können.

Die Sitzung bleibt aktiv und zustandsbehaftet, wobei das ausgewählte Modell über die Operationen hinweg auf verwalteten Beschleunigern geladen bleibt. Entwickler können lokal einen Python-Prozess ausführen, Operationen an die Sitzung senden, Ergebnisse prüfen und weiter iterieren, ohne zunächst eine vollständige Clusterkonfiguration schreiben oder einen separaten verteilten Trainingsjob erstellen zu müssen.

AWS zufolge unterstützt der Dienst derzeit unter anderem überwachtes Fine-Tuning, Direct Preference Optimization, Reinforcement Learning mit verifizierbaren Belohnungen, Reinforcement Learning auf Basis von KI-Feedback und mehrstufiges Reinforcement Learning. Nutzer können außerdem zwischen Low-Rank Adaptation und vollständigem Fine-Tuning wählen und anschließend Verfahren in einem kontinuierlichen Anpassungs-Workflow verketten.

Die Veröffentlichungsmaterialien nennen unter anderem Unterstützung für die Modelle gpt-oss-20b, gemma-4-31B-it, Qwen3.6-27B und Qwen3.8-27B. Laut Unternehmensdokumentation variiert die Verfügbarkeit je nach Modell und AWS-Region.

Wie die vom Entwickler kontrollierte Schleife funktioniert

In AWS’ Beispiel beginnt eine Reinforcement-Learning-Schleife damit, dass Prompts an den verwalteten Sampling-Dienst gesendet werden. Der Code des Entwicklers bewertet die erzeugten Antworten mithilfe eines Verifizierers, eines Belohnungsmodells, eines Test-Harnesses oder einer anderen Umgebung. Anschließend sendet er die Bewertungen an den Trainingsdienst, wo Gradientenberechnung und Optimizerschritt auf von AWS verwalteten GPUs stattfinden.

Der Code kann den Sampler mit aktualisierten Gewichten erneuern und den Zyklus wiederholen. Diese Struktur ist für Agentenentwickler relevant, weil die Belohnung von mehreren Tool-Aufrufen oder Interaktionen statt von einer einzigen Antwort abhängen kann. Ein Agent, der Reisen bucht, einen Supportfall löst oder eine Rechercheaufgabe erledigt, wird möglicherweise erst nach mehreren Gesprächsrunden bewertet.

AWS veranschaulicht den Ansatz mit Group Relative Policy Optimization. Dabei werden mehrere Antworten auf denselben Prompt erzeugt, anhand einer Belohnungsfunktion verglichen und zur Aktualisierung des Modells verwendet. Das Unternehmen beschreibt außerdem Cookbook-Beispiele mit GSM8K-Mathematikaufgaben und Wettbewerbsprogrammierung, bei denen erzeugter Code anhand von Unit-Tests bewertet wird.

Beim überwachten Fine-Tuning können dieselben Grundelemente ohne Sampling- und Belohnungsphasen eingesetzt werden. Ein Entwickler kann eine Kreuzentropie-Verlustfunktion auf gelabelte Beispiele anwenden. AWS zufolge bleibt das Modell während der aktiven Trainingssitzung auf den verwalteten GPUs, während Schleifensteuerung, Datenverarbeitung, Belohnungslogik und anderer Anwendungscode in der Umgebung des Entwicklers verbleiben können.

Belege, Preise und Grenzen der Aussagen

Die zentralen Produktdetails stammen aus eigenen technischen Ankündigungen von AWS. Sie belegen daher, was der Anbieter über die Funktionen des Dienstes sagt, nicht aber unabhängig, dass dieser die Modellqualität verbessert oder die Gesamtkosten bei jeder Art von Workload senkt.

AWS zufolge werden Kunden pro verarbeitetem Token und nicht für reservierte GPU-Kapazität abgerechnet. Der Zähler pausiert laut Unternehmen, während eine Belohnungsfunktion einen Batch in der Umgebung des Kunden bewertet. AWS stellt dies als möglichen Vorteil für Workloads mit langsamer Bewertung, komplexer Tool-Nutzung oder menschlicher Prüfung dar, weil Entwickler während dieser Phasen nicht für ungenutzte Beschleuniger zahlen.

Dieses Preismodell könnte den Vergleich von Experimenten erleichtern. Die tatsächliche Wirtschaftlichkeit hängt jedoch von Tokenvolumen, Generierungslänge, Berechnung der Belohnung, Speicher, Datenübertragung und der Anzahl der Iterationen ab, die für ein brauchbares Modell erforderlich sind. AWS liefert im bereitgestellten Material keinen allgemeinen Kostenvergleich mit selbst verwalteten GPUs.

Das Unternehmen erklärt außerdem, dass Sitzungen Checkpointing und Fortsetzung, Mandantentrennung und Fehlerwiederherstellung unterstützen. Daten und Checkpoints bleiben an vom Kunden kontrollierten Amazon-S3-Speicherorten, optional mit AWS Key Management Service und einer Virtual-Private-Cloud-Konfiguration. AWS erklärt, dass Kundendaten und angepasste Gewichte nicht zum Training eines anderen Modells verwendet werden; im Quellenmaterial ist dies jedoch eine Anbietererklärung und kein unabhängig geprüftes Ergebnis.

AWS führt Kundenkommentare von ImagineSoftware sowie ein weiteres, nicht namentlich genanntes Kundenbeispiel an, das gpt-oss-20b und einen Amazon-Neptune-Wissensgraphen nutzt. Diese Berichte beschreiben eine fein abgestufte Kontrolle und zuverlässige Wiederaufnahme aus Checkpoints. Sie sind jedoch von AWS bereitgestellte Kundenaussagen und weder ein neutrales Benchmark noch eine umfassende Adoptionsstudie. Der verfügbare Beitrag von AI Economy liefert keine weitere Bestätigung.

Warum die Einführung für KI-Entwickler wichtig ist

Die wichtigste Zielgruppe sind nicht alle Nutzer von Fine-Tuning. Teams, die Standardverfahren verwenden, könnten einen herkömmlichen Managed Job einfacher finden. Trainingssitzungen sind relevanter, wenn der Algorithmus selbst das Produkt ist: etwa für einen Alignment-Forscher, der einen neuen Advantage-Schätzer testet, ein Agententeam, das Belohnungen über Tool-Aufrufe hinweg gestaltet, oder einen ML-Ingenieur, der Code aus einem Low-Level-Trainingsframework migriert.

Die Funktion könnte die mit solchen Experimenten verbundene Betriebslast reduzieren. Teams müssen nicht mehr selbst entscheiden, wie GPUs platziert, Gradienten synchronisiert, ausgefallene Worker wiederhergestellt oder separate Inferenzdienste für jeden Rollout betrieben werden. Dadurch könnten kleinere Gruppen anspruchsvollere Post-Training-Verfahren testen und zugleich die Kontrolle über Datencurriculum und Bewertungslogik behalten.

Es gibt jedoch einen Zielkonflikt. Wenn die Infrastruktur aus dem Code des Entwicklers ausgelagert wird, verschwinden nicht die Schwierigkeiten beim Entwurf einer zuverlässigen Belohnungsfunktion, bei der Vermeidung von Reward Hacking, bei der Auswahl von Bewertungsdaten oder bei der Bestimmung, ob eine Verbesserung über einen Benchmark hinaus generalisiert. Außerdem können neue Abhängigkeiten von den unterstützten Modellen, SDK-Operationen, Regionen und dem Preismodell von SageMaker entstehen.

Für Unternehmen sind die Governance-Details bedeutend. AWS zufolge können Teams IAM-Ausführungsrollen, S3-Speicher, KMS-Schlüssel, VPC-Einstellungen, Bewertungen vor der Bereitstellung hinsichtlich Genauigkeit, Verzerrung und Sicherheit sowie Überwachung nach der Bereitstellung über Amazon CloudWatch nutzen. Diese Kontrollen können Organisationen dabei helfen, benutzerdefiniertes Training in bestehende Prozesse einzufügen. Käufer müssen jedoch weiterhin Datenresidenz, Zugriffsgrenzen, Prüfbarkeit und den operativen Support für ihre eigenen Regionen und Workloads validieren.

Die wettbewerbliche Bedeutung ist ebenso spezifisch. Cloud-Anbieter versuchen zunehmend, sowohl einfache Nutzung als auch Zugang zur Trainingsschleife anzubieten. Die Positionierung von SageMaker lautet nicht einfach „Managed Fine-Tuning“, sondern verwaltete Ausführung für benutzerdefinierte Algorithmen. Damit liegt der Dienst zwischen vollständig verwalteter Modellanpassung und Services wie Amazon SageMaker Training Jobs oder Amazon SageMaker HyperPod, bei denen Kunden mehr Verantwortung für die Infrastruktur übernehmen.

Was als Nächstes beobachtet werden sollte

Das erste Signal wird eine breitere Unterstützung von Modellen und Regionen sein. Die Einführung nennt vier unterstützte Basismodelle. Der Nutzen des Dienstes für Produktionsteams wird jedoch davon abhängen, wie schnell diese Liste wächst und ob Kunden die bereits verwendeten Open-Weight-Modelle mitbringen können.

Auch Preistransparenz wird wichtig sein. AWS beschreibt eine tokenbasierte Abrechnung, doch detaillierte Beispiele für überwachtes Fine-Tuning, lange Agenten-Rollouts und Belohnungsfunktionen mit erheblicher lokaler Berechnung würden Käufern helfen, den Dienst mit reservierter oder bedarfsgesteuerter GPU-Infrastruktur zu vergleichen.

Entwickler sollten unabhängige Bewertungen von Trainingsqualität, Konvergenz, Fehlerwiederherstellung und End-to-End-Kosten beobachten. Die Beispiele von AWS demonstrieren das Programmiermodell, belegen aber nicht, dass Trainingssitzungen bessere Modelle hervorbringen als bestehende Frameworks.

Der praktische Test wird schließlich sein, ob Teams ohne Verlust von Beobachtbarkeit und Sicherheitskontrollen vom Experiment zur Bereitstellung gelangen können. Unterstützung für benutzerdefinierte Schleifen ist nur dann nützlich, wenn die daraus entstehenden Modelle ebenso zuverlässig evaluiert, gesteuert, versioniert und überwacht werden können wie Modelle, die mit konventionelleren SageMaker-Workflows trainiert wurden.

Creati.ai-Perspektive

SageMaker-Trainingssitzungen schließen eine reale Lücke im KI-Entwicklungs-Stack: Viele Teams möchten das Lernverfahren ändern, aber nicht zu Betreibern von GPU-Infrastruktur werden. Indem AWS Trainingsoperationen zugänglich macht und zugleich die Ausführung verwaltet, macht das Unternehmen benutzerdefiniertes Post-Training zugänglicher, ohne so zu tun, als sei Algorithmusdesign einfach geworden.

Die Einführung sollte weniger danach beurteilt werden, wie neuartig das Schreiben einer Python-Schleife ist, sondern nach den betrieblichen Ergebnissen: reproduzierbare Experimente, vorhersehbare Tokenkosten, robuste Belohnungsbewertung und ein glaubwürdiger Weg vom benutzerdefinierten Training zur gesteuerten Produktionsbereitstellung. AWS hat die Fähigkeiten des Dienstes durch eigenes technisches Material dargestellt; für diese Ergebnisse benötigt der Markt weiterhin unabhängige Belege.