Nereus на лету перестраивает RL-дообучение LLM: до 7,27 раза быстрее OpenRLHF

RL-дообучение больших языковых моделей (reinforcement learning post-training) держит на GPU-кластере сразу несколько моделей, которые работают на этапах генерации, инференса и обучения. По ходу запуска многое меняется: доступные ресурсы, длина последовательностей, нагрузка на память, узкие места на отдельных этапах. Поэтому план выполнения, который сначала был удачным, со временем может стать медленным или вовсе неосуществимым. Перестроить такое задание непросто, потому что модели делят между собой GPU. Нужно решить, окупает ли новый план стоимость перехода, переиспользовать распределённое состояние задания и согласовать передачи данных между GPU для разных моделей и этапов.\n\nNereus, это среда выполнения (runtime), учитывающая стоимость перехода, которая превращает задание RL-дообучения в эффективные планы выполнения. Её контроллер с малыми накладными расходами выбирает глобальный план, укладывающийся в память, и допускает переход, опираясь на модель стоимости, откалиброванную по работающему заданию. Чтобы оценить и выполнить переход, Nereus представляет распределённое состояние каждой реплики модели на конкретном этапе (одна модель в одном этапе) как «эластичную модельную единицу» (Elastic Model Unit). Затем глобальный граф переходов задаёт порядок преобразований этих единиц и передач между GPU.\n\nЦифры из аннотации. В трассе, построенной на реальных данных, онлайн-адаптация TP/PP снижает среднюю задержку шага на 27,7% относительно исходной фиксированной схемы TP/PP с масштабированием DP. В запуске на 1000 шагов, дошедшем до 1024 GPU, шесть переходов заняли 0,079% общего времени работы. Сквозная пропускная способность на 8B PPO у Nereus выше, чем у OpenRLHF, в 2,14, 7,27 раза, и выше, чем у Verl, в 1,10, 1,47 раза, на разных кластерах.
Ключевые факты
- Nereus, среда выполнения, которая во время RL-дообучения языковых моделей меняет план выполнения задания на GPU-кластере с учётом стоимости перехода.
- Сквозная пропускная способность на 8B PPO выше в 2,14, 7,27 раза, чем у OpenRLHF, и в 1,10, 1,47 раза, чем у Verl, на разных кластерах.
- В трассе на реальных данных онлайн-адаптация TP/PP снижает среднюю задержку шага на 27,7% относительно исходной фиксированной схемы TP/PP с масштабированием DP.
- В запуске на 1000 шагов до 1024 GPU шесть переходов заняли 0,079% общего времени.
- Состояние каждой реплики модели на этапе описывается как Elastic Model Unit, порядок преобразований и передач между GPU задаёт глобальный граф переходов.
Почему это важно
RL-дообучение держит на кластере несколько моделей на разных этапах, а условия по ходу запуска меняются. Первоначально подобранный план может замедлиться или стать неосуществимым. Nereus предлагает не фиксировать план заранее, а перестраивать его во время работы и при этом считать, стоит ли переход своих затрат. Если цифры из аннотации подтвердятся на практике, это заметный выигрыш в скорости по сравнению с OpenRLHF и Verl.
Кому это важно
Командам, которые запускают RL-дообучение языковых моделей на GPU-кластерах и работают с системами вроде OpenRLHF и Verl. Также инженерам, занимающимся распределённым обучением и планированием ресурсов кластера.
Как это применить
Из аннотации нельзя понять, как получить систему: о выходе кода, лицензии или доступности в источнике ничего не сказано. Практически это повод изучить полный текст статьи и идею перестройки плана по ходу запуска, если вы сами упираетесь в смену условий на длинных запусках.
Можно ли доверять
Это аннотация научной статьи со страницы Hugging Face Papers, и все числа заявлены самими авторами. В источнике не названы авторы и организации. Ускорение по пропускной способности приведено только для 8B PPO, без указания, на каком кластере получены минимум и максимум диапазонов. Цифра 27,7% получена на трассе, построенной на реальных данных, а не на живом запуске, и из аннотации не видно, что это за данные. Независимой проверки в источнике нет.
Риски и подводные камни
Сравнение охватывает только 8B PPO: другие размеры моделей и алгоритмы в аннотации не названы. Конфигурации кластеров, кроме максимума в 1024 GPU, не раскрыты, а диапазоны ускорения широкие (2,14, 7,27 раза против OpenRLHF), поэтому ожидаемый выигрыш на вашем кластере оценить трудно. Накладные расходы переходов (0,079% времени) измерены на одном запуске из 1000 шагов с шестью переходами.