Asynchrones RL-Training: Wie GPUs besser ausgelastet werden
đź’ˇ Quellen-Hinweis: Dieser Beitrag ist eine redaktionelle Zusammenfassung basierend auf einem Originalbericht von Hugging Face Blog.
Beim Reinforcement Learning für Reasoning-Modelle ist häufig nicht das Training, sondern die Erzeugung langer Antworten der Zeitfresser. Ein Vergleich von 16 Open-Source-Bibliotheken zeigt, dass sich die meisten Projekte deshalb auf dieselbe Architektur zubewegen: Inferenz und Training laufen auf getrennten GPU-Pools, verbunden durch einen Rollout-Puffer und asynchron übertragene Modellgewichte.
Warum synchrone Abläufe GPUs ausbremsen
In einem klassischen RL-Schritt werden Prompts gewählt, mehrere Antworten erzeugt, Belohnungen berechnet und erst danach Gewichte aktualisiert. Reasoning-Ausgaben können jedoch Zehntausende Token lang sein. Bei GRPO wartet zusätzlich eine ganze Gruppe auf ihre langsamste Antwort. Der Beitrag rechnet vor, dass ein Batch mit 512 Rollouts und jeweils 32.000 Token bei einem 32B-Modell auf einer H100 mehrere Stunden beanspruchen kann. Währenddessen bleiben Trainings-GPUs weitgehend ungenutzt.
Eine getrennte Architektur lässt den Inferenz-Pool kontinuierlich neue Rollouts produzieren, während der Trainings-Pool bereits ältere Daten verarbeitet. Ein Rollout Buffer entkoppelt beide Geschwindigkeiten. Das erhöht die Auslastung, benötigt aber zusätzliche Hardware und erzeugt neue Fragen: Wie alt dürfen Trainingsbeispiele sein, wann werden Gewichte synchronisiert und wie behandelt man teilweise abgeschlossene Agentenläufe?
Gemeinsame Muster und offene Unterschiede
In acht der untersuchten Projekte übernimmt Ray die Orchestrierung. Für den Gewichtstransfer ist NCCL Broadcast verbreitet. Beim Umgang mit veralteten Rollouts reicht das Spektrum vom einfachen Verwerfen bis zu Importance-Sampling-Korrekturen. Besonders bei agentischen Aufgaben sind partielle Rollouts wichtig, weil Werkzeugaufrufe und Umgebungen sehr unterschiedliche Laufzeiten haben. Unterstützung für LoRA ist laut Analyse noch selten, während verteilte Mixture-of-Experts-Modelle zum neuen Differenzierungsmerkmal werden.
Colocation von Inferenz und Training auf denselben GPUs spart zwar Geräte, ermöglicht aber keine echte zeitliche Überlappung. Disaggregation erhöht den Durchsatz, bringt dafür Netzwerkverkehr, Queue-Management und potenziell veraltete Daten mit sich. Ein guter Aufbau braucht daher begrenzte Puffer, Versionsangaben pro Rollout und klare Regeln für maximal zulässige Staleness.
Einordnung fĂĽr KI-Teams
Die Untersuchung macht deutlich, dass skalierbares RL zunehmend eine Infrastrukturaufgabe ist. Mehr GPUs allein lösen das Problem nicht, wenn Generation, Training und Gewichtssynchronisation aufeinander warten. Für kleinere Experimente bleibt ein synchroner, gemeinsam genutzter Aufbau oft wirtschaftlicher. Bei langen Reasoning- oder Agenten-Trajektorien kann eine asynchrone Pipeline dagegen die teure Hardware wesentlich besser nutzen. Entscheidend sind Messwerte aus dem eigenen Workload, denn zusätzliche Komplexität lohnt sich erst, wenn Leerlauf und Straggler tatsächlich dominieren.
Originalquelle: Hugging Face Blog – Keep the Tokens Flowing: Lessons from 16 Open-Source RL Libraries
