DeepSeek publica 3 estrategias de procesamiento paralelo optimizadas como open source (4 de 5)

• Estrategias y códigos usados en DeepSeek V3/R1
  • DualPipe: algoritmo de paralelismo de canalización bidireccional para superponer cómputo y comunicación
  • EPLB: balanceador de carga para Expert Parallel
  • Profile-Data: perfilado de datos de la infraestructura de DeepSeek para analizar la superposición entre cómputo y comunicación

DualPipe

• DualPipe es un innovador algoritmo de paralelismo de canalización bidireccional presentado en el DeepSeek-V3 Technical Report
• Su función es superponer por completo las etapas de cómputo-comunicación hacia adelante y hacia atrás para reducir las burbujas del pipeline
• Más detalles sobre la superposición entre cómputo y comunicación están disponibles en profile data

Expert Parallelism Load Balancer (EPLB)

• En Expert Parallelism (EP), se asignan distintos expertos (experts) a cada GPU
• Sin embargo, como la carga de trabajo puede variar entre expertos, es importante equilibrar la carga entre GPUs
• En DeepSeek-V3 se usa una estrategia de expertos redundantes (redundant experts) para replicar los expertos con alta carga y luego ubicarlos eficientemente en las GPU para balancear la carga
• Además, mediante group-limited expert routing se colocan en lo posible los expertos del mismo grupo dentro del mismo nodo, minimizando así la transferencia de datos entre nodos
• Para facilitar su reproducción y despliegue, publicaron como open source el algoritmo de balanceo de carga EP en eplb.py
  • Este algoritmo calcula un plan equilibrado de replicación y colocación de expertos con base en la carga esperada de cada experto
  • Sin embargo, el método específico para predecir la carga de los expertos queda fuera del alcance de ese repositorio, y normalmente se usa un promedio móvil basado en estadísticas históricas
• El algoritmo de balanceo de carga ofrece dos políticas, cada una usada en situaciones distintas.
  • Balanceo de carga jerárquico (Hierarchical Load Balancing)
    • Cuando el número de nodos de servidor puede dividir el número de grupos de expertos, se usa la política de balanceo de carga jerárquico para optimizar el group-limited expert routing
    • Primero, los grupos de expertos se distribuyen uniformemente entre los nodos para equilibrar la carga entre nodos
    • Después, los expertos se replican dentro de cada nodo
    • Por último, los expertos replicados se asignan a GPUs individuales para equilibrar la carga entre GPUs
    • Esta política puede usarse en la etapa de prefilling, donde la escala del paralelismo de expertos es pequeña
  • Balanceo de carga global (Global Load Balancing)
    • En los demás casos, se usa la política de balanceo de carga global para replicar expertos globalmente sin importar el grupo de expertos y asignarlos a GPUs individuales
    • Esta política es adecuada para la etapa de decoding, donde la escala del paralelismo de expertos es grande.

Datos de profiling de la infraestructura de DeepSeek

• DeepSeek publicó datos de profiling de sus frameworks de entrenamiento e inferencia para ayudar a la comunidad a entender mejor las estrategias de superposición entre comunicación y cómputo, así como los detalles de implementación de bajo nivel
• Estos datos de profiling se recopilaron usando PyTorch Profiler y, tras descargarlos, pueden visualizarse en Chrome mediante chrome://tracing y en Edge mediante edge://tracing
• Además, en los experimentos se simuló una estrategia balanceada de ruteo MoE para realizar el profiling
• Entrenamiento (Training)
  • Los datos de profiling de entrenamiento muestran en DualPipe la estrategia de superposición de chunks hacia adelante y hacia atrás
  • Cada chunk incluye 4 capas MoE (Mixture of Experts) y tiene una configuración de paralelismo consistente con la del pretraining de DeepSeek-V3:
• Inferencia (Inference)
  • Prefilling
    • En esta etapa se usan dos microbatches para superponer el cómputo y la comunicación all-to-all
    • Además, la carga de operaciones de atención se distribuye equilibradamente entre los dos microbatches, permitiendo que un mismo prompt se divida entre varios microbatches
  • Decoding
    • En decoding, al igual que en prefilling, se usan dos microbatches para superponer el cómputo y la comunicación all-to-all
    • Sin embargo, en decoding la comunicación all-to-all no ocupa los GPU SM → tras enviar los mensajes RDMA libera los GPU SM, y funciona esperando a que la comunicación termine después de finalizar el cómputo
    • Más detalles sobre la implementación de all-to-all pueden consultarse en DeepEP

4.º de 5 open source publicados como DeepSeek Open Infra: 5 proyectos open source