Implantação Paralela por Especialistas do vLLM para DeepSeek e Outros Modelos MoE
O paralelismo por especialistas do vLLM é o modo de implantação a usar quando as camadas de especialistas de um modelo MoE devem ser divididas entre GPUs, em vez de serem tratadas como um único grande grupo de paralelismo de tensor. No vLLM atual, a opção é --enable-expert-parallel. Você dimensiona o paralelismo por especialistas indiretamente por meio das configurações de paralelismo de tensor (TP) e paralelismo de dados (DP): a documentação do vLLM define EP_SIZE = TP_SIZE × DP_SIZE.
Esse detalhe é importante. Muitos runbooks procuram uma “flag de tamanho do paralelismo por especialistas do vLLM” separada e, em seguida, tentam forçar uma flag que não faz parte da versão fixada. Comece pela opção compatível, verifique vllm serve --help na imagem exata que você implantará e escolha TP/DP com base em um plano de capacidade medido.
Este playbook aborda um caminho seguro de uma implantação DeepSeek MoE em nó único até o paralelismo por especialistas do vLLM em múltiplos nós, incluindo escolha de backend, balanceamento de carga dos especialistas, testes de aceitação e isolamento de falhas. Ele foi escrito para engenheiros de infraestrutura de ML e IA, não para uma demonstração de um único comando.
Nota sobre versão: os kernels de MoE, as dependências e a superfície de CLI do vLLM evoluem rapidamente. O comportamento documentado e os comandos abaixo foram verificados na documentação oficial do vLLM em 16 de outubro de 2026. Fixe a imagem do vLLM e verifique as flags nessa versão fixada antes de uma implantação em produção.
A resposta curta
| Pergunta | Resposta prática |
|---|---|
| O que habilita o paralelismo por especialistas do vLLM? | Adicione --enable-expert-parallel a uma implantação MoE compatível. |
| Como o tamanho de EP é escolhido? | Na documentação atual de paralelismo por especialistas do vLLM, ele é calculado como TP × DP; defina --tensor-parallel-size e --data-parallel-size, e não uma flag de tamanho de EP presumida. |
| O que muda? | As camadas de especialistas MoE são fragmentadas entre ranks de EP; as camadas de atenção continuam seguindo o comportamento TP/DP documentado. |
| Quando você deve usá-lo? | Quando um modelo MoE, a topologia de GPUs, a malha de comunicação e o volume de requisições justificarem a distribuição do trabalho dos especialistas. Não é uma opção genérica de aceleração para modelos densos. |
| Por onde você deve começar? | Um nó, revisão de modelo fixa, rastreamento de tráfego fixo e uma linha de base que não use EP. |
O guia oficial de implantação com paralelismo por especialistas do vLLM é a fonte de referência para o recurso. Ele descreve o paralelismo por especialistas como a distribuição de especialistas MoE entre GPUs, geralmente junto com o paralelismo de dados.
O que o paralelismo por especialistas do vLLM realmente muda
Um modelo MoE roteia cada token para um pequeno subconjunto de muitas redes especialistas. Sem paralelismo por especialistas, o comportamento MoE documentado do vLLM forma um grupo de paralelismo de tensor entre DP × TP. Com --enable-expert-parallel, as camadas de especialistas passam a usar paralelismo por especialistas, enquanto as camadas de atenção mantêm seu próprio comportamento TP/DP.
Para uma topologia concreta, considere TP=2 e DP=4:
| Componente | Comportamento de paralelismo com EP habilitado |
|---|---|
| Camadas de especialistas | Um grupo EP abrangendo 8 ranks; os especialistas são distribuídos entre essas GPUs. |
| Camadas de atenção | Grupos de paralelismo de tensor de 2 dentro de cada um dos 4 grupos DP. |
| Tamanho efetivo de EP | 2 × 4 = 8. |
É por isso que o paralelismo por especialistas do vLLM não substitui a decisão de como as camadas de atenção, a capacidade do cache KV, a concorrência de requisições e a topologia de rede se encaixam. Ele é uma parte de um projeto de serving distribuído.
Para uma introdução mais ampla sobre qual padrão multi-GPU se adequa a uma carga de trabalho, consulte inferência multi-GPU do vLLM: configuração de paralelismo de tensor e pipeline.
A flag de paralelismo por especialistas do vLLM e a questão da “flag de tamanho”
A documentação pública atual apresenta a flag canônica de ativação:
--enable-expert-parallel
Ela também afirma que o tamanho do paralelismo por especialistas é calculado a partir dos tamanhos de paralelismo de tensor e de dados:
EP_SIZE = TP_SIZE × DP_SIZE
Portanto, o padrão dos documentos de implantação com paralelismo por especialistas do vLLM é:
vllm serve <MODEL> --tensor-parallel-size <TP> --data-parallel-size <DP> --enable-expert-parallel
Não copie uma opção --expert-parallel-size separada de uma issue antiga, de um wrapper interno ou de outra stack de serving e presuma que ela se aplica à sua versão do vLLM. Trate a pergunta “qual é o meu tamanho de EP?” como uma questão de topologia:
- Escolha o número de GPUs e nós disponíveis para um grupo de serving.
- Escolha TP para a fragmentação das camadas de atenção e o comportamento local do modelo.
- Escolha DP para a capacidade de mecanismos independentes e a distribuição de requisições.
- Habilite EP para as camadas MoE.
- Confirme a topologia de processos calculada nos logs de inicialização e execute um teste de carga.
A referência da CLI serve do vLLM é a autoridade final sobre as flags em uma versão específica.
Antes de implantar: a etapa de prontidão
Faça estas verificações antes de atribuir um problema de inicialização ou de throughput ao paralelismo por especialistas.
| Verificação | O que verificar | Por que isso importa |
|---|---|---|
| Versão | Fixe o contêiner do vLLM, a pilha CUDA e a revisão do modelo em todos os workers. | Uma imagem mista ou uma wheel incompatível pode transformar um problema de topologia em um erro opaco de kernel. |
| Adequação do modelo | Considere os pesos do modelo, o cache KV, os espaços de trabalho de runtime e quaisquer especialistas redundantes antes de escolher a quantidade de GPUs. | EP não elimina o planejamento de memória. |
| Dependências | Siga os pré-requisitos atuais dos kernels EP do vLLM, incluindo DeepEP e DeepGEMM quando a documentação os exigir. | A documentação de paralelismo por especialistas os destaca como pré-requisitos. |
| Fabric | Verifique a topologia de GPU em um nó e confirme a comunicação de GPU entre nós antes da primeira solicitação de produção. | EP adiciona comunicação a cada passagem direta de MoE. |
| Rede de controle | Defina explicitamente o endereço do nó primário, a acessibilidade da porta e a seleção de NIC. | Um plano de dados saudável não ajuda quando a descoberta do plano de controle aponta para a interface errada. |
| Linha de base | Registre latência, throughput, taxa de erros e margem de memória da GPU sem EP. | Você precisa de uma resposta comparável para “o EP ajudou?” |
Para o aspecto de memória desta verificação, use o guia de requisitos de memória de GPU para LLMs para criar uma planilha de capacidade antes de reservar um cluster maior.
Mantenha o primeiro experimento simples
Use uma revisão de modelo, um tokenizador conhecido, uma combinação de solicitações, um limite de concorrência e um conjunto fixo de flags de inicialização. Evite alterar a quantização, as configurações de cache, o hardware e o backend all-to-all no mesmo teste. Uma linha de base limpa permite identificar se o paralelismo por especialistas do vLLM alterou o throughput útil ou apenas deslocou o gargalo.
Implantação de DeepSeek MoE em nó único
O guia atual do vLLM usa DeepSeek-V3-0324 como exemplo de nó único com TP de uma via, DP de oito vias e EP ativado:
vllm serve deepseek-ai/DeepSeek-V3-0324 --tensor-parallel-size 1 --data-parallel-size 8 --enable-expert-parallel
A documentação explica o efeito pretendido: os pesos de atenção são replicados entre os ranks de DP, enquanto os pesos dos especialistas são divididos entre as GPUs. Ela usa um nó com oito GPUs H200 ou H20 como topologia de exemplo e aconselha equipes com hardware diferente a validar sua própria adequação, em vez de tratar o exemplo como uma promessa universal de dimensionamento.
Use esse comando como ponto de partida para a topologia, não como uma configuração de produção para copiar e colar. Antes de expor um endpoint:
- Confirme que o servidor atinge um estado saudável de pronto, sem fallback oculto para um caminho de kernel diferente.
- Execute um teste de correção com prompts conhecidos e o comportamento esperado de esquema ou chamada de ferramentas.
- Aplique uma pequena carga estável e, em seguida, uma rajada e uma amostra de contexto longo.
- Compare p50 e p99 de tempo até o primeiro token, latência entre tokens, throughput de saída, margem de memória e erros com a linha de base sem EP.
- Salve o comando de inicialização, o digest da imagem, a revisão do modelo, a versão do driver e o snapshot de métricas junto com o resultado do benchmark.
Se você ainda estiver desenvolvendo a camada de API ao redor, este guia de implantação do vLLM aborda o caminho do servidor compatível com OpenAI separadamente da decisão sobre paralelismo de MoE.
Selecione o backend all-to-all pela carga de trabalho, não por hábito
O vLLM expõe --all2all-backend para comunicação com paralelismo por especialistas. O guia oficial atualmente descreve um padrão de uso geral, além de modos especializados do DeepEP. Combine o backend com o tráfego que você realmente mediu.
| Backend | Adequação documentada | Implicação para a implantação |
|---|---|---|
allgather_reducescatter |
Implantações EP + DP de uso geral | Uma configuração de controle sensata antes do ajuste especializado. |
deepep_high_throughput |
Cargas de trabalho multinó dominadas por prefill | Avalie quando prompts longos e throughput agregado predominarem no objetivo do serviço. |
deepep_low_latency |
Cargas de trabalho multinó dominadas por decodificação | Avalie quando a latência de tokens gerados importar mais do que o throughput máximo de prefill. |
| Modos NVLink do FlashInfer | Sistemas específicos de MNNVL / NVLink | Use somente quando o hardware e a documentação atual do vLLM corresponderem aos requisitos do backend. |
O objetivo não é escolher o rótulo que parece mais rápido. É testar um backend de cada vez em relação à sua combinação de comprimentos de prompt, concorrência, fabric e SLO. Meça o efeito na latência de cauda, bem como nos tokens por segundo.
Paralelismo por especialistas do vLLM multinó: um padrão de dois nós
Para implantação multinó, a documentação do vLLM usa um nó primário que processa o tráfego de API e um nó worker secundário --headless. O seguinte é uma forma parametrizada desse padrão documentado. Substitua endereços e contagens por valores que correspondam ao cluster que você realmente testou.
No nó primário:
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
No segundo nó:
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
Os números são importantes:
--data-parallel-sizeé o tamanho total de DP no grupo de serviço.--data-parallel-size-localé o número de ranks de DP iniciados nesse nó.--data-parallel-start-ranké o tamanho cumulativo de DP local dos nós anteriores.- O nó secundário é headless porque o primário lida com as solicitações dos clientes.
Para clusters InfiniBand, o guia atual do vLLM destaca especificamente GLOO_SOCKET_IFNAME=eth0 para manter a descoberta de grupos distribuídos na interface de controle Ethernet selecionada. Isso não substitui a validação da comunicação NCCL e GPU a GPU entre nós.
Checklist de aceitação multinó
Antes de enviar tráfego de clientes para um grupo paralelo por especialistas vLLM multinó, comprove todos os itens a seguir:
- Todos os workers resolvem a mesma revisão do modelo e iniciam com o rank pretendido.
- O nó primário consegue alcançar o endereço e a porta RPC configurados a partir de cada par.
- O grupo distribuído é inicializado repetidamente após uma reinicialização limpa.
- Uma solicitação é concluída com baixa concorrência e, em seguida, sob uma carga sustentada.
- Uma mistura de solicitações deliberadamente desequilibrada não causa travamentos silenciosos nem um precipício de latência de cauda.
- Reiniciar um worker de teste produz um sinal de falha observável e acionável, em vez de solicitações enfileiradas indefinidamente.
O guia de solução de problemas distribuídos do vLLM recomenda verificar a comunicação de GPU entre nós e disponibilizar as variáveis de ambiente de comunicação para todos os nós. Se você usar Ray, ele também documenta como manter alinhada a configuração do IP do host do vLLM e do Ray.
Adicione o balanceamento de carga paralelo por especialistas somente após observar desequilíbrio
O roteamento de MoE nem sempre é distribuído uniformemente em produção. O Balanceador de Carga Paralelo por Especialistas (EPLB) do vLLM coleta dados de carga e redistribui periodicamente os mapeamentos de especialistas entre os ranks de EP. O recurso é ativado com --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}'
Comece sem EPLB, a menos que você tenha evidências de especialistas sobrecarregados, trabalho desigual por rank ou latência de cauda persistente que acompanhe o desequilíbrio de roteamento. O EPLB pode usar especialistas redundantes, e essas cópias adicionais de especialistas consomem memória da GPU. Trate-o como uma otimização com custo de capacidade, não como uma flag obrigatória de paralelismo por especialistas do vLLM.
Para um experimento inicial:
- Registre a utilização por rank e a latência das solicitações sem EPLB.
- Ative o registro de balanceamento durante uma janela controlada.
- Adicione a menor configuração de redundância que caiba no orçamento de memória.
- Compare a latência de cauda, o throughput, a margem de memória e a interrupção do rebalanceamento sob a mesma carga.
- Mantenha prontos o comando de reversão e a configuração de implantação sem EPLB.
Um plano de benchmark que responde à pergunta certa
Não considere uma implantação de EP bem-sucedida apenas porque o processo é iniciado. Use a mesma revisão de modelo, prompts, limites de saída, concorrência, quantização, configurações de cache e reserva de hardware em cada comparação.
| Teste | O que revela | Sinal de decisão |
|---|---|---|
| Decodificação com prompt curto e alta concorrência | Comportamento de coletivas e de fila no lado da decodificação | Latência p99 entre tokens e throughput de tokens gerados |
| Prefill de prompt longo | Overhead de prefill e all-to-all | Tempo p99 até o primeiro token e throughput agregado de prefill |
| Rastreamento de desequilíbrio de especialistas | Se um pequeno conjunto de especialistas cria ranks sobrecarregados | Desequilíbrio entre ranks, crescimento da fila e justificativa para EPLB |
| Teste de capacidade com contexto longo | Margem de memória sob pressão realista de cache | Taxa de OOM, falhas de admissão e concorrência segura |
| Simulação de reinicialização / particionamento | Comportamento operacional diante de um par com falha ou uma porta bloqueada | Tempo até a detecção, visibilidade de erros e caminho de recuperação |
Registre mais do que o throughput médio. Uma implantação que melhora a média enquanto prejudica a latência p99 ou torna a recuperação opaca não é um ganho claro para produção.
Solução de problemas em implantações paralelas por especialistas do vLLM
| Sintoma | Classe provável de causa | Primeira ação |
|---|---|---|
Argumento --expert-parallel-size desconhecido |
O runbook e o vLLM instalado não correspondem | Execute vllm serve --help, fixe a compilação e use o dimensionamento de TP/DP documentado para essa compilação. |
| A inicialização falha em torno de um kernel de EP ou do backend all-to-all | Dependência de EP / stack de contêiner ausente ou incompatível | Verifique novamente os pré-requisitos atuais de EP e a imagem de contêiner, em vez de alterar vários sinalizadores de inicialização de uma só vez. |
| Workers multinó ficam bloqueados durante a inicialização | Configuração de endereço, porta, NIC ou grupo de processos do plano de controle | Verifique a conectividade, as interfaces selecionadas, o cálculo de ranks e a comunicação distribuída antes de ajustar kernels. |
| A primeira solicitação fica bloqueada após os workers parecerem prontos | A comunicação de GPU entre nós não está saudável | Execute as verificações de comunicação do fornecedor/vLLM e, em seguida, inspecione a configuração de NCCL e das interfaces. |
| O throughput não melhora | A combinação de tráfego, a malha, o comportamento de lote ou a configuração do lado da atenção ainda é o gargalo | Compare com a linha de base por comprimento de prompt e concorrência; altere uma variável de topologia por vez. |
| Falta de memória após ativar EPLB | A memória de especialistas redundantes consumiu a margem de segurança | Reduza a redundância ou reserve mais margem de memória; repita o teste de capacidade. |
| Um rank é persistentemente mais lento | Assimetria no roteamento de especialistas ou desempenho desigual de host/malha | Meça primeiro a carga no nível de rank; considere EPLB somente se as evidências o sustentarem. |
O hábito importante é o diagnóstico preciso. Mantenha o modelo, a imagem, o rastreamento de tráfego e a topologia fixos enquanto altera um fator. Isso transforma um relato vago de “EP está lento” em uma observação acionável.
Sequência de implantação em produção
- Estabeleça a linha de base. Execute o modelo MoE de destino sem EP e mantenha as métricas, os logs e o manifesto de inicialização.
- Ative EP em um nó. Use
--enable-expert-parallelcom uma topologia TP/DP escolhida explicitamente. - Verifique a qualidade e a capacidade. Confira o comportamento da saída, a margem de memória, a latência p50/p99 e o throughput sustentado.
- Escolha um backend pela forma do tráfego. Compare o backend geral com um backend especializado relevante somente usando o mesmo rastreamento.
- Adicione EPLB somente com evidências. Use dados de balanceamento e margem de memória para justificar especialistas redundantes.
- Expanda para múltiplos nós. Verifique a alocação de ranks, a rede de controle e a comunicação de GPU entre nós antes de aumentar o tráfego.
- Execute um teste de falhas. Teste reinicialização, perda de porta e um worker não saudável antes que o tráfego de produção encontre essa lacuna por você.
- Fixe e documente. Salve versões, sinalizadores de inicialização, topologia, métricas e etapas de reversão junto à implantação.
Quando não hospedar você mesmo a camada de serving de MoE
O paralelismo por especialistas do vLLM é o investimento certo quando o controle sobre o posicionamento do modelo, o caminho de dados, a reserva de hardware e o comportamento de serving faz parte do requisito do produto. Ele é pouco adequado quando a equipe precisa principalmente de acesso ao modelo e não consegue assumir a utilização de GPU, a rede distribuída, os testes de atualização e a recuperação de plantão.
Antes de reservar um cluster maior, compare o modelo operacional com uma abordagem de API gerenciada em GPU cloud vs. model API: quando a auto-hospedagem realmente economiza dinheiro. A resposta certa pode ser híbrida: hospede você mesmo a carga de trabalho que precisa de controle de infraestrutura e use uma camada de API para o restante.
Perguntas frequentes
O --enable-expert-parallel ativa o paralelismo por especialistas do vLLM?
Sim. A CLI atual do vLLM documenta --enable-expert-parallel como o uso de paralelismo por especialistas em vez de paralelismo de tensores para camadas MoE.
Qual é o sinalizador de tamanho de paralelismo por especialistas do vLLM?
Para o fluxo de implantação atualmente documentado, o tamanho de EP é derivado de --tensor-parallel-size e --data-parallel-size: EP_SIZE = TP × DP. Verifique a superfície exata da CLI na sua versão fixada do vLLM, em vez de presumir um sinalizador de tamanho separado.
O paralelismo por especialistas substitui o paralelismo de tensores em todos os lugares?
Não. EP altera a estratégia da camada de especialistas MoE. O comportamento da camada de atenção ainda depende dos valores de TP e DP que você escolher.
Toda implantação do DeepSeek deve ativar EPLB?
Não. Primeiro, demonstre o desequilíbrio de carga dos especialistas sob tráfego representativo e confirme que o custo de memória dos especialistas redundantes cabe no cluster. EPLB é uma otimização, não um requisito padrão.
Qual backend all-to-all devo usar?
Comece pelas orientações atuais do vLLM e teste o backend que corresponde ao formato da sua carga de trabalho: uma opção de uso geral para ampla compatibilidade, um modo DeepEP de alto throughput para tráfego com predominância de prefill ou um modo DeepEP de baixa latência para tráfego com predominância de decode.
Referências
- Documentação de Implantação Paralela por Especialistas do vLLM
- Documentação de Implantação Paralela de Dados do vLLM
- Referência da CLI vLLM serve
- Solução de problemas de implantação distribuída do vLLM
Próximo passo: use o comando de nó único como um ambiente de validação controlado, estabeleça uma linha de base e promova apenas a topologia que melhora o SLO com o qual você realmente se importa. É assim que o paralelismo por especialistas do vLLM se torna uma decisão de produção, em vez de uma flag que você espera que seja mais rápida.
