SyncAI.news, a Varaisys broadcasting
vLLM V0 to V1: Correctness Before Corrections in RL
HF

Hugging Face Blog

· 1 min read

AI LabsHugging Face Blog

vLLM V0 to V1: Correctness Before Corrections in RL

PipelineRL uses vLLM as the inference engine for rollout generation. The inference engine samples tokens and returns token logprobs; the trainer uses those logprobs to compute policy ratios, KL, clip rate, entropy, and reward. Any discrepancy in how those logprobs are computed can change the training dynamics. This is the train-inference mismatch we needed to eliminate during the vLLM V0 to V1 migration.

TL;DR. vLLM V1 matched our vLLM V0 reference after we fixed four things: processed rollout logprobs, V1-specific runtime defaults, the inflight weight-update path, and the fp32 lm_head used for the final projection. We fixed the backend behavior before changing the RL objective.

The reference run used vLLM 0.8.5; the V1 runs used vLLM 0.18.1. Figure 1 shows the final result. The red run is the initial V1 attempt, and the green run is the final V1 run after the fixes described below.

Migration Objective

vLLM V1 is a substantial rewrite of the V0 engine. Our migration target was therefore deliberately narrow:

  1. verify that V1 returned rollout logprobs in the form the trainer expected
  2. rerun the same workload against the V0 reference
  3. evaluate objective-level changes only after backend parity was restored

The first visible symptoms appeared in:

  • clamp_log_ratio_new_old_indicator
  • kl_new_old
  • entropy
  • reward

Those metrics came from a GSPO training run, the objective used for this experiment. The same class of mismatch can surface in PPO, GRPO, or any online RL system that treats rollout-side logprobs as part of the optimization target.

The initial V1 run showed the problem clearly. The trainer-side logprobs and reward moved away from the V0 reference early in training.

The same pattern appears in the trainer metrics. Clip rate is the easiest signal to read in the initial comparison.

Failure Modes

We separated the possible causes into three layers:

V1 Backend Fixes

Logprob Semantics

The required setting was:

  • logprobs-mode=processed_logprobs

Original source

This story was published by Hugging Face Blog. SyncAI.news shows a preview; the complete article is on the publisher's site.

Read the full story on huggingface.co

Similar News