vLLM V1 iguala a V0 tras corregir cuatro diferencias críticas que afectaban al entrenamiento RL

Al migrar su motor de inferencia de vLLM V0 a V1, el equipo de ServiceNow que usa PipelineRL detectó discrepancias entre los logprobs devueltos por el motor y los que esperaba el entrenador, lo que desvió métricas de entrenamiento clave como clip rate, KL, entropía y reward. Tras investigar el problema y aplicar correcciones en el backend, una ejecución final con V1 quedó cercana a la referencia previa con V0.

En el flujo de PipelineRL, vLLM genera rollouts muestreando tokens y devolviendo logprobs que el entrenador emplea para calcular policy ratios, KL, clip rate, entropía y reward. La referencia empleó vLLM 0.8.5 mientras que las pruebas de V1 se realizaron con vLLM 0.18.1; las comparaciones visuales aportadas por el equipo muestran una primera ejecución de V1 que se separa de V0 y una posterior que se realinea tras las correcciones.

Los autores clasificaron las fallas en tres capas: un mismatch semántico (logprobs con distinto significado), un mismatch en la ruta de inferencia (diferencias en defaults de runtime, caché, scheduling o manejo de peticiones) y un posible mismatch del objetivo RL. Aunque inicialmente se sospechó del objetivo, el diagnóstico práctico avanzó tratando primero las dos capas de backend, que resultaron ser las fuentes más relevantes.

Antes de modificar la formulación del objetivo aplicaron cuatro correcciones concretas en el backend: usar logprobs ya procesados en lugar de logits crudos (configuración requerida: logprobs_mode=processed_logprobs), alinear los defaults de runtime específicos de V1, corregir la ruta de actualización de inflight weight y emplear un lm_head en fp32 para la proyección final. El ajuste de processed_logprobs eliminó un sesgo medio evidente en los logprobs.

El experimento, realizado con un entrenamiento GSPO, evidencia que este tipo de discrepancia no es exclusiva de un algoritmo: puede aparecer también en PPO, GRPO u otros sistemas de RL online que incorporan logprobs de rollout al objetivo. Métricas como clamp_log_ratio_new_old_indicator, kl_new_old, entropy y reward reflejan cómo un desajuste en la inferencia se propaga y distorsiona la señal de aprendizaje.

Como recomendación práctica, los desarrolladores deberían verificar la paridad de backend antes de cambiar la formulación del objetivo: comprobar el postprocesado de logits, defaults de runtime, rutas de actualización de pesos y la precisión del lm_head, y comparar cambios frente a una referencia conocida (en este caso, vLLM 0.8.5 vs vLLM 0.18.1). Tras aplicar las cuatro correcciones señaladas, la ejecución con V1 reprodujo de cerca la trayectoria de V0 en clip rate, KL, entropía y reward.