Together AI startet Together Post-Training für benutzerdefinierte Modelle

Together AI hat am 19. Oktober 2026 Together Post-Training gestartet, einen Dienst zur Entwicklung benutzerdefinierter Modelle mithilfe nutzerdefinierter Reinforcement-Learning- und überwachter Feinabstimmungsschleifen. In den ersten sechs Wochen gilt ein Einführungspreis von 9 US-Dollar pro GPU-Stunde B200-Nutzung.

Startmodelle, Preise und früher Zugang

Der Dienst ist darauf ausgelegt, benutzerdefinierte Modelle sowohl anhand von Belohnungen aus der Umgebung mittels RL als auch anhand von Überwachungsdaten mittels SFT zu entwickeln. Kunden legen die Trainingsschleife fest, einschließlich Daten, Umgebungen und agentischer Ausführungsumgebungen, und können Schritte wie Protokollierung oder externes Benchmarking hinzufügen. Together optimiert gleichzeitig die zugrunde liegenden Systeme und die Infrastruktur, um die Modellqualität und die Trainingsgeschwindigkeit zu verbessern. Together erklärte, den Dienst entwickelt zu haben, weil die RL-Infrastruktur immer komplexer wird und viele Unternehmen, die von Post-Training profitieren könnten, gar nicht erst damit beginnen oder aufgrund der Infrastrukturlast nicht über den Anfang hinauskommen.

Zum Start umfasst der Dienst die Open-Weight-Modelle Muse Spark Open, GLM 5.3, Kimi K3 und Qwen 3.8-27B. Together erklärte, die Auswahl in den kommenden Wochen um Spitzenmodelle großer Sprachmodelle (LLMs) und effiziente kleinere Modelle erweitern zu wollen. In den ersten sechs Wochen wird der Dienst zum reduzierten Preis von 9 US-Dollar pro GPU-Stunde B200-Nutzung angeboten.

Vor dem Start gewährte Together in den vergangenen Monaten einer ausgewählten Gruppe von Organisationen frühzeitigen Zugang. Adit Jain, Forscher bei Collinear AI, sagte, sein Team arbeite seit dem Start der Post-Training-Betaversion im April 2026 mit dem Unternehmen zusammen.

Dedizierte Modellressourcen und Abrechnung pro GPU-Minute

Alle Experimente laufen auf sogenannten Modellressourcen von Together: GPU-Kapazitäten, die einem einzelnen Kunden dediziert zugewiesen werden, sodass keine Konkurrenz durch Prioritätsanfragen anderer Nutzer entsteht. Jede Modellressource kann eine oder mehrere Trainingssitzungen umfassen. Jede Sitzung entspricht einem einzelnen Experiment mit demselben Basismodell, beispielsweise mit einem Satz von LoRA-Adaptern. Together erklärte, dass die dedizierten Zuweisungen auch eine Feinabstimmung aller Modellgewichte über LoRA hinaus ermöglichen, wenn Modelle an umfangreiche, wissensintensive Aufgaben angepasst werden.

Jede Sitzung umfasst eine Trainer-Instanz, die für Vorwärts- und Rückwärtsdurchläufe sowie Gewichtsaktualisierungen zuständig ist, und Generator-Instanzen, die Rollouts anhand der Policy ausführen. Bei überwachter Feinabstimmung kann eine Modellressource mit null Generatoren gestartet werden, um Kosten zu sparen. Nutzer entscheiden, wann die Parameter des Trainers an den Generator übertragen werden. Asynchrones RL wird unterstützt, um beide Komponenten möglichst stark auszulasten, insbesondere bei langen agentischen Rollouts.

Nutzer können LoRA-Training durchführen, darunter auch mit mehreren LoRA-Adaptern, die sich dieselbe GPU-Kapazität teilen, sowie Vollgewichts-Experimente für ausgewählte Modelle. Der Dienst unterstützt gängige Verlustfunktionen wie Cross-Entropy, GRPO, CISPO und DPPO. Nutzer können außerdem lokal ein benutzerdefiniertes Trainingsziel berechnen und dessen Gradienten an den Trainer senden.

Laut der Dokumentation zum Post-Training umfasst die zentrale SDK-Schnittstelle eine create-Methode, die eine Modellressource bereitstellt – die Abrechnungseinheit –, sowie eine create_session-Methode, die dieser eine Trainingssitzung zuordnet. Darauf folgen Aufrufe für einzelne Schritte: sample_batch erzeugt zu bewertende Vervollständigungen, forward_backward berechnet den Verlust und propagiert Gradienten rückwärts, optim_step aktualisiert die Gewichte und weights_sync überträgt neue Gewichte an die Generator-Replikate. Bei SFT und DPO entfallen sample_batch und weights_sync, da dabei keine Vervollständigungen generiert werden.

Modellressourcen werden pro GPU-Minute abgerechnet. Together erklärte, dass die gesamten Trainingskosten im Vergleich zu einer tokenbasierten Abrechnung sinken, sobald Experimente einen größeren Umfang erreichen. In der Dokumentation wird das Modell dem Standard-Feinabstimmungsdienst des Unternehmens gegenübergestellt: Dieser rechnet pro verarbeitetem Token ab und läuft als Auftrag bis zum Abschluss, ohne dass während der Ausführung eingegriffen werden kann. Nutzer des Post-Trainings können Kennzahlen für einzelne Schritte einsehen, die Lernrate ändern, Daten neu mischen oder einen Lauf nach eigenen Kriterien stoppen.

Trainingsstabilität und der Weg zur Bereitstellung

Together erklärte, der Dienst beseitige zahlreiche Ursachen für Policy-Drift zwischen Trainings- und Inferenz-Engines. Geringfügige numerische Abweichungen trotz identischer Gewichte können dazu führen, dass ein RL-Lauf schlechter abschneidet oder zusammenbricht. Dafür kommen Standardtechniken wie Rollout Routing Replay sowie Optimierungen aus der Forschung des Unternehmens zur Trainingsstabilität zum Einsatz. Laut Together nutzen die Rollout-Engines dieselben Optimierungen wie der Serving-Stack des Unternehmens. Intelligentes Caching und Routing für Agenten mit mehreren Gesprächsrunden sowie optimierte Parallelisierung und Sequenzpackung beschleunigen sowohl SFT- als auch RL-Schritte.

Nach dem Training unterstützt das Unternehmen jetzt die Bereitstellung von Multi-LoRA-Adaptern mit Dedicated Model Inference. So können Nutzer Adapter innerhalb einer einzelnen GPU-Bereitstellung austauschen, anstatt für jeden Lauf eine separate Produktionsbereitstellung aufzusetzen. Together erklärte, jeder Trainingsprüfpunkt behalte seine Qualität beim Serving auch nach dem Wechsel vom Multi-LoRA-Sampling zur zusammengeführten Inferenz mit FP4-Präzision bei.

Die Dokumentation beschreibt einen Arbeitsablauf aus Training, Evaluierung und Produktivsetzung: Zunächst werden mehrere Adapter auf einem eingefrorenen Basismodell trainiert. Dann werden die Kandidaten in eine einzelne Multi-LoRA-Bereitstellung eingebunden und verglichen, indem in jeder Anfrage ein anderer Adapter angegeben wird. Anschließend wird der beste Adapter im zusammengeführten Modus in einer eigenen Bereitstellung eingesetzt. Für GLM-5.3 und Kimi-K3 müssen Adapter vor der FP4-Inferenz zunächst einen Vorbereitungsschritt durchlaufen.

Onboarding, Migration von Tinker und erste Nutzer

Für den Einstieg werden das neueste Together SDK und die Dokumentation benötigt. Together hat auf GitHub in einem Repository namens post-training-cookbook Kochbücher veröffentlicht, die GRPO-Training auf dem GSM8K-Benchmark, DPO mit einer benutzerdefinierten Loss-Funktion und das Training mehrerer LoRA-Adapter innerhalb derselben Modellressource abdecken. Die Dokumentation beschreibt das Kochbuch als Python-Bibliothek mit vorgefertigten Schleifen, deren Notebooks anhand der asynchronen Aufrufe des SDK durch GRPO, SFT und das Training mehrerer Adapter auf einer Modellressource führen. Für Teams mit einem bestehenden Setup über die Tinker-API ersetzt ein Migrationspfad eine Importzeile durch import together.post_training.tinker as tinker, wie in einem Migrationsleitfaden ausführlich beschrieben.

Anthony Li, stellvertretender Leiter für Data Science bei Deel, sagte, die Kontrolle und Flexibilität der Plattform hätten es seinem Team ermöglicht, innerhalb weniger Stunden mit echten RL-Experimenten zu beginnen und bis zu fünf RL-Experimente gleichzeitig auf derselben GPU-Kapazität durchzuführen. Oliver Normand, Gründungsingenieur bei Jack & Jill, sagte, sein Team habe ein Modell nachtrainiert, das vorhersagt, welche Kandidaten ein Personalverantwortlicher treffen möchte – ein zentraler Schritt bei der Suche, die der Recruiting-Agent Jill des Unternehmens durchführt. Bei Offline-Evaluierungen habe das Team mit einem Open-Source-Modell die Qualität eines Closed-Source-Modells erreicht, das sich deutlich kostengünstiger betreiben lasse. Außerdem hätten die in die Kundenteams eingebundenen Ingenieure von Together die Skripte geschrieben, mit denen das Team seine ersten Ergebnisse erzielte.

Jain von Collinear AI sagte, das nahtlose Self-Onboarding habe den Start umfassender agentischer RL-Läufe erleichtert. Die in die Kundenteams eingebundenen Ingenieure von Together arbeiten während des gesamten Post-Training-Prozesses eng mit den Kunden zusammen – von der Auswahl eines Open-Source-Modells und eines Agenten-Harness über Daten und Trainingsumgebungen bis hin zu Evaluierungen und der Bereitstellung eines optimierten Endpunkts.