Что именно ускоряет RL-обучение MoE на Amazon EKS
Ответ короткий: AWS объединила Amazon EKS, Elastic Fabric Adapter (EFA), DeepEP и Amazon S3 в один стек, а главный ускоритель - перенос коммуникационных примитивов DeepEP на libfabric с нативной поддержкой EFA. В публикации AWS указано, что такой стек увеличил совокупную пропускную способность RL-роллаутов на 40% при крупномасштабном RLHF и GRPO-обучении.
Цифра получена не на абстрактной модели. Стенд: 48 инстансов P5en, из которых 16 отданы обучению, а 32 - генерации роллаутов, сама модель при этом super-sparse MoE. Сравнение шло со стеком без EFA-ускоренного expert parallelism.
Прирост даёт конкретная операция: all-to-all обмен токенами между экспертами. Expert Parallelism (EP) маршрутизирует токены динамически, и объём этого трафика растёт вместе с разреженностью модели. Пока коммуникация идёт через стандартный сетевой стек, ускорители простаивают в ожидании данных. EFA снимает часть накладных расходов, а DeepEP поверх libfabric доводит обмен до сети напрямую.
Оговорка сразу: 40% - результат AWS на своей конфигурации. Воспроизводимость на другом железе, другой модели и другом числе узлов источник не подтверждает, и это стоит держать в голове до того, как считать бюджет кластера.
Почему MoE-обучение упирается в коммуникацию, а не в вычисления
MoE стал стандартной архитектурой для масштабирования LLM до сотен миллиардов и даже триллионов параметров: разреженность позволяет сохранить эффективный инференс, не пропуская каждый токен через всю сеть. Пайплайн обучения таких моделей стандартен: предобучение, mid-training, supervised fine-tuning (SFT) и reinforcement learning.
Узкое место появляется на пост-тренировке. Чтобы снизить стоимость инференса, новые MoE-архитектуры делают всё более разреженными, и тогда обучение ограничивается коммуникацией, а не вычислениями. Причина в характере трафика.
Tensor Parallelism (TP), Data Parallelism (DP) и Pipeline Parallelism (PP) дают плотные, предсказуемые паттерны обмена: объёмы и адресаты известны заранее. EP добавляет поверх них динамическую all-to-all маршрутизацию токенов между устройствами. Кто с кем будет обмениваться на следующем шаге, зависит от того, каким экспертам роутер отправил токены. Такой трафик плохо ложится на сети, рассчитанные на равномерный поток.
В асинхронных RL-нагрузках к этому добавляется встречное давление. Медленный шаг обучения останавливает инференс-воркеры, которые ждут обновлённых весов. Недостаточная пропускная способность генерации оставляет обучающие ускорители без данных. Reward-модели, верификаторы и обновления чекпоинтов добавляют нагрузку на память, сеть и оркестрацию. Баланс между двумя половинами кластера приходится настраивать, и он не берётся из коробки.
Чем PPO и GRPO отличаются и что у них общего на уровне инфраструктуры
PPO обычно держит critic-модель, которая оценивает value во время улучшения политики. GRPO обходится без отдельной critic-модели: он использует групповые относительные награды. Для инженера разница ощутима - меньше моделей в памяти, проще расписание, меньше чекпоинтов.
На уровне инфраструктуры требования совпадают: крупномасштабная генерация роллаутов, тесно связанное обучение политики, высокоскоростная межнодовая коммуникация. Практический вывод простой: переход с PPO на GRPO не требует переделки кластерной части. Референсная архитектура AWS рассчитана на оба подхода, заявленный прирост пропускной способности относится и к RLHF, и к GRPO.
Референсная архитектура AWS: разделение роллаутов и обучения
Каркас такой: Amazon EKS управляет кластером, роллаут-генерация и обучение политики живут в независимых группах узлов, EFA отвечает за межнодовую связь, DeepEP ускоряет expert-parallel обмен, Amazon S3 хранит чекпоинты и артефакты. Сочетание Amazon EKS, EFA и Amazon S3 и описано в материале AWS.
Разделение узлов даёт то, чего не хватает монолитному варианту: инференс и обучение масштабируются независимо. Роллауты эластичны по природе, их можно добавлять и убирать под нагрузкой. Обучение политики, наоборот, требует плотной синхронизации между узлами и чувствительно к задержкам. Две группы узлов позволяют подбирать конфигурацию под каждую половину отдельно, вместо того чтобы искать один компромиссный профиль на весь кластер.
Как EFA и libfabric ускоряют expert-parallel all-to-all
EFA - сетевой адаптер AWS для инстансов с ускоренными вычислениями, который даёт высокоскоростную межнодовую коммуникацию. libfabric - фреймворк, через который приложение получает доступ к сетевым транспортам.
Перенос коммуникационных примитивов DeepEP на libfabric означает нативную поддержку EFA: обмен между экспертами идёт через сеть напрямую, без накладных расходов стандартного стека. Это снижает стоимость all-to-all, а он и есть критическая операция для EP. Детали самого переноса AWS в публикации не раскрывает, поэтому оценивать его стоит по итоговому результату, а не по описанию.
Роль Amazon S3 в пайплайне: чекпоинты и артефакты
S3 хранит чекпоинты и артефакты. Чекпоинты позволяют вернуть обучение после сбоя, артефакты связывают роллаут-воркеры и обучающие узлы. Когда генерация вынесена на узлы, которые могут пропасть в любой момент, внешнее хранилище становится единственной гарантией, что прогресс не потеряется. Цифр по пропускной способности S3 или частоте сохранений источник не приводит.
Тестовая конфигурация и результаты: 48 инстансов P5en и +40%
Стенд: 48 инстансов P5en, 16 на обучение, 32 на инференс, super-sparse MoE-модель. Включение DeepEP поверх EFA увеличило совокупную пропускную способность RL-роллаутов на 40% по сравнению со стеком без EFA-ускоренного expert parallelism, о чём сказано в отчёте AWS.
Что стоит понимать про эту цифру:
- Это измерение AWS на своей конфигурации. Независимого воспроизведения нет.
- Метрика - совокупная пропускная способность роллаутов. Это не время шага обучения и не время до первого токена.
- Модель super-sparse MoE: чем выше разреженность, тем больше доля коммуникации в общем времени и тем заметнее эффект от ускорения all-to-all.
- Соотношение 16:32 между обучением и инференсом подобрано под конкретную нагрузку. Для другой задачи пропорция будет иной.
Практический смысл прироста зависит от того, где у вас простой. Если генерация роллаутов не успевает, а обучающие ускорители ждут, ускорение сети напрямую поднимает загрузку GPU. Если узкое место в дисковой подсистеме или в CPU-части пайплайна, те же 40% вы не увидите.
Требования к версиям и настройка EFA в Kubernetes
Оговорка по фактам: в доступном фрагменте публикации AWS список версий компонентов не приводится. Описание материала называет CUDA 13.0, PyTorch 2.12, NCCL 2.31, EFA 1.49, DeepEP 2.0 и SGLang 0.5.17, но подтвердить эти номера по источнику нельзя. Перед сборкой образа сверяйтесь с официальной документацией компонентов.
Принцип, который работает независимо от конкретных номеров: версии сетевого и вычислительного стека связаны между собой. Расхождение по NCCL, EFA или libfabric обычно проявляется не понятной ошибкой, а падением пропускной способности all-to-all или зависанием на этапе инициализации коммуникаторов.
| Компонент | За что отвечает | Что учитывать при подборе версии |
|---|---|---|
| CUDA | Вычислительный стек GPU | Должен поддерживаться драйвером на узлах и фреймворком обучения |
| PyTorch | Обучение политики | Совместимость с версией CUDA и библиотеками коммуникаций |
| NCCL | Коллективные операции TP, DP, PP | Связка с сетевым стеком и EFA |
| EFA | Межнодовая коммуникация | Версия драйвера и провайдера в libfabric |
| DeepEP | Expert-parallel all-to-all | Сборка libfabric с поддержкой EFA |
| SGLang | Генерация роллаутов | Совместимость с версиями PyTorch и CUDA |
Пошаговая установка EFA device plugin
Порядок работы в EKS выглядит так:
- Убедиться, что узлы запущены на инстансах с EFA. В тесте AWS использовались P5en.
- Проверить, что на узлах виден сетевой адаптер и установлены драйверы EFA.
- Развернуть EFA device plugin в кластере через Helm-чарт или манифест, чтобы Kubernetes начал видеть устройства.
- Убедиться, что поды получают доступ к ресурсу устройств EFA и планировщик учитывает его при размещении.
- Собрать libfabric с поддержкой EFA: без этого DeepEP не сможет использовать адаптер напрямую.
Последний пункт на практике ломается чаще всего. EFA device plugin сам по себе не заставляет библиотеку коммуникаций работать через EFA: нужна сборка libfabric с нужным провайдером. Точные команды и имена ресурсов берите из официальной документации EKS и EFA, в источнике эти шаги не описаны.
Spot Instances для роллаут-воркеров: экономия и риски
В описании материала AWS упоминаются Spot Instances для роллаут-воркеров; в доступном фрагменте публикации подтверждения этому нет, так что воспринимайте как требующее проверки. Логика выбора понятна: генерация роллаутов менее чувствительна к задержкам, чем обучение политики, и её проще перезапустить, чем синхронный шаг обучения.
Риск известен: Spot-узел могут забрать в самый неудобный момент. Отсюда набор требований: чекпоинты вне узла, автоматическое пересоздание подов, отсутствие зависимости обучающей группы от конкретного Spot-инстанса. Цифр экономии источник не даёт, поэтому выгоду придётся считать по своим ценам и своим коэффициентам прерываний.
Кому подходит этот стек и какие у него ограничения
Стек рассчитан на крупномасштабное RL-обучение MoE-моделей уровня сотен миллиардов параметров в AWS. Для модели, которая помещается на одну ноду, он избыточен: вся ценность приходит от ускорения межнодового all-to-all, а на одном узле ускорять нечего.
Ограничения, которые стоит взвесить заранее:
- нужны инстансы с EFA, в тесте это P5en и аналогичные модели;
- жёсткая совместимость версий CUDA, PyTorch, NCCL, EFA и DeepEP;
- сложная настройка: EKS, EFA device plugin, сборка libfabric с поддержкой EFA;
- результат 40% подтверждён только на конфигурации AWS с super-sparse MoE.
Альтернатива без EFA существует: тот же DeepEP поверх стандартного сетевого стека. Работать будет, но вы теряете ускорение expert parallelism, ради которого всё и затевалось. Другие облака предлагают похожие высокоскоростные сети, однако этот набор компонентов и измерений привязан к AWS.
Если ваш случай не RL-кластер, а запуск MoE-модели на машине с нехваткой VRAM, смотрите разбор стриминг-инференса MoE и ограничений DeepEP: там узкие места другие - пропускная способность PCIe, объём host RAM и топология NUMA.
Начните с двух проверок. Первая: попадает ли ваша нагрузка в профиль крупномасштабного RL, то есть много узлов, разреженная MoE и генерация роллаутов как узкое место. Вторая: доступны ли EFA-инстансы в вашем регионе и квотах. Если оба ответа положительные, схему AWS имеет смысл повторять. Если хотя бы один отрицательный, сначала посчитайте, где именно у вас простаивают GPU, иначе 40% останутся цифрой из чужого отчёта.