Mit den Trainingssitzungs-APIs von Amazon SageMaker AI lassen sich laut AWS eigene Trainingsschleifen in Python erstellen. Operationen wie forward_backward, optim_step und sample greifen auf eine laufende, zustandsbehaftete Sitzung zu. Das Modell bleibt zwischen den Schritten auf den GPUs geladen. Der Dienst übernimmt Laufzeitumgebung, verteilte Ausführung, Gradientensynchronisierung, Fehlerbehebung und Mandantenisolation.

Steuerung aus lokalem Python

Ein lokaler Python-Prozess kann die Sitzung steuern, während das gewählte Basismodell und ein LoRA-Adapter auf verwalteten Beschleunigern liegen. Weder die Erstellung eines Clusters noch eine Konfigurationsdatei für den vollständigen Trainingsablauf ist erforderlich.

Das SDK verwendet nacheinander drei Clients: ServiceClient hält Plattformparameter und startet die Sitzung. TrainingClient bietet Training und Checkpoints; SamplingClient stellt sample und compute_logprobs bereit. Aktive Sitzungen bieten außerdem einen OpenAI-kompatiblen Chat-Completions-Endpunkt.

In der gezeigten RL-Schleife erzeugen GPUs Antworten, die lokaler Python-Code bewertet. forward_backward und optim_step aktualisieren das Modell. Anschließend erneuert save_weights_and_get_sampling_client den Sampler. Beim überwachten Fine-Tuning entfallen Sampling und Belohnungsberechnung; beschriftete Beispiele werden mit cross_entropy trainiert.

Ausführung und Abrechnung

GPU-gebundene Aufrufe liefern sofort APIFuture-Objekte zurück. Anfragen werden im Hintergrund eingereiht und übermittelt; result() wartet auf den Abschluss. Sampling-Anfragen können parallel laufen, Trainingsoperationen folgen der Einreichungsreihenfolge. Ein Trainingsdatensatz im Beispiel enthält Prompt- und Antworttoken, Token-Logwahrscheinlichkeiten, einen Vorteil und eine Maske, die Prompt-Token vom Verlust ausschließt.

Laut AWS erfolgt die Abrechnung pro verarbeitetem Token bei GPU-Operationen. Für lokale Belohnungsberechnung, Datenladen, Protokollierung oder Debugging wird keine GPU-Zeit berechnet. Unterstützt werden SFT, RL-Verluste wie ppo, importance_sampling und cispo sowie eigene Ziele wie Präferenzoptimierung oder Destillation. AWS beschreibt mehr Algorithmuskontrolle als bei Serverless Model Customization und weniger Betriebsverantwortung als bei Training Jobs oder HyperPod.

Speichern und fortsetzen

Jeder Checkpoint registriert eine Modellpaketversion. Das Beispiel speichert ein zusammengeführtes Modell zur Bereitstellung sowie Gewichte und Optimiererzustand zur Wiederaufnahme über create_training_client_from_state_with_optimizer. Zusammengeführte Checkpoints lassen sich auf Echtzeit-Endpunkten bereitstellen. Sitzungen belegen die Quote gleichzeitiger Sitzungen bis zum Stoppen oder Ablauf.

Das begleitende Cookbook übernimmt Batching, Chatvorlagen, Vorteilsschätzung, überlappendes Sampling und Training, Validierung, Wiederaufnahme, Schrittmetriken und Laufkonfigurationen. Rezepte umfassen Chat-SFT mit Tulu 3 und UltraChat, GSM8K-RL sowie KTO-Präferenzanpassung anhand binärer Rückmeldungen.

Von AWS gemeldete Ergebnisse

Das GSM8K-Beispiel trainiert einen GPT-OSS-20B-LoRA-Adapter mit GRPO. Verstärkt werden Antworten, deren Korrektheit über dem Gruppendurchschnitt liegt. AWS berichtet nach zehn Schritten mit 40 Aufgaben eine Steigerung der Genauigkeit auf zurückgehaltenen Testdaten von 56 auf 75 Prozent.

Das Rezept code_rl nutzt Programmieraufgaben aus DeepCoder und prüft erzeugte Python-Lösungen in einem lokalen SandboxFusion-Container. Bestehen alle Tests, gibt es 1, andernfalls 0; fehlt ein Codeblock, werden 0,1 abgezogen. In zwei Runden kann das Modell check_solution aufrufen, Ergebnisse prüfen und die Antwort überarbeiten.

Das Rezept überlappt Generierung und Training, begrenzt das Alter der Antworten, korrigiert Richtlinienunterschiede mit cispo und berechnet Gradienten in Teilbatches. AWS nennt einen LoRA-Adapter mit Rang 32, 50 Schritte, 128 Aufgaben, acht Antworten je Aufgabe, zwei Runden und höchstens drei Schritte Verzögerung. Die Trainingsbelohnung stieg von 0,46 auf 0,60; die Genauigkeit auf 200 zurückgehaltenen Aufgaben von 40 auf 50,5 Prozent. Metriken lassen sich optional an SageMaker Managed MLflow senden.

Die Angaben betreffen konkrete AWS-Testläufe und garantieren keine Verbesserungen bei anderen Aufgaben. Die Unterlagen nennen weder eine vollständige Modellliste noch Regionen, numerische Quoten oder Tokenpreise.