vLLM V1 вернул поведение V0 после исправлений логвероятностей в PipelineRL

Опубликовано 6 мая 2026 г. Авторы: Rafael Pardinas и Ehsan Kamalloo. При миграции inference‑движка vLLM с V0 (0.8.5) на V1 (0.18.

Команда ServiceNow протестировала переход inference‑движка vLLM с версии V0 на V1 в PipelineRL при генерации rollout‑ов и заметила, что небольшие различия в вычислении логвероятностей токенов существенно изменяли динамику online‑обучения. В их конфигурации vLLM семплировал токены и возвращал logprobs, которые тренер использовал для расчёта policy ratios, KL, clip rate, entropy и reward. Сравнение запусков показало: эталонный поток использовал vLLM 0.8.5, первые прогонные тесты V1-vLLM 0.18. начальный V1‑прогон отклонился от поведения V0 уже на ранних шагах, тогда как финальный V1 после правок вернул метрики на траекторию V0.

Авторы выделили три класса причин расхождений: семантическое несоответствие логвероятностей, отличия в путях выполнения (runtime‑дефолты, кеширование и обработка запросов) и возможная необходимость скорректировать сам RL‑objective. Миграционный план предусматривал узкую последовательность действий: сначала добиться паритета бэкенда — то есть того, как именно возвращаются логвероятности — затем повторить рабочую нагрузку и только после подтверждённого паритета рассматривать изменение целевой функции. исправления бэкенда предотвратили преждевременную правку RL‑цели и снизили риск ошибочной диагностики проблем обучения.

В статье перечислены конкретные правки, которые потребовались для достижения паритета: включение обработанных распределений вместо сырых логитов (logprobs.mode=processed_logprobs), выравнивание V1‑специфичных runtime‑дефолтов, коррекция пути обновления inflight weight → update и использование fp32 для lm_head при финальной проекции. Включение processed_logprobs устранило заметный средний оффсет логвероятностей, но для полного совпадения метрик потребовались и остальные изменения реализации.

Эксперимент проводился на GSPO‑прогоне (тип online‑RL). Валидация показала, что clip rate оказался самым информативным сигналом разрыва между rollout и тренером, а тренер‑сторонние logprobs и reward первыми ушли от эталона в начальном V1‑прогоне. Диагностика велась «снизу вверх»: сначала последовательно устраняли различия в backend‑поведении и только убедившись в паритете приступали к оценке изменений в оптимизируемом объекте. После всех исправлений среднее отношение политик осталось очень близким к 1.0, а значения clip rate, KL, entropy и reward для финального V1 стали сопоставимы с эталоном.