Развертывание vLLM Expert Parallel для DeepSeek и других моделей MoE
vLLM expert parallel — это режим развертывания, который следует использовать, когда экспертные слои модели MoE нужно распределить между GPU, а не обрабатывать как одну большую группу tensor parallel. В текущей версии vLLM переключатель — --enable-expert-parallel. Размер экспертного параллелизма задается косвенно через настройки tensor parallel (TP) и data parallel (DP): в документации vLLM указано EP_SIZE = TP_SIZE × DP_SIZE.
Эта деталь важна. Во многих инструкциях ищут отдельный «флаг размера vLLM expert parallel», а затем пытаются принудительно использовать флаг, которого нет в закрепленной версии сборки. Начните с поддерживаемого переключателя, проверьте vllm serve --help в точном образе, который будете развертывать, и выбирайте TP/DP на основе измеренного плана емкости.
Это руководство описывает безопасный путь от одноузлового развертывания DeepSeek MoE до многоузлового vLLM expert parallel, включая выбор бэкенда, балансировку нагрузки экспертов, приемочные тесты и изоляцию сбоев. Оно написано для инженеров ML и инфраструктуры ИИ, а не для демонстрации с одной командой.
Примечание о версиях: MoE-ядра, зависимости и интерфейс CLI vLLM быстро развиваются. Описанное ниже поведение и команды были проверены по официальной документации vLLM 16 октября 2026 года. Закрепите образ vLLM и проверьте флаги для этой закрепленной версии перед развертыванием в production.
Краткий ответ
| Вопрос | Практический ответ |
|---|---|
| Что включает vLLM expert parallel? | Добавьте --enable-expert-parallel в поддерживаемое развертывание MoE. |
| Как выбирается размер EP? | В текущей документации vLLM по expert parallel он вычисляется как TP × DP; задавайте --tensor-parallel-size и --data-parallel-size, а не предполагаемый флаг размера EP. |
| Что меняется? | Экспертные слои MoE распределяются по EP-рангам; слои внимания по-прежнему следуют документированному поведению TP/DP. |
| Когда это следует использовать? | Когда модель MoE, топология GPU, коммуникационная сеть и объем запросов оправдывают распределение работы экспертов. Это не универсальный переключатель ускорения для плотных моделей. |
| С чего начать? | С одного узла, фиксированной ревизии модели, фиксированной трассы трафика и базового варианта без EP. |
Официальное руководство по развертыванию vLLM expert parallel — главный источник информации об этой функции. В нем экспертный параллелизм описывается как распределение MoE-экспертов по GPU, обычно вместе с data parallelism.
Что фактически меняет vLLM expert parallel
Модель MoE направляет каждый токен к небольшому подмножеству множества экспертных сетей. Без экспертного параллелизма документированное поведение MoE в vLLM формирует группу tensor parallel по DP × TP. При использовании --enable-expert-parallel экспертные слои вместо этого используют экспертный параллелизм, тогда как слои внимания сохраняют собственное поведение TP/DP.
Рассмотрим конкретную топологию: TP=2 и DP=4.
| Компонент | Поведение параллелизма при включенном EP |
|---|---|
| Экспертные слои | Группа EP, охватывающая 8 рангов; эксперты распределены между этими GPU. |
| Слои внимания | Группы tensor parallel из 2 рангов внутри каждой из 4 групп DP. |
| Эффективный размер EP | 2 × 4 = 8. |
Именно поэтому vLLM expert parallel не заменяет необходимость определить, как сочетаются слои внимания, емкость KV-кэша, параллельность запросов и топология сети. Это лишь одна часть распределенной архитектуры обслуживания.
Более подробное введение в выбор многографического шаблона для рабочей нагрузки см. в статье Инференс vLLM на нескольких GPU: настройка tensor и pipeline parallel.
Флаг vLLM expert parallel и вопрос о «флаге размера»
Текущая публичная документация приводит канонический флаг активации:
--enable-expert-parallel
В ней также указано, что размер expert parallel вычисляется из размеров tensor и data parallel:
EP_SIZE = TP_SIZE × DP_SIZE
Таким образом, шаблон из документации по развертыванию vLLM expert parallel выглядит так:
vllm serve <MODEL> --tensor-parallel-size <TP> --data-parallel-size <DP> --enable-expert-parallel
Не копируйте отдельную опцию --expert-parallel-size из старого issue, внутренней обертки или другого стека обслуживания, предполагая, что она применима к вашей сборке vLLM. Рассматривайте вопрос «каков мой размер EP?» как вопрос топологии:
- Выберите количество GPU и узлов, доступных одной группе обслуживания.
- Выберите TP для шардирования слоев внимания и локального поведения модели.
- Выберите DP для емкости независимых движков и распределения запросов.
- Включите EP для слоев MoE.
- Подтвердите вычисленную топологию процессов в журналах запуска и выполните нагрузочный тест.
Справочник vLLM serve CLI является окончательным источником информации о флагах в конкретном релизе.
Перед развертыванием: проверка готовности
Выполните эти проверки, прежде чем винить expert parallel в проблеме запуска или пропускной способности.
| Проверка | Что проверить | Почему это важно |
|---|---|---|
| Версия | Зафиксируйте контейнер vLLM, стек CUDA и ревизию модели на каждом воркере. | Смешанные образы или несовпадающие wheel-пакеты могут превратить проблему топологии в непрозрачную ошибку ядра. |
| Соответствие модели | Учтите веса модели, KV-кеш, рабочие области среды выполнения и все избыточные эксперты, прежде чем выбирать количество GPU. | EP не отменяет необходимость планирования памяти. |
| Зависимости | Следуйте актуальным требованиям vLLM к ядрам EP, включая DeepEP и DeepGEMM там, где этого требует документация. | Документация по expert parallel указывает их как предварительные требования. |
| Сеть | Проверьте топологию GPU на одном узле и межузловую связь между GPU до первого продакшн-запроса. | EP добавляет обмен данными к каждому прямому проходу MoE. |
| Управляющая сеть | Явно задайте адрес первичного узла, доступность порта и выбор NIC. | Исправная плоскость данных не поможет, если обнаружение в плоскости управления направлено на неверный интерфейс. |
| Базовый уровень | Зафиксируйте задержку, пропускную способность, частоту ошибок и запас памяти GPU без EP. | Вам нужен сопоставимый ответ на вопрос: «Помог ли EP?» |
Для оценки памяти на этом этапе используйте руководство по требованиям LLM к памяти GPU, чтобы составить таблицу расчета емкости до резервирования более крупного кластера.
Сделайте первый эксперимент простым
Используйте одну ревизию модели, один проверенный токенизатор, один набор запросов, один диапазон конкурентной нагрузки и один фиксированный набор флагов запуска. Не меняйте квантование, настройки кеша, оборудование и бэкенд all-to-all в одном тесте. Чистый базовый уровень позволяет определить, изменил ли vLLM expert parallel полезную пропускную способность или лишь переместил узкое место.
Развертывание DeepSeek MoE на одном узле
В текущем руководстве vLLM DeepSeek-V3-0324 используется в качестве одновузлового примера с односторонним TP, восьмикратным DP и включенным EP:
vllm serve deepseek-ai/DeepSeek-V3-0324 --tensor-parallel-size 1 --data-parallel-size 8 --enable-expert-parallel
В документации объясняется предполагаемый эффект: веса внимания реплицируются между рангами DP, тогда как веса экспертов распределяются между GPU. В качестве примера топологии используется узел с восемью GPU H200 или H20, а командам с другим оборудованием рекомендуется проверить собственное соответствие требованиям, а не воспринимать этот пример как универсальное обещание по подбору размера.
Используйте эту команду как отправную точку для топологии, а не как конфигурацию для продакшена, которую можно просто скопировать и вставить. Прежде чем открывать эндпоинт:
- Убедитесь, что сервер переходит в исправное состояние готовности без скрытого переключения на другой путь ядра.
- Выполните тест корректности с известными промптами и ожидаемой схемой или поведением вызова инструментов.
- Подайте небольшую постоянную нагрузку, затем всплеск и выборку с длинным контекстом.
- Сравните p50 и p99 времени до первого токена, задержку между токенами, пропускную способность вывода, запас памяти и ошибки с базовым уровнем без EP.
- Сохраните команду запуска, digest образа, ревизию модели, версию драйвера и снимок метрик вместе с результатом бенчмарка.
Если вы все еще создаете окружающий API-слой, это руководство по развертыванию vLLM отдельно рассматривает путь сервера, совместимого с OpenAI, и решение о параллелизме MoE.
Выбирайте бэкенд all-to-all по нагрузке, а не по привычке
vLLM предоставляет --all2all-backend для коммуникации при expert parallel. В официальном руководстве сейчас описаны универсальный вариант по умолчанию и специализированные режимы DeepEP. Сопоставляйте бэкенд с трафиком, который вы действительно измерили.
| Бэкенд | Задокументированное применение | Последствие для развертывания |
|---|---|---|
allgather_reducescatter |
Универсальные развертывания EP + DP | Разумная контрольная конфигурация перед специализированной настройкой. |
deepep_high_throughput |
Многоузловые нагрузки с преобладанием prefill | Оцените этот вариант, когда длинные промпты и совокупная пропускная способность доминируют в целях сервиса. |
deepep_low_latency |
Многоузловые нагрузки с преобладанием decode | Оцените этот вариант, когда задержка генерации токенов важнее максимальной пропускной способности prefill. |
| Режимы FlashInfer NVLink | Системы, специфичные для MNNVL / NVLink | Используйте только тогда, когда оборудование и актуальная документация vLLM соответствуют требованиям бэкенда. |
Смысл не в том, чтобы выбрать метку, которая выглядит самой быстрой. Нужно тестировать по одному бэкенду за раз с учетом вашего распределения длины промптов, конкурентной нагрузки, сети и SLO. Измеряйте влияние как на хвостовую задержку, так и на число токенов в секунду.
Многоузловой vLLM expert parallel: схема с двумя узлами
Для многоузлового развертывания в документации vLLM используется первичный узел, который обрабатывает API-трафик, и вторичный рабочий узел --headless. Ниже приведена параметризованная форма этой задокументированной схемы. Замените адреса и количества значениями, соответствующими кластеру, который вы действительно протестировали.
На первичном узле:
export GLOO_SOCKET_IFNAME=eth0
vllm serve deepseek-ai/DeepSeek-V3-0324 --all2all-backend deepep_low_latency --tensor-parallel-size 1 --enable-expert-parallel --data-parallel-size 16 --data-parallel-size-local 8 --data-parallel-address <PRIMARY_NODE_IP> --data-parallel-rpc-port 13345 --api-server-count 8
На втором узле:
export GLOO_SOCKET_IFNAME=eth0
vllm serve deepseek-ai/DeepSeek-V3-0324 --all2all-backend deepep_low_latency --tensor-parallel-size 1 --enable-expert-parallel --data-parallel-size 16 --data-parallel-size-local 8 --data-parallel-start-rank 8 --data-parallel-address <PRIMARY_NODE_IP> --data-parallel-rpc-port 13345 --headless
Числа имеют значение:
--data-parallel-size— это общий размер DP для всей группы обслуживания.--data-parallel-size-local— это число DP-рангов, запускаемых на данном узле.--data-parallel-start-rank— это совокупный локальный размер DP предыдущих узлов.- Вторичный узел работает в безголовом режиме, поскольку первичный обрабатывает клиентские запросы.
Для кластеров InfiniBand в текущем руководстве vLLM отдельно указано GLOO_SOCKET_IFNAME=eth0, чтобы обнаружение распределённой группы выполнялось через выбранный Ethernet-интерфейс управления. Это не заменяет проверку NCCL и связи GPU-to-GPU между узлами.
Контрольный список приёмки для нескольких узлов
Прежде чем направлять клиентский трафик в группу vLLM expert parallel на нескольких узлах, подтвердите всё перечисленное ниже:
- Каждый worker разрешает одну и ту же ревизию модели и запускается с назначенным рангом.
- Первичный узел может обращаться к настроенному RPC-адресу и порту с каждого однорангового узла.
- Распределённая группа многократно инициализируется после чистого перезапуска.
- Запрос завершается при низкой конкурентности, а затем при длительной трассе нагрузки.
- Преднамеренно несбалансированная смесь запросов не вызывает скрытых зависаний или резкого ухудшения хвостовой задержки.
- Перезапуск одного тестового worker создаёт наблюдаемый и пригодный для действий сигнал сбоя, а не приводит к бесконечному ожиданию запросов в очереди.
Руководство по устранению неполадок распределённого vLLM рекомендует проверить межузловую связь GPU и сделать переменные окружения для коммуникации доступными на каждом узле. Если вы используете Ray, в нём также описано, как согласовать настройки host IP для vLLM и Ray.
Добавляйте балансировку нагрузки Expert Parallel только после выявления дисбаланса
Маршрутизация MoE в production не всегда распределяется равномерно. Балансировщик нагрузки Expert Parallel (EPLB) в vLLM собирает данные о нагрузке и периодически перераспределяет сопоставления экспертов между EP-рангами. Эта функция включается с помощью --enable-eplb.
vllm serve Qwen/Qwen3-30B-A3B --enable-expert-parallel --enable-eplb --eplb-config '{"window_size":1000,"step_interval":3000,"num_redundant_experts":2,"log_balancedness":true}'
Начинайте без EPLB, если только у вас нет свидетельств наличия перегруженных экспертов, неравномерной работы по рангам или устойчивой хвостовой задержки, коррелирующей с перекосом маршрутизации. EPLB может использовать избыточных экспертов, и эти дополнительные копии экспертов потребляют память GPU. Рассматривайте его как оптимизацию с затратами на ёмкость, а не как обязательный флаг vLLM expert parallel.
Для первого эксперимента:
- Записывайте утилизацию по рангам и задержку запросов без EPLB.
- Включите журналирование сбалансированности на контролируемый интервал.
- Добавьте минимальную настройку избыточности, укладывающуюся в бюджет памяти.
- Сравните хвостовую задержку, пропускную способность, запас памяти и нарушения при перебалансировке на одной и той же трассе.
- Держите наготове команду отката и конфигурацию развертывания без EPLB.
План бенчмаркинга, отвечающий на правильный вопрос
Не считайте развертывание EP успешным только потому, что процесс запускается. Для каждого сравнения используйте одну и ту же ревизию модели, промпты, ограничения вывода, конкурентность, квантизацию, настройки кэша и резервирование оборудования.
| Тест | Что выявляет | Сигнал для принятия решения |
|---|---|---|
| Декодирование с короткими промптами и высокой конкурентностью | Поведение collective-операций и очередей на стороне декодирования | Межтокенная задержка p99 и пропускная способность по генерируемым токенам |
| Prefill с длинными промптами | Накладные расходы prefill и all-to-all | Время до первого токена p99 и совокупная пропускная способность prefill |
| Трасса с перекосом экспертов | Создаёт ли небольшой набор экспертов перегруженные ранги | Дисбаланс рангов, рост очередей и необходимость EPLB |
| Тест ёмкости с длинным контекстом | Запас памяти при реалистичной нагрузке на кэш | Частота OOM, отказы в допуске и безопасная конкурентность |
| Проверка перезапуска / разделения сети | Операционное поведение при сбое однорангового узла или заблокированном порте | Время обнаружения, видимость ошибок и путь восстановления |
Фиксируйте не только среднюю пропускную способность. Развертывание, которое улучшает среднее значение, но ухудшает задержку p99 или делает восстановление непрозрачным, не является однозначным выигрышем для production.
Устранение неполадок при развертывании vLLM expert parallel
| Симптом | Вероятный класс причины | Первое действие |
|---|---|---|
Неизвестный аргумент --expert-parallel-size |
Инструкция и установленная версия vLLM не совпадают | Выполните vllm serve --help, зафиксируйте сборку и используйте параметры TP/DP, задокументированные для этой сборки. |
| Сбой запуска, связанный с EP-ядром или бэкендом all-to-all | Отсутствующая или несовместимая зависимость EP / стек контейнера | Повторно проверьте актуальные требования EP и образ контейнера, а не меняйте сразу несколько флагов запуска. |
| Многоузловые воркеры зависают во время инициализации | Адрес плоскости управления, порт, NIC или конфигурация группы процессов | Проверьте доступность, выбранные интерфейсы, расчёт рангов и распределённые коммуникации, прежде чем настраивать ядра. |
| Первый запрос зависает после того, как воркеры кажутся готовыми | Межузловая GPU-коммуникация работает некорректно | Выполните проверки коммуникации от поставщика/vLLM, затем изучите конфигурацию NCCL и интерфейсов. |
| Пропускная способность не увеличивается | Узким местом по-прежнему остаются смесь трафика, сеть, поведение батчей или конфигурация на стороне attention | Сравните с базовым вариантом по длине промпта и параллельности; изменяйте по одной переменной топологии за раз. |
| Нехватка памяти после включения EPLB | Память для избыточных экспертов исчерпала запас безопасности | Уменьшите избыточность или зарезервируйте больший запас памяти; повторите тест ёмкости. |
| Один ранг стабильно работает медленнее | Перекос маршрутизации экспертов или неравномерная производительность хостов/сети | Сначала измерьте нагрузку на уровне рангов; рассматривайте EPLB, только если данные это подтверждают. |
Важная привычка — узкая диагностика. Не меняйте модель, образ, трассу трафика и топологию, пока изменяете один фактор. Это превращает расплывчатое сообщение «EP работает медленно» в наблюдение, по которому можно действовать.
Последовательность внедрения в production
- Установите базовый уровень. Запустите целевую MoE-модель без EP и сохраните метрики, логи и манифест запуска.
- Включите EP на одном узле. Используйте
--enable-expert-parallelс явно выбранной топологией TP/DP. - Проверьте качество и ёмкость. Проверьте поведение вывода, запас памяти, задержку p50/p99 и устойчивую пропускную способность.
- Выберите бэкенд по форме трафика. Сравнивайте универсальный бэкенд с подходящим специализированным бэкендом только на одной и той же трассе.
- Добавляйте EPLB только при наличии подтверждений. Используйте данные о сбалансированности и запасе памяти, чтобы обосновать избыточных экспертов.
- Расширьтесь до нескольких узлов. Проверьте распределение рангов, управляющую сеть и межузловую GPU-коммуникацию, прежде чем повышать трафик.
- Проведите тренировку отказа. Протестируйте перезапуск, потерю порта и нездоровый воркер, прежде чем проблему обнаружит production-трафик.
- Зафиксируйте и задокументируйте. Сохраните версии, флаги запуска, топологию, метрики и шаги отката рядом с развертыванием.
Когда не стоит самостоятельно хостить слой обслуживания MoE
Экспертный параллелизм vLLM — правильная инвестиция, когда контроль над размещением модели, путём данных, резервированием оборудования и поведением обслуживания является частью требований к продукту. Он плохо подходит, когда команде в основном нужен доступ к модели и она не может взять на себя использование GPU, распределённую сеть, тестирование обновлений и восстановление по вызову.
Прежде чем резервировать более крупный кластер, сравните операционную модель с путём через управляемый API в статье GPU cloud vs. model API: when self-hosting actually saves money. Правильным решением может быть гибридный подход: самостоятельно хостить нагрузку, которой нужен контроль над инфраструктурой, и использовать API-слой для остального.
FAQ
Включает ли --enable-expert-parallel экспертный параллелизм vLLM?
Да. В текущей документации CLI vLLM флаг --enable-expert-parallel описан как использование экспертного параллелизма вместо тензорного параллелизма для слоёв MoE.
Какой флаг задаёт размер экспертного параллелизма vLLM?
В текущем задокументированном процессе развертывания размер EP выводится из --tensor-parallel-size и --data-parallel-size: EP_SIZE = TP × DP. Проверьте точный набор параметров CLI в закреплённом вами релизе vLLM, а не предполагайте наличие отдельного флага размера.
Заменяет ли экспертный параллелизм тензорный параллелизм повсюду?
Нет. EP меняет стратегию для слоёв экспертов MoE. Поведение слоёв attention по-прежнему зависит от выбранных вами значений TP и DP.
Должно ли каждое развертывание DeepSeek включать EPLB?
Нет. Сначала подтвердите дисбаланс нагрузки экспертов на репрезентативном трафике и убедитесь, что затраты памяти на избыточных экспертов соответствуют возможностям кластера. EPLB — это оптимизация, а не обязательное требование по умолчанию.
Какой бэкенд all-to-all следует использовать?
Начните с актуальных рекомендаций vLLM, затем протестируйте бэкенд, соответствующий форме вашей нагрузки: универсальный вариант для широкой совместимости, высокопроизводительный режим DeepEP для трафика с преобладанием prefill или низколатентный режим DeepEP для трафика с преобладанием decode.
Ссылки
- Документация по развертыванию vLLM Expert Parallel
- Документация по развертыванию vLLM Data Parallel
- Справочник по CLI vLLM serve
- Устранение неполадок распределенного развертывания vLLM
Следующий шаг: используйте команду для одного узла в качестве контролируемой среды валидации, зафиксируйте базовые показатели и продвигайте только ту топологию, которая улучшает SLO, действительно важный для вас. Именно так vLLM expert parallel становится производственным решением, а не флагом, который, как вы надеетесь, работает быстрее.
