В мире обучения больших языковых моделей появляется всё больше подходов, которые ломают привычные представления о том, как должна выглядеть инфраструктура тренировки. Один из самых обсуждаемых экспериментов последнего времени — запуск асинхронного обучения с подкреплением на базе алгоритма GRPO, тонкой настройки через LoRA и распределённых задач Hugging Face Jobs. И самое интригующее здесь то, что вся эта конструкция работает без NCCL, опираясь лишь на объектное хранилище и небольшой прокси-сервис.
Что вообще происходит: контекст эксперимента
GRPO (Group Relative Policy Optimization) — это алгоритм обучения с подкреплением, который стал популярным благодаря проектам вроде DeepSeek. Его идея в том, чтобы не обучать отдельную модель-критика, а сравнивать ответы внутри группы и вычислять относительное преимущество. Это сильно упрощает пайплайн и снижает нагрузку на память, но по-прежнему требует быстрой синхронизации между генератором ответов и самим обучением.
LoRA (Low-Rank Adaptation) позволяет не трогать миллиарды параметров базовой модели, а обучать лишь небольшие адаптеры. Это уменьшает требования к видеопамяти и делает процесс куда более доступным для команд без огромных кластеров.
Hugging Face Jobs — это облачный сервис, позволяющий запускать задачи на GPU без ручного управления инфраструктурой. Комбинируя все три технологии, исследователи получили рабочую схему, где обучение идёт асинхронно, а узлы вообще не общаются напрямую друг с другом.
Асинхронность как философия
Классический подход к распределённому обучению предполагает, что все воркеры синхронно обмениваются градиентами на каждом шаге. Это надёжно, но требует жёсткой синхронизации и быстрых межсоединений. Асинхронный GRPO переворачивает эту логику: генерация примеров и обновление весов идут независимо друг от друга, а рассинхронизация между ними воспринимается не как проблема, а как естественное состояние системы.
Такой подход даёт сразу несколько выгод:
- генератор может работать на одной конфигурации GPU, а тренер — на другой;
- падение одного узла не обрушивает всю задачу;
- можно гибко масштабировать каждую часть отдельно;
- не нужно ждать самого медленного воркера на каждом шаге.
Именно здесь и появляется та самая связка из трёх компонентов — bucket, proxy и отсутствие NCCL.
Ведро, которое заменяет шину обмена
Вместо того чтобы гонять тензоры по высокоскоростной сети между GPU, участники процесса складывают результаты своей работы в обычное объектное хранилище — условное «ведро» S3-совместимого сервиса. Генератор пишет туда батчи промптов и ответов, тренер забирает их, обновляет адаптеры и публикует новые версии обратно.
Звучит медленно, но на практике для RL-пайплайнов это работает неожиданно хорошо, потому что:
- Полосы пропускания хватает — типичный трафик здесь неизмеримо меньше, чем при синхронном обмене градиентами между десятками воркеров.
- Нет жёстких требований к топологии сети — узлы могут находиться в разных дата-центрах и даже у разных провайдеров.
- Естественный буфер — если тренер отстал, данные просто подождут в ведре, а не вызовут таймаут.
Фактически объектное хранилище превращается в универсальную шину обмена, которая знает только операции «положить» и «забрать». Это невероятно просто, но при правильной архитектуре полностью заменяет целый слой распределённой инфраструктуры.
Зачем здесь прокси
Объектное хранилище хорошо для данных, но плохо для управления. Кто решает, когда публиковать новую версию адаптера? Как тренер узнаёт, что появился свежий батч? Как избежать гонок, когда несколько процессов пытаются одновременно обновить состояние?
Для этого в схему добавляют лёгкий прокси-сервис. Он играет роль диспетчера и координатора:
- отслеживает, какие батчи уже обработаны, а какие ещё нет;
- публикует актуальную версию LoRA-адаптера и сообщает о ней всем участникам;
- сглаживает рассинхронизацию между генератором и тренером;
- может выполнять базовую маршрутизацию запросов к моделям Inference.
По сути, прокси — это маленький «мозг» всей системы, в то время как ведро — её «память», а GPU-задачи Hugging Face Jobs — «руки», выполняющие вычисления.
Почему отказались от NCCL
NCCL (NVIDIA Collective Communications Library) — стандартный инструмент для обмена данными между GPU в одном кластере. Он быстрый, отточенный и почти всегда присутствует там, где есть несколько видеокарт. Но у него есть важные ограничения:
- он требует совместимых драйверов и одинаковой среды на всех узлах;
- хрупок к сетевым сбоям и падениям отдельной карты;
- привязывает всю задачу к одному кластеру или домену;
- дорого даёт сбои при асинхронной логике обновлений.
В мире HF Jobs, где каждая задача может стартовать в новом окружении и жить независимо, жёсткая синхронизация через NCCL перестаёт быть преимуществом. Поэтому авторы эксперимента выбрали другой путь: общение через ведро и прокси. Система становится чуть медленнее на каждом шаге, но зато неизмеримо устойчивее и проще в масштабировании.
Компромисс, который стоит своих денег
Может показаться, что отказ от NCCL — шаг назад. Но если честно посмотреть на задачу, то окажется, что для асинхронного RL пропускная способность внутрикластерного обмена далеко не так важна, как гибкость. Исследовательские команды выигрывают от того, что могут перезапускать любую часть пайплайна без пересборки всего кластера.
Как это выглядит на практике
Типичный запуск такой системы выглядит примерно так:
- Разворачивается ведро объектного хранилища с несколькими префиксами — prompts, responses, adapters, checkpoints.
- Запускается прокси-сервис, который держит состояние и раздаёт задачи.
- Стартует задача-генератор в HF Jobs: она читает промпты, обращается к базовой модели, получает ответы и складывает их в соответствующую папку.
- Параллельно работает задача-тренер: она следит за появлением новых батчей, вычисляет групповые награды, рассчитывает преимущество и обновляет LoRA-адаптер.
- Обновлённый адаптер публикуется обратно в ведро и подтягивается генератором на следующей итерации.
Всё это может работать часами и даже сутками, переживая перезапуски отдельных задач и не требуя, чтобы все участники были одновременно онлайн.
Что это меняет для индустрии
Такой подход открывает довольно много возможностей:
- Демократизация RLHF и RLVR — теперь для обучения с подкреплением не нужен суперкомпьютер с InfiniBand.
- Кооперация между командами — разные организации могут предоставлять свои GPU и обмениваться данными через общее ведро.
- Устойчивость к сбоям — падение одного узла не убивает тренировку, а лишь замедляет её.
- Прозрачность процессов — всё, что происходит, лежит в объектном хранилище и легко анализируется.
Конечно, есть и подводные камни. Задержки на чтение и запись в ведро могут стать узким местом, если генерировать данные слишком быстро. Прокси нужно уметь переживать высокие нагрузки и не превращаться в точку отказа. И, наконец, асинхронность требует аккуратной настройки гиперпараметров — иначе алгоритм теряет стабильность.
Взгляд в будущее
Комбинация Async GRPO, LoRA и HF Jobs с общением через ведро и прокси — это не просто технический трюк. Это сигнал о том, что распределённое обучение движется в сторону децентрализации и сервисной модульности. Вместо монолитных кластеров появляются слабо связанные компоненты, каждый из которых делает свою работу и не зависит от остальных.
Возможно, именно такая архитектура станет нормой для следующего поколения RL-пайплайнов: гибкой, отказоустойчивой и не требующей экзотического железа.
Краткий вывод
Async GRPO с LoRA на HF Jobs без NCCL показывает, что современное обучение моделей уже не обязано держаться на жёсткой синхронизации и быстрых межсоединениях. Объектное хранилище берёт на себя роль шины данных, прокси — роль координатора, а асинхронность — роль топлива, которое позволяет системе работать даже при рассинхронизации компонентов. Это проще, дешевле и надёжнее, чем кажется на первый взгляд. И, судя по всему, за таким подходом — будущее распределённого обучения.
