Baseten macht Serverless Loops für das Post-Training allgemein verfügbar

Baseten gab am 6. November 2026 bekannt, dass Serverless Loops allgemein verfügbar ist. Damit stellt das Unternehmen sein verwaltetes SDK für überwachtes Fine-Tuning und Reinforcement Learning mit offenen Modellen allen zur Verfügung. Der Dienst rechnet das Training pro Token ab und bietet einen direkten Weg von Checkpoints zu Baseten Dedicated Inference.

Loops beruht auf einer klaren Arbeitsteilung: Die Nutzer liefern das Trainingssignal, während Baseten GPUs, Kernel, Modellarchitekturen und das Backend für verteiltes Training betreibt. Mit dem Python-SDK werden LoRA-Adapter trainiert, während die Gewichte des Basismodells eingefroren bleiben. Die Nutzer wählen das Basismodell, den LoRA-Rang, die Lernrate, die Verlustfunktion, die Daten oder Umgebung sowie den Algorithmus aus; Baseten betreibt den Trainer und Sampler, synchronisiert die Gewichte und stellt die unterstützende Infrastruktur bereit.

Ein Kompatibilitätspaket erhält Tinker-Importe sowie zentrale Aufrufe für Training und Sampling, damit Teams ihre bestehenden Skripte migrieren können. Die Migrationsanleitung sieht weiterhin vor, die Authentifizierung auf einen Baseten-API-Schlüssel umzustellen, Checkpoints als paginierte Datei-URLs zurückzugeben, Bildeingaben inline bereitzustellen und die Abdeckung der LoRA-Module je nach Modellfamilie festzulegen. Die Kompatibilität umfasst die Trainings-API; einige infrastrukturspezifische Details müssen die Teams jedoch selbst anpassen.

Serverless-Modelle und Abrechnung

Der Serverless-Katalog umfasst drei Modelle: Qwen/Qwen3.6-35B-A3B und zai-org/GLM-5.3-Flash für Text und Bildverarbeitung sowie zai-org/GLM-5.3 nur für Text. Jedes Modell unterstützt eine maximale Sequenzlänge von 262.144 Tokens. Die Konfiguration von GLM-5.3 für lange Kontexte unterstützt weder cross_entropy noch dpo Verlustfunktionen. Der dedizierte Modus deckt den größeren Modellkatalog ab, rechnet GPU-Zeit ab und bietet zusätzliche Steuerungsmöglichkeiten für Replikate, Warmstarts und Spot-Kapazitäten.

Serverless-Ausführungen nutzen gemeinsam genutzte Kapazitäten, ohne GPU-Reservierungen vorauszusetzen, und rechnen die beim Training und Sampling verwendeten Tokens ab. Für das Lesen von Ergebnissen, das Ändern einer Reward-Funktion oder Wartezeiten im Leerlauf fallen keine Tokengebühren an. Bei der Standardmodus-Auswahl kann auf dedizierte Kapazitäten zurückgegriffen werden, wenn ein Modell, ein LoRA-Rang oder eine Sequenzlänge nicht unterstützt wird oder eine Ausführung die Deployments einer anderen Ausführung wiederverwendet. Wird der Geltungsbereich auf Serverless beschränkt, schlägt eine nicht unterstützte Anfrage stattdessen fehl.

Die Freischaltung eines Modells garantiert nicht, dass Kapazitäten bereitgestellt werden. Workspace-spezifische Zugriffsrechte, nicht verfügbare GPUs und Trainer-Limits einer Organisation können eine Ausführung weiterhin verhindern. Das setzt dem Pay-per-Token-Modell in der Praxis zusätzliche Kapazitätsgrenzen, die über den veröffentlichten Katalog hinausgehen.

Checkpoints und Inferenz in der Produktion

Der Schnellstart stellt vier zentrale Vorgänge vor: forward_backward für Verlust- und Gradientenberechnungen, optim_step für Adapteraktualisierungen, sample für die Generierung und save_state für fortsetzbares Training. Beim Veröffentlichen der Sampler-Gewichte werden ein bereitstellbarer Checkpoint und ein daran gebundener Sampling-Client erstellt. Ein separater save_state Vorgang bewahrt den Modell- und Optimiererzustand. Die erste Sampling-Anfrage kann mehrere Minuten dauern, während die Serverless-Kapazität hochgefahren wird – ein praktischer Aspekt bei kurzen Experimenten.

Ein Sampler-Checkpoint wird als Basismodell mit geladenem, trainiertem LoRA-Adapter bereitgestellt. Checkpoints bleiben auch nach dem Ende ihrer Ausführungen bestehen und können über die CLI, die REST-API oder das Dashboard mit einem Hugging-Face-Zugriffstoken bereitgestellt werden, da beim Deployment die Basisgewichte heruntergeladen werden. Für den daraus entstehenden OpenAI-kompatiblen Endpunkt werden GPU-Kosten berechnet, solange er aktiv ist. Wird dieses Deployment gelöscht, fallen keine GPU-Kosten mehr an, der Checkpoint bleibt jedoch erhalten; durch das Deaktivieren der Loops-Ausführung wird das Deployment nicht entfernt.

Für die allgemeine Verfügbarkeit hat Baseten die Behandlung vorübergehender Netzwerkfehler und GPU-Ausfälle verbessert, den Startaufwand verringert und die Übertragung von Gewichten zwischen Trainern und Samplern beschleunigt. Laut Baseten ermöglichen diese Änderungen die gleichzeitige Ausführung einer größeren Zahl von Kunden-Workloads. Außerdem verarbeitet der Inferenz-Stack des Unternehmens in der Produktion täglich mehr als 15 Milliarden Anfragen. Der Produktionspfad umfasst Autoskalierung, Deployment-Verwaltung und Inferenzmetriken; zudem können Nutzer Gewichte im Hugging-Face-Safetensors-Format herunterladen.

Validierung und erste Kunden-Workloads

Baseten zufolge wurde der Dienst mit numerischen Tests und End-to-End-Experimenten zum Reinforcement Learning validiert. Dabei kamen τ-bench-Aufgaben aus den Bereichen Einzelhandel, Luftfahrt und Bankwesen zum Einsatz; anschließend wurden die Ergebnisse anhand zurückgehaltener, anspruchsvoller Aufgaben bewertet. Das τ-bench-Projekt beschreibt einen Benchmark, mit dem geprüft wird, ob Agenten in verschiedenen Unternehmensbereichen mit Nutzern kommunizieren, Tools aufrufen, Wissen abrufen und Richtlinien befolgen können. Die Ergebnisse werden anhand überprüfbarer Datenbankresultate kontrolliert.

Baseten berichtet, dass NVIDIA Nemotron Super 3.5 VL mit Text- und Bildverarbeitungsaufgaben nachtrainiert und dabei die Genauigkeit der Absichtsklassifizierung von 76,8 % auf 94 % gesteigert sowie bei der Extraktion von Belegen einen Validierungs-F1-Wert von 87 % erreicht hat. Zu der Arbeit gehörte außerdem Reinforcement Learning für das Zählen visueller Objekte. Datadog nutzt mehrstufiges agentisches Reinforcement Learning, um Trainingsideen für seinen SRE-Agenten zu testen. Ambience Healthcare trainierte Modelle nach, um Fehler in klinischen Transkriptionen zu korrigieren und medizinische Terminologie sowie Formatierung präzise zu erfassen.

LangChain Labs trainiert Modelle nachträglich anhand von Agenten-Traces für LangSmith Engine. Dazu gehört auch die Arbeit an einem GitHub-Repository, bei der ein Problem diagnostiziert und ein Prompt oder eine Codeänderung für einen Pull Request entworfen wird. Für die Klassifizierung von Traces nach Fehlermodus und Schweregrad oder ihre Zuordnung zu bestehenden Problemen kann auf ein kleineres Modell mit offenen Gewichten umgestellt werden. Der Workflow von LangChain veranschaulicht, wie das Verhalten einer Anwendung zum Trainingsziel wird und Modellgröße sowie Aufgabenspezialisierung passend zur jeweiligen Aufgabe gewählt werden.

Die Kundenberichte dokumentieren die Nutzung bereits vor der Ankündigung der allgemeinen Verfügbarkeit und zeigen den vorgesehenen Infrastrukturkreislauf: Anwendungsdaten werden zu Trainingsdaten, Checkpoints werden ausgewertet und ausgewählte Modelle auf den Produktionseinsatz vorbereitet. Für Infrastrukturteams ist auch die Kostengrenze klar definiert. Unterstützte serverlose Ausführungen vermeiden GPU-Reservierungen und Token-Kosten im Leerlauf, während für einen aktiven Inferenz-Endpunkt weiterhin die GPU abgerechnet wird. Der serverlose Katalog und die Kapazität des Arbeitsbereichs bestimmen, wo die serverlose Option verfügbar ist.