- Estratégias e códigos usados no DeepSeek V3/R1
- DualPipe: algoritmo de paralelismo em pipeline bidirecional para sobreposição de computação-comunicação
- EPLB: balanceador de carga para paralelismo de especialistas
- Profile-Data: profiling de dados da infraestrutura da DeepSeek para analisar a sobreposição de computação-comunicação
- O DualPipe é um algoritmo inovador de paralelismo em pipeline bidirecional apresentado no DeepSeek-V3 Technical Report
- Ele reduz as bolhas do pipeline ao sobrepor completamente as etapas de computação-comunicação do forward e do backward
- Informações mais detalhadas sobre a sobreposição de computação-comunicação podem ser vistas em profile data
- No Expert Parallelism (EP), diferentes especialistas (experts) são atribuídos a cada GPU
- Porém, como a carga de trabalho pode variar entre os especialistas, é importante equilibrar a carga entre as GPUs
- No DeepSeek-V3, é usada a estratégia de especialistas redundantes (redundant experts) para duplicar especialistas com alta carga e então distribuí-los de forma eficiente entre as GPUs para equilibrar a carga
- Além disso, usando group-limited expert routing, os especialistas do mesmo grupo são colocados no mesmo nó tanto quanto possível, minimizando a transferência de dados entre nós
- Para facilitar a reprodução e a implantação, o algoritmo de balanceamento de carga de EP é disponibilizado como open source em
eplb.py
- Esse algoritmo calcula um plano equilibrado de replicação e alocação de especialistas com base na carga prevista dos especialistas
- No entanto, o método específico para prever a carga dos especialistas está fora do escopo desse repositório, e em geral é comum usar uma média móvel com base em estatísticas históricas
- O algoritmo de balanceamento de carga oferece duas políticas, usadas em situações diferentes.
- Balanceamento de carga hierárquico (Hierarchical Load Balancing)
- Quando o número de nós de servidor é divisível pelo número de grupos de especialistas, a política de balanceamento de carga hierárquico é usada para otimizar o group-limited expert routing
- Primeiro, os grupos de especialistas são distribuídos de forma uniforme entre os nós para equilibrar a carga entre nós
- Depois, os especialistas são replicados dentro de cada nó
- Por fim, os especialistas replicados são alocados em GPUs individuais para equilibrar a carga entre GPUs
- Essa política pode ser usada na etapa de prefilling, em que a escala do paralelismo de especialistas é pequena
- Balanceamento de carga global (Global Load Balancing)
- Nos demais casos, usa-se a política de balanceamento de carga global, que replica especialistas globalmente sem considerar os grupos de especialistas e os distribui entre GPUs individuais
- Essa política é adequada para a etapa de decoding, em que a escala do paralelismo de especialistas é grande.
- A DeepSeek divulgou dados de profiling do seu framework de treinamento e inferência para ajudar a comunidade a entender melhor as estratégias de sobreposição entre comunicação e computação e os detalhes de implementação de baixo nível
- Esses dados de profiling foram coletados com o PyTorch Profiler e, após o download, podem ser visualizados no Chrome por
chrome://tracing e no Edge por edge://tracing
- Além disso, nos experimentos, o profiling foi realizado simulando uma estratégia balanceada de roteamento MoE
- Treinamento (Training)
- Os dados de profiling de treinamento mostram, em DualPipe, a estratégia de sobreposição dos chunks de forward e backward
- Cada chunk inclui 4 camadas MoE (Mixture of Experts) e tem uma configuração paralela alinhada com o setup de pré-treinamento do DeepSeek-V3:
- Inferência (Inference)
- Prefilling
- Nessa etapa, dois microbatches são usados para sobrepor computação e comunicação all-to-all
- Além disso, a carga computacional de attention é distribuída de forma equilibrada entre os dois microbatches, permitindo que o mesmo prompt seja dividido em vários microbatches
- Decoding
- No decoding, assim como no prefilling, dois microbatches são usados para sobrepor computação e comunicação all-to-all
- No entanto, no decoding, a comunicação all-to-all não ocupa os SMs da GPU → após enviar a mensagem RDMA, os SMs da GPU são liberados, e o funcionamento ocorre aguardando a conclusão da comunicação depois que a computação termina
- Mais detalhes sobre a implementação de all-to-all podem ser vistos em DeepEP
Ainda não há comentários.