TRL schickt beim asyn­chronen Training nur noch den LoRA-Adapter an vLLM, Trainer und Inferenz brauchen keine gemein­same Maschine mehr

Hugging Face hat den asynchronen GRPO-Trainer seiner Bibliothek TRL um LoRA erweitert, und die Folge reicht weiter als eine neue Option: Seit TRL v1.14 trainiert der asynchrone Trainer einen LoRA-Adapter und gleicht nur diesen mit vLLM ab. 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­än­de­rungen, 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 mit 1,5 Milliarden Parametern wenige Megabyte groß, das volle Modell rund 3 Gigabyte. 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: Mit Policy-Gradient-Verfahren lernt LoRA im Reinforcement Learning genauso gut wie ein volles Fine-Tuning aller Gewichte, selbst mit Rang 1. Die Begründung ist infor­ma­ti­ons­theo­re­tisch. Beim überwachten Training liefert jedes Token des Zieltexts Information, beim Policy-Gradient-Verfahren nur die Bewertung am Ende, und die liefert je Durchgang eine feste, kleine Zahl von Bits, in der Schreibweise der Informatik O(1). 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. Ein Netzweg zwischen den Jobs ist dafür überhaupt nicht nötig, und weder an TRL noch an vLLM musste dafür etwas geändert werden.

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 läuft, während neue schon die jüngste Fassung, Policy 7, benutzen. Und weil vLLM seinen Präfix-Cache nach dem Namen des Adapters ordnet, 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.

Drei Jobs und ein Bucket statt eines Clusters

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.

Schneller durch den Adapter und durch drei Umbauten

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 Trai­nings­bei­spiele werden dicht in den Speicher der Grafikkarte gepackt statt eines je Zeile, das Nachrechnen des Vor­wärts­durch­gangs im Rückwärtsschritt ist abgeschaltet, und die Grenze für gleichzeitig laufende Anfragen ist von 128 auf 384 gehoben. Der Bericht nennt genau diese drei Umbauten als den Unterschied. 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 Mathe­ma­tik­auf­gaben, 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, der nach Angabe der Autoren kein Engpass war, ausdrücklich nur für diese Größenordnung. Und es ist der Bericht des Herstellers über die eigene Bibliothek.

Einordnung

Für die meisten, die Sprachmodelle in der eigenen Arbeit einsetzen, ist das ein Bericht aus der Werkstatt der Modellbauer. Wer nicht selbst nachtrainiert, braucht weder Trainer noch Adapter-Abgleich. Interessant wird er für Teams, die ein offenes Modell auf eine eng umrissene, automatisch bewertbare Aufgabe zuschneiden wollen, ohne eigenen Rechnerverbund. Ob Nachtraining überhaupt der passende Weg ist oder Anweisung, Beispiele und Unterlagen genügen, klärt Nutzung und Anpassung von LLMs, Kapitel 08.