前言

      深度求索开源周第四天：DualPipe双向流水线并行算法重磅来袭，算力压榨再升级！贴上了开源周活动的github主贴，大家可以不上推特就能了解详情。

deepseek-ai/open-infra-index: Production-tested AI infrastructure tools for efficient AGI development and community-driven innovationhttps://github.com/deepseek-ai/open-infra-index/tree/main?tab=readme-ov-file

开源第四天：Deepseek-V3/R1的优化并行策略

一、DualPipe：双向流水线并行算法

技术目标：解决传统流水线并行中因计算与通信无法重叠导致的GPU空闲（“流水线气泡”）问题，提升硬件利用率。
核心机制：

  1. 双向计算-通信重叠

    • 前向传播与反向传播的计算和通信阶段完全重叠，通过对称调度（例如8个流水线阶段和20个微批次）实现时间片交错，减少空闲等待。

    • 与传统的1F1B（交替前向后向）和ZB1P（零气泡单向流水线）相比，DualPipe在减少气泡的同时仅增加1倍的激活内存峰值，显著优化内存效率。

  2. 流水线调度优化

    • 引入气泡优化调度策略，通过动态调整微批次的执行顺序，降低因依赖关系导致的GPU空闲时间，硬件利用率提升可达30%以上。

应用场景：

  • DeepSeek-V3/R1训练：首次应用于V3模型的分布式训练，支持大规模MoE（混合专家）架构下的高效参数更新。

  • 开源实践：提供PyTorch 2.0+的快速集成示例，开发者可通过GitHub获取调度示例代码和性能对比数据。

二、EPLB：专家并行负载均衡器

技术目标：解决MoE模型中专家负载不均衡导致的GPU资源浪费和通信开销增加问题。
核心机制：

  1. 动态冗余专家策略

    • 复制高负载专家并采用启发式分配算法，将专家副本分布到不同GPU，实现负载均衡。例如，在预填充阶段采用分层负载均衡，解码阶段启用全局负载均衡。

  2. 分层与全局平衡结合

    • 分层负载管理：单个节点内通过分组限制路由（group-limited routing），减少跨节点通信；

    • 全局负载调度：跨节点动态调整专家分布，结合流量优化降低通信数据量。

优化效果：

  • 在V3/R1模型中，EPLB将GPU闲置率从传统方案的15%降低至3%以下，同时减少30%的节点间通信开销。

开源实现：

  • 提供eplb.rebalance_experts接口，支持根据专家权重、副本数、节点数等参数生成最优放置方案，并附可视化示例。

三、profile-data：性能分析数据

技术目标：公开训练与推理框架的底层性能数据，帮助开发者理解通信-计算重叠策略的优化细节。
数据内容：

  1. 训练场景

    • 展示DualPipe在MoE模型（4层结构、EP64并行）中前向与反向分块的重叠效果，排除流水线通信干扰以简化分析。

  2. 推理场景

    • 预填充阶段：EP32并行下，利用双微批次重叠All-to-All通信与注意力计算，平衡跨GPU负载；

    • 解码阶段：EP128并行下，通过RDMA异步通信释放GPU资源，实现更高吞吐。

工具支持：

  • 数据通过PyTorch Profiler采集，支持在Chrome/Edge浏览器中通过chrome://tracing可视化时间轴，直观展示GPU计算、通信与空闲段。

  • 提供模拟的绝对均衡MoE路由策略，便于开发者聚焦流水线优化而非负载波动影响。

四、技术综合价值与行业影响

  1. 效率提升

    • DualPipe与EPLB结合后，V3/R1模型的训练速度提升40%，推理吞吐量增加2倍。

  2. 开源生态贡献

    • 三大工具的开源填补了MoE并行优化领域的空白，被英伟达CEO黄仁勋评价为“点燃全球AI推理需求”的关键创新。

  3. 商业价值

    • DeepSeek在线服务通过动态资源调度（日间全节点部署、夜间释放资源至研发），日均节省成本超8万美元，成本利润率达545%。

DualPipe双向流水线并行算法

deepseek-ai/DualPipe: A bidirectional pipeline parallelism algorithm for computation-communication overlap in V3/R1 training.https://github.com/deepseek-ai/DualPipe        DualPipe 是 DeepSeek-V3 技术报告中介绍的一种创新的双向管道并行算法。它实现了前向和后向计算通信阶段的完全重叠，还减少了管道气泡。有关 computation-communication overlap 的详细信息，请参阅 profile data。

Schedules调度机制

        DualPipe双向流水线并行算法在8个流水线并行（PP）等级和20个微批次（micro-batches）下的调度示例。为简化说明，反向传播的微批次与前向传播呈对称结构，故省略其批次ID标注。共享黑色边框的两个单元格表示计算与通信相互重叠的阶段。

调度逻辑解析

  1. 对称双向流水线

    • 前向（Forward）与反向（Backward）微批次以镜像方式分布，确保通信资源（如NCCL通道）的复用效率。

    • 例如：微批次0的前向计算与微批次19的反向梯度聚合共享同一时间窗口。

  2. 重叠优化

    • 计算阶段（绿色块）：包括MoE专家计算、注意力层前向/反向传播。

    • 通信阶段（橙色块）：跨节点的AllReduce（梯度同步）或All-to-All（专家结果聚合）。

    • 关键设计：通过精确时序控制，使一个微批次的通信操作（如梯度发送）完全隐藏于另一微批次的计算过程中。

  3. 硬件利用率提升

    • 在8 PP等级场景下，传统1F1B流水线的气泡率（Bubble Ratio）约为15%，而DualPipe可将其降至5%以下，GPU利用率提升超30%。

 

1.设备编号：

  • 设备从Device 0 到 Device 7。

2. 时间轴：

  • 时间从左到右增加。

3. 颜色编码：

  • 橙色：前向传递（Forward）。
  • 绿色：后向传递（Backward）。
  • 浅绿色：输入的后向传递（Backward for input）。
  • 蓝色：权重的后向传递（Backward for weights）。
  • 黄色和绿色重叠：前向和后向传递重叠（Overlapped forward & Backward）。

4. 微批次编号：

  • 每个单元格中的数字表示微批次的ID。

5. 重叠区域：

  • 用黑色边框包围的两个单元格表示计算和通信相互重叠的部分。

​流水线空泡（Pipeline Bubbles）与内存占用对比

术语定义（中英对照）​
符号英文解释中文解释
​PP​Pipeline Parallelism Stages (流水线并行阶段数)流水线并行的总阶段数（例如：将模型分为4段，则PP=4）
​F​Execution time of a forward chunk (单个前向计算块的时间)完成一个前向计算块（如一个数据分片或一个微批次）所需时间
​B​Execution time of a full backward chunk (完整反向传播块的时间)完成一个完整的反向传播块（包括梯度计算和激活内存保留）所需时间
​W​Execution time of a "backward for weights" chunk (权重更新反向传播时间)仅计算权重梯度（不保留激活内存）的反向传播块时间
​F&BExecution time of two mutually overlapped forward and backward chunks前向和反向计算块相互重叠后的合并时间（通过并行优化缩短总时间）
流水线空泡（Pipeline Bubbles）与内存占用对比
方法流水线空泡公式（Bubble）参数内存倍数（Parameter）激活内存倍数（Activation）
​1F1B​(PP-1)(F+B)1×PP（阶段数）
​ZB1P​(PP-1)(F+B-2W)1×PP（阶段数）
​DualPipe(PP/2-1)(F&B + B-3W)2×PP+1

​解析与说明

1. ​1F1B（One-Forward-One-Backward）​
  • ​空泡公式：(PP-1)(F+B)
    • 每个流水线阶段需等待前向（F）和反向（B）完成，空泡时间与阶段数（PP-1）成正比。
    • ​示例：若PP=4，空泡时间为3(F+B)。
  • ​内存占用：
    • 参数内存与单阶段相同（1×），但激活内存需保留PP个阶段的中间结果。
2. ​ZB1P（Zero-Bubble-1-Phase）​
  • ​空泡公式：(PP-1)(F+B-2W)
    • 通过剥离权重更新（W）​​ 减少空泡时间（相比1F1B减少2W）。
    • ​优化原理：将权重梯度计算（W）与其他计算重叠，降低空泡占比。
  • ​内存占用：与1F1B相同（1×参数内存，PP激活内存）。
3. ​DualPipe（双流水线并行）​
  • ​空泡公式：(PP/2-1)(F&B + B-3W)
    • 将流水线分为两组（PP/2阶段），并重叠前向与反向计算（F&B）​，进一步减少空泡。
    • ​示例：若PP=8，则分两组（每组4阶段），空泡时间为3(F&B + B-3W)。
  • ​内存占用：
    • 参数内存翻倍（2×），需同时维护两组流水线参数。
    • 激活内存为PP+1，因需额外存储跨组通信的中间结果。

关键结论

  1. ​空泡效率：

    • ​1F1B：简单但空泡最大，适合阶段数少（PP小）的场景。
    • ​ZB1P：通过分离权重更新优化空泡，适合需要平衡内存与速度的场景。
    • ​DualPipe：空泡最小，但以双倍参数内存为代价，适合阶段数多（PP大）的复杂模型。

  2. ​内存权衡：

    • 若GPU内存充足，DualPipe的高效空泡优化更优；若内存紧张，1F1B或ZB1P更合适。

  3. ​实际应用：

    • 大语言模型训练（如GPT-3）通常结合流水线并行+数据并行，采用1F1B或ZB1P。
    • 超大规模模型（如万亿参数）可能需DualPipe来突破空泡瓶颈。

专家并行负载均衡 (EPLB) 

        在使用专家并行（Expert Parallelism, EP）时，不同的专家会被分配到不同的 GPU 上。由于不同专家的负载可能因当前工作负载而异，保持不同 GPU 的负载均衡至关重要。如 DeepSeek-V3 论文所述，我们采用了冗余专家策略，即复制高负载的专家，并通过启发式分配算法将这些复制的专家智能分配到各 GPU 上，确保跨 GPU 的负载均衡。此外，借助 DeepSeek-V3 中使用的组受限专家路由技术​（Group-Limited Expert Routing），我们尽可能将同一组的专家放置在同一个节点内，从而减少跨节点的数据流量。

        为便于复现和部署，我们在 eplb.py 中开源了已落地的 EP 负载均衡算法。该算法基于预估的专家负载，计算出均衡的专家复制与放置方案。需注意的是，预测专家负载的具体方法不在本代码库范围内，常见方法包括使用历史统计数据的移动平均（Moving Average）

算法实现

分层负载均衡（Hierarchical Load Balancing）​

        当服务器节点数量可被专家组数量整除时，采用分层负载均衡策略以利用组限制专家路由技术。该策略首先将专家组均匀分配到各节点，确保节点间负载平衡；接着在每个节点内复制专家副本；最后将复制的专家分配到节点内的GPU，确保GPU间的负载均衡。这种策略适用于专家并行规模较小的预填充阶段（Prefilling Stage）。

全局负载均衡（Global Load Balancing）​

        在其他情况下，采用全局负载均衡策略，全局复制专家（忽略专家组限制）并将副本分配到各个GPU。该策略适用于专家并行规模较大的解码阶段（Decoding Stage）。

接口与示例

核心功能​
负载均衡器的主要函数是 eplb.rebalance_experts，它根据专家负载预测值生成专家复制与分配计划。

代码示例​
以下是一个两层 MoE（混合专家）模型的负载均衡示例：

  • ​模型结构：每层包含 12 个专家
  • ​冗余策略：每层引入 4 个冗余专家，总副本数为 16
  • ​硬件配置：2 个节点，每个节点包含 4 个 GPU（共 8 个 GPU）
import torch
import eplb

weight = torch.tensor([[ 90, 132,  40,  61, 104, 165,  39,   4,  73,  56, 183,  86],
                       [ 20, 107, 104,  64,  19, 197, 187, 157, 172,  86,  16,  27]])

num_replicas = 16
num_groups = 4
num_nodes = 2
num_gpus = 8

phy2log, log2phy, logcnt = eplb.rebalance_experts(weight, num_replicas, num_groups, num_nodes, num_gpus)
print(phy2log)

# Output:
# tensor([[ 5,  6,  5,  7,  8,  4,  3,  4, 10,  9, 10,  2,  0,  1, 11,  1],
#         [ 7, 10,  6,  8,  6, 11,  8,  9,  2,  4,  5,  1,  5,  0,  3,  1]])

        分层负载均衡策略生成的输出表明了如下的专家复制与放置计划。

这里的"分层负载均衡策略"特指EPLB负载均衡器的核心策略之一，当服务器节点数量能整除专家组数量时，该策略会先将专家组均匀分配到不同节点，再在节点内复制专家实现GPU级负载均衡。这与全局负载均衡策略形成对比，后者适用于无法整除或大规模并行场景

负载均衡器的主要功能是 eplb.rebalance_experts。

以下代码展示了一个两层 MoE（Mixture of Experts）模型的例子，每层包含 12 个专家。我们为每层引入了 4 个冗余专家，总共 16 个副本放置在 2 个节点上，每个节点包含 4 个 GPU。

图片信息解释
这张图片展示了两个节点的 GPU 分配情况：

Node 0：
GPU 0：专家编号 5, 6, 7, 10
GPU 1：专家编号 5, 7, 6, 8
GPU 2：专家编号 8, 4, 6, 11
GPU 3：专家编号 3, 4, 8, 9
Node 1：
GPU 0：专家编号 10, 9, 2, 4
GPU 1：专家编号 10, 2, 5, 1
GPU 2：专家编号 0, 1, 5, 0
GPU 3：专家编号 11, 1, 3, 1

Profiling Data in DeepSeek Infra 性能分析数据

        为帮助社区深入理解通信与计算重叠策略​（Communication-Computation Overlap）及底层实现细节，我们在此公开分享训练与推理框架中的性能分析数据。该数据通过 ​PyTorch Profiler（PyTorch性能分析工具）​​ 采集，下载后您可直接通过以下方式可视化分析：

  1. ​Chrome浏览器：访问 chrome://tracing
  2. ​Edge浏览器：访问 edge://tracing

注：为简化性能分析过程，我们在此次数据采集中模拟了一个绝对均衡的MoE路由策略​（理想化负载分配，无专家偏斜）。实际生产环境中路由策略可能因动态负载调整而有所不同。

训练过程

        训练性能分析数据展示了我们在DualPipe框架中对单个前向和后向计算块的重叠策略。每个计算块包含4个MoE（混合专家）层，并行配置与DeepSeek-V3预训练设置保持一致：采用专家并行64路（EP64）、张量并行1路（TP1），序列长度为4K。为简化分析过程，性能剖析数据中未包含流水线并行（PP）通信部分。

        该描述对应的技术背景是：在DeepSeek-V3的预训练中，研究者通过DualPipe实现了前向传播与反向传播计算阶段的完全重叠，这种双向流水线并行算法有效减少了传统流水线并行中的"气泡"等待时间。每个计算块中的4个MoE层设计，与模型架构中"除前三层外全替换为MoE层"的结构特点相呼应。EP64的专家并行配置结合了256个路由专家的分布式部署策略，确保了每个token最多发送到4个节点的计算负载均衡。

 

计算部分
  • MLP (B): 多层感知器（MLP）的后向传递。
  • MLP (W): 权重更新。
  • MLP (F): 多层感知器（MLP）的前向传递。
  • ATTN (B): 注意力机制（Attention）的后向传递。
  • ATTN (W): 注意力机制（Attention）的权重更新。
  • ATTN (F): 注意力机制（Attention）的前向传递。
通信部分
  • Dispatch (F): 前向分发。
  • Dispatch (B): 后向分发。
  • Combine (F): 前向合并。
  • Combine (B): 后向合并。
  • PP (F): 管道化（Pipeline Parallelism）的前向通信。
  • PP (B): 管道化（Pipeline Parallelism）的后向通信。

解释

  • 计算部分：

    • MLP 和 Attention 层分别进行前向和后向传递，并进行权重更新。
    • 每个块包含4个MoE层，这些层通过前向和后向传递进行计算。

  • 通信部分：

    • 分发（Dispatch）和合并（Combine）操作分别用于前向和后向传递。
    • PP通信表示管道化中的前向和后向通信，但在此配置文件中未包括。

推理阶段Inference 

预填充阶段Prefilling

        在预填充阶段的分析中，我们采用与DeepSeek V3/R1线上服务实际部署一致的EP32专家并行与TP1张量并行架构，具体参数如下：

  • 提示长度（Prompt Length）：4K（4096 token）

  • 单GPU处理批次规模：16K token

  • 计算-通信重叠策略：使用**双微批次（2 micro-batches）**机制，将All-to-All通信隐藏于计算过程中

计算部分
  • ATTN: 注意力机制（MLA 和 MoE 路由门）
  • SHARED: 共享专家
  • MLP: 多层感知器
通信部分
  • COMBINE: 合并操作
  • DISPATCH: 分发操作
微批次
  • micro-batch 0: 橙色表示
  • micro-batch 1: 绿色表示

解释

  • 计算部分：

    • ATTN: 注意力机制（MLA 和 MoE 路由门）。
    • SHARED: 共享专家。
    • MLP: 多层感知器。

  • 通信部分：

    • COMBINE: 合并操作。
    • DISPATCH: 分发操作。

  • 微批次：

    • micro-batch 0: 橙色表示。
    • micro-batch 1: 绿色表示。

总结

  • 在预填充阶段，使用EP32和TP1配置，提示长度为4K，每个GPU的批处理大小为16K个令牌。
  • 利用两个微批次来重叠计算和全连接通信，确保注意力计算负载在两个微批次之间平衡。
  • 相同的提示可能会在这两个微批次之间分割，以平衡计算负载。

解码阶段Decoding

        在解码阶段，系统采用 EP128（专家并行规模为128）、TP1（张量并行度为1）的配置，并设置 4K 的提示长度（与线上实际部署配置高度匹配），每个 GPU 的请求批量大小为 128。与预填充阶段类似，解码阶段同样利用两个微批次（micro-batches）实现计算与全对全通信（all-to-all）的重叠。然而，与预填充阶段不同的是，解码期间的全对全通信 ​不占用 GPU 的流式多处理器（SM）资源：在通过 RDMA（远程直接内存访问）发起通信指令后，所有 GPU 的 SM 资源会被完全释放，系统将在计算完成后等待全对全通信的完成。关于全对全通信的具体实现细节，请参考 ​DeepEP​ 通信库。

  1. ​EP128 与 TP1 的协同优化​

    • EP（专家并行）的规模（如128）体现了模型在解码阶段对专家模块的分布式处理能力，通过跨节点部署专家提升吞吐量（网页5提到类似场景中专家并行规模可达144）。
    • TP（张量并行）设为1，说明解码阶段更依赖专家并行而非模型参数切分，这与 MoE（混合专家）模型的特性一致（网页6提到 MoE 的通信优化核心在于专家分配）。

  2. ​RDMA 与 SM 资源释放​

    • RDMA 技术直接通过网卡完成跨节点数据传输，无需 CPU 介入，显著降低延迟（网页6提到 DeepEP 的 RDMA 内核实现微秒级延迟）。
    • SM 资源的释放意味着通信与计算完全解耦，GPU 可专注于模型推理，避免资源争用（网页7提到通过 Warp 专用化技术动态分配 SM 资源）。

  3. ​DeepEP 的核心作用​

    • DeepEP 是 DeepSeek 开源的通信库，专为 MoE 模型设计，通过 ​双通信内核​（高吞吐 NVLink 内核 + 低延迟 RDMA 内核）和 ​隐式 CPU-GPU 协作机制​ 优化 all-to-all 通信效率（网页6/7/8 均详细描述了其架构）。
    • 在解码场景中，DeepEP 的 ​后台通信钩子（hook）​​ 允许数据接收与计算流水线并行，最大化 GPU 利用率（网页6提到“不占用任何 SM 资源”的实现原理）。

计算部分
  • SHARED: 共享专家
  • ATTN-0: MLA 下/上投影和其他操作（在全连接通信之后和核心注意力之前）
  • MLP: 多层感知器
  • ATTN-1: 核心注意力、注意力输出投影和 MoE 路由门
通信部分
  • DISPATCH: 分发操作
  • COMBINE: 合并操作
微批次
  • micro-batch 0: 橙色表示
  • micro-batch 1: 绿色表示

解释

  • 计算部分：

    • SHARED: 共享专家。
    • ATTN-0: MLA 下/上投影和其他操作（在全连接通信之后和核心注意力之前）。
    • MLP: 多层感知器。
    • ATTN-1: 核心注意力、注意力输出投影和 MoE 路由门。

  • 通信部分：

    • DISPATCH: 分发操作。
    • COMBINE: 合并操作。

  • 微批次：

    • micro-batch 0: 橙色表示。
    • micro-batch 1: 绿色表示。

总结

  • 在解码阶段，使用EP128、TP1和提示长度为4K的配置，每个GPU的批处理大小为128个请求。
  • 利用两个微批次来重叠计算和全连接通信。
  • 与预填充不同的是，在解码过程中，全连接通信不占用GPU的SM：在发出RDMA消息后，所有GPU的SM都被释放，并且系统在计算完成后等待全连接通信完成。

 

# 开源 # 负载均衡
Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

DeepSeek-R1 + 本地知识库解决方案

avatar DeepSeek技术社区

DeepSeek【部署 03】客户端应用ChatBox、AnythingLLM及OpenWebUI部署使用详细步骤

DeepSeek 客户端应用ChatBox、AnythingLLM及OpenWebUI部署使用详细步骤

avatar DeepSeek技术社区

清华大学 DeepSeek 1-6 版全资料惊艳首发，速点解锁 AI 秘境

带你全面了解DeepSeek，从基础概念、核心功能，到工具安装、环境配置，再到基础操作、交互界面解析，最后深入到定制化模型与参数优化，还有丰富的案例实战，助你快速上手。DeepSeek资料库链接：https://pan.quark.cn/s/7b94dc240bea。链接：https://pan.quark.cn/s/df8ce3ea6f4e。链接：https://pan.quark.cn/s/7

avatar DeepSeek技术社区