vLLM: Standardisierte APIs zur Gewichtssynchronisation beschleunigen asynchrones RL

Das Projekt vLLM, einer der am weitesten verbreiteten Open-Source-Dienste für die Inferenz großer Sprachmodelle, hat am 28. Mai 2026 standardisierte native APIs für Reinforcement Learning (RL) veröffentlicht. Ziel ist es, die Fragmentierung zu beseitigen, die bislang die Entwicklung von RL-Pipelines verlangsamt hat.

Welches Problem lösen die nativen RL-APIs?

Im Reinforcement Learning — einer Trainingsmethode, bei der ein Modell durch Belohnungen und Strafen lernt — müssen die Gewichte (weights) des Modells ständig zwischen der Trainings- und der Inferenzphase übertragen werden. vLLM weist darauf hin, dass die “Gewichtssynchronisation zwischen Training und Inferenz” bislang “ad-hoc implementiert und über Frameworks hinweg dupliziert” wurde. Jedes RL-Werkzeug löste dasselbe Problem auf seine eigene Weise.

Die Neuerung führt standardisierte APIs mit vier Betriebsphasen ein: Initialisierung (init_weight_transfer_engine), Start des Updates (start_weight_update), Übertragung der Gewichte (update_weights) und Abschluss mit Nachverarbeitung wie Quantisierung (finish_weight_update).

Wie werden die Gewichte übertragen und welche Backends gibt es?

vLLM bietet zwei Transport-Implementierungen. NCCL dient dem GPU-zu-GPU-Broadcast über separate Geräte, während IPC den Transfer auf demselben Gerät über ein CUDA-Shared-Memory-Handle ermöglicht. Beide nutzen eine optimierte Packed-Implementierung zur Minimierung des Serialization-Overheads — der Kosten für die Umwandlung von Daten in ein für die Übertragung geeignetes Format.

Für asynchrones RL wurde ein dritter Pausenmodus, der Keep Mode, hinzugefügt, der aktive Anfragen pausiert und dabei den Zustand des Schedulers bewahrt, was Gewichts-Updates ohne Unterbrechung oder Warten auf den Abschluss ermöglicht.

Wie werden Stabilitätsprobleme verhindert?

In großen verteilten Deployments vom Typ DPEP (Data Parallel + Expert Parallel) führt vLLM ein zweiphasiges Pause/Resume-Protokoll ein, das Deadlocks verhindert. In der ersten Phase pausieren die Engines das Scheduling, beachten aber weiterhin die START_DP_WAVE-Koordinationsnachrichten; in der zweiten Phase stellt eine globale All-Reduce-Verifikation sicher, dass alle Ranks gemeinsam übergehen.

Die APIs wurden in SkyRL für asynchrones DAPO-Training demonstriert und in großem Maßstab vom Team Prime-RL auf 16 Knoten mit 8 H200-GPUs validiert, bei stabilem Training über mehr als 100 Schritte. Damit wird eine Schlüsselkomponente moderner RL-Pipelines standardisiert.