Zwei Jahre lang war die Geschichte der Anpassung großer Sprachmodelle die Geschichte des überwachten Fine-Tunings. Du sammeltest Beispiele für gutes Verhalten, führtest LoRA oder ein vollständiges Fine-Tuning durch, und das Modell lernte, sie nachzuahmen. Dieser Ansatz ist ausgereift, kostengünstig und gut verstanden — und für eine wachsende Klasse von Problemen ist er nicht ausreichend. Wenn das, das dir wichtig ist, ein Ergebnis ist und nicht ein Stil — hat der Agent das Ticket gelöst, hat die mehrstufige Tool-Sequenz tatsächlich die richtige Antwort abgerufen, hat die Verhandlung einen Deal erreicht — stößt Imitation an eine Grenze. Du kannst keine überwachten Beispiele der optimalen Aktion bei jedem Schritt einer langen, verzweigten Interaktion sammeln, weil du nicht weißt, was die optimale Aktion war. Was du tun kannst, ist den Agent handeln zu lassen, das Ergebnis zu bewerten und ihn in Richtung dessen zu schieben, was die höhere Bewertung erzeugt hat. Das ist Reinforcement Learning, und im Jahr 2026 ist es zu einer praktischen, zugänglichen Technik zum Trainieren von Agenten geworden, anstatt einer exotischen Forschungsarbeit zu sein.
Der Wandel wurde großteils von einem Algorithmus und einer Welle von Tooling um ihn herum angetrieben. GRPO (Group Relative Policy Optimization) streifte viel der Mechanik ab, die klassisches RLHF schmerzhaft machte, und eine Reihe von Open-Source-Frameworks — ART, verl und OpenRLHF — machte es ohne die Infrastruktur eines Forschungslabors auführbar. Dieser Leitfaden erklärt, wie Reinforcement Fine-Tuning für Agenten tatsächlich im Jahr 2026 funktioniert, vergleicht die drei Frameworks, die die meisten Teams verwenden, und bietet konkrete Anleitung zu Reward-Design und wann RL die Mühe wert ist.
Warum überwachtes Fine-Tuning an die Grenzen stößt
Überwachtes Fine-Tuning (SFT) ist in seinem Kern Next-Token-Imitation. Du zeigst dem Modell Input-Output-Paare und es lernt die bedingte Verteilung der Ausgaben. Für Aufgaben, bei denen gutes Verhalten durch Beispiele gut erfasst wird — einen Ton anpassen, ein Format folgen, Domänenfragen beantworten — funktioniert dies wunderbar und sollte dein erster Zug bleiben. Es ist billiger, stabiler und leichter zu debuggen als alles, was mit RL zu tun hat.
Die Grenze erscheint, wenn gutes Verhalten durch ein Ergebnis definiert wird, das sich über viele Schritte entfaltet. Stellen dir vor, du hast einen Agent, der Fragen beantwortet, indem er interne Dokumente durchsucht: Er stellt eine Abfrage aus, liest Ergebnisse, entscheidet, ob erneut zu suchen ist, und verfasst schließlich eine Antwort. Das Qualitätssignal, das du tatsächlich hast, ist, ob die endgültige Antwort korrekt war. Du hast keine bezeichnete „richtige Abfrage zum Ausgeben in Schritt eins angesichts dieses teilweisen Kontexts", da die richtige Abfrage davon abhängt, was zurückkommt, was vom Dokumentenspeicher abhängt, der sich ändert. SFT kann den Agent lehren, eine Handvoll Spuren nachzuahmen, die du aufgezeichnet hast, aber es kann nicht lehren, das End-to-End-Ergebnis über den enormen Raum möglicher Interaktionen zu optimieren. Der Agent überpasst sich auf die Oberflächenform deiner Beispiele statt zu lernen, die zugrunde liegende Zielvorgabe zu lernen.
Reinforcement Learning invertiert das Setup. Statt die richtige Aktion zu demonstrieren, lässt du den Agent seine eigenen Aktionen ergreifen, das Ergebnis beobachten, eine Belohnung zuweisen und die Policy anpassen, um hochbelohnte Verhaltensweisen wahrscheinlicher zu machen. Der Agent erkundet, und die Belohnung — nicht ein fester Transkript — definiert Erfolg. Dies ist genau das Regime, in dem mehrstufige, Tool-nutzende Agenten leben, weshalb RL zur Technik der Wahl für die Förderung von Agenten über das hinaus geworden ist, was SFT allein erreichen kann.
GRPO: Der Algorithmus, der dies praktisch machte
Der Grund, warum RL für LLMs lange unerreichbar zu sein schien, war PPO, der Workhorse-Algorithmus hinter dem ursprünglichen RLHF. PPO ist mächtig, aber operativ schwer: Es erfordert das Trainieren und Bedienen eines separaten Value-(Critic-)Modells neben der Policy, ungefähr verdoppelt den Speicher und fügt ein zweites Modell hinzu, das man einstellen und stabil halten muss. Für die meisten Teams war dieser Overhead untersagend.
GRPOs Schlüsseleinblick ist, dass du schätzen kannst, wie gut eine Aktion war, ohne eine gelernte Value-Funktion, indem du mehrere geprobte Antworten auf die gleiche Eingabeaufforderung gegeneinander vergleichst. Du generierst eine Gruppe von Vervollständigungen, bewertest sie alle und verwendest die Durchschnittsbewertung der Gruppe als Baseline. Eine Vervollständigung, die den Durchschnitt der Gruppe schlägt, bekommt einen positiven Vorteil; eine, die darunter fällt, bekommt einen negativen. Das relative Ranking innerhalb der Gruppe ersetzt die absolute Value-Schätzung, die PPOs Kritiker bereitgestellt hat. Kein Kritiker-Modell, viel weniger Speicher, und eine Trainingsschleife, die viel leichter nachzudenken ist.
Das ist, warum fast jedes Agent-RL-Framework im Jahr 2026 auf GRPO zentriert ist. Es machte den Unterschied zwischen „du benötigst ein dediziertes ML-Team und einen Cluster" und „du kannst dies auf einer einzelnen fähigen GPU mit einer angemessenen Menge an Code ausführen". Die Frameworks unten sind, zu großen Teilen, unterschiedliche Meinungen darüber, wie man GRPO in brauchbare Infrastruktur verpackt.
ART: Reinforcement Learning, das in deinem Code lebt
ART (Agent Reinforcement Trainer) von OpenPipe nimmt die Agent-nativste Haltung der drei an. Seine definierende Designentscheidung ist eine Aufteilung zwischen einem Client und einem Backend. Der Client führt die Rollouts deines Agenten — die aktuellen Episoden, in denen der Agent handelt — in deinem eigenen Anwendungscode aus und spricht mit dem Modell über einen Standard-OpenAI-kompatiblen Chat-Completion-Endpoint. Das Backend verwaltet die schwere Maschinerie: Bedienung des Modells für Inferenz mit vLLM und Ausführung von GRPO-Training mit Unsloth-optimierten Kerneln. Die beiden Hälften können auf verschiedenen Maschinen laufen, sodass deine Agent-Logik auf deinem Laptop bleiben kann, während Training auf einer Cloud-GPU stattfindet.
Diese Architektur ist wichtig, weil sie bedeutet, dass du Rollouts genauso schreibst, wie du bereits Agenten schreibst. Du rufst das Modell auf, lässt es Tools verwenden, erfasst die Trajektorie und weist eine Belohnung mit gewöhnlichem Python zu. ART nimmt dann Gruppen dieser Trajektorien und führt GRPO-Updates durch. Du musst deinen Agent nicht als spezielle RL-Umgebung umrahmen; das RL ist um den Code gepackt, den du ohnehin geschrieben hättest. ART wird auch mit einem Helper namens RULER für relative Bewertung ausgeliefert, der ein Modell verwendet, um Trajektorien innerhalb einer Gruppe zu rangieren, wenn du keine saubere numerische Metrik hast — nützlich für die vielen echten Aufgaben, bei denen „besser" zu urteilen ist, aber nicht direkt messbar.
ART ist der richtige Startpunkt, wenn dein Ziel darin besteht, einen bestimmten Agent zu verbessern, den du bereits gebaut hast, besonders einen mehrstufigen, Tool-nutzenden, und du die Rollout-Logik in deiner eigenen Umgebung behalten möchtest. Es zielt auf Best-in-Class-Trainingseffizienz für diesen Single-Agent-, On-the-Job-Training-Anwendungsfall ab, anstatt ausschweifend verteilte Pipelines.
verl: Durchsatz und Forschungsflexibilität
verl (Volcano Engine Reinforcement Learning) kommt aus einer anderen Richtung: Hochleistungs-, großskaliges RL für LLMs. Gebaut rund um Ray für Verteilung und vLLM für schnelle Generierung, ist verl für Durchsatz und für die Flexibilität konzipiert, die Forscher benötigen, um mit Algorithmen und Belohnungsschemata zu experimentieren. Es unterstützt PPO, GRPO und eine wachsende Familie von Varianten, und es ist für effiziente Skalierung über viele GPUs ausgelegt.
Der Tradeoff ist, dass verl mehr der RL-Maschinerie freilegt. Du gewinnst Kontrolle über die Trainingstopologie, die Algorithmen-Details und die Performance-Knöpfe, aber du übernimmst auch mehr der konzeptionellen Last. verl glänzt für Teams, die ernsthaftes, rechenintensives RL durchführen — Training größerer Modelle, Ausführung vieler Experimente oder das Schieben an algorithmischen Grenzen — bei dem roher Durchsatz und Konfigurierbarkeit die steilere Einrichtung rechtfertigen. Es ist weniger ein „mein existierendes Agent-Tool umpacken" und eher eine Forschungs- und Skalierungsplattform.
OpenRLHF: Produktions-RLHF in großem Maßstab
OpenRLHF wirbt sich selbst als ein hochleistungs-, produktionsreifes RLHF-Framework, ebenfalls auf Ray und vLLM aufgebaut, mit einem einheitlichen Agent-basierten Design. Es implementiert ein breites Menü an Algorithmen — PPO, GRPO, REINFORCE++, RLOO und mehr — mit den Optimierungstricks, die praktisches RLHF braucht, um groß stabil zu bleiben. Seine Abstammung ist die vollständige RLHF-Pipeline: Reward-Modellierung, Präferenz-Optimierung und Policy-Training über verteilte Hardware.
OpenRLHF hat mit dem Platz Schritt gehalten, wohin das Feld geht. Seine 2026-Versionen hinzugefügt Multi-Turn-Vision-Language-RL, die Teilen erlaubt, VLMs zu trainieren, die über viele Schritte Ende zu Ende über Bilder nachdenken — ein Signal, dass Agent-RL über Text in multimodale Tool-Verwendung expandiert. OpenRLHF ist die natürliche Wahl, wenn du einen ausgereiften, skalierbaren RLHF-Stack mit einer breiten Algorithmusauswahl brauchst und dich damit wohlfühlst, ein verteiltes System zu betreiben, um es zu bekommen.
Wahl zwischen den drei
Die Entscheidung verfolgt die Form deines Problems und deine Appetit auf Infrastruktur. Greife zu ART, wenn du einen bestimmten Agent verbessern möchtest, den du bereits geschrieben hast, Wert auf das Halten von Rollout-Logik in deinem eigenen Code legst und eine Split-Architektur bevorzugst, die bequem auf bescheidener Hardware läuft. Greife zu verl, wenn Durchsatz und algorithmische Flexibilität dominieren — große Modelle, viele Experimente, eine Forschungs-Ausrichtung — und du mehr Hands-On-Einrichtung absorbieren kannst. Greife zu OpenRLHF, wenn du eine produktionsreife, breite RLHF-Plattform in großem Maßstab brauchst, einschließlich multimodales RL, und du die operative Kapazität hast, ein Ray-basiertes verteiltes System zu betreiben.
Alle drei konvergieren am gleichen Maschinenraum — GRPO für den Algorithmus, vLLM für schnelle Generierung — sodass die Wahl weniger um rohe Fähigkeit geht und eher um das Abstraktionslevel, auf dem du arbeiten möchtest. Ein nützliches mentales Modell: ART verpackt RL um deinen Agent, während verl und OpenRLHF dich bitten, deinen Agent in ihre RL-Plattform zu bringen.
Ein konkretes Bild der Trainingsschleife
Es hilft, die Abstraktion greifbar zu machen. Stellen dir vor, du trainierst einen Dokument-Recherche-Agent — die Art, die eine Frage beantwortet, indem sie eine interne Wissensdatenbank durchsucht, Ergebnisse liest und eine Antwort verfasst. Unter GRPO schaut die Schleife so aus. Für jede Training-Frage probierst du eine Gruppe von vollständigen Agent-Episoden, sagen wir acht davon. Jede Episode ist ein vollständiger Rollout: Der Agent führt Suchen aus, liest Ergebnisse, entscheidet, ob er weitersuchen soll, und produziert eine endgültige Antwort. Weil Sampling stochastisch ist, unterscheiden sich die acht Episoden — einige finden das richtige Dokument schnell, einige irren herum, einige antworten selbstbewusst aber falsch.
Du bewertest dann jede Episode mit deiner Belohnungsfunktion, produzierst acht Zahlen. GRPO berechnet den Durchschnitt der Gruppe und weist jeder Episode einen Vorteil gleich zu, wie weit über oder unter dem Durchschnitt sie landete. Die zwei Episoden, die die Antwort verhaute, bekommen positive Vorteile; die drei, die halluzinierten, bekommen negative. Das Policy-Update treibt das Modell dazu, das hochbelohnte Verhalten wahrscheinlicher zu machen und das niedrigbelohnte Verhalten weniger wahrscheinlich — über jeden Token jeder Episode in der Gruppe. Wiederhole über viele Fragen und viele Schritte, und der Agent schiebt schrittweise seine ganze Strategie in Richtung dessen, was Belohnung verdient: bessere Abfragen, zu wissen, wann zu stoppen ist, Antworten in abgerufenen Text zu verankern.
Was dies für Agenten besonders mächtig macht, ist, dass die Belohnung nur das endgültige Ergebnis beurteilen muss. Du musstest nie die richtige Abfrage in Schritt eins bezeichnen. Der Agent entdeckte, durch Vergleich und Verstärkung, dass bestimmte Abfragemuster zu hochbelohnten Enden führen. Das ist das Ding, das SFT nicht tun kann, ausgedrückt als eine Schleife, die du tatsächlich ausführen kannst. ART strukturiert dies als Trajektorie-Gruppen, die gleichzeitig gesammelt werden; verl und OpenRLHF drücken die gleiche Idee durch ihre Ray-basierten Rollout-Worker aus. Das Vokabular unterscheidet sich, aber der Gruppen-relative Vergleich im Kern von GRPO ist identisch über alle drei.
Hardware- und Kostenerwartungen
Reinforcement Fine-Tuning ist schwerer als SFT, und es ist wert, Erwartungen zu setzen, bevor du anfängst. Die dominante Kosten ist Generierung: Jeder Training-Schritt erfordert Stichprobennahme ganzer Gruppen mehrstufiger Rollouts, und für einen Tool-nutzenden Agent kann jeder Rollout mehrere Modellaufrufe plus die Latenz der Tools selbst beinhalten. Das ist, warum jedes ernstzunehmendes Framework auf vLLM lehnt — schnelle gepufferte Inferenz ist hier keine Annehmlichkeit, es ist der Unterschied zwischen einem Training-Lauf, der über Nacht fertig wird, und einem, der überhaupt nicht fertig wird.
Für ein kleines Modell in der 3–8B-Spanne mit LoRA-ähnlichen Adaptern ist eine einzelne moderne Rechenzentrum-GPU oft genug, um echtes Signal zu sehen, besonders mit ARTs Unsloth-optimiertem Backend, das für genau diese Single-GPU-Effizienz ausgestellt ist. Skalieren zu größeren Modellen oder größeren Gruppengrößen treibt dich in Richtung der Multi-GPU-, Ray-basierten Topologien, für die verl und OpenRLHF gebaut sind. Eine praktische Sequenz ist, die Belohnung und den Rollout auf dem kleinsten lebensfähigen Modell lokal zu prototypisieren, die Belohnungskurve auf einem winzigen Datensatz aufwärts zu bestätigen und erst dann Cloud-GPUs auf ein größeres Lauf zu committen. Das Split-Client/Server-Design, das ART fördert, ist praktisch genau, weil es die Prototype-Rollout-Code gleich bleibt, wenn du das Backend zu größerer Hardware verschiebst.
Reward-Design ist die echte Arbeit
Unabhängig davon, welches Framework du wählst, ist das Framework nicht, wo dein Projekt erfolgreich sein wird oder scheitern wird. Die Belohnungsfunktion ist. Reinforcement Learning optimiert genau das, das du belohnst, was bedeutet, dass eine schlampige Belohnung dir einen Agent bekommt, der ausgezeichnet im falschen Ding ist — das Phänomen, das als Reward Hacking bekannt ist. Eine Handvoll Prinzipien helfen sich kontinuierlich.
Halte Belohnungen begrenzt und gut skaliert. GRPO arbeitet aus relativen Vorteilen innerhalb einer Gruppe, und wildverändernde oder unbegrenzte Belohnungen machen diese Vorteilsschätzungen laut und Training instabil. Belohne das Ergebnis statt der Formulierung: Wenn du bewertest, wie eine Antwort formuliert ist, wird der Agent lernen zu formulieren statt zu lösen. Wo mehrstufige Credit-Zuordnung schwer ist, kleine Shaping-Belohnungen für intermediäre Erfolge — ein Tool-Aufruf, der nützliche Daten zurückgab, eine Retrieval, die das richtige Dokument traf — können dem Agent helfen, gute Strategien zu entdecken, ohne sie zu diktieren. Und validiere deine Belohnung auf einer Handvoll von Hand inspizierter Rollouts, bevor du skalierst: Lese, was der Agent tatsächlich tat, um eine hohe Bewertung zu verdienen, und bestätige, dass es mit deiner Absicht übereinstimmt. Fast jeder RL-Fehler geht zurück auf eine Belohnung, die etwas subtil anders als was das Team gemeint hat, gemessen.
Schließlich, respektiere die Kosten und Instabilität, die mit RL kommen. Es ist rechenintensiver und fintickier als SFT. Starten mit dem kleinsten Modell und Datensatz, der Signal zeigen kann, protokolliere Belohnungs- und Verlust-Kurven zwanghaft (alle drei Frameworks integrieren mit Weights & Biases), und skaliere nur einmal, wenn du der Belohnung und dem Trend vertraust. RL ist ein mächtiges Werkzeug für den bestimmten Job der Optimierung von Ergebnissen — und ein frustrierendes, wenn vor SFT erreichtet.
Das Fazit
Reinforcement Fine-Tuning überquerte in 2026 in den Mainstream, weil GRPO den Critic-Modell-Overhead entfernte, der RLHF unpraktisch machte, und weil ART, verl und OpenRLHF den Algorithmus in brauchbare Infrastruktur verwandelt. Verwende SFT zuerst; es bleibt die billigere, stabilere Standard. Wende dich RL zu, wenn Erfolg ein Ergebnis ist, das sich über viele Schritte entfaltet und nicht durch Imitation erfasst werden kann. Wähle ART, um RL um einen Agent zu verpacken, den du bereits hast, verl für Durchsatz und Forschungsflexibilität, und OpenRLHF für skalierbare, Multi-Fähig-Produktions-RLHF. Dann verwende den Großteil deiner Bemühung nicht auf das Framework, sondern auf die Belohnungsfunktion — weil im Reinforcement Learning, du genau das bekommst, das du fragst.
Referenzen und Ressourcen
Frameworks
- ART (Agent Reinforcement Trainer) — GitHub und der Launch-Beitrag
- verl — GitHub
- OpenRLHF — GitHub
- vLLM und Unsloth (Inferenz + Training-Backends)
Algorithmen und Hintergrund
Verwandte 1337skills Cheatsheets
Weiterführende Literatur