GRPO-Training: GPU-Bedarf und Speicher für Reinforcement Learning mit LLMs

GPU-Anforderungen für GRPO: Rollouts plus Training

GRPO braucht mehr GPU-Speicher als ein LoRA-Fine-Tuning desselben Modells, weil jeder Trainingsschritt auch Text erzeugt: Die GPUs halten den Trainingslauf, eine zweite Kopie der Gewichte in einer Inferenz-Engine wie vLLM und den KV-Cache aller Antworten, die gerade erzeugt werden. Nach unserer Auslegung passt ein 8B-LoRA-Lauf auf zwei Karten der NVIDIA RTX PRO 6000 Blackwell Server Edition, eine erzeugt, eine trainiert; ein 32B-LoRA-Lauf passt auf vier, ein 70B-LoRA-Lauf auf acht H200 NVL. Antwortlänge und Zahl der Antworten je Prompt bestimmen den Rollout-Speicher stärker als das Modell.

Die Speicherregeln für überwachtes LoRA, QLoRA und vollständiges Fine-Tuning stehen in unserem Leitfaden zum GPU-Speicher für Fine-Tuning, die Server für diese Läufe in unserem Leitfaden zum Fine-Tuning-Server. Diese Seite ergänzt, was Reinforcement Learning zusätzlich verlangt.

Was ein GRPO-Schritt tut

GRPO wurde im DeepSeekMath-Papier (arXiv 2402.03300) eingeführt, als „a variant of Proximal Policy Optimization (PPO)“, die das mathematische Schlussfolgern verbessert und dabei „concurrently optimizing the memory usage of PPO“. Für jeden Prompt erzeugt das aktuelle Modell mehrere Antworten, eine Belohnungsfunktion bewertet sie, und jede Antwort wird mit den anderen Antworten auf denselben Prompt verglichen; der Trainingsschritt macht die besseren dann wahrscheinlicher.

In der Praxis hat ein Schritt zwei Phasen mit unterschiedlichem Hardwareprofil. Die Erzeugung ist Inferenz: Das Modell dekodiert Tausende Token je Antwort, begrenzt durch Speicherbandbreite und KV-Cache. Das Training ist ein Vorwärts- und Rückwärtsdurchlauf über Prompts und Antworten, begrenzt durch die Tensor-Rechenleistung. Die TRL-Bibliothek von Hugging Face führt die Erzeugung in vLLM aus, wenn use_vllm gesetzt ist, und der Trainer überträgt nach jedem Optimiererschritt die aktualisierten Gewichte per NCCL an vLLM, wie TRLs Leitfaden zur vLLM-Integration beschreibt.

Die Voreinstellungen von TRL 1.16.0, dem stabilen Release vom 15. Oktober 2026, bilden den Ausgangspunkt. Laut Docstring von GRPOConfig sind das: num_generations mit 8 Antworten je Prompt, max_completion_length mit 512 Token, beta mit 0,0 („If 0.0 (default), the reference model is not loaded“), learning_rate 1e-6, loss_type „dapo“, außerdem eingeschaltetes Gradient Checkpointing und BF16. Reasoning-Läufe setzen die Antwortlänge meist weit über 512, und genau dafür wird der Speicher gebraucht.

Das Speicherbudget eines GRPO-Laufs

Unsere Rechnung. Trainingszustände für ein LoRA mit Rang 16 auf Llama 3.1 8B, Qwen3-32B und Llama 3.3 70B aus unserem Leitfaden zum GPU-Speicher (8,03, 32,76 und 70,55 Milliarden Parameter). KV-Cache in BF16 aus der config.json jedes Modells (gelesen am 24. Oktober 2026): 32, 64 und 80 Schichten mit 8 KV-Köpfen der Dimension 128, also 128, 256 und 320 KiB je Token, für einen Rollout aus einem Prompt mit 512 Token und einer Antwort mit 4.096 Token. Aktivierungen kommen hinzu.

Der Rollout-Cache wächst mit drei Zahlen, die Sie wählen: Prompts je Schritt, Antworten je Prompt und Antwortlänge. Sechzehn Prompts mit je acht Antworten sind 128 Rollouts; bei 4.096 Token je Antwort dekodiert ein Schritt bis zu 524.288 Token. vLLM muss nicht alle gleichzeitig halten, es arbeitet den Batch ab, sobald Cache frei wird. Je weniger es aber gleichzeitig hält, desto mehr Durchgänge braucht die Erzeugung und desto länger dauert jeder Schritt.

Das Referenzmodell braucht nur Speicher, wenn β über null liegt, weil TRL dann eine KL-Strafe gegenüber dem Ausgangsmodell berechnet. Für einen Lauf mit allen Parametern kann das eine weitere eingefrorene 16-Bit-Kopie der Gewichte bedeuten; bei TRLs Voreinstellung von 0,0 wird es nicht geladen. Wie lang die Ausgaben trainierter Reasoning-Modelle werden, behandelt unsere Seite zu Reasoning-Modellen.

TRL im Colocate- oder Server-Modus

TRLs Dokumentation beschreibt zwei Arten, vLLM zu betreiben. Im Colocate-Modus, der Voreinstellung, „vLLM runs inside the trainer process and shares GPU memory with the training model“; das „can improve GPU utilization, but may lead to memory contention on the training GPUs“. Im Server-Modus „vLLM runs as a separate process on dedicated GPUs and communicates with the trainer via HTTP“, was TRL „ideal if you have GPUs dedicated to inference“ nennt; Server und Trainer „must run on separate CUDA devices“. TRLs Beispiel startet den Server auf den GPUs 0 bis 3 mit --tensor-parallel-size 4 und den Trainer auf den GPUs 4 bis 7.

Im Colocate-Modus erhält vLLM über vllm_gpu_memory_utilization einen Anteil jeder Karte, standardmäßig 0,3. Auf einer RTX PRO 6000 Server Edition mit 96 GB und einem 8B-Modell sind das nach unserer Rechnung 28,8 GB, davon 16,1 GB Gewichte, es bleiben höchstens etwa 12,7 GB für den Cache: etwa 21 Rollouts mit 4.608 Token gleichzeitig. Ein Anteil von 0,5 gibt vLLM 48 GB und Platz für etwa 52 Rollouts und lässt 48 GB für die 16,7 GB LoRA-Zustände und die Aktivierungen des Trainings. Reicht der Speicher dann noch nicht, empfiehlt TRL vllm_enable_sleep_mode. Laut Dokumentation gilt dann: „the vllm parameters and cache will be offloaded during the optimization step“.

Der Server-Modus widmet der Erzeugung eine ganze Karte. Auf einer zweiten RTX PRO 6000 Server Edition ergibt vLLMs eigene Voreinstellung von 0,92 dann 88,3 GB, nach den Gewichten genug für etwa 119 Rollouts mit 4.608 Token, fast alle 128 des Beispielschritts auf einmal, während der Trainer die erste Karte für sich hat. Für ein Team, das regelmäßig mit GRPO trainiert, bevorzugen wir diese Aufteilung auf einem Server mit zwei Karten: keine Konkurrenz um Speicher, und jede Karte erledigt nur eine Art von Arbeit. Diese Zahlen sind nach unserer Schätzung Obergrenzen, gerechnet gegen die angegebene Kapazität; vLLM hält in seinem Anteil auch Aktivierungen und CUDA Graphs.

Wir liefern Server mit zwei, vier oder acht Karten für diese Arbeit; nennen Sie uns Modell, Antwortlänge und die geplanten Antworten je Prompt, und unser Team antwortet mit der Aufteilung und dem Speicher je Karte.

Drei Konfigurationen nach Modellgröße

Unsere Rechnung, Server-Modus: vLLM mit seiner Voreinstellung von 0,92 der angegebenen 96 oder 141 GB je Karte, abzüglich der BF16-Gewichte, geteilt durch den KV-Cache eines Rollouts mit 4.608 Token; Trainerzustände aus unserem Leitfaden zum GPU-Speicher, datenparallel, sofern nicht FSDP genannt ist. Obergrenzen; Aktivierungen und der Eigenbedarf von vLLM gehen ab.

8B. Zwei Karten wie oben, oder für Experimente eine Karte im Colocate-Modus. Unseren Einstiegsserver mit zwei Karten der RTX PRO 6000 Server Edition beschreibt unsere Seite zum Kauf eines Servers mit 2× RTX PRO 6000 Server Edition.

32B. Vier Karten der RTX PRO 6000 Server Edition: vLLM teilt die 65,5 GB Gewichte mit Tensor-Parallelität auf zwei Karten auf, und der Trainer läuft datenparallel auf den anderen beiden, mit je einer Kopie der 67,7 GB LoRA-Zustände und etwa 28 GB Rest für Aktivierungen, oder bei langen Sequenzen mit FSDP bei etwa 34 GB je Karte. Vier H200 NVL bieten mehr Cache und mehr Platz je Karte.

70B. Acht H200 NVL mit zwei 4-Wege-Brücken: vLLM läuft mit Tensor-Parallelität in einer NVLink-Domäne, und der Trainer verteilt die 144,4 GB LoRA-Zustände mit 36,1 GB je Karte auf die andere Domäne. Acht Karten der RTX PRO 6000 Server Edition halten dieselbe Aufteilung vom Speicher her, aber beide Hälften arbeiten dann über PCIe: die verteilten Gewichte des Trainers, nach der Rechnung in unserem Leitfaden zum Fine-Tuning-Server etwa 212 GB je Karte und Vorwärts- plus Rückwärtsdurchlauf, und der All-Reduce der Tensor-Parallelität in vLLM. vLLM schaltet seinen eigenen All-Reduce bei mehr als zwei reinen PCIe-GPUs standardmäßig ab, und vLLM 0.30.0 (22. September 2026) hat einen optionalen FlashInfer-All-Reduce über PCIe IPC für Systeme ohne NVLink eingeführt.

Verbindungen zwischen den Karten und der Gewichtsabgleich

Datenparalleles LoRA-Training verträgt PCIe gut: Nur die Gradienten der Adapter laufen durch den All-Reduce, nach der Rechnung unseres Leitfadens etwa 0,83 GB je Karte und Schritt für ein LoRA mit Rang 16 auf Llama 3.3 70B. GRPO bringt eine Übertragung hinzu, die überwachtes Fine-Tuning nicht kennt: Nach jedem Optimiererschritt schickt der Trainer die aktualisierten Gewichte per NCCL an vLLM. Wandern die vollständigen 16-Bit-Gewichte, wie bei einem Lauf mit allen Parametern unvermeidlich, sind das für ein 70B-Modell 141,1 GB je Schritt, über PCIe Gen5 mit 64 GB/s nach unserer Rechnung mindestens 2,2 Sekunden. Auf einem Server mit acht H200 NVL, der in einer NVLink-Domäne erzeugt und in der anderen trainiert, läuft auch diese Übertragung über PCIe.

Gegenüber einer Erzeugungsphase, die Hunderttausende Token dekodiert, sind einige Sekunden je Schritt ein kleiner Anteil. Wichtiger ist, dass NCCL zwischen allen Karten funktioniert: NVIDIAs NCCL-Dokumentation hält fest, dass „CUDA and the NVIDIA driver stack do not support IOMMU-enabled PCIe peer-to-peer memory transfer“, und unser P2P-Leitfaden für die RTX PRO 6000 macht daraus eine Abnahmeprüfung. TRLs Leitfaden weist außerdem darauf hin, dass vLLM seit Version 0.14.0 für dichte Modelle keine Offline-Skalierung über Datenparallelität mehr unterstützt; die Erzeugung skaliert bei ihnen daher über --tensor-parallel-size.

GRPO mit allen Parametern

Ein Lauf mit allen Parametern trainiert jedes Gewicht, nach der Zählung des ZeRO-Papiers mit 16 Byte je Parameter bei Mixed-Precision-Adam. Für Llama 3.1 8B sind das 128,5 GB Zustände, die zwei Karten der RTX PRO 6000 Server Edition mit FSDP bei 64,2 GB je Karte halten. Mit einer dritten Karte für vLLM und einer vierten für eine zweite vLLM-Instanz oder ein Referenzmodell passt ein 8B-GRPO-Lauf mit allen Parametern nach unserer Auslegung auf einen Server mit vier Karten. Liegt β über null, kommen für das Referenzmodell 16,1 GB in BF16 hinzu.

Ab 32B ist GRPO mit allen Parametern eine Aufgabe für mehrere Knoten. TRLs eigenes SLURM-Beispiel trainiert Qwen2.5-72B auf vier Knoten mit je acht GPUs unter DeepSpeed ZeRO-3 und nutzt einen fünften Knoten mit acht GPUs für vLLM mit --tensor-parallel-size 8. TRLs GRPO-Seite hält fest, dass „using ZeRO Stage 3 is required for training such models“. Für die meisten Projekte in Unternehmen ist ein LoRA-Lauf auf einem Server der realistische Rahmen; unsere Seite zum Server mit 8× H200 NVL beschreibt den Trainingsknoten mit 400G für einen zweiten Knoten.

Frameworks, Laufzeiten und der Einstieg

TRLs GRPOTrainer ist der direkteste Weg, und unser Vergleich von Unsloth, Axolotl und TRL auf mehreren GPUs behandelt die Multi-GPU-Unterstützung jedes Frameworks. verl, unter der Lizenz Apache-2.0, beschreibt sich als „a flexible, efficient and production-ready RL training library“, trainiert mit „FSDP, FSDP2 and Megatron-LM“, erzeugt mit „vLLM, SGLang and HF Transformers“, führt GRPO unter seinen Algorithmen und bietet „Multi-gpu LoRA RL support to save memory“. Unsloths Seite zu Qwen3.8 gibt an, dass sich das Modell mit RL „on 24GB VRAM“ trainieren lässt.

Veröffentlichte Laufzeiten geben eine Vorstellung von der Größenordnung. TRLs GRPO-Beispiel trainiert Qwen2.5-0.5B-Instruct auf DeepMath-103K und schreibt: „Distributed across 8 GPUs, the training takes approximately 1 day.“ Unsloth berichtet von 1.000 Schritten und etwa 4 Stunden RL-Training für gpt-oss-20b auf einer DGX Spark, wie unser Artikel zum Fine-Tuning auf der DGX Spark zitiert. Belohnungsdesign und Antwortlänge verändern diese Werte stärker als die Hardware; ein kurzer Pilot auf dem Zielserver legt die Schrittzeit fest.

Beide Phasen lasten die Karten aus, die Stromversorgung ist also für Trainingslast zu planen: nach unserer Schätzung (Karten mit 600 W, Prozessoren, plus 15 Prozent) etwa 1,8 kW aus dem Netz für zwei Karten der RTX PRO 6000 Server Edition mit zwei AMD EPYC 9135, etwa 3,4 kW für vier mit zwei EPYC 9355 und etwa 6,3 kW für acht H200 NVL mit zwei EPYC 9555; eine Messung am gelieferten System bestätigt den Wert.

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration nach Ihrer Arbeitslast und Ihrem Budget aus und antwortet innerhalb eines Werktages. Der Server wird vor der Lieferung montiert und getestet und in der EU mit einem Vertrag und einer Rechnung geliefert, mit Herstellergarantie auf jede Komponente; Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt. Die Einrichtung von TRL oder verl mit vLLM, die Belohnungsfunktionen und der Betrieb des trainierten Modells gehören zu unserem Service Private AI/ML mit unserem Engineering-Partner Vixen.UNO. Beschreiben Sie den geplanten Lauf im Formular unten.

FAQ