Большие языковые модели на архитектуре MoE – «смесь экспертов» – устроены сложно: вместо одной большой нейросети внутри работает множество специализированных подсетей, и для каждого запроса активируется лишь часть из них. Это экономит вычисления, но требует особой организации работы оборудования.
Чтобы обслуживать такие модели в промышленных масштабах, принято использовать подход под названием широкий параллелизм экспертов – когда одна копия модели распределена сразу по 32 и более GPU. Это позволяет обрабатывать большие потоки запросов быстрее и дешевле. Проблема в том, что чем больше GPU задействовано, тем выше вероятность выхода из строя хотя бы одного из них. А при классической схеме развёртывания один сбойный процесс влечёт за собой падение всего инференс-инстанса.
Почему это серьёзная проблема
Представьте, что у вас запущен сервис на 32 GPU, и один из них дал сбой. В традиционной схеме это означает полный перезапуск – со всеми вытекающими последствиями: несколько минут простоя, потеря очереди запросов, нагрузка на инфраструктуру. При высоких объёмах трафика даже пара минут простоя – это ощутимые потери.
Именно эту уязвимость и взялась устранить команда Mooncake совместно с Volcano Engine, встроив в фреймворк SGLang механизм под названием Elastic EP – эластичный параллелизм экспертов.
Идея: разорвать жёсткую привязку
В обычной схеме каждый «эксперт» (подсеть) жёстко закреплён за конкретным GPU. Если этот GPU падает – эксперт недоступен, и система не может продолжать работу.
Elastic EP меняет эту логику: эксперты хранятся с избыточностью, то есть часть из них продублирована на нескольких GPU сразу. Если одно из устройств отказывает, система обнаруживает это, перераспределяет нагрузку на оставшиеся GPU и продолжает обработку запросов – без полной остановки.
Проще говоря: модель немного «теряет в мощности», но не останавливается.
Что показали тесты
Чтобы проверить решение в условиях, приближённых к боевым, команда запустила модель DeepSeek V3.2 на четырёх узлах – 32 GPU суммарно – с 256 резервными экспертами. Конфигурация позволяла системе пережить одновременный отказ до 16 процессов.
В ходе эксперимента часть процессов принудительно завершалась, после чего измерялось время восстановления. Результат: перерыв в обслуживании составил менее 10 секунд – против 2–3 минут при полном перезапуске. Это примерно на 90% быстрее.
При этом в штатном режиме – когда сбоев нет – производительность системы с Elastic EP совпадает с показателями стандартного подхода. То есть надёжность добавляется без потерь в скорости при нормальной работе.
Два уровня защиты
Под капотом решение работает на двух уровнях одновременно.
Первый – уровень планировщика. Это «привратник» системы: он постоянно следит за состоянием всех GPU и, если один из них перестаёт отвечать, сразу исключает его из очереди распределения задач. Новые запросы уходят только на работоспособные ресурсы – без каких-либо прерываний.
Второй – уровень самого параллелизма экспертов. Здесь происходит более тонкая работа: система в реальном времени перераспределяет экспертов с упавших GPU на выжившие, чтобы вычисления продолжались математически корректно. Это позволяет избежать тяжёлых прерываний на уровне исполнения.
Вместе эти два механизма превращают хрупкую MoE-систему в куда более устойчивую конструкцию.
Mooncake как коммуникационная основа
Ключевую роль в реализации играет библиотека Mooncake EP – она выступает в роли отказоустойчивого слоя связи между GPU. Именно она обеспечивает быструю передачу данных между узлами, отслеживает сбои и перестраивает маршруты обмена информацией при частичном отказе оборудования.
Важная деталь: библиотека спроектирована так, чтобы встраиваться в уже существующую инфраструктуру SGLang без масштабных переработок. Это снижает барьер для тех, кто хочет добавить отказоустойчивость в уже работающие системы.
Также в рамках того же фреймворка Elastic EP команда NVIDIA Dynamo предложила реализацию на основе собственного коммуникационного бэкенда – NIXL EP. Это свидетельствует о том, что архитектура задумана как расширяемая: разные команды могут подключать собственные реализации поверх общей схемы.
Почему это важно за пределами конкретного проекта
MoE-модели – это не экзотика. DeepSeek и ряд других крупных моделей используют именно эту архитектуру. По мере того как такие модели всё активнее внедряются в продакшн-системы, вопрос надёжности инфраструктуры становится не менее важным, чем качество самой модели.
До сих пор широкий параллелизм экспертов был несколько похож на канат, натянутый над пропастью без страховки: работает хорошо, пока всё в порядке, но один срыв – и всё падает. Elastic EP предлагает ту самую страховку.
Открытым остаётся вопрос полного динамического восстановления процессов – то есть возможности автоматически «вернуть» упавший GPU обратно в работу без перезапуска всего инстанса. По информации команды, эта функциональность находится в активной разработке.
Тем не менее уже реализованное решение – сокращение времени простоя с нескольких минут до считанных секунд – само по себе меняет уравнение надёжности для систем, где непрерывность работы критически важна.
