Quartz 4

通信计算融合

28 min read

Low latency supa kernel 走读启示：

  1. DeepEP FP8 量化通信， INT8 量化提升通信效率

  2. IB 专用网卡 ibgda，与 NVSHMEM 低延迟 ，RDMA 是否可以替代

  3. 复现方案，还缺少哪些技术

  4. DeepEP_ll 发送数据前 SM 做完量化，然后调用 nvshmemi_ibgda 之后，此时 SM 是空闲的，SM 是否切换出来给计算使用，是否发送完成是用 stream event 来做不再消耗 SM 的计算资源，owner：John

  5. IB 网卡 ibgda 与 NVlink，是否可以用现有 ROCE RDMA 替代，性能相差多少， Moying 找相关同事确认

  6. INT8 量化提升通信效率，精度是否满足，需要本地验证 naigang

  7. SCCL 接入 INT8 量化与反量化 kernel 函数

通信计算融合课题研究

分布式系统优化与应用探索

讨论了分布式系统整体、大模型训练、硬件系统等方面的问题。提到了分布式系统的运行方案、通信阶段的情况，以及硬件的主要构成。同时，也探讨了如何整合之前的分享资料，以便更好地理解和消化。此外，还讨论了分布式训练办公室任务如何拆分，以及是否需要邀请外部专家进行讲解。最后，提到了前沿架构和方案跟踪的问题，建议在后续工作中结合实际情况进行优化。

技术分享与优化探索

讨论了以下几个方面的内容： 通信与计算融合，主要通过框架层面的优化来实现计算和通信的重叠；3. 现有方案的改进，包括单个流和多流模型在不同的 GPU 上进行处理；4. 将模型分成多组在不同的设备上进行处理。

GPU 计算与通信的优化改进

主要讲述了 V 字型流水线中如何优化计算和通信的效率。通过将计算和通信合并，可以减少设备占用和通信占用。同时，通过 SM 或 GCU 的切分，可以将多个操作融合到一个格子里，提高效率。然而，由于通信的存在，整个流程的效率并不能达到最密集的程度。因此，在设计流水线时，需要权衡计算和通信的比重，以提高整体效率。

优化计算与通信流程的探索

讨论了一个长方形方块的设计，主要通过这种方式排列机密方案。风险和计算排了这么一个流程，设计方式能够优化两个方面。在反向流水中，可以对 T 和相关的部分进行优化。在通信和计算过程中，可以将计算和 BPW 的计算融合在一起，但前项不可以。整个流水填的不满，只有中间这一块既有前向和反向计算的时候，把整个前面包捆起来，混起来做。在能掩盖的地方就掩盖掉。但如果换一个模型，可能前面花的时间更短，这种方法其实也没有办法完全掩盖。

深度学习框架优化与应用探讨

讨论了 HaiL fm 框架在处理语言问题时可能的应用，以及论文中提到的权重更新问题。同时，探讨了 Pipeline 优化、异步更新和同步更新的区别，以及如何通过拆分 Transformer block 组件来提高效率。此外，还讨论了通信和计算并行处理的技术，以及如何在不同 SM 卡上分配任务。

6G 技术应用与优化探索

提到了在 100 上可能会遇到的问题，如不能支持 CE S PC 任务的切分，以及 stream safe mode 的限制。同时，也探讨了 5G 的尝试和实际应用中的问题。最后，讨论了关于计算和通信操作的对齐问题，以及如何优化链路和数据处理。

推理与并行计算的实践探索

讨论了推理和训练的并行计算问题，提到了通过多个微批次来实现的并行计算。同时，也探讨了推理时的并行方式，以及如何提高效率。此外，还提到了 SM 和 channel 的关系，以及如何在算子内部实现并发度提升。最后，讨论了如何动态分配通信算子，并通过 special 化操作来提高效率。

SM 内部工作分配与优化探讨

讨论了 SM 内部的工作分配和优化，以及如何减少通信开销。提到了一种新的编程模式，即在同一个地址里可以做好几个 buffer，从而提高效率。同时，还讨论了动态调整通信 SM 数量的技术，以减少数据量和 L2 占用。此外，还提到了 PPS 的作用，以及为什么不能直接 pass 掉某些操作。最后，提到了实验和 nico 中的内嵌汇编，以及如何反汇编写。

通信优化与数据量减少的重要性

讨论了通信量调整对通信的影响，指出调整通信量可能会导致同步范围变大，从而影响其他方面的性能。同时，提到了使用 FP8 而非 FP16 可以减少数据量，提高效率。会议还强调了实验偏工程的重要性，认为这是一个重要的优化方向。最后，提到了业界创新的重要性，并建议后续讨论时关注 IP 相关问题。

  1. DualPipe 算法在 br10x 上是否可行？
  2. warp specialization 技术与分发与计算流重叠，PTX 指令使用与动态调整通信块的大小在 br10x 上是否可行？
  3. NVSHMEM 相比于 NCCL 提供更细粒度的操作，单边通信，更灵活但编程更复杂，与 CUDA 紧密集成，支持在内核中直接调用 NVSHMEM 的通信操作，典型应用在科学计算中
  4. 通信算子中融合量化与反量化操作，把 FP16 的数据压缩为 INT8 后传输，1 个额外的 scale 的传输需要额外的 block，造成通信数据的增加，这里有风险，需要进一步详细设计方案

通信与计算融合

通过算法、框架和硬件的协同设计，克服了跨节点 MoE 训练中的通讯瓶颈，近乎完全的计算/通信重叠， 主要在 3.2 节阐述，

DeepSeek-V3 的训练得到了 HAI-LLM 框架的支持，这是一个由我们的工程师从头开始构建的高效且轻量级的训练框架。总体而言，DeepSeek-V3 采用了 16 路流水线并行（Pipeline Parallelism, PP）（Qi et al., 2023a）、跨越 8 个节点的 64 路专家并行（Expert Parallelism, EP）（Lepikhin et al., 2021），以及 ZeRO-1 数据并行（Data Parallelism, DP）（Rajbhandari et al., 2020）。

  1. 训练框架设计了 DualPipe 算法，减少了流水线气泡

DualPipe 的核心思想是在一对独立的前向和反向块中重叠计算和通信。具体来说，我们将每个块分为四个部分：注意力（attention）、全对全分发（all-to-all dispatch）、MLP 和 全对全合并（all-to-all combine）。特别地，对于反向块，注意力和 MLP 进一步分为两部分：输入的反向传播 和 权重的反向传播，类似于 ZeroBubble（Qi et al., 2023b）中的设计。此外，我们还有一个 PP（Pipeline Parallelism）通信部分。如图 4 所示，对于一对前向和反向块，我们重新排列这些组件，并手动调整 GPU SMs 中用于通信与计算的比例。在这种重叠策略中，我们可以确保全对全通信和 PP 通信在执行过程中完全隐藏。

  1. 开发高效的跨节点全通信内核，以充分利用 InfiniBand（IB）和 NVLink 的带宽。见 3.2.2 节

为了确保 DualPipe 具有足够的计算性能，我们定制了高效的跨节点全对全通信内核（包括分发和合并），以减少用于通信的流式多处理器（SM）数量。这些内核的实现与 MoE 门控算法和我们集群的网络拓扑共同设计。具体来说，在我们的集群中，跨节点的 GPU 通过 InfiniBand（IB）完全互连，而节点内的通信则通过 NVLink 处理。NVLink 提供 160 GB/s 的带宽，大约是 IB（50 GB/s）的 3.2 倍。为了有效利用 IB 和 NVLink 的不同带宽，我们限制每个令牌最多分发给 4 个节点，从而减少 IB 的流量。对于每个令牌，当路由决策完成后，它将首先通过 IB 传输到目标节点上具有相同节点内索引的 GPU。一旦到达目标节点，我们将确保它通过 NVLink 即时转发到托管其目标专家的特定 GPU，而不会被后续到达的令牌阻塞。通过这种方式，IB 和 NVLink 的通信完全重叠，每个令牌可以高效地选择每个节点平均 3.2 个专家，而不会因 NVLink 产生额外开销。这意味着，尽管 DeepSeek-V3 在实践中仅选择 8 个路由专家，但它可以将这一数量扩展到最多 13 个专家（4 个节点 × 3.2 个专家/节点），同时保持相同的通信成本。总体而言，在这种通信策略下，仅需 20 个 SM 即可充分利用 IB 和 NVLink 的带宽。

具体来说，我们采用了warp specialization技术（Bauer et al., 2014），并将 20 个 SM 划分为 10 个通信通道。在分发过程中，（1）IB 发送、（2）IB 到 NVLink 转发以及（3）NVLink 接收分别由不同的 warp 处理。每个通信任务分配的 warp 数量会根据所有 SM 的实际工作负载动态调整。类似地，在合并过程中，（1）NVLink 发送、（2）NVLink 到 IB 转发和累加以及（3）IB 接收和累加也由动态调整的 warp 处理。此外，分发和合并内核与计算流重叠，因此我们还考虑了它们对其他 SM 计算内核的影响。具体来说，我们采用了定制的 PTX（并行线程执行）指令，并自动调整通信块大小，从而显著减少了 L2 缓存的使用以及对其他 SM 的干扰。

关键点总结

  1. 通信内核的定制：

  • 通过协同设计 MoE 门控算法和集群网络拓扑，优化跨节点全对全通信。

  • 减少用于通信的 SMs 数量，提升计算性能。

  1. 带宽优化：

  • 利用 NVLink 的高带宽（160 GB/s）和 IB 的中等带宽（50 GB/s）。

  • 限制每个 token 最多分发到 4 个节点，减少 IB 流量。

  1. 路由与转发机制：

  • token 通过 IB 传输到目标节点后，立即通过 NVLink 转发到目标专家 GPU。

  • 确保通信过程中无阻塞，最大化带宽利用率。

  1. 扩展性与成本控制：

  • 在保持通信成本不变的情况下，支持从 8 个路由专家扩展到最多 13 个专家。

  • 仅需 20 个 SMs 即可充分利用 IB 和 NVLink 的带宽。

  1. 精心优化了内存占用，没有使用 Tensor Parallel

为了减少训练期间的内存占用，我们采用了以下技术：

RMSNorm 和 MLA 上投影的重计算：我们在反向传播期间重新计算所有 RMSNorm 操作和 MLA 上投影，从而避免了持久存储它们的输出激活值。尽管这会带来轻微的计算开销，但该策略显著减少了存储激活值所需的内存。

CPU 中的指数移动平均：在训练过程中，我们保存模型参数的指数移动平均（EMA），以便在学习率衰减后对模型性能进行早期评估。EMA 参数存储在 CPU 内存中，并在每个训练步骤后异步更新。这种方法使我们能够在不增加额外内存或时间开销的情况下维护 EMA 参数。

多令牌预测的共享嵌入和输出头：通过 DualPipe 策略，我们将模型的最浅层（包括嵌入层）和最深层（包括输出头）部署在同一个流水线并行（PP）层级上。这种安排使得多令牌预测（MTP）模块与共享嵌入和输出头之间的参数和梯度能够物理共享，从而进一步优化内存使用

感想： Deepseek 设计每一步都精细的做到合适， 即重视细节又注重系统工程而推出的一个产品

基础概念

MOE（Mixture Of Experts）

EP 是 Expert Parallelism 的缩写，也叫专家并行策略。该策略用于在分布式训练中处理混合专家模型，在这种策略中，模型的不同部分（如不同的专家模块）被分配到不同的进程（或 GPU）上进行计算。

MOE 是一种稀疏激活的模型架构，通过将大模型拆分为多个子网络（称为“专家”），每次只激活少数专家（通常 1-2 个），在不显著增加计算量的情况下大幅提升模型容量。

关键组成：

  • 专家网络（Experts）：每个专家是一个独立的前馈网络（FFN），通常结构相同但参数独立。

  • 门控机制（Gating/Router）：根据输入动态决定激活哪些专家（例如通过 Softmax 选择 Top-K 专家）。

  • 稀疏性：虽然总参数量巨大（如万亿级），但每次推理仅激活部分参数（如 10%），降低计算成本。

在 MoE 模型中，Gate 和 Router 是两个经常被交替使用的术语，它们的核心功能是决定如何将输入数据（Token）分配给不同的 Experts（专家模块）进行处理。

  • 功能：Gate 是一个神经网络模块，通常是一个线性变换层（如 nn.Linear），其作用是根据输入数据的特征，计算每个 Token 应该被分配到各个 Expert 的概率。Router 是 Gate 的另一种称呼。

  • 工作原理：输入数据经过 Gate 后，会得到一个概率分布，表示每个 Token 分配到每个 Expert 的概率。通常会使用 Top-K 选择策略，例如 Top-2，即选择概率最高的两个 Expert。

  • 重要性：Gate 的设计和训练效果直接影响 MoE 模型的性能，因为它决定了数据如何被分配到不同的 Experts，进而影响模型的计算效率和负载均衡。Router 的设计需要考虑如何在保证模型性能的同时，实现高效的负载均衡，避免某些 Experts 被过度使用，而其他 Experts 则闲置。

关键步骤

  1. 计算门控值（Gating）：

折叠源码

| |

|---|

|# 门控网络（通常是一个线性层 + Softmax）

gate_logits = torch.matmul(token_hidden_states, gating_weight) # [num_tokens, num_experts]

gate_probs = torch.softmax(gate_logits, dim=-``1``)|

  1. Top-k 选择：

折叠源码

| |

|---|

|topk_values, topk_indices = torch.topk(gate_probs, k=``2``) # 选择概率最高的``2``个专家|

Model 视图如下：

MoE EP Gate/Router

  • 通信优化

  • Device limited Routing: 将 routing 的 experts 限定在 M 个设备上 (减少通信范围，从而降低通信开销)

  • Node limited Routing: 将 routing 的 experts 限定在最高亲和力 (网络拓扑结构 (NUMA/UMA)、网络延迟、带宽) 的 M 个 Node 上

  • 负载均衡优化

  • Aux-loss-free: tokens 更加均衡 (训练步骤中引入控制变量，使得负载较重的专家偏置会减少，而负载较轻的专家偏置则会增加)

  • Sequence Aux-Loss: 解决单个 sequence 内部的极端负载不均衡 (辅助损失函数)

All to All

  • 均衡 all to all (上图): 每张卡已确定需要接收的 size，只做一次 all to all 可拿到结果

  • 非均衡 all to all: 每张卡不确定需要接收的 size，可先做一次 all to all 拿到接收的 size

Dispatch && Combine

下图是 Operator 调用：

  • Dispatch：

  • 将输入数据分发到不同的专家 experts 进行处理

  • 每个输入 token 只需要激活 Top-K 个专家，dispatch 需要根据路由结果 (token_idx) 将数据分发到对应的专家

  • Combine：

  • 将各个专家的输出结果合并回一个完整的输出张量

  • 每个 token 的输出是由 Top-K 个专家的输出加权求和得到的，因此需要将这些部分结果重新组合

Intranode && Internode

  1. Intranode（节点内）

Intranode 指的是在同一计算节点（Node）内部的操作或通信。具体来说，它涉及同一个物理机器或计算节点内的多个处理单元（如 CPU 核心、GPU 等）之间的交互。

  • 通信方式：节点内的通信通常通过共享内存或高速互连（如 NVLink）进行，具有低延迟和高带宽的特点。
  1. Internode（节点间）

Internode 指的是不同计算节点之间的操作或通信。具体来说，它涉及多个物理机器或计算节点之间的交互。

  • 通信方式：节点间的通信通常通过网络接口（如 InfiniBand、Ethernet）进行，具有较高的延迟和较低的带宽，但可以通过优化协议（如 RDMA）来提高效率。

|数据传输路径|数据通过主机内存传输，CPU 可能参与数据准备和传输|数据直接在 GPU 和 RDMA 网络设备之间传输，绕过主机内存和 CPU|

|延迟|低延迟，但涉及主机内存时可能有额外延迟|更低延迟，直接访问 GPU 内存|

|带宽利用率|高带宽利用率，但可能受限于主机内存带宽|更高带宽利用率，直接访问 GPU 内存|

|CPU 负载|CPU 可能需要参与数据传输的某些阶段|CPU 完全不参与 GPU-GPU 通信，显著减轻了 CPU 负载|

|硬件支持|需要支持 RDMA 的网卡（如 InfiniBand 或 RoCE）|需要支持 RDMA 的网卡和 NVIDIA GPU，支持 GPUDirect 技术|

|编程复杂性|相对简单，使用 MPI 或其他 RDMA 库|稍微复杂，需要使用特定的 GPUDirect API 和 CUDA 编程|

|内存固定|需要固定主机内存（内存 Pinning）|需要固定 GPU 内存（内存 Pinning）|

|内存映射|使用 IOMMU 将主机内存地址映射到 PCIe 地址空间|使用 IOMMU 将 GPU 内存地址映射到 PCIe 地址空间|

|通信协议|支持 InfiniBand、RoCE 等|支持 InfiniBand、RoCE 等|

GPUDirect RDMA 主要用于同一节点内 GPU 之间的直接通信，但 deepEP 涉及多个计算节点。外接网卡（如 InfiniBand 或 RoCE 网卡）用于连接不同节点，实现跨节点的 GPU 通信。

IBGDA（InfiniBand GPUDirect Async）是一种优化的通信技术，用于进一步降低 GPU 之间的通信延迟。在传统的 GPUDirect RDMA 中，GPU 准备好数据后，需要通知 CPU 代理线程，然后 CPU 代理线程填充工作请求（WR）的控制信息，并通过门铃机制向网卡（NIC）发出信号，以启动数据传输。这个过程会带来额外的通信开销。IBGDA 可以优化开销。在 deepEP 的低延迟模式下会用到。

目前我们的 cmodel 仅仅支持 GPU 之间直连以及通过 Switch 桥接，两种通信模式。GPU 直接 trigger RDMA 目前在 cmodel 无法验证功能 (RDMA br200 是 vendor(GPU 制造商) 提供的，它的 init sequnce 以及设计我们无从得知，目前 CModel 仅支持自研模块的开发建模)。

具体的可以参考之前 liyao 分享的文档：Internode

NVSHMEM

  • 将多个 GPU 的内存组合成一个分区的全局地址****空间

  • 可通过 NVSHMEM API 访问将输入数据分发到不同的专家 experts 进行处理

  • 包含一个低开销的内核通信 API，供 GPU 线程使用

  • 包括基于流和 CPU 启动的通信 API

  • 可与 MPI 和其他 OpenSHMEM 实现互操作

和 NCCL 对比：

| | | |

|---|---|---|

|特性|NCCL|NVSHMEM|

|主要用途|针对集合通信（如 AllReduce、Broadcast）优化，专为深度学习分布式训练设计。|基于 PGAS 模型的细粒度内存访问，支持任意 GPU/节点间的直接内存读写。|

|设计|强调高吞吐、低延迟的集合操作，适合紧密同步的并行任务。|提供全局地址空间抽象，支持灵活的异步通信，适合非规则或动态通信模式。|

|通信协议|基于 BLink/RDMA 优化集合通信算法（如 Ring AllReduce）。|利用 PGAS(Partitioned Global Address Space) 模型 (提供了逻辑上统一的全局地址空间，允许程序员像在共享内存系统中一样访问数据) 和

CUDA-aware 技术 (MPI 接口可以直接在 GPU 内存之间传输数据)，直接操作远程内存地址。|

|通信粒度|基于集体操作（如 AllReduce、AllGather），需要所有进程参与同一操作。|支持单边通信（Put/Get/Atomics），允许单个 GPU 直接读写远程内存。|

|同步机制|隐式同步，操作完成后自动保证数据一致性。|需显式同步（如 nvshmem_fence 或 nvshmem_quiet）确保内存可见性。|

|编程范式|通过显式调用通信函数（如 ncclAllReduce）。|类似共享内存的地址直接访问（如 nvshmem_put）。|

DeepEP

源码：[https://github.com/deepseek-ai/DeepEP](https://github.com/deepseek-ai/DeepEP)

  • 高度优化的 All2All 通信，适合 MoE 模型的 2 个主要过程：

  • Fused_Dispatch：将 Token hidden states 发送给 experts，作为 experts MLP 的输入。

  • Fused_Combine：experts 计算 MLP 完成后，从 experts 接收计算过的 Token hidden states.

  • 支持不同的通信类型：

  • 节点内（intra-node）：可以使用 NVLink + NVSwitch 通信。

  • 节点间（inter-node）：可以使用 RDMA 通信。

  • 针对不同场景的 Kernel：

  • 常规（高吞吐） Kernel（Normal Kernel）：针对 Training 和 Inference Prefill，节点内 NVLink + 节点间 RDMA 通信。

  • 低时延 Kernel（Low-Latency Kernel）：针对 Inference Decoding，使用纯 RDMA 通信来最小化时延。

  • 原生支持 FP8，减少数据传输需求，相比 FP16 通信量减半。

  • 灵活的 GPU 资源（SM）控制，支持计算和通信的 Overlap。

具体相关使用见**[https://github.com/deepseek-ai/DeepEP](https://github.com/deepseek-ai/DeepEP)**的readme.md

Graph View

Backlinks