Я в последнее время много общался с людьми, работающими над RL, и заметил нечто интересное — всякий раз, когда разговор заходит о RL Infra, он почти всегда сводится к одной теме: согласование обучения и вывода. Как сохранить согласованность между политиками обучения и вывода. Как контролировать степень офф-политики. Как справляться с разницей логарифмических вероятностей после введения асинхронности. Все это важные вопросы, без сомнения. Но я все больше убеждаюсь, что RL Infra страдает от значительного неправильного распределения внимания. Заимствуя формулировку из недавнего обсуждения с коллегой, я называю это Эффектом Бочки RL Infra. Бочка удерживает только столько воды, сколько позволяет ее самая короткая планка. Пропускная способность и корректность системы обучения RL работают так же — они не определяются модулем, который вы оптимизировали больше всего, а тем, который вы пренебрегли больше всего. Согласование обучения и вывода может быть той планкой, которую вы отшлифовали и отполировали до совершенства. Но если ваша стабильность песочницы — это катастрофа, ваш конвейер вознаграждений постоянно застревает, а ваша сквозная наблюдаемость практически отсутствует — какая польза от идеального согласования? Вместимость системы уже ограничена каждой другой слабой связью. Это принципиально отличается от того, как работает оптимизация системы вывода. В качестве движка вывода SGLang имеет огромное пространство стратегий для оптимизации, но его конвейер относительно линейный — обработка запроса, предварительное заполнение, декодирование. Вы можете изолировать узкие места модуль за модулем, и связь между компонентами управляемая. Обучение RL — это совершенно другое дело — кошмарно сложный многосистемный цикл: генерация развертываний зависит от движка вывода, вычисление вознаграждения может зависеть от внешних сред, обновления политики зависят от обучающей структуры, а следующий раунд развертываний зависит от обновленной политики. Если любая отдельная связь ломается, весь цикл рушится. К сожалению, судя по тому, что я видел за последний год, все еще существует много серьезно недооцененных слабых мест: Надежность песочницы агента. Это, вероятно, самая грязная, самая изнурительная и наименее академически гламурная работа в RL Infra сегодня. Агентный RL нуждается в надежной песочнице для выполнения развертываний — звучит просто, но оказывается настоящим кошмаром. Стабильность контейнеров, задержка холодного старта, надежность изоляции ресурсов, управление состоянием песочницы — эти вещи кажутся разъединенными на бумаге, но продукты песочницы, доступные на рынке, постоянно не соответствуют ожиданиям. Песочница агента не является проблемой алгоритма, но она напрямую определяет вашу эффективность генерации данных, что, в свою очередь, определяет вашу скорость обучения. Наблюдаемость. Отладка предварительного обучения относительно проста — смотрите на кривую потерь, проверяйте норму градиента, и вы обычно можете точно определить проблему. Но отладка RL требует возможностей сквозного отслеживания: распределения качества развертываний, статистики вознаграждений, степени офф-политики, величины обновлений политики и даже атрибуции разницы логарифмических вероятностей (приходит ли разница со стороны вывода или из-за задержки версии асинхронного обучения?). К сожалению, большинство команд, с которыми я сталкивался, по сути, действуют вслепую в этих измерениях. Это приводит к неловкой ситуации — когда результаты обучения плохие, вы даже не знаете, какой модуль винить. Дилемма масштаба. Многие оптимизации RL Infra показывают измеримый эффект только при достаточном масштабе. Эксперименты малого масштаба часто не показывают значительных различий — не потому, что оптимизация бесполезна, а потому, что шум слишком высок, а количество шагов слишком мало, чтобы сигнал проявился. Однако эксперименты большого масштаба prohibitively дороги. Это создает порочный круг: вы не можете доказать, что ваша оптимизация работает на малом масштабе, поэтому не можете получить ресурсы для экспериментов большого масштаба; а без валидации большого масштаба ваша оптимизация навсегда застревает на "теоретически это должно помочь." Инвестиции отрасли в RL Infra серьезно не соответствуют его фактической сложности. Большинство команд рассматривают это как временное решение поверх инфраструктуры предварительного обучения — берут готовую обучающую структуру, прикрепляют движок вывода, склеивают их вместе с помощью скриптов и называют это RL Infra. Но системная сложность обучения RL и предварительного обучения даже не в одной лиге. Конвейеры предварительного обучения линейные, однородные и практически не имеют внешних зависимостей. Конвейеры обучения RL циклические, гетерогенные и сильно зависят от внешних сред. Применение архитектурного мышления первого к последнему гарантированно приведет к стене на масштабе. Настоящая сложность в системной инженерии не в том, чтобы довести любой отдельный модуль до предела — это понимание связи между модулями и глобального пространства компромиссов. Это верно для систем вывода, и тем более для RL Infra, где размеры связи больше, обратные связи длиннее, а плотность информации для отладки гораздо ниже. Я хочу закончить двумя вопросами, над которыми я размышлял, и мне было бы интересно услышать мнение других, работающих в этой области: Где именно начинают уменьшаться предельные доходы от согласования обучения и вывода? Как только асинхронность введена, степень офф-политики уже значительна. На этой основе, действительно ли дополнительная выгода от дальнейшего согласования выше ROI, чем инвестиции тех же инженерных усилий в стабильность песочницы, оптимизацию конвейера вознаграждений или инфраструктуру наблюдаемости? У меня есть свой предварительный ответ, но я думаю, что этот вопрос заслуживает серьезного обсуждения от большего числа людей — вместо того, чтобы по умолчанию считать согласование высшим приоритетом просто потому, что это самая заметная тема. И есть причина, по которой это наиболее заметно: согласование обучения и вывода имеет четкую математическую формализацию и производит элегантные абляции — это естественно подходит для статей. Но как написать статью о стабильности песочницы? Как представить надежность оркестрации контейнеров как академическую историю? На самом деле, вы не можете. Поэтому эти проблемы коллективно игнорируются. Даже если система RL Infra достигает битового согласования обучения и вывода, общая эффективность все равно может быть ужасной — потому что узкое место переместилось куда-то еще давно. В какой степени RL Infra может быть стандартизирована? Системы вывода имеют относительно четко определенные бенчмарковые метрики — TTFT, TBT, Пропускная способность. Эти объективные индикаторы позволяют нам четко оценить влияние оптимизаций. Но какие стандарты оценки для RL Infra? Пропускная способность обучения? Эффективность образцов? Время в реальном времени от начала до конца? Оптимальная архитектура может сильно варьироваться в зависимости от сценариев (генерация кода против агента против рассуждений). Если у нас даже нет согласия по поводу того, как выглядит "хорошая RL Infra", то накопить и повторно использовать инженерные знания в этой области будет крайне сложно. Является ли RL критическим путем для улучшения возможностей модели — это суждение все еще развивается. Но если ответ да, то Infra является самым недооцененным узким местом на этом пути. Не потому, что никто не работает над этим, а потому, что коллективное внимание неправильно распределено. Жестокость Эффекта Бочки заключается в том, что независимо от того, насколько высока ваша самая высокая планка, она не может спасти систему.