Async GRPO mit LoRA: RL-Training ohne NCCL auf Hugging Face Jobs

Verteiltes RL-Training gilt als Zauberei für NCCL-Cluster - Hugging Face zeigt in einem neuen Blogpost, dass es auch ohne geht. Der Beitrag beschreibt, wie AsyncGRPOTrainer (TRL v1.14) jetzt LoRA-Adapter trainieren und nur diese Adapter an vLLM synchronisieren kann. Trainer und Inference-Server laufen dabei als getrennte Hugging Face Jobs auf verschiedenen Maschinen.

Warum LoRA genügt: Thinking Machines’ Analyse “LoRA Without Regret” zeigt, dass LoRA bei Policy-Gradient-RL sogar mit Rank 1 gleich gut wie Full Fine-Tuning abschneidet. Die Advantage-Funktion liefert nur ~O(1) Bits Information pro Episode - ein Rank-1-Adapter hat genug Kapazität. Für ein 1,5B-Modell wiegt der Adapter wenige Megabytes statt 3 GB.

Die Architektur: Statt Gigabytes übers Netzwerk zu schieben, laufen drei HF Jobs: ein Trainer-Job mit AsyncGRPOTrainer, zwei vLLM-Replikas, und ein Storage Bucket, der per FUSE-Filesystem in allen Jobs gemountet wird. Der Trainer schreibt den Adapter per atomic rename in den Bucket, vLLM laed ihn über den /v1/load_lora_adapter-Endpoint. Dazwischen sitzt ein kleiner Proxy, der Auth-Header setzt, Rollouts an die Replika mit passendem KV-Präfix routet und Adapter-Updates broadcastet.

Details mit Tiefgang: Der Post erklärt max_staleness (veraltete Policy-Versionen werden bis 4 Steps toleriert, daher 6 Adapter-Slots in vLLM), warum Adapter versionierte Namen brauchen (sonst matcht der Prefix-Cache alte KV-Blöcke mit neuen Gewichten), und die Sanity-Test-Datensatz-Auswahl aus dem Precision-RL-Paper.

Das Ergebnis: Fünf Optimierungslaefte mit demselben Rezept verkürzen 500 Steps von 3h27min auf 53 Minuten - 3,9x schneller, 31 Prozent mehr trainierte Samples, identische Reward-Kurve. Das Repo hfjobs-lora-buckets auf GitHub enthält das komplette Setup zum Nachbauen.

Original: Async GRPO with LoRA across HF Jobs (Hugging Face Blog, 10.09.2026)