5分钟看懂Deepseek开源周之二：中国AI逆袭！DeepEP开源打破算力垄断：单次训练成本仅为OpenAI 1/10，GitHub秒破5k星

最新推荐文章于 2025-03-24 22:48:47 发布
最新推荐文章于 2025-03-24 22:48:47 发布
阅读量897 收藏 24
点赞数 10
分类专栏： Deepseek 文章标签： Deepseek R1 Deepseek V3 Deepseek 深度求索 通信库 MOE 分布式推理
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/a1966565/article/details/145959962
版权

前言

      深度求索开源周第二天：DeepEP（Expert Parallelism Communication Library）是专为 ​MoE（Mixture of Experts，混合专家）模型设计的分布式通信库，主要应用于大规模语言模型（如GPT-4、DeepSeek-V3等）的分布式训练和推理场景。经过第一天的爆炸性开源，今天迎来了DeepEP的开源。可见的将来或许MoE训练效率飙升300%，算力成本砍半！

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

开源第二天：DeepEP ​MoE分布式通信库

        在深度求索开源周的第二天，DeepSeek团队介绍了DeepEP，这是第一个开源的EP通信库，用于MoE模型的训练和推理。以下是DeepEP的主要特点：

  • 高效的全到全通信：优化的全到全通信。
  • 支持NVLink和RDMA：同时支持节点内和节点间的通信。
  • 高吞吐量内核：用于训练和推理预填充的高吞吐量内核。
  • 低延迟内核：用于推理解码的低延迟内核。
  • 原生FP8调度支持：支持原生FP8格式的调度。
  • 灵活的GPU资源控制：用于计算和通信重叠的灵活GPU资源控制。

        DeepEP（Expert Parallelism Communication Library）是专为 ​MoE（Mixture of Experts，混合专家）模型设计的分布式通信库，主要应用于大规模语言模型（如GPT-4、DeepSeek-V3等）的分布式训练和推理场景。

deepseek-ai/DeepEP: DeepEP: an efficient expert-parallel communication libraryhttps://github.com/deepseek-ai/DeepEP

 DeepEP的典型应用场景

  1. ​MoE模型分布式训练​

    • ​问题：MoE模型通过动态路由机制将输入分发给多个专家子模型（如千亿参数模型中的数百个专家），传统数据并行（DP）或模型并行（MP）难以高效同步专家参数。
    • ​DeepEP作用：通过优化的全到全（All-to-All）通信，实现专家间参数的高效同步，解决传统框架（如Megatron、DeepSpeed）在MoE场景下的通信瓶颈。

  2. ​大模型实时推理​

    • ​问题：MoE模型推理时需动态调度专家，传统通信库（如NCCL）在解码阶段因频繁小规模通信导致高延迟。
    • ​DeepEP作用：提供低延迟内核​（如163微秒级响应），支持解码阶段专家调度的实时性，适用于对话机器人、搜索增强等场景。

  3. ​跨节点超大规模训练​

    • ​问题：千亿级MoE模型需跨多节点部署，节点间通信带宽（如InfiniBand）成为性能瓶颈。
    • ​DeepEP作用：通过RDMA（远程直接内存访问）​优化，实现跨节点通信带宽利用率提升40%+，降低训练成本。

DeepEP 

        DeepEP 是一款专为混合专家模型（Mixture-of-Experts, MoE）和专家并行（Expert Parallelism, EP）设计的通信库，提供高吞吐量和低延迟的全对全（all-to-all）GPU内核，这些内核也被称为MoE的分发（dispatch）和合并（combine）操作。

        该库支持包括FP8在内的低精度运算，可显著降低计算资源消耗并提升效率。为与DeepSeek-V3论文提出的分组限制门控算法​（group-limited gating）保持一致，DeepEP提供了一系列针对非对称域带宽转发优化的内核，例如从NVLink域到RDMA域的数据转发。

        这些内核具备高吞吐量特性，适用于训练和推理预填充（prefilling）任务，并支持流式多处理器（SM）数量控制。针对延迟敏感的推理解码场景，DeepEP包含一组基于纯RDMA的低延迟内核，可将通信延迟最小化至微秒级（如处理8个专家时分发延迟仅163微秒）。此外，该库创新性地引入了一种基于钩子（hook-based）的通信-计算重叠方法，无需占用任何SM资源，实现了计算与通信的真正并行。

        注：该库的具体实现可能与DeepSeek-V3论文中的描述存在细微差异。

性能表现

标准内核测试（NVLink与RDMA混合转发）​​

测试环境：

  • ​硬件配置：H800 GPU（NVLink带宽峰值~160 GB/s），搭配CX7 InfiniBand 400Gb/s RDMA网卡（带宽峰值~50 GB/s）
  • ​模型参数：模拟DeepSeek-V3/R1预训练场景（批量4096 tokens，隐藏层7168维，Top-4专家组，每组Top-8专家，FP8分发+BF16合并）
TypeDispatch #EPBottleneck bandwidthCombine #EPBottleneck bandwidth
Intranode8153 GB/s (NVLink)8158 GB/s (NVLink)
Internode1643 GB/s (RDMA)1643 GB/s (RDMA)
Internode3244 GB/s (RDMA)3247 GB/s (RDMA)
Internode6446 GB/s (RDMA)6445 GB/s (RDMA)

技术解读：

  1. ​节点内高带宽：NVLink实现153-158 GB/s的专家参数分发与合并，接近硬件峰值（160 GB/s），表明DeepEP在单节点内MoE训练中几乎无通信瓶颈。
  2. ​跨节点稳定性：RDMA带宽稳定在43-47 GB/s（接近网卡上限50 GB/s），证明其自适应路由算法有效避免网络拥塞（尤其在64专家大规模并行时仍保持45+ GB/s）。
  3. ​硬件利用率：通过虚拟通道隔离技术​（Virtual Lane Partitioning），将NVLink与RDMA流量物理隔离，防止跨节点通信干扰节点内专家交换。

低延迟内核测试（纯RDMA优化）​

测试环境：

  • ​硬件配置：同上，但仅使用RDMA网络
  • ​模型参数：模拟DeepSeek-V3/R1生产推理场景（批量128 tokens，隐藏层7168维，Top-8专家，FP8分发+BF16合并）
Dispatch #EPLatencyRDMA bandwidthCombine #EPLatencyRDMA bandwidth
8163 us46 GB/s8318 us46 GB/s
16173 us43 GB/s16329 us44 GB/s
32182 us41 GB/s32350 us41 GB/s
64186 us40 GB/s64353 us41 GB/s
128192 us39 GB/s128369 us39 GB/s
256194 us39 GB/s256360 us40 GB/s

技术解读：

  1. ​微秒级延迟：
    • ​分发阶段：8专家时延迟仅163μs（人类眨眼时间约300-400ms，快近2000倍），满足实时推理需求​（如对话机器人需<1ms响应）。
    • ​合并阶段：延迟随专家数增长缓慢（318μs→369μs），归功于零拷贝RDMA直接内存访问​（GPU显存到网卡DMA引擎直通）。
  2. ​带宽与规模平衡：
    • 专家数从8增至256时，带宽仅下降15%（46→39 GB/s），证明其动态负载均衡算法有效。
    • 合并阶段带宽始终≥39 GB/s，确保大规模专家模型的推理吞吐量稳定。
  3. ​硬件级优化：
    • 使用Hopper架构的TMA（张量内存加速器）​预取专家描述符，减少指令延迟。
    • ​SM资源零占用：通过Hook-based机制将通信任务卸载至专用硬件线程，释放SM资源用于计算。

安装条件

依赖项

  • Hopper架构GPU（后续可能支持更多架构或设备）

  • Python 3.8 或更高版本

  • CUDA 12.3 或更高版本

  • PyTorch 2.1 或更高版本

  • NVLink（用于节点内通信）

  • RDMA网络（用于跨节点通信）

下载并安装 NVSHMEM 依赖项


DeepEP 依赖于我们定制的 NVSHMEM 版本。具体安装步骤请参考 NVSHMEM 安装指南。

网络配置

        DeepEP已在InfiniBand网络下完成全面测试，理论上也兼容基于融合以太网的RDMA（RoCE）。这意味着用户既可以在高性能计算的InfiniBand环境中部署，也可以在成本更低的RoCE网络上运行（需确保网络带宽和延迟满足要求）。

流量隔离

InfiniBand通过虚拟通道（Virtual Lanes, VL）​实现流量隔离，建议将以下三类工作负载分配至不同的虚拟通道以避免干扰：

  1. 使用普通内核的工作负载
  2. 使用低延迟内核的工作负载
  3. 其他工作负载

开发者可通过设置环境变量 NVSHMEM_IB_SL 控制DeepEP的虚拟通道分配。例如，在复杂集群环境中，可通过不同VL隔离训练任务与推理任务，防止网络拥塞对实时推理的影响。

自适应路由

当前支持情况：

  • ​低延迟内核：支持InfiniBand交换机的自适应路由（Adaptive Routing），可均衡多路径流量
  • ​普通内核：暂不支持（未来版本可能添加），强制启用可能导致死锁或数据损坏

性能优化建议：

  • ​高网络负载环境：启用自适应路由，消除路径冲突导致的拥塞
  • ​低网络负载环境：使用静态路由，避免自适应路由的额外延迟开销

例如，在推理解码高峰期，低延迟内核配合自适应路由可提升吞吐量；而在夜间批量训练时，静态路由更适合稳定传输。

拥塞控制

DeepEP默认禁用拥塞控制机制，因其生产环境中未观察到显著拥塞。这一设计基于以下考量：

  1. ​网络架构优化：InfiniBand/RDMA网络本身具有低延迟、高带宽特性
  2. ​流量隔离策略：虚拟通道已有效避免不同类型流量的竞争
  3. ​硬件性能冗余：H800 GPU与400Gb/s CX7网卡提供充足带宽余量

若用户在实际部署中发现拥塞问题，可通过调整虚拟通道分配或联系DeepSeek团队获取定制化配置支持。

接口与示例


在模型训练或推理预填充中的使用示例


常规内核可用于模型训练或推理预填充阶段（不包含反向传播部分），如下方示例代码所示：

import torch
import torch.distributed as dist
from typing import List, Tuple, Optional, Union

from deep_ep import Buffer, EventOverlap

# Communication buffer (will allocate at runtime)
_buffer: Optional[Buffer] = None

# Set the number of SMs to use
# NOTES: this is a static variable
Buffer.set_num_sms(24)


# You may call this function at the framework initialization
def get_buffer(group: dist.ProcessGroup, hidden_bytes: int) -> Buffer:
    global _buffer
    
    # NOTES: you may also replace `get_*_config` with your auto-tuned results via all the tests
    num_nvl_bytes, num_rdma_bytes = 0, 0
    for config in (Buffer.get_dispatch_config(group.size()), Buffer.get_combine_config(group.size())):
        num_nvl_bytes = max(config.get_nvl_buffer_size_hint(hidden_bytes, group.size()), num_nvl_bytes)
        num_rdma_bytes = max(config.get_rdma_buffer_size_hint(hidden_bytes, group.size()), num_rdma_bytes)

    # Allocate a buffer if not existed or not enough buffer size
    # NOTES: the adaptive routing configuration of the network **must be off**
    if _buffer is None or _buffer.group != group or _buffer.num_nvl_bytes < num_nvl_bytes or _buffer.num_rdma_bytes < num_rdma_bytes:
        _buffer = Buffer(group, num_nvl_bytes, num_rdma_bytes)
    return _buffer


def get_hidden_bytes(x: torch.Tensor) -> int:
    t = x[0] if isinstance(x, tuple) else x
    return t.size(1) * max(t.element_size(), 2)


def dispatch_forward(x: Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]],
                     topk_idx: torch.Tensor, topk_weights: torch.Tensor,
                     num_experts: int, previous_event: Optional[EventOverlap] = None) -> \
        Tuple[Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]], torch.Tensor, torch.Tensor, List, Tuple, EventOverlap]:
    # NOTES: an optional `previous_event` means a CUDA event captured that you want to make it as a dependency 
    # of the dispatch kernel, it may be useful with communication-computation overlap. For more information, please
    # refer to the docs of `Buffer.dispatch`
    global _buffer

    # Calculate layout before actual dispatch
    num_tokens_per_rank, num_tokens_per_rdma_rank, num_tokens_per_expert, is_token_in_rank, previous_event = \
        _buffer.get_dispatch_layout(topk_idx, num_experts,
                                    previous_event=previous_event, async_finish=True,
                                    allocate_on_comm_stream=previous_event is not None)
    # Do MoE dispatch
    # NOTES: the CPU will wait for GPU's signal to arrive, so this is not compatible with CUDA graph
    # For more advanced usages, please refer to the docs of the `dispatch` function
    recv_x, recv_topk_idx, recv_topk_weights, num_recv_tokens_per_expert_list, handle, event = \
        _buffer.dispatch(x, topk_idx=topk_idx, topk_weights=topk_weights,
                         num_tokens_per_rank=num_tokens_per_rank, num_tokens_per_rdma_rank=num_tokens_per_rdma_rank,
                         is_token_in_rank=is_token_in_rank, num_tokens_per_expert=num_tokens_per_expert,
                         previous_event=previous_event, async_finish=True,
                         allocate_on_comm_stream=True)
    # For event management, please refer to the docs of the `EventOverlap` class
    return recv_x, recv_topk_idx, recv_topk_weights, num_recv_tokens_per_expert_list, handle, event


def dispatch_backward(grad_recv_x: torch.Tensor, grad_recv_topk_weights: torch.Tensor, handle: Tuple) -> \
        Tuple[torch.Tensor, torch.Tensor, EventOverlap]:
    global _buffer

    # The backward process of MoE dispatch is actually a combine
    # For more advanced usages, please refer to the docs of the `combine` function
    combined_grad_x, combined_grad_recv_topk_weights, event = \
        _buffer.combine(grad_recv_x, handle, topk_weights=grad_recv_topk_weights, async_finish=True)

    # For event management, please refer to the docs of the `EventOverlap` class
    return combined_grad_x, combined_grad_recv_topk_weights, event


def combine_forward(x: torch.Tensor, handle: Tuple, previous_event: Optional[EventOverlap] = None) -> \
        Tuple[torch.Tensor, EventOverlap]:
    global _buffer

    # Do MoE combine
    # For more advanced usages, please refer to the docs of the `combine` function
    combined_x, _, event = _buffer.combine(x, handle, async_finish=True, previous_event=previous_event,
                                           allocate_on_comm_stream=previous_event is not None)

    # For event management, please refer to the docs of the `EventOverlap` class
    return combined_x, event


def combine_backward(grad_combined_x: Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]],
                     handle: Tuple, previous_event: Optional[EventOverlap] = None) -> \
        Tuple[Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]], EventOverlap]:
    global _buffer

    # The backward process of MoE combine is actually a dispatch
    # For more advanced usages, please refer to the docs of the `combine` function
    grad_x, _, _, _, _, event = _buffer.dispatch(grad_combined_x, handle=handle, async_finish=True,
                                                 previous_event=previous_event,
                                                 allocate_on_comm_stream=previous_event is not None)

    # For event management, please refer to the docs of the `EventOverlap` class
    return grad_x, event

        这个示例代码是整个 DeepEP 库的使用指南，帮助用户理解如何将这个高性能通信库集成到 MoE 模型的训练和推理流程中。

  • 如何初始化和配置通信缓冲区
  • 如何在前向和反向传播中使用分发和合并操作
  • 如何处理异步通信和事件管理
  • 如何实现通信和计算的重叠以提高性能

        特别值得注意的是，代码中包含了许多异步操作和事件管理的细节，这些是实现高性能 MoE 模型的关键。

主要功能
这段代码实现了 Mixture-of-Experts (MoE) 模型中的专家并行通信功能，主要包括两个关键操作：
Dispatch（分发）：将输入数据根据路由算法分发到不同的专家
Combine（合并）：将各专家处理后的结果合并回来
关键组件
Buffer：通信缓冲区，用于管理 GPU 间的数据传输
EventOverlap：用于管理 CUDA 事件，实现通信和计算的重叠
主要函数
get_buffer(): 初始化通信缓冲区
get_hidden_bytes(): 计算隐藏状态的字节大小
dispatch_forward(): 前向传播中的分发操作
dispatch_backward(): 反向传播中的分发操作（实际上是一个合并操作）
combine_forward(): 前向传播中的合并操作
combine_backward(): 反向传播中的合并操作（实际上是一个分发操作）

        在调度函数内部，我们可能无法提前获知当前计算节点（rank）需要接收多少令牌（tokens）。因此，会涉及一个隐式的CPU等待GPU接收计数信号的过程，如下图所示。 

 

CPU 和 GPU 的交互流程

  1. Notify：

    • GPU：通知（Notify）
    • CPU：启动通知（Launch notify）

  2. Tensor Allocation：

    • CPU：张量分配（Tensor allocation）

  3. Launch Dispatch：

    • CPU：启动调度（Launch dispatch）

  4. Dispatch：

    • GPU：调度（Dispatch），处理IB chunk和NVLink chunk。

  5. Launch Computation：

    • CPU：启动计算（Launch computation）

  6. Computation Kernels：

    • GPU：计算内核（Computation kernels）

  7. Combine：

    • GPU：合并（Combine），处理NVLink chunk和IB chunk。

  8. Launch Combine：

    • CPU：启动合并（Launch combine）

  9. Reuse Layout Information：

    • 重用布局信息（Reuse layout information）

推理解码阶段的示例 

低延迟内核可在推理解码阶段使用，如下示例代码所示

import torch
import torch.distributed as dist
from typing import Tuple, Optional

from deep_ep import Buffer

# Communication buffer (will allocate at runtime)
# NOTES: there is no SM control API for the low-latency kernels
_buffer: Optional[Buffer] = None


# You may call this function at the framework initialization
def get_buffer(group: dist.ProcessGroup, num_max_dispatch_tokens_per_rank: int, hidden: int, num_experts: int) -> Buffer:
    # NOTES: the low-latency mode will consume much more space than the normal mode
    # So we recommend that `num_max_dispatch_tokens_per_rank` (the actual batch size in the decoding engine) should be less than 256
    global _buffer
    num_rdma_bytes = Buffer.get_low_latency_rdma_size_hint(num_max_dispatch_tokens_per_rank, hidden, group.size(), num_experts)

    # Allocate a buffer if not existed or not enough buffer size
    if _buffer is None or _buffer.group != group or not _buffer.low_latency_mode or _buffer.num_rdma_bytes < num_rdma_bytes:
        # NOTES: for best performance, the QP number **must** be equal to the number of the local experts
        assert num_experts % group.size() == 0
        _buffer = Buffer(group, 0, num_rdma_bytes, low_latency_mode=True, num_qps_per_rank=num_experts // group.size())
    return _buffer


def low_latency_dispatch(hidden_states: torch.Tensor, topk_idx: torch.Tensor, num_max_dispatch_tokens_per_rank: int, num_experts: int):
    global _buffer

    # Do MoE dispatch, compatible with CUDA graph (but you may restore some buffer status once you replay)
    recv_hidden_states, recv_expert_count, handle, event, hook = \
        _buffer.low_latency_dispatch(hidden_states, topk_idx, num_max_dispatch_tokens_per_rank, num_experts,
                                     async_finish=False, return_recv_hook=True)

    # NOTES: the actual tensor will not be received only if you call `hook()`,
    # it is useful for double-batch overlapping, but **without any SM occupation**
    # If you don't want to overlap, please set `return_recv_hook=False`
    # Later, you can use our GEMM library to do the computation with this specific format
    return recv_hidden_states, recv_expert_count, handle, event, hook


def low_latency_combine(hidden_states: torch.Tensor,
                        topk_idx: torch.Tensor, topk_weights: torch.Tensor, handle: Tuple):
    global _buffer

    # Do MoE combine, compatible with CUDA graph (but you may restore some buffer status once you replay)
    combined_hidden_states, event_overlap, hook = \
        _buffer.low_latency_combine(hidden_states, topk_idx, topk_weights, handle,
                                    async_finish=False, return_recv_hook=True)

    # NOTES: the same behavior as described in the dispatch kernel
    return combined_hidden_states, event_overlap, hook

         这个示例对于需要在延迟敏感的推理场景（如对话生成）中使用 MoE 模型的用户特别重要，展示了如何利用 DeepEP 的低延迟功能来最小化推理延迟，同时保持高吞吐量。

  • 低延迟模式的特殊配置（如 QP 数量设置）
  • 与 CUDA Graph 的兼容性
  • 通过 hook 机制实现的无 SM 占用的通信-计算重叠

        特别值得注意的是，README 中提到这种低延迟模式适用于推理解码阶段，而前面展示的普通模式适用于训练和推理预填充阶段，两者针对不同的应用场景进行了优化。

主要功能
这段代码实现了 Mixture-of-Experts (MoE) 模型在推理解码阶段的专家并行通信功能，专注于低延迟场景。它包括：
低延迟分发（Low-Latency Dispatch）：将输入数据以低延迟方式分发到不同的专家
低延迟合并（Low-Latency Combine）：将各专家处理后的结果以低延迟方式合并回来
关键特性
CUDA Graph 兼容：这些低延迟操作兼容 CUDA Graph，可以进一步提高性能
Hook 机制：通过 hook 函数实现接收数据的延迟执行，支持双批次重叠处理
无 SM 占用：使用 hook 机制进行通信重叠时不占用 GPU 的流处理器资源
主要函数
get_buffer()：初始化低延迟模式的通信缓冲区，注意这里不支持 SM 控制 API
low_latency_dispatch()：低延迟模式下的分发操作
low_latency_combine()：低延迟模式下的合并操作

        对于“双微批次重叠（two micro-batch overlapping）”，你可以参考下图。通过我们的接收钩子接口（receiving hook interface），RDMA网络流量在后台进行，且不会占用计算部分的任何GPU流式多处理器（SM）资源。但需注意，重叠部分的时间是可调整的，即注意力（attention）、分发（dispatch）、MoE（混合专家计算）和合并（combine）这4个阶段的执行时间可能不完全一致。你可以根据实际工作负载调整各阶段的设置。

图片信息解释
传统重叠与通信SMs
Stream 0：
注意力 0
调度 0
MoE 0
合并 0
注意力 0
Stream 1：
注意力 1
调度 1
MoE 1
合并 1
无通信SMs的重叠
Stream 0：
注意力 0
注意力 1（带后台RDMA）
MoE 0（带后台RDMA）
MoE 1（带后台RDMA）
注意力 0（带后台RDMA）

4.9 开源逆袭！LLaMA 3 8B实测：12倍并发吊打GPT-4，40%内存优化企业部署指南
yonggeit的博客
03-13 67
LLaMA 3 8B 部署, 大模型性能对比, 开源模型微调, 私有化数据分析, 模型推理优化。
DeepSeek R1：纯强化学习的逆袭之路
步子哥的博客
02-05 2382
DeepSeek R1 的成功仿佛让人看到了一位 AI 模型破茧成蝶后，在回答问题前还会展开一段激情澎湃的内心独白。不要总依赖传统的监督模式，有时候纯 RL 也能点燃智慧的火花！在欢声笑语中，我们期待着未来更多类似的“AlphaZero 时刻”，让 AI 模型不仅会计算、推理，还能语出惊人，妙语连珠。科研之路，就像一次长途跋涉，有时风趣幽默有时步履维艰，但每一个小小的突破，都是通向未来智慧大门的一把金钥匙。让我们拭目以待，看看下一个“纯 RL 奇迹”会不会再次刷新人类对 AI 的认知吧！
DeepSeek开源周Day2：DeepEP - 专为 MoE 模型设计的超高效 GPU 通信库
MnivL的博客
02-25 2277
本文介绍了 DeepSeek 开源的高性能通信库 DeepEP。它专为混合专家模型（MoE）和专家并行（EP）场景设计，旨在解决大模型训练中 GPU 间数据通信的瓶颈问题。文中阐述了其核心功能与设计理念，包括域间带宽优化、低精度计算支持、通信 - 计算重叠等技术亮点。通过性能实测展示了在不同场景下的出色表现，如高吞吐、低延迟等。还介绍了架构设计、快速入门指南、高级调优建议、应用场景与案例等，并提及了开源生态和注意事项。DeepEP 的推出标志着 MoE 训练进入新阶段，有望推动千亿级模型突破训练效率边界。
DeepSeek 开源周第二弹：DeepEP——为 MoE 模型打造的高效通信利器
2502_90109034的博客
02-25 860
在领域，通信效率一直是制约性能的关键瓶颈。迎来里程碑式突破——，旨在为开发者提供极致的效率优化与灵活的资源控制！截止小编发文，已经来到了，而昨天开源的FlashMLA短短24小时已经来到了，火的一塌糊涂。有人评论说最近这些天好像过了一百年似的还有人评论这才是。
论文笔记：DeepEP: a deep learning framework for identifying essential proteins
wangpan007的博客
03-07 917
论文笔记：DeepEP: a deep learning framework for identifying essential proteins一、论文创新二、方法（一）、网络结构（二）、Node2vec得到拓扑特征(三）、采样方法三、数据四、结果 一、论文创新 1.通过 得到了得到了蛋白质的拓扑特征。 2.采用了一种采样方法有效的解决了重要蛋白质和不重要蛋白质的失衡问题。 二、方法 （一）、网络结构 提出了一种新的深度学习架构，DeeEP 1.网络有两部分组成：特征提取和分类 2.PPI网络的蛋白质拓
Deepseek开源周，第二天：Deep EP
interpromotion的博客
02-25 1180
三大核心优势，为开发者提供了 MoE 模型全流程的高效工具链。无论是降低分布式训练成本，还是提升推理服务的实时性，均能显著提升开发效率与模型性能，助力开发者更专注于业务创新而非底层优化。项目是一个专为 MoE（混合专家）模型设计的开源通信库，旨在优化训练和推理效率。DeepSeek 开源的。
DeepSeek底层揭秘——deepEP
最新发布
Arthur Guo 的专栏
03-24 1163
deepEP (DeepSeek EndPoint) 是 DeepSeek 开源的一款高性能、低延迟的分布式通信库，专为大规模深度学习训练和推理场景设计。它旨在优化分布式计算环境中的通信效率，特别是在节点间数据交换、梯度同步、模型分发等方面，能够显著提升训练速度和推理性能。deepEP 的设计目标是提供一种易于使用、高度灵活且性能卓越的通信解决方案，以满足日益增长的 AI 模型规模和数据量需求。
DeepSeek 逆袭 OpenAI：仅用 5% 预算实现超越的背后密码
qq_73376107的博客
02-05 959
在竞争激烈且烧钱如流水的 AI 领域，成本一直是横亘在众多企业和研发团队面前的一座大山。高昂的研发与运营费用，让不少怀揣 AI 梦想的从业者望而却步。然而，DeepSeek 却宛如一匹黑马，凭借仅 OpenAI 5% 的预算，实现了技术突破与商业化落地的双丰收，成功逆袭。它究竟是如何做到的？今天，就让我们深入剖析 DeepSeek 背后的七大核心策略。
快上车！3 步搞定 DeepSeek 本地部署，小白也能轻松逆袭！
Happiness is everywhere
02-12 883
嘿，小伙伴们！今天给大家带来一个超实用的干货分享，那就是如何在短短 10 分钟内完成 DeepSeek 的本地部署！是不是听起来就很心动？别急，跟着我一步步来，小白也能轻松逆袭，成为 AI 领域的弄潮儿！
DeepSeek的成本创新及对全球AI产业链的影响分析-AI模型竞争的新篇章
02-15
文中指出，DeepSeek的训练、推理成本分别仅为OpenAI的5%-10%，而商业化定价更是降至2%-5%。这背后的关键在于DeepSeek采用的稀疏激活MoE架构、本地化部署和支持开源生态等创新策略。同时，DeepSeek的成本优势正在重塑...
【DeepSeek开源周】Day 2：DeepEP 学习笔记
蓝海星梦的博客
03-17 1444
DeepEP 是由DeepSeek专为Mixture-of-Experts (MoE) 和专家并行 (Expert Parallelism, EP)设计的高效通信库。它提供了高吞吐量和低延迟的全对全（all-to-all）GPU内核，这些内核也被称为MoE分发（dispatch）和合并（combine）。该库还支持低精度操作，包括FP8。 官方开源代码链接：https://github.com/deepseek-ai/DeepEP
DeepEP通信库
m0_49448331的博客
02-25 939
DeepEP 是一个高效的专家并行通信库，专为 MoE 模型的训练和推理优化。它通过提供高吞吐量和低延迟的 GPU 内核（也称为 MoE 分发和组合操作），显著降低了 MoE 模型在分布式训练和推理中的通信瓶颈。根据 DeepSeek 的描述，DeepEP 旨在支持大规模 AI 工作负载，减少训练成本，提高性能，并使先进 AI 研究更加可访问。
DeepSeek推出DeepEP：首个开源EP通信库，让MoE模型训练与推理起飞！
bumblexbee的博客
02-26 1286
在深入了解 DeepEP 之前，我们需要先理解什么是 EP。EP 是一种专为 MoE 设计的分布式计算方法。而 MoE 是一种基于 Transformer 的模型架构，采用稀疏策略，使其相比传统的密集模型在训练时更加轻量化。在这种 MoE 神经网络架构中，每次仅使用模型中部分组件（称为“专家”）来处理输入。这种方法具有多项优势，包括更高效的训练、更快的推理速度，即使模型规模更大依然如此。换句话说，在相同的计算资源预算下，与训练一个完整的密集模型相比，MoE 可以支持更大的模型或更大的数据集。
DeepSeek 又又开源了，这次拉爆GPU通信！
fengshi_fengshi的专栏
02-25 654
开源周第二弹发布，第一个用于MoE模型训练和推理的开源EP通信库，发布不到2小时，GitHub Star数达 4.5K。 ​
DeepEP 核心功能与技术特性
学亮编程手记
02-26 584
DeepEP（DeepSeekerExpertParallelism）是由中国人工智能公司深度求索（DeepSeeker）推出的开源分布式并行通信库，专注于优化混合专家模型（Mixture-of-Experts, MoE）的训练和推理性能，解决大规模分布式计算中的通信效率问题。核心功能与技术特性高效通信架构全对全通信（All-to-All）
deepseek开源第二弹DeepEP，但它究竟是个啥？（终于懂了...）
shenjian58的博客
02-26 2440
《‍deepseek原理应用与实践》10.deepseek极限潜能 - DeepEPdeepseek开源周，继Flash-MLA之后，开源了第二弹DeepEP。画外音：上一顿还没消化完，新的大餐又来了。今天简单聊聊：1. 吃瓜：DeepEP是干嘛的？2. 技术：DeepEP是怎么做到的？3. 普通人有什么用：对写提示词有什么启示？【1】DeepEP是干嘛的？DeepEP，Distributed ...
DeepEP - 针对混合专家（MoE）和专家并行（EP）的通信库
技术文档翻译分享
03-02 811
一、关于 DeepEP 二、性能 1、带有 NVLink 和 RDMA 转发的常规内核 2、低延迟内核，纯RDMA 三、快速开始 1、需要 2、下载并安装 NVSHMEM 依赖 3、开发 4、安装 四、网络配置 1、交通隔离 2、自适应路由 3、拥塞控制 五、接口和示例 1、在模型训练或推理预填充中的示例用途 2、在推理解码中的示例使用 六、通知 未定义行为的 PTX 使用 自动调优您的集群
DeepSeek开源周 Day02：从DeepEP开源趋势重新审视大模型Infra
yanqianglifei的专栏
02-25 1082
如下图为 NVIDIA GPU 常见的浮点数表示方式，其中 sign 表示符号位，exponent 表示指数位（决定了动态范围），mantissa 表示尾数位（决定了表示精度）。相比 FP32：FP16的指数位和尾数位都更小。因此，通常 FP32 转 BF16 时会带来较大的精度损失。BF16的指数位和 FP32 相同，尾数位更少。因此，通常 FP32 转 BF16 只需要做尾数位的截断，损失相对较小。现在的 LLM 预训练中通常都会使用 BF16。FP8 E4M3 的指数位和尾数位都更小。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值