SageMaker: Teams schreiben eigene Trainingsschleifen, ohne GPUs zu verwalten

Die Rechenleistung abstrahieren, nicht den Algorithmus

AWS beschreibt ein bekanntes Problem beim Fine-Tuning von LLMs. Vollständig verwaltete Dienste funktionieren gut, solange ein Standardrezept passt, lassen aber kaum Spielraum für eine eigene Verlustfunktion, ein Daten-Curriculum, eigene Preference Optimization oder eine Reward-Funktion für Reinforcement Learning (RL). Weniger stark verwaltete Optionen bieten mehr Kontrolle, doch dann betreibt der Nutzer einen größeren Teil der Infrastruktur und der Trainings-Frameworks selbst.

Die neuen Training-Session-APIs ziehen die Grenze eine Ebene tiefer. Operationen wie forward_backward(), optim_step() und sample() werden zu SageMaker-API-Aufrufen, die Entwickler zu Supervised Fine-Tuning (SFT), Preference Optimization, RL oder einer neuen Technik zusammensetzen. Die Aufrufe richten sich an eine laufende, zustandsbehaftete Sitzung, sodass das Modell über alle Schritte hinweg auf den GPUs geladen bleibt.

Laut AWS übernimmt der Dienst die Einrichtung der Laufzeitumgebung, die verteilte Ausführung, die Gradientensynchronisation, die Fehlerbehebung, die Mandantentrennung und den Betrieb der GPUs in großem Maßstab. Der Nutzer schreibt die Schleife. Zusätzlich hat AWS das SageMaker Training Sessions Cookbook veröffentlicht, eine Sammlung sofort ausführbarer SFT- und RL-Rezepte, die als Vorlagen gedacht sind.

So funktioniert das Programmiermodell

Entwickler steuern eine GPU-gestützte Sitzung aus ihrem eigenen Python-Prozess auf einem lokalen Rechner. Die Sitzung führt ein gewähltes Basismodell samt Low-Rank-Adaptation-Adapter (LoRA) aus. Eine vorab erstellte Konfigurationsdatei für den gesamten Job oder ein Schritt zum Anlegen eines Clusters entfällt.

Das SageMaker Python SDK stellt drei Clients bereit, die nacheinander erzeugt werden:

• ServiceClient enthält Plattformeinstellungen wie die Ausführungsrolle, die Model Package Group und den Amazon-S3-Speicherort für die Ausgabe, optional auch einen AWS-KMS-Schlüssel und eine VPC-Konfiguration. Er startet eine Sitzung.
• TrainingClient deckt Trainings- und Checkpoint-Operationen ab, etwa forward, forward_backward, optim_step und save_weights_for_sampler.
• SamplingClient bietet sample und compute_logprobs zur Generierung und Bewertung bei Rollouts und Evaluierungen.

Eine aktive Sitzung stellt außerdem einen OpenAI-kompatiblen Chat-Completions-Endpunkt bereit, sodass bestehender Code für OpenAI-Clients daraus sampeln kann.

In einem RL-Schritt erzeugt das Modell auf der GPU Ausgaben, der Code des Nutzers bewertet sie mit einem Verifier, einem Reward-Modell-Aufruf oder einem Test-Harness, und forward_backward sowie optim_step machen aus den Bewertungen ein Gradienten-Update. Der Aufruf save_weights_and_get_sampling_client() aktualisiert anschließend den Sampler. Bei SFT entfallen Sampling und Bewertung, und forward_backward wird mit einem cross_entropy-Loss über gelabelte Beispiele aufgerufen.

Abrechnung pro Token und Zielgruppe

Laut AWS wird die Nutzung pro verarbeitetem Token abgerechnet. Zeit, die auf dem Rechner des Nutzers für Reward-Berechnung, Datenladen, Logging oder Debugging anfällt, wird nicht als GPU-Zeit berechnet. Das Unternehmen argumentiert, dass dadurch Kosten für ungenutzte GPUs entfallen und sich die Ausgaben leichter planen lassen, da die Kosten mit Datenmenge und Generierungsvolumen skalieren statt mit der Laufzeit oder der Clustergröße. Bei Workloads mit viel lokaler Berechnung, etwa komplexen Reward-Modellen, agentischen Rollouts mit mehreren Tools oder Human-in-the-Loop-Evaluierung, könnten die Einsparungen erheblich sein.

Dieselben Bausteine unterstützen SFT, RL mit ppo, importance_sampling oder cispo sowie eigene Zielfunktionen wie Preference Optimization oder Distillation. Als vorgesehene Nutzer nennt AWS Forschende im Bereich Post-Training und Alignment, Teams mit Bedarf an nicht standardisierten Verlustfunktionen oder mehrstufigen Pipelines, Entwickler agentischer und mehrstufiger RL-Setups, ML-Ingenieure, die über konfigurationsgesteuertes Fine-Tuning hinausgewachsen sind, sowie Forschende, die bestehenden Trainingsschleifen-Code portieren.

Einordnung in SageMaker AI

AWS positioniert die APIs zwischen seinen bestehenden Optionen. Die serverlose Modellanpassung mit verwalteten APIs bietet wenig Kontrolle über das Training. Die Training-Session-APIs bieten viel Kontrolle und bleiben dabei serverlos, ohne Auswahl von Instanzen. SageMaker Training Jobs und SageMaker HyperPod bieten volle Kontrolle, doch der Nutzer wählt Instanztypen aus oder betreibt dauerhafte Cluster.

Für Teams, die algorithmische Freiheit brauchen, aber keine GPUs bereitstellen wollen, ergibt sich damit ein Mittelweg. Unterstützte Basismodelle und Regionen sind in der Dokumentation zu den Training-Session-APIs aufgeführt.