TRL schickt beim asynchronen Training nur noch den LoRA-Adapter an vLLM, Trainer und Inferenz brauchen keine gemeinsame Maschine mehr

Hugging Face hat den asynchronen GRPO-Trainer seiner Bibliothek TRL um LoRA erweitert, und die Folge reicht weiter als eine neue Option: „AsyncGRPOTrainer can now train a LoRA adapter and sync only that adapter to vLLM (TRL v1.14)“, heißt es im Bericht. Bis dahin ging nach jedem Abgleich das ganze Modell an den Inferenz-Server. Jetzt geht ein Adapter von wenigen Megabyte, und der Bericht führt vor, was das erlaubt: Training und Generierung laufen in drei getrennten Jobs auf drei Maschinen, die kein Netz miteinander teilen. Der Bericht setzt ein halbes Dutzend Fachbegriffe voraus, deshalb zuerst die Teile, dann der Zusammenhang.

Die Teile, und was sie tun

TRL ist die Bibliothek von Hugging Face für das Nachtraining von Sprachmodellen, also für den Schritt, der aus einem vortrainierten Textfortsetzer einen Assistenten oder einen Spezialisten macht. Eines ihrer Verfahren ist GRPO, eine Spielart des Reinforcement Learning: Das Modell bekommt eine Aufgabe, erzeugt dazu mehrere Antworten, hier acht, und lernt daraus, welche davon besser bewertet wurden als der Durchschnitt ihrer Gruppe. Das Modell, das dabei trainiert wird, heißt Policy, ein einzelner Versuch samt Bewertung Rollout. Der asynchrone Trainer trennt beides: Ein Rollout-Arbeiter lässt Antworten erzeugen und bewertet sie, der Trainer rechnet daraus Gewichtsänderungen, und beide laufen in ihrem eigenen Takt.

Die Antworten erzeugt vLLM, ein Inferenz-Server, der ein Modell für Hunderte gleichzeitiger Anfragen betreibt. Damit die Inferenz mit der aktuellen Policy rechnet, muss der Trainer sie nach jedem Abgleich dorthin bringen. Bei einem vollen Modell mit 1,5 Milliarden Parametern sind das rund 3 Gigabyte, und in einem Rechnerverbund übernimmt das NCCL, NVIDIAs Bibliothek für den Datenaustausch zwischen Grafikkarten. Sie setzt voraus, dass die Karten ein schnelles Netz teilen.

LoRA ändert die Größenordnung. Die Gewichte des Modells bleiben eingefroren, trainiert werden kleine Zusatzmatrizen daneben, und ihr Rang bestimmt, wie breit sie sind. Ein Adapter mit Rang 1 ist für dasselbe Modell wenige Megabyte groß, der Bericht rechnet es vor: „A rank-1 adapter for a 1.5B model is a few megabytes, while the full model is around 3 GB.“ Wie das Verfahren im Einzelnen arbeitet, steht in Beurteilen und Einordnen, Kapitel 02.

Warum ein Adapter reicht

Dass ein so kleiner Adapter für Reinforcement Learning genügt, hat Thinking Machines im September 2025 gemessen: „LoRA fully matches the learning performance of FullFT when running policy gradient algorithms for reinforcement learning, even with ranks as low as 1.“ Die Begründung ist informationstheoretisch. Beim überwachten Training liefert jedes Token des Zieltexts Information, beim Policy-Gradient-Verfahren nur die Bewertung am Ende, „the advantage function which provides only O(1) bits per episode“. Es gibt je Versuch wenig zu lernen, und dafür reicht wenig Platz.

Daraus folgt die Systemfrage, um die es im Bericht geht. Ein Adapter dieser Größe passt durch ein gemeinsames Dateisystem. Hugging Face Jobs, der Dienst, in dem der Versuch läuft, gibt je Job einen Container auf einer virtuellen Maschine, und zwei Jobs haben weder eine gemeinsame Platte noch ein gemeinsames Netz. Was es gibt, ist ein Speicher-Bucket, ein Objektspeicher, der sich in jeden Job als Dateisystem unter demselben Pfad einhängen lässt. Der Trainer schreibt alle vier Trainingsschritte einen neuen Adapter unter einem versionierten Namen dorthin und ruft bei vLLM den Endpunkt zum Laden mit diesem Pfad auf; die Server lesen die Datei aus ihrem eigenen Einhängepunkt. „No network path between the Jobs is needed at all“, und weiter: „Nothing in TRL or vLLM had to change for this.“

Die Versionsnummer im Namen hat einen Grund. vLLM hält mehrere Adapter gleichzeitig, sechs in diesem Aufbau, weil ein Rollout, der unter Policy 3 begonnen hat, unter Policy 3 zu Ende laufen soll, während neue schon Policy 7 benutzen: „Old rollouts finish with the policy they started with, while new rollouts use the latest one.“ Und weil „vLLM keys its prefix cache by adapter name“, kann ein Zwischenergebnis der alten Fassung nie für die neue durchgehen.

Was der Proxy dazwischen tut

Zwischen Trainer und Servern steht ein kleines Programm, ein Proxy, an das TRL sich wendet, als wäre es ein einziger vLLM-Server. Es fügt jedem Aufruf den Zugangsschlüssel an, den ein nach außen geöffneter Job verlangt, und es erlaubt mehrere Server nebeneinander: TRL verweigert den Adapter-Abgleich, sobald ein einzelner vLLM-Server intern auf mehrere Grafikkarten verteilt, weil ein Ladebefehl dort nur eine davon erreicht. Der Proxy schickt jeden Ladebefehl an alle Replikate und nimmt ihn zurück, wenn eines scheitert, damit ein Policy-Name überall dasselbe bedeutet.

Die eigentliche Arbeit des Proxys ist die Verteilung der Rollouts, und dafür braucht es den KV-Cache. Eine Antwort entsteht in zwei Phasen: Erst geht der ganze Prompt in einem Durchgang durch das Modell (Prefill), dann entsteht Token für Token die Antwort (Decode), und jedes neue Token sieht auf die Schlüssel und Werte aller Token davor. Weil ein Token nur von dem abhängt, was vor ihm steht, teilen sich zwei Anfragen mit demselben Anfang diese Einträge. Die acht Rollouts einer Aufgabe haben denselben Prompt; landen sie beim selben Server, rechnet der den Prefill ein einziges Mal, und die anderen sieben übernehmen ihn. Der Proxy zerlegt jeden Prompt deshalb wie vLLM in Blöcke zu 16 Token, verkettet deren Hashes mit dem Adapternamen als Anfang und merkt sich, welcher Server welche Blöcke gesehen hat. Den Anfang, den alle Prompts teilen, hier die 23 Token der Chat-Vorlage, lässt er dabei weg, sonst sähe jede neue Aufgabe wie ein Treffer aus. Über 64.728 Rollouts landeten so 84,5 Prozent beim Server, der ihren Anfang schon hatte; 14,2 Prozent waren neu, bei einem rechnerischen Minimum von 12,5 Prozent, denn der erste von acht ist immer neu. Dasselbe Prinzip verkaufen die Anbieter als Prompt Caching, und in Grundkurs, Kapitel 10 steht, ab wann es sich rechnet.

Welche Annahme kippt

Bisher galt: Wer Training und Generierung entkoppelt, braucht dafür eine Maschine oder einen Verbund mit schnellem Netz, weil nach jedem Abgleich Gigabyte wandern. Das ist der Grund, warum solche Aufbauten auf Clustern mit NCCL und Netzwerk-Dateisystem zu Hause sind. Jetzt genügen drei Jobs, die einander nicht kennen, und ein Bucket als Briefkasten. Möglich wird das durch zwei Dinge, die getrennt entstanden sind: eine Messung, nach der Rang 1 für Reinforcement Learning reicht, und ein Ladeweg in vLLM, der mit einem Dateipfad arbeitet. Was ein Modell im Betrieb an Hardware voraussetzt und wo es sonst läuft, steht in Beurteilen und Einordnen, Kapitel 01.

Was die Zahlen zeigen, und was nicht

Der Abgleich selbst ist mit dem Adapter von 30,8 auf 8,5 Sekunden gefallen, alle 252 Ladevorgänge über 126 Abgleiche gelangen, und die Kennzahl, an der ein Auseinanderlaufen von erzeugender und trainierender Policy sichtbar würde, blieb über den ganzen Lauf bei 1,000. Der Aufbau kostet nach Angabe des Berichts etwa 20 Dollar je Stunde für alle drei Jobs.

Die auffälligste Zahl des Berichts hat einen anderen Grund als den Adapter. Der erste Lauf brauchte für 500 Schritte 3 Stunden und 27 Minuten, der fünfte 53 Minuten, und dazwischen liegen drei Umbauten am Trainer: Die Trainingsbeispiele werden dicht in den Speicher der Grafikkarte gepackt statt eines je Zeile, das Nachrechnen des Vorwärtsdurchgangs im Rückwärtsschritt ist abgeschaltet, und die Grenze für gleichzeitig laufende Anfragen ist von 128 auf 384 gehoben. Der Bericht sagt es selbst: „Packing, disabling checkpointing and raising the in-flight limit made the difference.“ Die Belohnungskurve ist in beiden Läufen dieselbe, von 0,145 auf 0,438 beziehungsweise 0,416.

Was das Material nicht hergibt: Gemessen ist ein Modell mit 1,5 Milliarden Parametern auf einem Datensatz mit 1.460 Mathematikaufgaben, der so gewählt ist, dass das Modell früh ein Signal bekommt. Einen Vergleich gegen denselben Lauf auf einer einzelnen Maschine mit NCCL enthält der Bericht nicht; belegt ist, dass der getrennte Aufbau funktioniert, und ob er schneller ist, bleibt offen. vLLM ist auf die Fassung 0.27.1 festgenagelt, weil Schalter und Endpunkte zum Laden von Adaptern an der Fassung hängen, und der Proxy ist ein einzelner Python-Prozess, für den die Autoren selbst „at least at this scale“ schreiben. Und es ist der Bericht des Herstellers über die eigene Bibliothek.