Despliegue de vLLM Expert Parallel para DeepSeek y otros modelos MoE
vLLM expert parallel es el modo de despliegue que se debe usar cuando las capas de expertos de un modelo MoE deben dividirse entre GPU en lugar de gestionarse como un único grupo grande de paralelismo de tensores. En la versión actual de vLLM, el modificador es --enable-expert-parallel. El paralelismo de expertos se dimensiona indirectamente mediante la configuración de paralelismo de tensores (TP) y paralelismo de datos (DP): vLLM documenta EP_SIZE = TP_SIZE × DP_SIZE.
Ese detalle es importante. Muchos manuales de operaciones buscan una «marca de tamaño de vLLM expert parallel» independiente y luego intentan forzar una marca que no forma parte de la compilación fijada. Comience con el modificador compatible, compruebe vllm serve --help en la imagen exacta que desplegará y tome las decisiones de TP/DP a partir de un plan de capacidad medido.
Esta guía práctica cubre una ruta segura desde un despliegue MoE de DeepSeek en un solo nodo hasta vLLM expert parallel multinodo, incluida la elección del backend, el equilibrio de carga de expertos, las pruebas de aceptación y el aislamiento de fallos. Está escrita para ingenieros de infraestructura de ML e IA, no para una demostración de un solo comando.
Nota sobre la versión: los kernels MoE, las dependencias y la superficie de CLI de vLLM evolucionan rápidamente. El comportamiento documentado y los comandos que aparecen a continuación se comprobaron con la documentación oficial de vLLM el 16 de octubre de 2026. Fije la imagen de vLLM y verifique las marcas con esa versión fijada antes de un lanzamiento en producción.
La respuesta corta
| Pregunta | Respuesta práctica |
|---|---|
| ¿Qué habilita vLLM expert parallel? | Añada --enable-expert-parallel a un despliegue MoE compatible. |
| ¿Cómo se elige el tamaño de EP? | En la documentación actual de vLLM expert parallel, se calcula como TP × DP; configure --tensor-parallel-size y --data-parallel-size, no una marca de tamaño de EP supuesta. |
| ¿Qué cambia? | Las capas de expertos MoE se fragmentan entre rangos EP; las capas de atención siguen el comportamiento TP/DP documentado. |
| ¿Cuándo debería usarlo? | Cuando un modelo MoE, la topología de GPU, el tejido de comunicación y el volumen de solicitudes justifiquen distribuir el trabajo de expertos. No es un modificador de velocidad genérico para modelos densos. |
| ¿Por dónde debería empezar? | Un nodo, una revisión de modelo fija, una traza de tráfico fija y una línea base que no use EP. |
La guía oficial de despliegue de vLLM expert parallel es la fuente de referencia para esta funcionalidad. Describe el paralelismo de expertos como la distribución de expertos MoE entre GPU, normalmente junto con el paralelismo de datos.
Qué cambia realmente vLLM expert parallel
Un modelo MoE enruta cada token a un pequeño subconjunto de muchas redes de expertos. Sin paralelismo de expertos, el comportamiento MoE documentado de vLLM forma un grupo de paralelismo de tensores entre DP × TP. Con --enable-expert-parallel, las capas de expertos usan en su lugar paralelismo de expertos, mientras que las capas de atención mantienen su propio comportamiento TP/DP.
Para una topología concreta, considere TP=2 y DP=4:
| Componente | Comportamiento de paralelismo con EP habilitado |
|---|---|
| Capas de expertos | Un grupo EP que abarca 8 rangos; los expertos se distribuyen entre esas GPU. |
| Capas de atención | Grupos de paralelismo de tensores de 2 dentro de cada uno de los 4 grupos DP. |
| Tamaño EP efectivo | 2 × 4 = 8. |
Por eso vLLM expert parallel no sustituye la decisión de cómo encajan las capas de atención, la capacidad de caché KV, la concurrencia de solicitudes y la topología de red. Es una parte de un diseño de serving distribuido.
Para una introducción más amplia sobre qué patrón multi-GPU se ajusta a una carga de trabajo, consulte inferencia multi-GPU de vLLM: configuración de paralelismo de tensores y de canalización.
La marca de vLLM expert parallel y la cuestión de la «marca de tamaño»
La documentación pública actual proporciona la marca de activación canónica:
--enable-expert-parallel
También indica que el tamaño de paralelismo de expertos se calcula a partir de los tamaños de paralelismo de tensores y de datos:
EP_SIZE = TP_SIZE × DP_SIZE
Por tanto, el patrón de la documentación de despliegue de vLLM expert parallel es:
vllm serve <MODEL> --tensor-parallel-size <TP> --data-parallel-size <DP> --enable-expert-parallel
No copie una opción --expert-parallel-size independiente de un problema antiguo, un envoltorio interno u otra pila de serving y suponga que se aplica a su compilación de vLLM. Trate la pregunta «¿cuál es mi tamaño de EP?» como una cuestión de topología:
- Elija el número de GPU y nodos disponibles para un grupo de serving.
- Elija TP para la fragmentación de las capas de atención y el comportamiento local del modelo.
- Elija DP para la capacidad independiente del motor y la distribución de solicitudes.
- Habilite EP para las capas MoE.
- Confirme la topología de procesos calculada en los registros de inicio y ejecute una prueba de carga.
La referencia de la CLI serve de vLLM es la autoridad final sobre las marcas en una versión específica.
Antes de desplegar: la puerta de preparación
Realice estas comprobaciones antes de culpar al paralelismo de expertos de un problema de inicio o de rendimiento.
| Control | Qué verificar | Por qué importa |
|---|---|---|
| Versión | Fije el contenedor de vLLM, la pila de CUDA y la revisión del modelo en todos los workers. | Una imagen mixta o una wheel no coincidente puede convertir un problema de topología en un error opaco del kernel. |
| Ajuste del modelo | Considere los pesos del modelo, la caché KV, los espacios de trabajo de tiempo de ejecución y cualquier experto redundante antes de elegir la cantidad de GPU. | EP no elimina la planificación de memoria. |
| Dependencias | Siga los requisitos previos actuales de los kernels EP de vLLM, incluidos DeepEP y DeepGEMM cuando la documentación los exija. | La documentación de paralelismo de expertos los señala como requisitos previos. |
| Fabric | Verifique la topología de GPU en un nodo y la comunicación de GPU entre nodos antes de la primera solicitud de producción. | EP añade comunicación a cada pasada hacia adelante de MoE. |
| Red de control | Haga explícitos la dirección del nodo principal, la accesibilidad del puerto y la selección de NIC. | Un plano de datos saludable no ayuda cuando el descubrimiento del plano de control apunta a la interfaz equivocada. |
| Línea base | Capture la latencia, el rendimiento, la tasa de errores y el margen de memoria de GPU sin EP. | Necesita una respuesta comparable a «¿EP ayudó?». |
Para el aspecto de memoria de este control, use la guía de requisitos de memoria de GPU para LLM para crear una hoja de cálculo de capacidad antes de reservar un clúster más grande.
Mantenga el primer experimento simple
Use una revisión de modelo, un tokenizador conocido, una mezcla de solicitudes, un rango de concurrencia y un conjunto fijo de indicadores de lanzamiento. Evite cambiar la cuantización, la configuración de caché, el hardware y el backend all-to-all en la misma prueba. Una línea base limpia permite determinar si el paralelismo de expertos de vLLM cambió el rendimiento útil o solo desplazó el cuello de botella.
Despliegue de DeepSeek MoE en un solo nodo
La guía actual de vLLM usa DeepSeek-V3-0324 como ejemplo de un solo nodo con TP unidireccional, DP de ocho vías y EP habilitado:
vllm serve deepseek-ai/DeepSeek-V3-0324 --tensor-parallel-size 1 --data-parallel-size 8 --enable-expert-parallel
La documentación explica el efecto previsto: los pesos de atención se replican entre los rangos de DP, mientras que los pesos de los expertos se dividen entre las GPU. Usa un nodo H200 o H20 de ocho GPU como topología de ejemplo y aconseja a los equipos con hardware diferente validar su propio ajuste en lugar de tratar el ejemplo como una promesa universal de dimensionamiento.
Use ese comando como punto de partida de topología, no como una configuración de producción para copiar y pegar. Antes de exponer un endpoint:
- Confirme que el servidor alcanza un estado listo y saludable sin recurrir de forma oculta a una ruta de kernel diferente.
- Ejecute una prueba de corrección con prompts conocidos y el comportamiento esperado de esquema o llamada a herramientas.
- Aplique una carga estable pequeña, luego una ráfaga y una muestra de contexto largo.
- Compare el tiempo p50 y p99 hasta el primer token, la latencia entre tokens, el rendimiento de salida, el margen de memoria y los errores con la línea base sin EP.
- Guarde el comando de lanzamiento, el digest de la imagen, la revisión del modelo, la versión del controlador y la instantánea de métricas junto con el resultado del benchmark.
Si todavía está creando la capa de API circundante, esta guía de despliegue de vLLM cubre la ruta del servidor compatible con OpenAI por separado de la decisión sobre el paralelismo MoE.
Seleccione el backend all-to-all según la carga de trabajo, no por costumbre
vLLM expone --all2all-backend para la comunicación de paralelismo de expertos. La guía oficial describe actualmente un valor predeterminado de propósito general y modos especializados de DeepEP. Ajuste el backend al tráfico que realmente midió.
| Backend | Ajuste documentado | Implicación para el despliegue |
|---|---|---|
allgather_reducescatter |
Despliegues de propósito general con EP + DP | Una configuración de control sensata antes de la optimización especializada. |
deepep_high_throughput |
Cargas de trabajo multinodo dominadas por prefill | Evalúelo cuando los prompts largos y el rendimiento agregado dominen el objetivo del servicio. |
deepep_low_latency |
Cargas de trabajo multinodo dominadas por decodificación | Evalúelo cuando la latencia de los tokens generados importe más que el rendimiento máximo de prefill. |
| Modos NVLink de FlashInfer | Sistemas específicos de MNNVL / NVLink | Úselos solo cuando el hardware y la documentación actual de vLLM coincidan con los requisitos del backend. |
El objetivo no es elegir la etiqueta que parece más rápida. Es probar un backend a la vez con respecto a su combinación de longitudes de prompts, concurrencia, fabric y SLO. Mida el efecto en la latencia de cola, así como en los tokens por segundo.
Paralelismo de expertos de vLLM multinodo: un patrón de dos nodos
Para el despliegue multinodo, la documentación de vLLM usa un nodo principal que gestiona el tráfico de API y un nodo worker secundario --headless. Lo siguiente es una forma parametrizada de ese patrón documentado. Sustituya las direcciones y los recuentos por valores que coincidan con el clúster que realmente probó.
En el nodo principal:
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
En el segundo nodo:
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
Los números importan:
--data-parallel-sizees el tamaño total de DP en todo el grupo de servicio.--data-parallel-size-locales el número de rangos de DP iniciados en ese nodo.--data-parallel-start-rankes el tamaño acumulado de DP local de los nodos anteriores.- El nodo secundario no tiene interfaz porque el primario gestiona las solicitudes de los clientes.
Para clústeres InfiniBand, la guía actual de vLLM destaca específicamente GLOO_SOCKET_IFNAME=eth0 para mantener la detección de grupos distribuidos en la interfaz de control Ethernet seleccionada. Esto no sustituye la validación de NCCL y de la comunicación GPU a GPU entre nodos.
Lista de verificación de aceptación multinodo
Antes de enviar tráfico de clientes a un grupo paralelo de expertos vLLM multinodo, demuestre todo lo siguiente:
- Cada trabajador resuelve la misma revisión del modelo e inicia con el rango previsto.
- El nodo primario puede alcanzar la dirección y el puerto RPC configurados desde cada par.
- El grupo distribuido se inicializa repetidamente después de un reinicio limpio.
- Una solicitud se completa con baja concurrencia y luego bajo una traza sostenida.
- Una mezcla de solicitudes deliberadamente sesgada no provoca bloqueos silenciosos ni un desplome de la latencia de cola.
- Reiniciar un trabajador de prueba produce una señal de error observable y accionable, en lugar de solicitudes en cola indefinidamente.
La guía de solución de problemas distribuidos de vLLM recomienda verificar la comunicación GPU entre nodos y poner las variables de entorno de comunicación a disposición de cada nodo. Si usa Ray, también documenta mantener alineada la configuración de IP de host de vLLM y Ray.
Añada el equilibrio de carga Expert Parallel solo después de observar desequilibrio
El enrutamiento MoE no siempre se distribuye uniformemente en producción. El equilibrador de carga Expert Parallel (EPLB) de vLLM recopila datos de carga y redistribuye periódicamente las asignaciones de expertos entre los rangos EP. La función se habilita con --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}'
Comience sin EPLB a menos que tenga evidencia de expertos sobrecargados, trabajo desigual por rango o latencia de cola persistente que se correlacione con el sesgo de enrutamiento. EPLB puede usar expertos redundantes, y esas copias adicionales de expertos consumen memoria GPU. Trátelo como una optimización con un coste de capacidad, no como una opción obligatoria de vLLM expert parallel.
Para un experimento inicial:
- Registre la utilización por rango y la latencia de las solicitudes sin EPLB.
- Habilite el registro de equilibrio durante una ventana controlada.
- Añada la configuración de redundancia más pequeña que se ajuste al presupuesto de memoria.
- Compare la latencia de cola, el rendimiento, el margen de memoria y la interrupción por reequilibrio con la misma traza.
- Mantenga listo el comando de reversión y la configuración de despliegue sin EPLB.
Un plan de benchmarking que responde a la pregunta correcta
No considere exitosa una implementación EP solo porque el proceso se inicia. Use la misma revisión del modelo, prompts, límites de salida, concurrencia, cuantización, configuración de caché y reserva de hardware para cada comparación.
| Prueba | Qué revela | Señal de decisión |
|---|---|---|
| Decodificación con prompts cortos y alta concurrencia | Comportamiento de colectivos y colas en la decodificación | Latencia p99 entre tokens y rendimiento de tokens generados |
| Prefill con prompts largos | Sobrecarga de prefill y all-to-all | Tiempo p99 hasta el primer token y rendimiento agregado de prefill |
| Traza con sesgo de expertos | Si un pequeño conjunto de expertos crea rangos sobrecargados | Desequilibrio de rangos, crecimiento de colas y justificación para EPLB |
| Prueba de capacidad con contexto largo | Margen de memoria bajo presión realista de caché | Tasa de OOM, fallos de admisión y concurrencia segura |
| Simulacro de reinicio / partición | Comportamiento operativo ante un par fallido o un puerto bloqueado | Tiempo de detección, visibilidad de errores y ruta de recuperación |
Registre más que el rendimiento promedio. Un despliegue que mejora la media mientras degrada la latencia p99 o hace opaca la recuperación no es una mejora clara para producción.
Solución de problemas en despliegues vLLM expert parallel
| Síntoma | Clase probable de causa | Primer paso |
|---|---|---|
Argumento --expert-parallel-size desconocido |
El runbook y la versión instalada de vLLM no coinciden | Ejecute vllm serve --help, fije la compilación y use el dimensionamiento TP/DP documentado para esa compilación. |
| El inicio falla en torno a un kernel de EP o un backend all-to-all | Dependencia de EP o pila de contenedores ausente o incompatible | Vuelva a comprobar los requisitos actuales de EP y la imagen de contenedor, en lugar de cambiar varias opciones de inicio a la vez. |
| Los workers multinodo se bloquean durante la inicialización | Configuración de dirección del plano de control, puerto, NIC o grupo de procesos | Verifique la conectividad, las interfaces seleccionadas, el cálculo de rangos y la comunicación distribuida antes de ajustar los kernels. |
| La primera solicitud se bloquea después de que los workers parecen estar listos | La comunicación de GPU entre nodos no es correcta | Ejecute las comprobaciones de comunicación del proveedor/vLLM y, después, inspeccione la configuración de NCCL y de las interfaces. |
| El rendimiento no mejora | La mezcla de tráfico, la red, el comportamiento de los lotes o la configuración del lado de atención siguen siendo el cuello de botella | Compare con la línea base según la longitud del prompt y la concurrencia; cambie una variable de topología cada vez. |
| Falta de memoria después de habilitar EPLB | La memoria de expertos redundantes consumió el margen de seguridad | Reduzca la redundancia o reserve más margen de memoria; repita la prueba de capacidad. |
| Un rango es persistentemente más lento | Sesgo en el enrutamiento de expertos o rendimiento desigual del host/la red | Mida primero la carga a nivel de rango; considere EPLB solo si la evidencia lo respalda. |
El hábito importante es el diagnóstico acotado. Mantenga fijos el modelo, la imagen, la traza de tráfico y la topología mientras cambia un factor. Eso convierte un informe vago de «EP es lento» en una observación accionable.
Secuencia de despliegue en producción
- Establezca la línea base. Ejecute el modelo MoE objetivo sin EP y conserve las métricas, los registros y el manifiesto de inicio.
- Habilite EP en un nodo. Use
--enable-expert-parallelcon una topología TP/DP elegida explícitamente. - Verifique la calidad y la capacidad. Compruebe el comportamiento de salida, el margen de memoria, la latencia p50/p99 y el rendimiento sostenido.
- Elija un backend según la forma del tráfico. Compare el backend general con un backend especializado relevante únicamente con la misma traza.
- Añada EPLB solo si hay evidencia. Use datos de equilibrio y margen de memoria para justificar expertos redundantes.
- Amplíe a multinodo. Verifique la asignación de rangos, la red de control y la comunicación de GPU entre nodos antes de aumentar el tráfico.
- Realice un simulacro de fallos. Pruebe el reinicio, la pérdida de puertos y un worker no saludable antes de que el tráfico de producción detecte la brecha por usted.
- Fije y documente. Guarde las versiones, las opciones de inicio, la topología, las métricas y los pasos de reversión junto al despliegue.
Cuándo no alojar usted mismo la capa de serving de MoE
El paralelismo de expertos de vLLM es la inversión adecuada cuando el control sobre la ubicación del modelo, la ruta de datos, la reserva de hardware y el comportamiento de serving forma parte de los requisitos del producto. No es una buena opción cuando el equipo necesita principalmente acceso al modelo y no puede asumir la utilización de GPU, las redes distribuidas, las pruebas de actualización y la recuperación de guardia.
Antes de reservar un clúster más grande, compare el modelo operativo con una vía de API gestionada en Nube de GPU frente a API de modelo: cuándo el alojamiento propio realmente ahorra dinero. La respuesta adecuada puede ser híbrida: alojar usted mismo la carga de trabajo que necesita control de infraestructura y usar una capa de API para el resto.
Preguntas frecuentes
¿--enable-expert-parallel habilita el paralelismo de expertos de vLLM?
Sí. La CLI actual de vLLM documenta --enable-expert-parallel como el uso de paralelismo de expertos en lugar de paralelismo de tensores para las capas MoE.
¿Cuál es la opción de tamaño de paralelismo de expertos de vLLM?
Para el flujo de despliegue documentado actual, el tamaño de EP se deriva de --tensor-parallel-size y --data-parallel-size: EP_SIZE = TP × DP. Verifique la superficie exacta de la CLI en su versión fijada de vLLM en lugar de asumir que existe una opción de tamaño independiente.
¿El paralelismo de expertos reemplaza el paralelismo de tensores en todas partes?
No. EP cambia la estrategia de las capas de expertos MoE. El comportamiento de las capas de atención sigue dependiendo de los valores de TP y DP que elija.
¿Todos los despliegues de DeepSeek deberían habilitar EPLB?
No. Primero demuestre el desequilibrio de carga de expertos con tráfico representativo y confirme que el coste de memoria de los expertos redundantes cabe en el clúster. EPLB es una optimización, no un requisito predeterminado.
¿Qué backend all-to-all debería usar?
Parta de la guía actual de vLLM y, después, pruebe el backend que se ajuste a la forma de su carga de trabajo: una opción de propósito general para amplia compatibilidad, un modo DeepEP de alto rendimiento para tráfico intensivo de prefill o un modo DeepEP de baja latencia para tráfico intensivo de decode.
Referencias
- Documentación de despliegue Expert Parallel de vLLM
- Documentación de despliegue Data Parallel de vLLM
- Referencia de la CLI vLLM serve
- Solución de problemas de despliegues distribuidos de vLLM
Siguiente paso: utiliza el comando de un solo nodo como entorno de validación controlado, captura una línea de base y promociona únicamente la topología que mejore el SLO que realmente te importa. Así es como el paralelismo de expertos de vLLM se convierte en una decisión de producción, en lugar de una opción que esperas que sea más rápida.
