TRL 1.0: Hugging Face liefert Async GRPO, VESPO und DPPO für LLM-Training

Hugging Faces Reinforcement-Learning-Bibliothek TRL hat am 31. März 2026 ihr erstes Major-Release erhalten. Version 1.0 bringt neue Trainer-Varianten und Loss-Funktionen, 35 Prozent schnelleres Sequence-Packing und eine überarbeitete vLLM-Integration. Der entscheidende Punkt für alle, die heute mit GRPO trainieren: Asynchronous GRPO entkoppelt die Rollout-Generierung vom Gradient-Update-Loop — das bedeutet weniger GPU-Idle-Time und damit direkt niedrigere Rechenkosten pro Trainingsschritt.

TRL ist seit mehreren Jahren das Standardwerkzeug im Hugging-Face-Ökosystem für Policy-Optimierung mit Methoden wie PPO, DPO und GRPO. Mit 17.900 GitHub-Stars und über 2.600 Forks ist die Bibliothek de facto der meistgenutzte Einstiegspunkt für RLHF-Workflows auf Open-Source-Modellen. Das 1.0-Release signalisiert API-Stabilität — was für Produktionseinsätze relevant ist, weil Breaking Changes künftig anders kommuniziert werden müssen. Ein MIGRATION.md deckt alle Breaking Changes ab; wer bereits auf v0.29 ist, hat laut Maintainer kaum Anpassungsbedarf.

Asynchronous GRPO: Wo die GPU-Zeit bleibt

Das teuerste Problem im Standard-GRPO-Training ist einfach zu beschreiben: Während das Modell Rollouts generiert, wartet der Gradienten-Update-Schritt. Und während der Gradient-Update läuft, steht die Generierung still. Dieser synchrone Engpass kostet je nach Modellgröße und Batch-Konfiguration messbar GPU-Stunden.

Asynchronous GRPO löst das, indem Rollouts auf einen externen vLLM-Server ausgelagert werden. Generierung und Training laufen jetzt parallel — der Trainer zieht fertige Rollouts aus dem Server, während der nächste Batch bereits generiert wird. Die Implementierung ist als trl.experimental.async_grpo.AsyncGRPOTrainer verfügbar und benötigt nur wenige Zeilen:

from trl.experimental.async_grpo import AsyncGRPOTrainer
from trl.rewards import accuracy_reward
from datasets import load_dataset

dataset = load_dataset("trl-lib/DeepMath-103K", split="train")

trainer = AsyncGRPOTrainer(
    model="Qwen/Qwen2.5-0.5B-Instruct",
    reward_funcs=accuracy_reward,
    train_dataset=dataset,
)
trainer.train()

Der Default für vllm_mode wurde in v1.0 auf "colocate" gesetzt, was für die meisten Single-Node-Setups ohne zusätzliche Konfiguration funktioniert. Wer einen separaten vLLM-Server betreibt, setzt vllm_mode="server" explizit. Wichtig: Der AsyncGRPOTrainer liegt im experimental-Namespace — die API kann sich noch ändern.

VESPO und DPPO: Stabilere Gradienten durch bessere Mathematik

GRPO hat ein bekanntes Stabilitätsproblem: Token-Level-Clipping und Sequence-Length-Normalisierung sind Heuristiken, die in Off-Policy-Szenarien mit veralteten Rollouts fragil werden. TRL 1.0 bringt zwei alternative Loss-Formulierungen, die das mathematisch sauberer lösen.

VESPO (Variational Sequence-Level Soft Policy Optimization) leitet eine asymmetrische Gamma-Gewichtungsfunktion aus einem Variationsrahmen ab. Das Ergebnis: Extreme Sequence-Level-Importance-Weights werden gedämpft, ohne Length-Bias einzuführen. In der Praxis bedeutet das glattere Trainingskurven bei Off-Policy-Setups. Der Einstieg kostet eine einzige Konfigurationszeile als Parameter des stabilen GRPOTrainers:

from trl import GRPOConfig, GRPOTrainer

trainer = GRPOTrainer(
    model="Qwen/Qwen3-0.6B",
    args=GRPOConfig(loss_type="vespo"),
    ...
)

DPPO (Divergence Proximal Policy Optimization) ersetzt den PPO-Clipping-Mechanismus durch Divergenz-Constraints für prinzipiertere Trust-Region-Updates. DPPO ist als separater experimenteller Trainer verfügbar. Wer aktuell mit Standard-GRPO Instabilitäten bei längeren Sequenzen oder asynchronen Updates beobachtet, sollte VESPO als erste Testvariante ausprobieren — der Wechsel ist durch den loss_type-Parameter ohne Code-Änderungen möglich.

SDPO und GKD-Buffer: Selbstdistillation ohne externen Teacher

SDPO (Self-Distillation Policy Optimization) geht einen anderen Weg: Statt eines externen Teacher-Modells nutzt SDPO die eigenen High-Reward-Trajektorien des Modells als Destillationsquelle. Das Modell konditioniert sich auf Feedback und destilliert diese informierten Vorhersagen zurück in die Policy.

from trl.experimental import SDPOTrainer, SDPOConfig

config = SDPOConfig(
    output_dir="./results",
    num_generations=8,
    success_reward_threshold=1.0,
    use_successful_as_teacher=True,
)

trainer = SDPOTrainer(
    model="Qwen/Qwen2.5-Math-1.5B-Instruct",
    reward_funcs=[accuracy_reward],
    args=config,
    train_dataset=dataset,
)
trainer.train()

Der GKD/GOLD-Trainer erhält ebenfalls ein relevantes Update: Ein Buffer entkoppelt Rollout-Generierung von Gradient-Updates — dasselbe Prinzip wie beim Async-GRPO, aber für Distillations-Workflows. Zusätzlich wurde vLLM-Inference für den Base-Self-Distillation-Trainer ergänzt, was die Throughput-Engpässe beim Rollout-Sampling beseitigt.

35% schnelleres Packing und Reward-Logging

BFD-Packing ist in v1.0 um 35 Prozent schneller — laut Release-Notes durch algorithmische Optimierungen im Packing-Algorithmus. Wer die "bfd-requeue"-Strategie nutzt, muss sie auf "bfd_split" umbenennen; das ist der einzige Breaking Change, der die meisten Nutzer betrifft.

Praktisch nützlich für jeden, der Debugging-Zeit in Trainingsläufen sparen will: Reward-Funktionen können jetzt Extra-Metriken direkt loggen, ohne Custom-Callbacks zu schreiben. Die Funktion nimmt log_extra- und log_metric-Callbacks entgegen und schreibt Zwischensignale — etwa extrahierte Antworten oder Accuracy-Werte — direkt ins Training-Log:

def my_reward_fn(completions, answer, log_extra=None, log_metric=None, **kwargs):
    extracted = [extract_answer(c) for c in completions]
    rewards = [1.0 if e == a else 0.0 for e, a in zip(extracted, answer)]

    if log_extra:
        log_extra("golden_answer", list(answer))
        log_extra("extracted_answer", extracted)

    if log_metric:
        log_metric("accuracy", sum(rewards) / len(rewards))

    return rewards

Ebenfalls neu: VLLMClient.chat() unterstützt jetzt Tool-Calling — relevant für alle, die agentische Trainingsworkflows mit Werkzeugnutzung aufbauen. Der Fix für den Re-Tokenisierungs-Bug im Tool-Calling-Loop war schon länger überfällig und ist jetzt ebenfalls enthalten.

So what? GPU-Kosten und Trainingszeit konkret einsparen

Die Frage ist, welches Feature sich wann lohnt. Für Teams, die GRPO-Training bereits produktiv nutzen und ihre GPU-Auslastung optimieren wollen, ist Async GRPO der direkte Hebel. Der Bottleneck "Generierung blockiert Training" ist bei Modellen ab 7 Milliarden Parametern signifikant — konkrete Speedup-Zahlen nennt das Release noch nicht, aber das Entkopplungsprinzip ist strukturell sound. Wer auf einem einzigen Node mit vLLM arbeitet, profitiert ab sofort durch den neuen Colocate-Default, ohne seine Infrastruktur ändern zu müssen.

VESPO ist der risikoärmste Upgrade-Pfad für alle, die Trainingsinstabilitäten bei Off-Policy-Setups beobachten. Ein einzelner Parameter-Wechsel (loss_type="vespo") reicht für den Test — der Rollback ist genauso schnell erledigt. DPPO ist interessant für alle, die PPO-basierte Workflows betreiben und mit dem Clipping-Mechanismus kämpfen, bleibt aber noch im experimentellen Status.

Das 35-Prozent-schnellere BFD-Packing ist ein kostenloser Gewinn für alle SFT-Workflows — kein Code zu ändern außer dem Strategienamen. Bei großen Datasets mit vielen kurzen Sequenzen summiert sich das auf messbar weniger Preprocessing-Zeit pro Trainingslauf. Wer täglich mehrere Trainingsjobs startet, rechnet das schnell durch: Bei einer Stunde Preprocessing-Overhead pro Job und 35 Prozent Ersparnis sind das 21 Minuten pro Lauf — bei 50 Jobs im Monat über sieben Stunden GPU-Zeit.

Fazit: Wer jetzt upgraden sollte

TRL 1.0 ist kein Pflicht-Upgrade für alle, aber ein klares Signal für drei Gruppen. Erstens: Wer heute GRPO mit vLLM betreibt und seine GPU-Auslastung verbessern will, sollte Async GRPO testen — der Einstieg ist wie oben gezeigt minimal. Zweitens: Wer mit Trainingsinstabilitäten bei Off-Policy-Rollouts kämpft, probiert VESPO über den loss_type-Parameter ohne weiteren Overhead. Drittens: Alle, die BFD-Packing mit der "bfd-requeue"-Strategie nutzen, müssen sowieso den Strategienamen anpassen — und bekommen dabei die 35-Prozent-Verbesserung gratis.

Wer von v0.29 kommt, hat laut Maintainern minimalen Anpassungsbedarf. Das MIGRATION.md listet alle Breaking Changes vollständig auf. Den offiziellen Überblick zum Release liefert der Hugging-Face-Blogpost zu TRL v1. Wer noch auf älteren Versionen ist und sich fragt, ob der Sprung zu v1.0 sich lohnt: Die API-Stabilität allein ist ein Argument, denn ab jetzt kommunizieren die Maintainer Breaking Changes explizit — das ist für Produktionseinsätze wertvoller als jedes einzelne Feature.