SemiAnalysis: Effizienz beim Reinforcement-Learning-Training hängt vom Durchsatz ab, nicht nur von der Skalierung der Rechenleistung
Experimente mit Open-Source-RL-Frameworks offenbaren den kritischen Engpass bei der Skalierung von Modellfähigkeiten – 16. Juni 2026
Reinforcement Learning (RL) im Post-Training hat sich als das "Geheimrezept" hinter den leistungsfähigsten KI-Modellen etabliert, doch die Skalierung von RL ist enorm kostspielig. SemiAnalysis hat umfangreiche Experimente mit Open-Source-RL-Frameworks durchgeführt, um zu verstehen, was die Effizienz beim RL-Training tatsächlich bestimmt. Die überraschende Antwort: Es geht nicht darum, einfach mehr Rechenleistung bereitzustellen, sondern den Durchsatz zwischen zwei Schlüsselkomponenten präzise aufeinander abzustimmen – dem Generator, der Trainingsdaten erstellt, und dem Trainer, der daraus lernt.
Das Forschungsteam führte Experimente mit Modellen wie Qwen3-235B und GLM-5 über verschiedene RL-Frameworks hinweg durch, darunter Prime RL, slime und verl. Die Ergebnisse stellen die konventionelle Sichtweise auf die Infrastruktur von RL grundlegend infrage.
Das Warteschlangen-Problem, über das niemand spricht
SemiAnalysis beschreibt die Effizienz von RL-Training anhand eines anschaulichen Modells: eine Warteschlange, in der der Generator Rollouts produziert und der Trainer diese konsumiert. Ist der Generator zu langsam, hungert der Trainer und bleibt im Leerlauf. Ist der Generator zu schnell, altern die Samples in der Warteschlange, was zu einer sogenannten "Policy Staleness" führt – einem Phänomen, bei dem das Modell auf Ausgaben älterer Versionen seiner selbst trainiert, was die Lernqualität verschlechtert.
In ihrem ersten großen Experiment mit Qwen3-235B-Thinking auf 64 H200-GPUs für das Training und 192 GPUs für die Generierung war das System stark durch die Generierung limitiert. Der Trainer verarbeitete zwar 2,75 Samples pro Sekunde, wartete jedoch 30 % der Zeit und erreichte nur 10,5 % der Modell-FLOPs-Auslastung. Der Generator lieferte lediglich 1,95 Samples pro Sekunde, obwohl er dreimal so viel Rechenleistung wie der Trainer beanspruchte. Der Grund: Das Modell produzierte extrem lange Antworten mit ausführlichen Reasoning-Sequenzen; die Varianz in der Antwortlänge führte zu massiven Problemen bei der Tail-Latency.
Um dies zu bewältigen, musste das Team 60 % der versendeten Rollouts verwerfen – eine Technik namens Oversampling, bei der mehr parallele Rollouts gestartet werden, als benötigt werden, um unfertige Prozesse abzubrechen. Dieser verschwenderische Ansatz unterstreicht, wie entscheidend die Inferenz-Effizienz während des RL-Trainings ist – ein Punkt, der in aktuellen Diskussionen über RL-Infrastruktur offenbar unterschätzt wird.
Modell-Drift schafft bewegliche Ziele
Ein zweites Experiment mit GLM-5 auf 128 H200-GPUs offenbarte eine weitere Dimension des Problems, die das Design von RL-Systemen besonders herausfordernd macht: Das Verhalten des Modells ändert sich während des Trainings so, dass sich die Systembeschränkungen verschieben. Im Verlauf des Trainings verdreifachten sich die durchschnittliche Antwortlänge pro Turn und die Anzahl der Tool-Calls von 20 auf 51. Dies erhöhte die Sequenzlängen und verschob die Arbeitslast hin zu einem Prefill-lastigen Profil, was die optimale Infrastrukturkonfiguration mitten im Training grundlegend veränderte.
Erschwerend kam hinzu, dass das Curriculum für das Modell zu einfach war: 55 % der Aufgaben hatten eine Lösungsquote von 100 %, bei der jedes Rollout in der Gruppe erfolgreich war. Wenn jedes Rollout die gleiche Belohnung erhält, ergibt die Advantage-Berechnung Null und die Gruppe liefert kein Trainingssignal. Wie SemiAnalysis erläutert, passiert dies, wenn "die Lösungsquote nahe 100 % oder nahe 0 % liegt" – die Aufgabe ist entweder zu leicht oder zu schwer. Die durchschnittliche Belohnung stagnierte trotz des hohen Rechenaufwands.
Die kombinierten Effekte führten zu einem stark durch die Generierung limitierten System, in dem der Trainer 74 % der Zeit im Leerlauf verbrachte und seine Verbrauchsrate fünfmal so hoch war wie die effektive Produktionsrate des Generators. Die tatsächliche Produktionsrate des Generators brach aufgrund der gefilterten Samples, die kein Lernsignal lieferten, ein.
Die Skalierungsmauer bei Sandboxes
Ein drittes Experiment auf GB300-Hardware erhöhte die Anzahl der gleichzeitigen Rollouts von 96 auf 960 und stieß auf eine harte infrastrukturelle Grenze, die selten diskutiert wird: die Sandbox-Skalierung. Jedes Rollout erfordert mindestens eine containerisierte Sandbox, um Code auszuführen und Belohnungen bereitzustellen. Bei 960 gleichzeitigen Rollouts stieß das Team auf "Sandbox-Initialisierungsfehler und Latenzzeiten von einer Stunde beim Start der Sandbox". Sie mussten auf 96 gleichzeitige Rollouts zurückgehen, beobachteten dann jedoch eine geringe Rollout-Effizienz.
Dies offenbart eine fundamentale Einschränkung beim RL-Training für Coding-Assistenten, die SemiAnalysis heute auf über 30 Milliarden US-Dollar an jährlich wiederkehrenden Umsätzen bei sechs großen Akteuren schätzt – mit Tendenz zu über 100 Milliarden US-Dollar bis Jahresende. Die Sandbox-Infrastruktur muss linear mit den gleichzeitigen Rollouts skalieren. Sandbox-Dienstleister wie Modal stehen vor einzigartigen Herausforderungen wie Start-Latenz, schwankender Nachfrage und Robustheit gegenüber unerwartetem Modellverhalten, etwa dem Erstellen von Millionen von Dateien, die den Arbeitsspeicher erschöpfen.
Policy Staleness: Die versteckte Steuer des asynchronen Trainings
Klassische Policy-Gradient-Algorithmen setzen voraus, dass alle Rollouts in einer Gruppe von denselben Modellgewichten stammen. Dies erzwingt eine synchrone Ausführung, bei der der Generator keine Gewichte aktualisieren kann, bis der aktuelle Batch abgeschlossen ist, was zu massiver Ineffizienz führt. Die Branche ist zu asynchronen Techniken übergegangen, insbesondere PipelineRL, das Gewichtsaktualisierungen während der laufenden Generierung von Rollouts ermöglicht.
Dies führt jedoch zu Policy Staleness – Samples werden durch eine Mischung aus alten und neuen Policies generiert. SemiAnalysis identifiziert drei Ebenen der Staleness: Trajektorien-Ebene (Abstand zwischen der Policy-Version zu Beginn des Rollouts und der aktuellen Version), Token-Ebene (Gewichtsaktualisierungen während des Rollouts, sodass verschiedene Token von unterschiedlichen Policy-Versionen stammen) und Umgebungszustands-Ebene (besonders relevant für zustandsbehaftete Umgebungen).
Das Framework slime implementiert eine "Partial Rollout"-Funktion, die verzögerte Rollouts in einem Puffer speichert und in späteren Batches neu startet, um die Tail-Latency zu mildern. Dies führt jedoch eine besonders tückische Staleness auf Umgebungszustands-Ebene ein. Wie das Team erklärt: "Die Sandbox, in der es aufwacht, ist kein frisches Repository. Die Sandbox enthält die halb angewendeten Änderungen, erstellten Dateien und den Arbeitsverzeichnisstatus, den die alte Policy in ihren früheren Turns produziert hat. Die neuere Policy muss nun in einer Situation weitermachen, die sie nicht selbst geschaffen hat und die sie so vielleicht gar nicht erzeugt hätte." Dies korrumpiert das Trainingssignal während der Advantage-Attribution.
Die Ökonomie erzählt eine brutale Geschichte
SemiAnalysis führte eine Analyse der Gesamtbetriebskosten (TCO) durch und verglich ihre Experimente mit Tinker von Thinking Machines Lab, einer verwalteten RL-Trainingsplattform. Für H200-Infrastruktur berechnen sie 1,59 $ pro GPU-Stunde an Gesamtkosten, wobei die Kapitalkosten 72,5 % ausmachen. Die Serverkosten bleiben mit 258.000 $ pro Server der dominierende Faktor, was 71 % der gesamten Investitionskosten (Capex) von 361.000 $ pro Server entspricht.
Bei ihrem Qwen3-235B-Experiment mit slime landeten sie bei 16,23 $ pro Million Token – 4,86-mal höher als das von Tinker veröffentlichte Ziel von 4,86 $ pro Million Token. Bei Prime RL verringerte sich die Lücke auf das 2,01-fache bei 6,90 $ pro Million Token gegenüber Tinkers Ziel von 3,43 $. Der deutliche Unterschied zwischen den Kosten von slime und Prime RL unterstreicht, wie stark die Inferenz-Effizienz die Gesamtkosten bestimmt.
SemiAnalysis vermutet, dass Tinker seinen Kostenvorteil primär durch Multi-Tenancy erreicht. Tinker bietet eine API für das Training mittels Low-Rank Adaptation (LoRA), bei der sich mehrere Nutzer Modelle teilen, die den Großteil der Gewichte gemeinsam nutzen. "Auf der Trainer-Seite kann Tinker die Effizienz durch das Batching von Trainingsanfragen über Nutzer hinweg mit einigen LoRA-spezifischen Modifikationen erheblich steigern. Auf der Generierungsseite mildert Multi-Tenancy den Effekt verzögerter Rollouts, indem freie Slots mit Rollouts anderer Mieter aufgefüllt werden, wenn ein Lauf ins Stocken gerät."
Das Team geht davon aus, dass Thinking Machines Lab auch Inferenz-Optimierungen wie die Trennung von Prefill und Decode anwendet und möglicherweise Blackwell-GPUs einsetzt, die laut ihrer InferenceX-Analyse erhebliche Inferenz-Gewinne gegenüber Hopper bieten. Der Multi-Tenancy-Vorteil potenziert sich mit Infrastruktur- und Hardware-Verbesserungen und führt zu dieser dramatischen Kostenlücke.
Anthropics Wette auf RL-Skalierung
Der Bericht liefert wichtigen Kontext dafür, warum dies von Bedeutung ist. Anthropic-CEO Dario Amodei hat RL als ein Verfahren beschrieben, das "dieselbe Art von Skalierung zeigt wie einst das Pre-Training, bei dem die Leistung log-linear mit der Trainingsdauer steigt." Doch diese Skalierung ist enorm teuer, was die Effizienz von RL-Systemen entscheidend dafür macht, wie viel RL man sich leisten kann und wie weit die Fähigkeiten der Modelle somit voranschreiten können.
Konkret erreicht Claude Opus 4.8 69,2 % bei SWE-bench Pro und 74,6 % bei Terminal-Bench 2.1, wobei das RL-Training als "ein wesentlicher Teil dessen, was den Score treibt", beschrieben wird. Diese agentischen Coding-Fähigkeiten entstehen nicht allein durch Pre-Training – sie erfordern umfangreiches und teures Post-Training durch Reinforcement Learning.
Die Open-Source-Community hat bemerkenswerte Fortschritte gemacht. SemiAnalysis zeichnet die Entwicklung von OpenRLHF, einer der frühen Bemühungen nach der Veröffentlichung von DeepSeek R1, bis hin zu populären Frameworks wie slime und verl nach. Zahlreiche OpenRLHF-Maintainer entwickelten später diese Frameworks und schufen lebendige chinesische Communities rund um das RL-Training, die laut dem Team "positiv zu den jüngsten Fortschritten chinesischer Modelle beigetragen haben". Die Frameworks haben es auch akademischen Forschern ermöglicht, neue Algorithmen und Techniken zu entwickeln, wodurch RL-Forschung für die Wissenschaft zugänglich wurde.
Die User Experience der Frameworks zählt mehr als erwartet
Das Team gibt eine ehrliche Einschätzung der getesteten Frameworks ab. Prime RL wird für die Benutzerergonomie gelobt – die meisten Befehle funktionieren über uv mit Konfiguration in toml-Dateien, ergänzt durch Agent-Skill-Dateien für eine reibungslosere KI-Agenten-Integration. Der Hub für RL-Umgebungen und die Unterstützung für die Trennung von Prefill und Decode stechen als Stärken hervor. Die starke Abhängigkeit von uv führte jedoch zu Reibungsverlusten; das Team verbrachte viel Zeit damit, "Flash Attention 3 zu kompilieren und neu zu installieren, weil wir nicht herausfinden konnten, warum uv es deinstalliert hat."
Prime Sandbox, noch in der Beta, produzierte viele fehlgeschlagene Läufe gegen Ende der Ausführung. "Zu den Fehlern gehören hängende Sandboxes, die das Sandbox-Kontingent aufbrauchen, sowie Ressourcen- und Guthabenprobleme, von denen viele vor dem Start eines Laufs hätten erkannt werden können."
Slime wird für "saubere und minimale Abstraktionen" gelobt, insbesondere für die Hook-Abstraktionen, die Anpassungen unkompliziert machen. Das Entwicklungsteam erhält Bestnoten für seine Reaktionsfähigkeit. Die Hauptkritik: Der Fokus auf den Co-located-Modus führte zu einer spärlichen Dokumentation der asynchronen Modi, was das Team zwang, die Mechanismen "größtenteils durch Ausprobieren" zu verstehen.
Die Sandbox-API von Modal wird für die Qualität der Dokumentation und die Robustheit des Dienstes im kleinen Maßstab gelobt. Bei hoher Parallelität traten jedoch Herausforderungen mit Initialisierungsfehlern und langen Start-Latenzen auf. Dies stellte sich als Ressourcenbeschränkung des Accounts heraus, nicht als harte Plattform-Limits – Modal erhöhte die Limits und das Team bestätigte die Stabilität bei hoher Parallelität. Dennoch unterstreicht die Erfahrung die Notwendigkeit besserer Observability-Tools für Sandboxes und eine bessere Skalierungsdokumentation.
Die schonungslose Ehrlichkeit über die Schwachstellen der Open-Source-Tools steht im Kontrast zum typischen Marketing der Anbieter, dient aber dem institutionellen Publikum, das die realen Implementierungsherausforderungen verstehen muss, bevor es Kapital in RL-Trainingsinfrastruktur investiert.