Ostatnio rozmawiałem z wieloma osobami pracującymi nad RL i zauważyłem coś interesującego — kiedy rozmowa schodzi na RL Infra, prawie zawsze koncentruje się na jednym temacie: zgodności treningu i wnioskowania. Jak utrzymać spójność polityk treningowych i wnioskowania. Jak kontrolować stopień off-policy. Jak radzić sobie z różnicą log prob po wprowadzeniu asynchroniczności. To wszystko są ważne pytania, bez wątpienia. Ale coraz bardziej jestem przekonany, że RL Infra cierpi na znaczną niewłaściwą alokację uwagi. Pożyczając ramy z ostatniej dyskusji z kolegą, nazywam to Efektem Baryłki RL Infra. Baryłka trzyma tylko tyle wody, ile wynosi jej najkrótszy element. Przepustowość i poprawność systemu treningowego RL działają w ten sam sposób — nie są określane przez moduł, który zoptymalizowałeś najbardziej, ale przez ten, który zaniedbałeś najbardziej. Zgodność treningu i wnioskowania może być tym elementem, który wyszlifowałeś i wypolerowałeś do perfekcji. Ale jeśli stabilność twojego piaskownicy jest katastrofą, twoja rura nagród ciągle się zatyka, a twoja end-to-end obserwowalność jest praktycznie nieistniejąca — jaki sens ma doskonała zgodność? Pojemność systemu jest już ograniczona przez każdy inny słaby ogniwo. To zasadniczo różni się od tego, jak działa optymalizacja systemu wnioskowania. Jako silnik wnioskowania, SGLang ma ogromną przestrzeń strategii do optymalizacji, ale jego pipeline jest stosunkowo liniowy — przetwarzanie żądania, wypełnienie wstępne, dekodowanie. Możesz izolować wąskie gardła moduł po module, a sprzężenie między komponentami jest zarządzalne. Trening RL to zupełnie inna bestia — koszmarnie złożona pętla multi-systemowa: generacja rolloutów zależy od silnika wnioskowania, obliczanie nagród może zależeć od zewnętrznych środowisk, aktualizacje polityki zależą od frameworka treningowego, a następna runda rolloutów zależy od zaktualizowanej polityki. Jeśli jakiekolwiek pojedyncze ogniwo pęknie, cała pętla się załamuje. Niestety, z tego, co widziałem w ciągu ostatniego roku, wciąż istnieje wiele poważnie niedocenianych słabych punktów: Niezawodność piaskownicy agenta. To prawdopodobnie najbrudniejsza, najbardziej wyczerpująca i najmniej akademicko efektowna praca w RL Infra dzisiaj. RL oparty na agentach potrzebuje niezawodnej piaskownicy wykonawczej dla rolloutów — brzmi prosto, okazuje się być koszmarem. Stabilność kontenerów, opóźnienie zimnego startu, niezawodność izolacji zasobów, zarządzanie stanem piaskownicy — te rzeczy wydają się być odseparowane na papierze, ale dostępne na rynku produkty piaskownicowe konsekwentnie nie spełniają oczekiwań. Piaskownica agenta nie jest problemem algorytmicznym, ale bezpośrednio określa twoją efektywność generowania danych, co z kolei określa twoją prędkość treningu. Obserwowalność. Debugowanie wstępnego treningu jest stosunkowo proste — obserwuj krzywą straty, sprawdź normę gradientu, a zazwyczaj możesz zlokalizować problem. Ale debugowanie RL wymaga możliwości śledzenia end-to-end: rozkłady jakości rolloutów, statystyki nagród, stopień off-policy, wielkości aktualizacji polityki, a nawet przypisanie różnicy logprob (czy różnica pochodzi z strony wnioskowania, czy z opóźnienia wersji asynchronicznego treningu?). Niestety, większość zespołów, które napotkałem, zasadniczo działa w ciemno w tych wymiarach. To prowadzi do niezręcznej sytuacji — gdy wyniki treningu są słabe, nawet nie wiesz, który moduł obwiniać. Dylemat skali. Wiele optymalizacji RL Infra pokazuje wymierny wpływ tylko przy wystarczającej skali. Eksperymenty w małej skali często nie ujawniają żadnej znaczącej różnicy — nie dlatego, że optymalizacja jest bezużyteczna, ale dlatego, że szum jest zbyt wysoki, a liczba kroków zbyt niska, aby sygnał mógł się ujawnić. Jednak eksperymenty w dużej skali są nieproporcjonalnie drogie. To tworzy błędne koło: nie możesz udowodnić, że twoja optymalizacja działa w małej skali, więc nie możesz zabezpieczyć zasobów na eksperymenty w dużej skali; a bez walidacji w dużej skali, twoja optymalizacja na zawsze utknie w "teoretycznie powinna pomóc." Inwestycje branży w RL Infra są poważnie niedopasowane do jej rzeczywistej złożoności. Większość zespołów traktuje to jako prowizoryczne rozwiązanie na wierzchu infrastruktury wstępnego treningu — biorą gotowy framework treningowy, montują silnik wnioskowania, łączą je razem skryptami i nazywają to RL Infra. Ale złożoność systemu treningu RL i wstępnego treningu nie jest nawet w tej samej lidze. Pipeline wstępnego treningu są liniowe, jednorodne i mają praktycznie zerowe zewnętrzne zależności. Pipeline treningu RL są cykliczne, heterogeniczne i silnie zależne od zewnętrznych środowisk. Zastosowanie architektonicznego myślenia z pierwszego do drugiego na pewno uderzy w ścianę na dużą skalę. Prawdziwa trudność w inżynierii systemów nie polega na pchaniu jakiegokolwiek pojedynczego modułu do jego ekstremum — chodzi o zrozumienie sprzężenia między modułami i globalnej przestrzeni kompromisów. To prawda dla systemów wnioskowania, a jeszcze bardziej dla RL Infra, gdzie wymiary sprzężenia są większe, pętle sprzężenia są dłuższe, a gęstość informacji do debugowania jest znacznie niższa. Chcę zakończyć dwoma pytaniami, nad którymi się zastanawiałem, i chętnie usłyszę od innych pracujących w tej dziedzinie: Gdzie dokładnie zaczynają się malejące zwroty z zgodności treningu i wnioskowania? Gdy wprowadzona jest asynchroniczność, stopień off-policy jest już znaczny. Na tej podstawie, czy przyrostowa korzyść z dalszej zgodności jest rzeczywiście wyższa ROI niż inwestowanie tego samego wysiłku inżynieryjnego w stabilność piaskownicy, optymalizację rury nagród lub infrastrukturę obserwowalności? Mam swoją własną wstępną odpowiedź, ale myślę, że to pytanie zasługuje na poważne przemyślenie przez więcej osób — zamiast domyślnie traktować zgodność jako najwyższy priorytet tylko dlatego, że jest to najbardziej widoczny temat. I jest powód, dla którego jest to najbardziej widoczne: zgodność treningu i wnioskowania ma czystą matematyczną formalizację i produkuje eleganckie ablacje — to naturalne dopasowanie do prac naukowych. Ale jak napisać pracę o stabilności piaskownicy? Jak ująć niezawodność orkiestracji kontenerów jako akademicką historię? Nie możesz, naprawdę. Więc te problemy są zbiorowo ignorowane. Nawet jeśli system RL Infra osiągnie zgodność treningu i wnioskowania na poziomie bitowym, ogólna efektywność może wciąż być opłakana — ponieważ wąskie gardło przeniosło się gdzie indziej już dawno temu. W jakim stopniu RL Infra może być standaryzowane? Systemy wnioskowania mają stosunkowo dobrze zdefiniowane metryki benchmarkowe — TTFT, TBT, Przepustowość. Te obiektywne wskaźniki pozwalają nam wyraźnie ocenić wpływ optymalizacji. Ale jakie są standardy oceny dla RL Infra? Przepustowość treningu? Efektywność próbkowania? Czas rzeczywisty end-to-end? Optymalna architektura może się dramatycznie różnić w zależności od scenariuszy (generacja kodu vs. agent vs. rozumowanie). Jeśli nawet nie mamy konsensusu co do tego, jak wygląda "dobry RL Infra", to wiedza inżynieryjna w tej dziedzinie będzie niezwykle trudna do zgromadzenia i ponownego wykorzystania. Czy RL jest krytyczną ścieżką do poprawy możliwości modeli — ta ocena wciąż się rozwija. Ale jeśli odpowiedź brzmi tak, to Infra jest najbardziej niedocenianym wąskim gardłem na tej ścieżce. Nie dlatego, że nikt nad tym nie pracuje, ale dlatego, że zbiorowa uwaga jest niewłaściwie alokowana. Okrutność Efektu Baryłki jest taka: niezależnie od tego, jak wysoki jest twój najwyższy element, nie może uratować systemu. RL Infra nie jest sprawą drugorzędną. To niezależna dziedzina inżynierii systemów o wysokiej złożoności. Tylko traktując ją jako obywatela pierwszej klasy, będziemy mieli jakąkolwiek szansę na skalowanie RL.