Nebius сократила время сбора фиксированного пакета из 256 траекторий для агентного RL на 66,9%. Результат относится не ко всему циклу обучения, а именно к подготовке данных для следующего шага: дорогие GPU нередко простаивают, пока агент ждёт браузер, песочницу или выполнение кода. Для команд, развивающих обучение агентных моделей, это напоминание: следующий прирост скорости может лежать не в новом ускорителе, а в очереди контейнеров.
Об эксперименте сообщает The New Stack со ссылкой на Ди Цзиня, вице-президента Nebius по AI Training. Компания тестировала изменения на нагрузке на базе Terminal-Bench: доработала маршрутизацию запросов, запуск песочниц и сборку батча. Важно не превратить цифру в маркетинговую формулу: 66,9% — это сокращение времени получения траекторий при фиксированных весах модели. В замер не входили прямой и обратный проходы тренера, а также обновление оптимизатора, поэтому ускорение полного обучения будет другим.
В классическом supervised fine-tuning модель получает заранее собранный датасет. В агентном reinforcement learning она сама набирает опыт: решает задачу, вызывает инструменты, работает с кодом или сайтом, получает награду — и только затем эта траектория становится материалом для обучения. Длительность таких эпизодов сильно различается. Большая часть агентов может завершить попытку быстро, но синхронный батч ждёт последний «хвостовой» запуск. В этот момент GPU, за который уже выставлен счёт, занят главным образом ожиданием.
Поэтому Nebius предлагает смотреть не только на привычные токены в секунду, но и на время до готового обучаемого батча. Средняя скорость генерации может выглядеть бодро, пока несколько долгих траекторий тормозят следующий шаг. Для схем в духе GRPO это особенно заметно: несколько попыток одной задачи оцениваются вместе, и группе требуется дождаться всех участников. Практический подход — складывать завершённые группы в пул готовности и отдавать тренеру любые полные группы, а не строго те, что были запущены раньше.
Почему GPU простаивает рядом с дешёвыми контейнерами
У агентного контура много компонентов, не связанных с матричными вычислениями: песочницы, браузеры, API, базы кода, верификаторы результатов и сеть между ними. Их задержки складываются на сотнях вызовов инструментов в одной длинной траектории. Рекомендация Цзиня предельно приземлённая: масштабировать CPU и песочницы независимо от GPU, держать запас готовых окружений, использовать снимки и форки там, где это возможно, а также располагать среды исполнения близко к GPU по сети. Свободный контейнер обычно обходится дешевле простоя ускорителя.
Не менее важна классификация сбоев. Если песочница упала или завис браузер, такой эпизод нельзя бездумно превращать в отрицательное вознаграждение модели: иначе в градиент попадёт шум инфраструктуры. Команде стоит отдельно записывать успех модели, её ошибку, инфраструктурный сбой и неопределённый исход, а проблемные эпизоды уметь воспроизводить. При этом тайм-аут, вызванный действиями самого агента, не должен становиться лазейкой для ухода от штрафа. Надёжность среды здесь уже часть качества датасета, а не забота соседней команды эксплуатации.
Асинхронность ускоряет обучение, но добавляет долг данных
Вторая проблема — свежесть весов. В полностью синхронной схеме инференс ждёт, пока завершится обучение, а обучение ждёт новые rollout-данные. Параллельная генерация на версии модели, отстающей на один или несколько шагов, повышает загрузку оборудования, но создаёт policy lag: траектория получена уже не той политикой, которую тренируют сейчас. Nebius советует измерять не просто число «устаревших шагов», а расхождение между политиками. Его можно ограничивать порогом, понижать вес слишком старых примеров или корректировать importance sampling; на практике такие поправки часто обрезают, чтобы не раздувать дисперсию.
Есть и менее очевидная ловушка: rollout-движок и тренер способны назначать разную вероятность одним и тем же токенам даже при одинаковых исходных весах. Причины — квантизация, разные ядра, батчинг и маршрутизация экспертов в MoE-моделях. Это систематически искажает обновления. Сначала имеет смысл сблизить численные режимы инференса и forward pass тренера, затем измерить остаточное расхождение и выбрать поправку. Оценивать модель тоже нужно в том движке и с той точностью, в которых она будет обслуживать пользователей; смена квантизации — повод заново прогнать eval.
Для обучения агентных моделей вывод из кейса Nebius не сводится к рецепту «добавьте контейнеров». Нужны метрики времени готовности батча, GPU-часов в ожидании окружений, возраста политики, задержки публикации весов и доли инфраструктурных ошибок. Весы можно обновлять через общее GPU-пространство, прямую передачу отдельным инференс-воркерам или горячую загрузку из хранилища — выбор зависит от топологии и допустимой свежести. Но в любом варианте следует заранее решить, что делать с активными запросами и KV-кешем.
Агентный RL постепенно превращает инфраструктуру из обслуживающего слоя в часть алгоритма. Пока команды покупают ускорители, но не измеряют путь от старта задачи до пригодного батча, самый дорогой ресурс может терпеливо ждать самый дешёвый. Следующим конкурентным преимуществом станет не максимальная пиковая скорость генерации, а способность стабильно собирать качественный опыт без длинного хвоста, испорченных окружений и неуправляемо устаревших траекторий.
