Останнім часом я спілкувався з багатьма людьми, які працюють над RL, і помітив дещо цікаве — коли розмова переходить до RL Infra, вона майже завжди тягнеться до однієї теми: вирівнювання поїзд-інференцій. Як підтримувати послідовність політик навчання та висновків. Як контролювати ступінь поза політикою. Як впоратися з логарифмічною диференціальністю після введення асинхронності. Це всі важливі питання, без сумніву. Але я дедалі більше переконаний, що RL Infra страждає від значного неправильного розподілу уваги. Запозичуючи формулювання з нещодавньої дискусії з колегою, я називаю це ефектом бочки RL Infra. Бочка вміщує лише стільки води, скільки її найкоротший посох. Пропускна здатність і коректність системи навчання RL працюють так само — вони визначаються не модулем, який ви найбільше оптимізували, а тим, який ви найбільше ігнорували. Train-inference align — це може бути посох, який ви відшліфували і відполірували до досконалості. Але якщо ваша стабільність у пісочниці — це катастрофа, ваш конвеєр винагород постійно зависає, а ваша наскрізна спостережуваність практично відсутня — який сенс у ідеальному вирівнюванні? Пропускна здатність системи вже обмежена всіма іншими слабкими ланками. Це принципово відрізняється від оптимізації системи висновків. Як двигун висновку, SGLang має величезний простір стратегій для оптимізації, але його конвеєр відносно лінійний — запит процесу, попереднє заповнення, декодування. Можна ізолювати вузькі місця модуль за модулем, і зв'язок між компонентами керований. Навчання RL — це зовсім інша справа: кошмарно складний багатосистемний цикл: генерація запуску залежить від інференційного двигуна, обчислення винагороди може залежати від зовнішніх оточень, оновлення політик — від навчальної структури, а наступний раунд впровадження залежить від оновленої політики. Якщо будь-яке окреме зв'язок розривається, вся петля руйнується. На жаль, з того, що я бачив за минулий рік, досі існує багато сильно недооцінених слабких місць: Надійність Agent Sandbox. Це, мабуть, найбрудніша, найвиснажливіша і найменш академічно гламурна робота в RL Infra сьогодні. Агентному RL потрібна надійна пісочниця для реалізації — звучить просто, але виявляється справжнім кошмаром. Стабільність контейнера, латентність холодного запуску, надійність ізоляції ресурсів, управління станом пісочниці — ці речі виглядають роз'єднаними на папері, але продукти, доступні на ринку, постійно поступаються очікуванням. Sandboxing агентів — це не проблема алгоритму, але він безпосередньо визначає ефективність генерації даних, а це, у свою чергу, визначає швидкість тренувань. Спостережуваність. Попереднє навчання з налагодження досить просте — слідкуйте за кривою втрат, перевіряйте норму градієнта, і зазвичай можна точно визначити проблему. Але налагодження RL вимагає наскрізних можливостей трасування: розгортання якісних розподілів, статистики винагород, ступеня поза політикою, величини оновлень політик і навіть атрибуція logprob diff (різниця виникає з боку висновку, чи через запізнення версій асинхронного навчання?). На жаль, більшість команд, з якими я стикався, фактично літають у цих вимірах навмання. Це призводить до незручної ситуації — коли результати навчання погані, ви навіть не знаєте, який модуль звинувачувати. Дилема з масштабами. Багато оптимізацій RL Infra показують вимірюваний вплив лише при достатньому масштабі. Невеликі експерименти часто не виявляють суттєвої різниці — не тому, що оптимізація марна, а тому, що шум занадто високий, а кількість кроків занадто низька, щоб сигнал міг з'явитися на поверхні. Проте масштабні експерименти надто дорогі. Це створює порочне коло: ви не можете довести, що оптимізація працює в малому масштабі, тому не можете забезпечити ресурси для масштабних експериментів; І без масштабної валідації ваша оптимізація назавжди застрягає на «теоретично це має допомогти». Інвестиції галузі в RL Infra суттєво не відповідають реальній складності. Більшість команд сприймають це як патчджіп поверх попередньої інфраструктури — беруть готову навчальну структуру, встановлюють інференційний двигун, склеюють їх скриптами і називають RL Infra. Але складність системи RL тренувань і передпідготовки навіть не на одному рівні. Конвеєри попереднього навчання є лінійними, однорідними і практично не мають зовнішніх залежностей. Конвеєри навчання RL є циклічними, гетерогенними і сильно залежать від зовнішніх умов. Застосування архітектурного мислення першого до другого гарантовано призведе до масштабної стіни. Справжня складність системної інженерії полягає не в тому, щоб доводити будь-який модуль до крайності, а в розумінні зв'язку між модулями та глобальним простором компромісу. Це справедливо для систем виведення, а особливо для RL Infra, де розміри зв'язку більші, петлі зворотного зв'язку довші, а щільність інформації для налагодження значно нижча. Я хочу завершити двома питаннями, над якими довго розмірковував, і мені було б цікаво почути думки інших, хто працює в цій сфері: Де саме починають зменшуватися граничні віддачі від вирівнювання поїздів і інференцій? Після введення асинхронності ступінь позаполітики вже є значним. На цьому базовому рівні, чи є поступова вигода від подальшого узгодження дійсно вищою віддачею інвестицій, ніж інвестування тих самих інженерних зусиль у стабільність пісочниці, оптимізацію конвеєрів винагород чи інфраструктуру спостережуваності? У мене є власна попередня відповідь, але я вважаю, що це питання заслуговує на серйозну увагу більшої кількості людей — а не на те, щоб за замовчуванням ставати узгодження як пріоритет лише тому, що це найпомітніша тема. І є причина, чому це найпомітніше: вирівнювання поїзд-інференція має чисту математичну формалізацію і дає елегантні абляції — це природно підходить для статей. Але як написати статтю про стабільність пісочниці? Як ви подаєте надійність оркестрації контейнерів як академічну історію? Ти не можеш, справді. Тож ці проблеми колективно ігнорують. Навіть якщо система RL Infra досягає узгодження на рівні поїзда та виведення, загальна ефективність все одно може бути низькою — бо вузьке місце давно перемістилося в інше місце. Наскільки можна стандартизувати RL Infra? Системи висновку мають відносно чітко визначені еталонні метрики — TTFT, TBT, пропускну здатність. Ці об'єктивні показники дозволяють нам чітко оцінити вплив оптимізацій. Але які стандарти оцінки для RL Infra? Пропускна здатність тренувань? Ефективність зразків? Час на годиннику від кінця до кінця? Оптимальна архітектура може суттєво відрізнятися залежно від сценарію (генерація коду, агент проти міркування). Якщо ми навіть не маємо консенсусу щодо того, як виглядає «хороша RL інфраструктура», то інженерні знання в цій галузі буде надзвичайно складно накопичити та повторно використати. Чи є RL критичним шляхом для покращення можливостей моделей — це рішення ще розвивається. Але якщо відповідь так, то Infra — це найбільш недооцінене вузьке місце на цьому шляху. Не тому, що ніхто над цим не працює, а тому, що колективна увага неправильно розподілена. Жорстокість ефекту бочки така: незалежно від того, наскільки високий ваш найвищий посох, він не може врятувати систему. Інфраструктура RL не є другорядною проблемою. Це незалежна, високоскладна галузь системної інженерії. Тільки ставитися до нього як до громадянина першого сорту ми матимемо шанс зробити реальний рівень масштабованим.