AReaL: asynchrones RL-Training für LLM-Agenten, ohne den Agenten umzubauen
The RL Bridge for LLM-based Agent Applications. Made Simple & Flexible.
Auf einen Blick
- Was ist das?
- AReaL ist eine RL-Infrastruktur aus der Forschung von Tsinghua IIIS und Ant Group, die vortrainierte Modelle über einen austauschbaren base_url an bestehende Agenten-Runtimes anbindet. Der Reiz liegt im asynchronen Trainingsloop, die Kosten liegen in der verteilten Microservice-Architektur ab Version 2.0.
- Für wen ist es gedacht?
- Wer bereits eine Agenten-Runtime betreibt und nur die base_url auf den AReaL-RL-Service umbiegen will, findet hier den kürzesten Weg zu Online-RL-Daten. Wer dagegen einen einzelnen Trainingslauf auf einer einzelnen Maschine plant oder keine verteilte Microservice-Topologie betreiben will, sollte zuerst AReaL-lite prüfen und die Versionsnummern von areal und areal-lite im eigenen Environment abgleichen, bevor irgendetwas installiert wird.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem AReaL löst und für wen es gedacht ist
Viele Teams haben einen funktionierenden Agenten: eine Schleife, die ein Modell aufruft, Werkzeuge ausführt, Ergebnisse zurückfüttert. Was fehlt, ist der Rückkanal ins Modellgewicht. Genau dort setzt AReaL an. Das Projekt beschreibt sich selbst als Brücke zwischen Foundation-Model-Training und agentenbasierten Anwendungen und nennt als Kernziel das Training großer Reasoning- und Agentenmodelle.
Der entscheidende Satz im README ist die Behauptung, dass sich agentisches RL und Online-Training für Black-Box-Agentenanwendungen durch simples Ersetzen der base_url umsetzen lassen. Das grenzt die Zielgruppe scharf ab. Angesprochen sind Teams, die ihren Agenten bereits als eigenständigen Dienst betreiben, ihn aber nicht in eine Trainingsbibliothek hineinportieren wollen. Wer ein Modell von Grund auf mit selbst geschriebener Rollout-Logik trainieren will, braucht diese Brücke nicht.
Die Herkunft ist im README offengelegt: ursprünglich von Forschern und Ingenieuren des Tsinghua IIIS und des AReaL-Teams bei Ant Group entwickelt. Das erklärt den Zuschnitt auf große Modelle und verteilte Ausführung. Es erklärt auch, warum die Beispiele stark auf Mathematik, Coding, Suche und Kundenservice ausgerichtet sind, also auf Aufgaben mit überprüfbarem Ergebnis.
Microservices statt Monolith: die Architektur ab 2.0
Mit Version 2.0 wurde AReaL laut Release Notes in eine Microservice-Architektur umgebaut. Das ist die wichtigste Änderung im gesamten Repository, weil sie die Betriebsanforderungen verschiebt. Statt eines Prozesses, der Rollout und Training verzahnt, gibt es nun vier getrennte Dienste: einen Trainingsdienst, einen Inferenzdienst, einen Agentendienst und einen Dienst für Gewichtsupdates. Die Verzeichnisse im Repository spiegeln das: areal/v2/training_service, areal/v2/inference_service, areal/v2/agent_service und areal/v2/weight_update.
Diese Aufteilung ist die Voraussetzung für das asynchrone Paradigma. Wenn Rollout-Erzeugung und Gradientenberechnung in getrennten Diensten laufen, kann die Inferenz weiterläufige Trajektorien produzieren, während der Trainer auf dem zuletzt veröffentlichten Gewichtsstand rechnet. Der Dienst für Gewichtsupdates ist dabei das Bindeglied: Er transportiert neue Parameterstände vom Training zurück in die Inferenz. Wer schon einmal versucht hat, diesen Rückkanal in einem einzigen Prozess zu bauen, weiß, warum das ausgelagert wurde.
Der Preis ist Betriebsaufwand. Vier Dienste bedeuten vier Fehlerquellen, vier Konfigurationen und die Notwendigkeit, Zustand zwischen ihnen zu synchronisieren. Das README benennt das nicht als Nachteil, aber die Struktur macht es offensichtlich. Für einen einzelnen Forscher mit einer GPU ist das eine schwere Maschine für ein kleines Problem.
KPop und IcePop: Token-Masking als eigentliche Trainingsschraube
Die inhaltlich interessanteste Neuerung ist nicht die Architektur, sondern das, was im Trainingsloop maskiert wird. Im Juni 2026 wurde KPop eingeführt, beschrieben als bidirektionale binäre KL-Divergenz-Token-Maskierung. Konfiguriert wird sie über rejection_sampling.metric=binary_kl. Daneben steht IcePop, eine Maskierung auf Basis des Importance Ratio, mit eigener Beispieldatei examples/math/gsm8k_icepop.yaml.
Beide Verfahren greifen auf derselben Ebene an: Sie entscheiden, welche Token eines Rollouts überhaupt in den Gradienten eingehen. Das ist bei asynchronem Training kein Detail. Wenn die Inferenz mit einem anderen Gewichtsstand läuft als der Trainer, weichen die Wahrscheinlichkeiten der erzeugten Token von denen ab, die das trainierende Modell zuweisen würde. Maskierung ist die Antwort darauf: Token, deren Abweichung zu groß ist, werden verworfen, statt das Update zu verzerren. Die beiden Beispielkonfigurationen gsm8k_kpop.yaml und gsm8k_icepop.yaml sind der schnellste Weg, den Unterschied praktisch zu sehen, weil sie sich dieselbe Aufgabe teilen und nur im Maskierungskriterium unterscheiden.
Was das README nicht liefert, ist eine Anleitung, wann welches Kriterium zu wählen ist. Es nennt die Metrik und die Konfigurationsdateien, mehr nicht. Wer hier auf eine Entscheidungshilfe hofft, wird sie in der Dokumentation suchen müssen.
Installation und der erste Lauf: was tatsächlich im Material steht
Das gekürzte README enthält keine Installationsbefehle. Es verweist für den Einstieg auf die Dokumentationsseite areal-project.github.io/AReaL und für die NPU-Variante auf den Abschnitt installation_npu. Wer eine vollständige Anleitung braucht, muss diesen Weg gehen; aus dem Repository-Ausschnitt lässt sich kein pip- oder uv-Kommando belegen, und ich erfinde hier keines.
Belegbar sind dagegen die Konfigurationsschlüssel. Für Online-RL mit einem bestehenden Agenten ist der Eingriff die base_url: Der Agent zeigt nicht mehr auf den ursprünglichen Modellendpunkt, sondern auf den AReaL-RL-Service. Das OpenClaw-Beispiel unter examples/openclaw beschreibt genau das, base_url und api_key werden ersetzt, der Agentencode bleibt unverändert. Dasselbe Muster nennt das README für agentisches RL allgemein. Für die Token-Maskierung ist der Schlüssel rejection_sampling.metric, belegte Werte sind binary_kl für KPop und die Importance-Ratio-Variante für IcePop.
Für die verteilte Variante kommen die vier Dienstverzeichnisse unter areal/v2 hinzu. Wer AReaL-lite nutzt, arbeitet dagegen mit einer anderen Oberfläche: Das README beschreibt AReaL-lite als algorithm-first-API mit nativem Support für asynchrones agentisches RL und verweist auf den Quickstart unter areal-project.github.io/AReaL/en/tutorial/quickstart.html. Zwei Einstiegspunkte, zwei Dokumentationspfade, und das ist eine reale Stolperstelle beim Lesen von Anleitungen aus verschiedenen Quellen.
Wo AReaL die falsche Wahl ist
Der offensichtlichste Fall: ein einzelner Trainingslauf auf einer Maschine ohne verteilte Infrastruktur. Die Microservice-Aufteilung ab 2.0 setzt voraus, dass Trainings- und Inferenzdienst getrennt laufen können. Wer das nicht betreiben will, zahlt den Aufwand ohne den Nutzen. Das README liefert für diese Gruppe eine eigene Antwort, nämlich AReaL-lite, laut eigener Beschreibung mit 80 Prozent weniger Code bei 90 Prozent der Leistung und Kernfunktionalität. Diese Zahlen stammen aus der Projektbeschreibung und sind nicht unabhängig überprüft; sie sind ein Hinweis auf die Zielsetzung, kein Messergebnis.
Der zweite Fall ist subtiler. Das Versprechen, einen Agenten durch Ersetzen der base_url anzubinden, funktioniert nur, wenn der Agent seinen Modellzugriff tatsächlich über eine konfigurierbare URL abwickelt. Ein Agent, der einen SDK-Client fest verdrahtet, eigene Retry- und Streaming-Logik mitbringt oder Prompts clientseitig zusammensetzt, lässt sich nicht auf diese Weise umlenken. Das README nennt als Bedingung ausdrücklich jede agentische Runtime, aber die Beispiele zeigen Runtimes, die bereits über base_url konfigurierbar sind. Der Umbauaufwand für alles andere bleibt unerwähnt.
Drittens die Hardware. Der Ascend-NPU-Support liegt laut News in einem separaten Branch namens ascend und wird dort aktiv gepflegt. Das ist kein Teil des Hauptzweigs. Wer auf NPU-Hardware plant, muss mit einem abweichenden Stand rechnen, und Fehlerberichte gehören entsprechend dorthin.
Der Vergleich mit TRL und verl fällt anders aus als erwartet
Die naheliegenden Alternativen für RL auf Sprachmodellen sind TRL und verl. Der Unterschied liegt nicht im Algorithmus, sondern im Angriffspunkt. TRL und verl erwarten, dass der Rollout innerhalb des Trainingsskripts entsteht: Man schreibt eine Reward-Funktion, das Modell generiert, die Bibliothek rechnet. Der Agent ist Teil des Trainingsprogramms.
AReaL dreht das um. Der Agent bleibt ein externer Dienst, der über HTTP mit einem Modellendpunkt spricht. AReaL stellt den Endpunkt und lernt aus dem, was durch ihn hindurchgeht. Das ist der Grund, warum das OpenClaw-Beispiel ohne Codeänderung am Agenten auskommt, und der Grund, warum die Scaffoldings-Integration aus dem April 2026 als Entkopplung von Agentenausführung, Reward-Berechnung und Trajektorienerfassung beschrieben wird. Bei TRL und verl wäre diese Trennung ein Fremdkörper; bei AReaL ist sie die Grundannahme.
Der zweite Unterschied ist die Nebenläufigkeit. AReaL nennt sein Paradigma vollständig asynchron und stellt es als Kern der Effizienz dar. Ob das in einem konkreten Setup schneller ist als eine synchrone Variante, lässt sich aus dem Repository-Ausschnitt nicht beurteilen. Sicher ist nur, dass asynchrones Training die Maskierungsmechanismen nötig macht, die AReaL mit KPop und IcePop selbst mitliefert. Eine Bibliothek, die synchron trainiert, braucht diesen Teil nicht.
Wartung, Versionen und die Lizenzfrage
Die Release-Kadenz ist im Material sichtbar: v1.0.4 im Mai 2026, v2.0.0 im Juli 2026, v2.1.0 im August 2026. Der Sprung von 1.0 auf 2.0 innerhalb von knapp zwei Monaten war ein Architekturbruch, kein Feature-Update. Wer auf v1 aufgebaut hat, steht vor einer Migration, deren Umfang das README nicht beschreibt. Der letzte Push liegt auf dem 9. September 2026, das Projekt ist nicht archiviert.
AReaL steht unter Apache-2.0. Das ist eine permissive Lizenz mit einer ausdrücklichen Patentgewährung und relativ wenigen Auflagen: Namensnennung, Beibehaltung der Lizenzhinweise, Kennzeichnung geänderter Dateien. Was Apache-2.0 nicht leistet, ist eine Aussage über die Lizenz der Modelle, die man damit trainiert, oder über die Daten, mit denen trainiert wird. Das README verlinkt Modelle und Datensätze über Hugging-Face-Sammlungen, jeweils unter eigenen Bedingungen. Diese Prüfung ist von der Repository-Lizenz unabhängig. Rechtsberatung ist das nicht.
Ein konkreter Wartungspunkt ergibt sich aus der Struktur selbst: Die vier Dienste unter areal/v2 müssen versionskompatibel zueinander betrieben werden. Ein Upgrade eines Dienstes ohne die anderen ist nicht vorgesehen. Wer AReaL produktiv einsetzt, pinnt also nicht ein Paket, sondern eine Kombination.
Belegbares aus den Beispielen: Hermes, SWE, tau2
Das Repository enthält mehrere End-to-End-Beispiele, die mehr über die gedachte Nutzung verraten als jede Beschreibung. Das Hermes-Beispiel unter examples/hermes wird zusammen mit dem SWE-Beispiel als Teil des 2.0-Release genannt und deckt den Online-RL-Loop ab. examples/swe zeigt RL-Training für Software-Engineering-Aufgaben. examples/tau2 gehört zu AReaL-SEA, einem Daten-Synthese-Motor, dessen 235B-MoE-Modell laut Projektangaben auf tau2-bench Ergebnisse auf dem Niveau von Gemini 3.0 Pro erreicht. Diese Angabe stammt aus der Projektankündigung und ist nicht unabhängig nachvollzogen.
Für die Praxis relevanter ist, was diese Beispiele gemeinsam haben: Sie sind aufgabenbezogen und liefern jeweils Daten, Reward und Auswertung mit. Das ist der eigentliche Einstiegspunkt. Wer AReaL evaluieren will, sollte nicht mit der Microservice-Dokumentation beginnen, sondern mit einem dieser Beispiele, weil dort der vollständige Pfad von der Trajektorie bis zum Update sichtbar wird.
Das README verlinkt zusätzlich ein technisches Dokument zu 2.0 sowie einen Artikel zum Thema Online-RL über einen Proxy, der das base_url-Muster ausführlicher behandelt. Beide sind Teil des Materials, aber nicht sein Inhalt. Wer die Architektur bewerten will, kommt um diese beiden Quellen nicht herum.
Redaktionelles Fazit
Wer bereits eine Agenten-Runtime betreibt und nur die base_url auf den AReaL-RL-Service umbiegen will, findet hier den kürzesten Weg zu Online-RL-Daten. Wer dagegen einen einzelnen Trainingslauf auf einer einzelnen Maschine plant oder keine verteilte Microservice-Topologie betreiben will, sollte zuerst AReaL-lite prüfen und die Versionsnummern von areal und areal-lite im eigenen Environment abgleichen, bevor irgendetwas installiert wird.
Community-Notizen