vLLM V1: jak ServiceNow rozwiązało problemy migracji w uczeniu ze wzmocnieniem

Zespół z ServiceNow AI opisał szczegóły swojej migracji z vLLM V0 do V1 w kontekście trenowania modeli z uczeniem ze wzmocnieniem. Artykuł opublikowany na Hugging Face przedstawia cztery kluczowe problemy, które musieli rozwiązać, aby zachować zgodność obliczeniową między wersjami.

Kluczowe wnioski

• Problem zgodności logprobs: vLLM V1 domyślnie zwracał nieprzetworzone prawdopodobieństwa logarytmiczne, podczas gdy system trenujący oczekiwał wartości po przetworzeniu przez sampler.
• Konieczne poprawki konfiguracji: Zespół musiał wyłączyć domyślne ustawienia V1 jak prefix caching i async scheduling, aby zachować zgodność z V0.
• Synchronizacja wag w locie: Problemy z aktualizacją wag modelu podczas wykonywania zapytań wymagały specjalnego traktowania w kontekście online RL.
• Precyzja obliczeń: Użycie fp32 dla finalnej projekcji lm_head okazało się kluczowe dla zachowania identycznych wyników.

Cel migracji i pierwsze symptomy

Migracja z vLLM 0.8.5 do 0.18.1 wymagała szczególnej ostrożności ze względu na fundamentalną przepisanie silnika w wersji V1. Zespół przyjął deliberatnie wąski cel: zweryfikować, że V1 zwraca prawdopodobieństwa logarytmiczne w formie oczekiwanej przez system trenujący, a następnie odtworzyć to samo obciążenie względem referencyjnego V0.

Pierwsze symptomy problemów pojawiły się w metrykach trenera: clamp_log_ratio_new_old_indicator, kl_new_old, entropy i reward. Te wskaźniki pochodziły z treningu GSPO (Group Supervised Policy Optimization), ale podobne problemy mogą wystąpić w PPO, GRPO lub dowolnym systemie online RL, który traktuje logprobs z rolloutów jako część celu optymalizacji.

Identyfikacja i rozwiązanie problemów

Zespół podzielił możliwe przyczyny na trzy kategorie: semantyczne niepasowanie (backend zwraca logprobs o innym znaczeniu), niepasowanie ścieżki wnioskowania (różne domyślne ustawienia runtime) oraz niepasowanie celu RL.

Semantyka logprobs stanowiła pierwszy problem. vLLM V1 domyślnie zwraca prawdopodobieństwa z surowych wyjść modelu, przed post-processingiem jak skalowanie temperatury, kary czy filtrowanie top-k/top-p. PipelineRL oczekiwał logprobs z przetworzonego rozkładu używanego przez sampler. Rozwiązanie wymagało ustawienia: logprobs-mode=processed_logprobs.

Ustawienia runtime w wczesnej wersji V1 mieszały wersję silnika z domyślnymi ustawieniami V1, włączając prefix caching i async scheduling. Dla zgodności zespół jawnie wyłączył te funkcje: enable-prefix-caching: false i async-scheduling: false.

Aktualizacje wag w locie wymagały dopasowania modelu synchronizacji V1 do zachowania V0. Zamiast rygorystycznego drenaża zapytań i czyszczenia cache'y przy każdej aktualizacji, zespół zreplikował zachowanie V0: blokowanie wykonania na granicy silnika, ładowanie nowych wag i wznowienie bez jawnego czyszczenia stanu.

Finalnym elementem było użycie fp32 dla lm_head — ostatecznej projekcji modelu, która okazała się kluczowa dla zachowania identycznych wyników numerycznych.

Po wszystkich poprawkach finalna wersja V1 osiągnęła trajektorię bardzo bliską referencyjnej V0 we wszystkich kluczowych metrykach: clip rate, KL, entropia i reward, potwierdzając skuteczność podejścia „poprawność przed korekcjami”.