Migration von vLLM V0 zu V1: Ein Fokus auf Backend-Korrektheit in Reinforcement Learning

Von vLLM V0 zu V1: Korrektheit vor Korrekturen im Reinforcement Learning

Die Weiterentwicklung von vLLM, einer zentralen Inferenz-Engine für Large Language Models (LLMs), von Version V0 zu V1 stellt einen entscheidenden Fortschritt dar. Diese Migration, insbesondere im Kontext des Reinforcement Learning (RL), unterstreicht die Wichtigkeit einer präzisen Backend-Implementierung. Das Hauptziel bestand darin, die Korrektheit der zugrunde liegenden Prozesse sicherzustellen, bevor Anpassungen auf der Ebene der Lernziele vorgenommen wurden. Dieser Ansatz ist von grundlegender Bedeutung, um die Zuverlässigkeit und Effizienz von LLM-Trainingsprozessen zu gewährleisten.

Die Herausforderung: Diskrepanzen in der Trainingsdynamik

Die PipelineRL-Architektur nutzt vLLM als Inferenz-Engine zur Generierung von Rollouts. Dabei werden Token abgetastet und deren Log-Wahrscheinlichkeiten (Logprobs) zurückgegeben. Diese Logprobs sind essenziell für den Trainer, um Policy-Ratios, KL-Divergenz, Clip-Rate, Entropie und Belohnungen zu berechnen. Jede Inkonsistenz in der Berechnung dieser Logprobs kann die Trainingsdynamik erheblich beeinflussen. Die Migration von vLLM V0 (Version 0.8.5) zu V1 (Version 0.18.1) offenbarte zunächst erhebliche Abweichungen in diesen Metriken im Vergleich zur V0-Referenz. Die anfänglichen V1-Durchläufe zeigten eine deutliche Abweichung der trainerseitigen Logprobs und Belohnungen vom V0-Referenzwert bereits früh im Training, was auf ein grundlegendes Problem hindeutete.

Analyse der Fehlerursachen

Die potenziellen Ursachen für die beobachteten Diskrepanzen wurden in drei Kategorien unterteilt:

• Semantische Diskrepanz: Das Backend liefert Logprobs mit einer anderen Bedeutung als vom Trainer erwartet.
• Inferenzpfad-Diskrepanz: Das Backend verwendet unterschiedliche Laufzeit-Standardeinstellungen für Caching, Scheduling oder Anfragenbehandlung, wodurch dieselben Prompts unterschiedliche Ausführungspfade nehmen.
• Objektive Diskrepanz: Das RL-Ziel erfordert eine Korrektur aufgrund verbleibender Veralterung oder Backend-Inkonsistenzen.

Die anfängliche Vermutung, dass das Problem in der dritten Kategorie liege, erwies sich als verfrüht. Eine nützliche Diagnose ergab sich erst, als die ersten beiden Kategorien als Backend-Verhaltensprobleme behandelt und zuerst ausgeschlossen wurden.

Die Behebung von Backend-Problemen in V1

Semantik der Log-Wahrscheinlichkeiten

Das erste identifizierte Problem war semantischer Natur. Standardmäßig gab vLLM V1 Logprobs aus den rohen Modell-Outputs zurück, bevor Logits-Nachbearbeitungsschritte wie Temperaturskalierung, Penalisierungen und Top-k/Top-p-Filterung angewendet wurden. PipelineRL erwartete jedoch Logprobs aus der verarbeiteten Verteilung, die vom Sampler verwendet wird. Die Lösung bestand darin, die Einstellung logprobs-mode=processed_logprobs zu aktivieren. Dies eliminierte eine offensichtliche mittlere Verschiebung in den Rollout-Logprobs und stellte sicher, dass die mittlere Policy-Ratio nahe 1.0 blieb.

Anpassung der Laufzeit-Standardeinstellungen

Die frühen V1-Durchläufe mischten die Engine-Version mit V1-Laufzeit-Standardeinstellungen. Um Parität mit V0 herzustellen, mussten bestimmte Einstellungen explizit angepasst werden:

• Prefix-Caching: In V1 standardmäßig aktiviert, in V0 jedoch anders behandelt. Das Deaktivieren des Prefix-Cachings (enable-prefix-caching: false) eliminierte eine V1-spezifische Variable, die zu Inkonsistenzen führen konnte, insbesondere bei der Wiederverwendung von Zuständen, die vor einer Gewichtsaktualisierung berechnet wurden.
• Asynchrones Scheduling: Ebenfalls in V1 standardmäßig aktiviert, wurde es für die Paritätsprüfung deaktiviert (async-scheduling: false).

Diese Anpassungen stellten sicher, dass der Inferenzpfad deterministisch und synchron mit dem Trainer blieb.

Synchronisation von Inflight-Gewichtsaktualisierungen

Die Gewichtssynchronisation musste ebenfalls an das Online-RL-Update-Modell angepasst werden. Während V0 Ausführungen an einer Engine-Grenze blockierte, neue Gewichte lud und ohne explizite Cache-Invalidierung fortfuhr, musste V1 so konfiguriert werden, dass es dieses Verhalten nachbildete. Dies wurde durch die Verwendung von engine.pause_generation(mode="keep", clear_cache=False) erreicht, um sicherzustellen, dass zwischengespeicherte Zustände während der Aktualisierung intakt blieben. Dies reduzierte signifikant die Persistenz von Verzögerungen im Training.

Die verbleibende Lücke: fp32 lm_head

Trotz aller Backend-Fixes blieb eine numerische Diskrepanz bestehen. Der Trainer verwendete für die finale Projektion einen fp32 lm_head, eine 32-Bit-Gleitkomma-Sprachmodell-Kopf. Das Rollout-Backend von V1 entsprach dieser Präzision standardmäßig nicht. Da kleine Änderungen in den Logits direkte Auswirkungen auf Policy-Ratios, KL-Divergenz und Clipping haben, war es entscheidend, auch im V1-Backend die fp32-Berechnung für den Sprachmodell-Kopf zu erzwingen. Erst mit dieser letzten Anpassung erreichte die V1-Version eine vollständige Parität mit der V0-Referenz, was sich in einer exakt übereinstimmenden Belohnungskurve zeigte.

Warum Korrektheit vor Korrekturen?

Die Entscheidung, Backend-Korrektheit vor objektiven Korrekturen zu priorisieren, ist methodisch fundiert. Objektive Korrekturen wie Truncated Importance Sampling oder Importance-Ratio Reweighting sind wertvolle Werkzeuge, wenn Rollouts absichtlich veraltet, asynchron generiert oder von einem Backend stammen, dessen Äquivalenz zur Trainer-Policy nicht gewährleistet ist. Im vorliegenden Fall lag das Problem jedoch in der grundlegenden Inferenz-Korrektheit. Hätte man an diesem Punkt eine objektive Korrektur hinzugefügt, wären zwei unterschiedliche Fragen vermischt worden:

• Produziert das Inferenz-Backend die richtigen Logprobs?
• Benötigt das Ziel, bei korrekten Logprobs, noch eine Off-Policy- oder asynchrone Korrektur?

Diese Fragen müssen getrennt voneinander betrachtet werden. Eine objektive Korrektur könnte ansonsten fehlerhaftes Inferenz-Backend-Verhalten kompensieren, was die Interpretation der Trainingskurve erschweren würde. Die primäre Lehre aus dieser Migration ist daher klar: Zuerst die Backend-Korrektheit herstellen, dann Korrekturen für die verbleibende Diskrepanz hinzufügen. Nach der Wiederherstellung der Inferenz-Parität können weitere Verbesserungen im Bereich der asynchronen/Off-Policy-Bereinigung vorgenommen werden, wie beispielsweise das explizite Speichern von Behavior-Policy-Logprobs, die Neuberechnung trainerseitiger alter Policy-Logprobs zur Optimierungszeit und die Trennung von Backend-Mismatch-Korrekturen vom Policy-Update-Verhältnis.

Ausblick und Implikationen für die KI-Entwicklung

Die erfolgreiche Migration von vLLM V0 zu V1 durch die Priorisierung der Backend-Korrektheit schafft eine stabilere und zuverlässigere Grundlage für das Training und den Einsatz von LLMs, insbesondere in RL-Kontexten. Diese methodische Herangehensweise ist beispielhaft für die Entwicklung robuster KI-Systeme und bietet eine klare Richtlinie für zukünftige Architektur-Upgrades und die Fehlerbehebung in komplexen KI-Pipelines.

Bibliographie

• Hugging Face Blog. (2026, 6. Mai). vLLM V0 to V1: Correctness Before Corrections in RL. Abgerufen von https://huggingface.co/blog/ServiceNow-AI/correctness-before-corrections
• AIToolly. (2026, 7. Mai). vLLM V1: Correctness in Reinforcement Learning Explained. Abgerufen von https://aitoolly.com/ai-news/article/2026-05-07-vllm-v0-to-v1-prioritizing-correctness-before-corrections-in-reinforcement-learning-workflows
• NewMaxx. (2026, 6. Mai). vLLM V0 to V1: Correctness Before Corrections in RL. Abgerufen von https://borecraft.com/2026/05/06/vllm-v0-to-v1-correctness-before-corrections-in-rl/
• Hyper.AI. (2026, 3. Mai). vLLM V1 Shifts Focus to Correctness Before RL Fine-Tuning. Abgerufen von https://hyper.ai/en/stories/11e756df6b84c8785d2c727dd85332d7
• Databubble. (2026, 6. Mai). vLLM V0 to V1: Correctness Before Corrections in RL · via huggingface. Abgerufen von https://databubble.co/news/vllm-v0-to-v1-correctness-before-corrections-in-rl
• vLLM. (o. D.). Reinforcement Learning from Human Feedback. Abgerufen von https://docs.vllm.ai/en/v0.20.1/training/rlhf/
• vLLM Blog. (2025, 27. Januar). vLLM V1: A Major Upgrade to vLLM's Core Architecture. Abgerufen von https://blog.vllm.ai/2025/01/27/v1-alpha-release.html
• arXiv. (2026, 26. Januar). [2601.18984v1] Save the Good Prefix: Precise Error Penalization via Process-Supervised RL to Enhance LLM Reasoning. Abgerufen von http://arxiv.org/abs/2601.18984v1
• arXiv. (2024, 19. September). [2409.12917v1] Training Language Models to Self-Correct via Reinforcement Learning. Abgerufen von https://arxiv.org/abs/2409.12917v1