«Сорок процентов на раздаче»: AWS ускорила RL для MoE на Amazon EKS через EFA и DeepEP

Три нагрузки одного RL-цикла

MoE стал стандартной архитектурой для масштабирования языковых моделей до сотен миллиардов и триллионов параметров: разреженность снижает стоимость инференса, но не убирает инфраструктурную сложность обучения.

На этапе пост-обучения разреженность добавляет отдельную проблему — чем разреженнее новые MoE-архитектуры, тем сильнее обучение ограничено не вычислениями, а коммуникацией.

Главный источник этих издержек — Expert Parallelism (EP): к структурированным шаблонам Tensor Parallelism (TP), Data Parallelism (DP) и Pipeline Parallelism (PP) добавляется динамическая маршрутизация токенов all-to-all между устройствами.

В асинхронном RL медленный шаг обучения останавливает инференс-воркеров, а недостаточная пропускная способность раздачи оставляет ускорители простаивающими — и это одинаково верно и для RLHF на Proximal Policy Optimization (PPO), и для GRPO.

PPO оценивает значение через отдельную critic-модель, GRPO обходится групповыми относительными наградами, но требования к инфраструктуре у них совпадают: масштабная генерация опыта, жёстко связанное обучение политики и высокоскоростная межузловая связь.

Раздача максимизирует агрегатную пропускную способность, а не время до первого токена (TTFT) или межтокенную задержку, тогда как обучение политики требует воркеров, идущих в ногу.

Всплеск задержки или отстающий воркер останавливает всё задание либо приводит к таймаутам NVIDIA Collective Communications Library (NCCL).

Кластер, буфер и хранилище

Кластер Amazon EKS разбит на отдельные node groups под каждый этап работы: GPU-инстансы занимаются раздачей, инференсом reward-моделей и обучением политики, CPU-инстансы выполняют среды и предобработку, а memory-optimized инстансы держат буферы опыта и кэши чекпойнтов, чтобы производители и потребители обменивались данными без постоянного хранилища на критическом пути.

Контур данных замкнут: rollout-воркеры генерируют опыт во взаимодействии с CPU-подами сред, опыт попадает в буфер, обучение политики разбирает батчи, обновляет веса и публикует новые чекпойнты для следующего раунда раздачи.

Чекпойнты и готовые артефакты, включая веса модели, сохраняются в Amazon S3 — для долговременного хранения и восстановления после сбоя.

Внутри инстанса высокоскоростную связь несёт NVLink через NVSwitch, межузловую — Elastic Fabric Adapter (EFA); на поддерживаемых конфигурациях EFA работает вместе с NVIDIA GPUDirect RDMA и обходом операционной системы, передавая данные напрямую между буферами GPU-памяти и снижая участие CPU и ОС в пути коммуникации.

Документация Amazon EC2 уточняет, что RDMA write доступен на большинстве инстансов с Nitro версии 4 и новее, а GPUDirect RDMA (GDR) и GPUDirect Async (GDA) — на отдельных инстансах Nitro v4 и новее.

Баланс между двумя доменами связи и определяет производительность: часть операций выгодно держать на NVLink, часть — на EFA.

DeepEP поверх EFA

Обычные all-to-all коллективы эффективны для плотного и регулярного трафика, а MoE порождает разреженный, мелкозернистый и несбалансированный поток; когда Expert Parallelism выходит за пределы одного узла, синхронизация и накладные расходы на сообщение делают межузловую связь главным узким местом.

DeepEP заменяет стандартные all-to-all коллективы двумя специализированными GPU-ядрами: dispatch-ядро развозит токены по удалённым экспертам, а combine-ядро собирает обработанные токены назад.

Внутри узла они используют NVLink через NVSwitch, между узлами — libfabric поверх EFA.

Сама библиотека DeepEP описывает себя как высокопроизводительную библиотеку коммуникации для обучения и инференса, сосредоточенную на expert parallelism и предоставляющую высокопроизводительные и низколатентные all-to-all GPU-ядра (MoE dispatch и combine) с поддержкой низкой точности, включая FP8.

Ядра компилируются во время выполнения через лёгкий JIT-модуль, поэтому при установке компиляция CUDA не требуется.

Amazon передала в апстрим набор изменений, переводящих примитивы коммуникации DeepEP на libfabric: транспорт становится переносимым между сетями с поддержкой libfabric, а DeepEP v2 получает нативную поддержку EFA.

Дополнительно NCCL 2.31 включает свежие EFA-оптимизации для плотных коллективных операций.

По сути это миграция с CUDA-специфичного RDMA-бэкенда на libfabric, которая снижает накладные расходы на сообщение для разреженного мелкозернистого трафика Expert Parallelism.

Результат замера: на 48 инстансах P5en (16 выделены под обучение, 32 под инференс) с одной и той же super-sparse MoE-моделью включение DeepEP поверх EFA увеличило агрегатную пропускную способность раздачи на 40 процентов.

В выводах AWS добавляет, что архитектура также сократила время полной итерации политики и масштабировалась примерно до тысячи ускорителей.

Сравнение в посте идёт между двумя стеками на тех же 48 инстансах: базовый вариант на Slime (CUDA 12.9, PyTorch 2.9.1, NCCL 2.27, SGLang 0.5.9, Slime 0.2.4) без EFA-ускоренного expert parallelism против конфигурации с DeepEP поверх EFA (CUDA 13.0, PyTorch 2.12, NCCL 2.31, EFA 1.49, DeepEP 2.0, SGLang 0.5.17, Miles 0.1.0).

Абсолютных значений пропускной способности в тексте нет — сравнение приведено только на графике.

Spot под раздачу

Раздача хорошо ложится на Amazon EC2 Spot Instances, потому что это распределённые инференс-задачи, которые делятся между независимыми воркерами: прерывание одного rollout-воркера не требует остановки всего RL-задания, а незавершённые задачи возвращаются в очередь и перераспределяются между остальными.

При уведомлении о прерывании воркеры должны доработать активные запросы и вернуть незавершённые задачи в очередь, публикуя готовые сэмплы часто и работая ограниченными порциями.

Обучение политики при этом остаётся на стабильных мощностях и защищено от прерываний Spot, задержек и таймаутов NCCL.

Как это воспроизвести

Требования из поста: Amazon EKS 1.31 или новее, EFA installer 1.49 с плагином AWS OFI NCCL, DeepEP 2.0.0, NCCL 2.31.2, SGLang 0.5.17, PyTorch 2.12.1 (CUDA 13.0) и поддерживаемые GPU-инстансы — например, p5.48xlarge, p5e.48xlarge или p6-b200.48xlarge.

Инстансы, которые общаются друг с другом, обязаны находиться в одной Availability Zone (AZ), а в кластер нужно поставить Kubernetes device plugin для EFA.

Практичная точка старта — образ SGLang из каталога AWS Deep Learning Containers.

Задание отправляется через TorchX: референсный скрипт train_rl.py из репозитория Miles оркеструет цикл «раздача — обучение», поднимая rollout-воркеров и воркеров обучения политики отдельными Kubernetes-подами.

Конфигурация deepseek_v3_moe задаёт число экспертов и стратегию параллелизма, а команда запуска указывает сетку 4x8, 32 rollout-воркера и каталог чекпойнтов в Amazon S3.

Miles описывает себя как решение для RL-постобучения крупных моделей на уровне enterprise, и версия 0.1.0 вышла в августе 2026 года.

Ключевые выводы AWS: компоненты стоит масштабировать независимо и применять Spot выборочно, а выигрыш на всём пути требует совместного проектирования — от транспорта и примитивов коммуникации до дизайна модели.