DeepEP V2 完全指南：基于 ElasticBuffer 的高性能专家并行通信库实践

DeepEP V2 完全指南基于 ElasticBuffer 的高性能专家并行通信库实践【免费下载链接】DeepEPDeepEP: an efficient expert-parallel communication library项目地址: https://gitcode.com/GitHub_Trending/de/DeepEPDeepEPDeepEveryParallel是面向现代机器学习训练与推理的高性能通信库当前聚焦专家并行Expert Parallelism, EP提供支持 FP8 低精度的高吞吐、低延迟全对全 GPU KernelMoE dispatch 与 combine并附带流水线并行PP、上下文并行CP与远程内存访问Engram等实验性原语全部以零或极低 SM 占用为设计目标。V2 版本重构了专家并行实现将高吞吐与低延迟接口统一为单一ElasticBuffer接口并切换到更轻量的 NCCL Gin 后端安装时无需任何 CUDA 编译。本文以 README.md 为核心骨架结合仓库源码ElasticBuffer 实现、事件重叠工具、测试用例展开带你从环境搭建、接口调用到底层原理全面掌握 DeepEP V2。一、DeepEP V2 概览从 V1 到 V2 的架构演进1.1 V2 定位与核心特性DeepEP V2 是一次对专家并行的彻底重构。根据 README.md 的说明V2 与 V1 相比实现了极端性能以数倍更少的 SM 资源达成与 V1 相当或更好的性能同时支持显著更大的 scale-up 与 scale-out 域。V2 的核心特性包括完全 JITJust-In-Time编译所有 Kernel 在运行时通过轻量级 JIT 模块编译安装阶段无需 CUDA 编译。NCCL Gin 后端Header-only 且轻量能够复用已有的 NCCL communicator取代了 V1 依赖的 NVSHMEM 后端。EPv2高吞吐与低延迟 API 统一到单个ElasticBuffer接口并引入新的 GEMM 布局支持更大的 scale-up / scale-out 域最高 EP2048通过解析式 SM 与 QP 计数计算取代自动调优混合hybrid与直接direct两种模式同时保留对 V3 式传统训练SM 占用从 24 降到 4–6 而性能持平或更优。0 SM 原语0 SM Engram配合 RDMA、0 SM PP配合 RDMA、0 SM CP配合 Copy Engine。同时 V2 也有一些需要注意的取舍缓冲区大小消耗比 V1 更大不再支持 0 SM RDMA 低延迟 EPEngram、PP、CP 均属于实验性特性。V1基于 NVSHMEM的历史文档保留在 docs/legacy.md其性能数据可参考 docs/legacy.md#performance。1.2 仍在推进中的特性README 明确列出了 V2 仍在开发中的能力README.md弹性 GPU 与 CPU 缓冲区一个连续的虚拟地址空间底层映射到 GPU 与 CPU 物理内存的混合支持全自动、透明的 Engram 或不均衡 EP。当前仓库中的ElasticBuffer构造函数已预留num_cpu_bytes参数deep_ep/buffers/elastic.py用于为 Engram 存储分配 CPU 侧缓冲区。借助 EP replay 处理负载不均衡以缩减中间缓冲区大小。面向 DP 与 TP 的 All-gather 更新与 Reduce-scatter 实现。仓库中已出现实验性的 AGRSAll-Gather Reduce-Scatter会话 API如create_agrs_session、agrs_set_config、all_gather等deep_ep/buffers/elastic.py。二、性能基准硬件带宽边界上的表现README 按照 V3 的配置每批 8K tokens、hidden 7168、top 8 experts、FP8 dispatch、BF16 combine测试得到如下结果README.md| Arch | NIC type | Topo | Dispatch Bottleneck Bandwidth | Combine Bottleneck Bandwidth | #SMs | |--|--|--|--|--|--| | SM90 | CX7 | EP 8 x 2 | 90 GB/s (RDMA) | 81 GB/s (RDMA) | 12 | | SM90 | CX7 | EP 8 x 4 | 61 GB/s (RDMA) | 61 GB/s (RDMA) | 6 | | SM100 | CX7 | EP 8 x 2 | 90 GB/s (RDMA) | 91 GB/s (RDMA) | 12 | | SM100 | N/A | EP 8 | 726 GB/s (NVLink) | 740 GB/s (NVLink) | 64 (Max perf) | | SM100 | N/A | EP 8 | 643 GB/s (NVLink) | 675 GB/s (NVLink) | 24 (Min #SM) |需要注意表中数据为逻辑带宽例如EP 8 x 2场景下的 90 GB/s 实际包含了本地 rank 流量。与 V1 相比V2 最高可达到 1.3 倍峰值性能同时节省最多 4 倍 SM 数量。README 暂时省略了更大 EP 配置的结果但依据内部经验预期 Kernel 在更大规模下仍能饱和硬件带宽鼓励读者直接自行基准测试验证。三、快速开始环境要求与安装3.1 环境要求根据 README.md运行 DeepEP V2 需要GPUHopperSM90或支持 SM90 PTX ISA 的其他架构Python3.8 及以上CUDASM90 GPU 需 CUDA 12.3 及以上PyTorch2.10 及以上NCCL2.30.4 及以上网络节点内通信需要 NVLink节点间通信需要 RDMA 网络3.2 安装 NCCL 依赖DeepEP 依赖较新版本的 NCCL。README 推荐使用 pip 安装 NCCL以便 DeepEP 能在 Python 环境中自动定位pip install nvidia-nccl-cu132.30.4 --no-deps从源码看DeepEP 在导入时会执行 NCCL 版本一致性检查deep_ep/init.py它会对比运行时已加载的libnccl.so与链接目录中的 NCCL 库是否二进制一致若系统出现重复 NCCL 运行时会直接断言失败。如果出现此类问题可以通过EP_SUPPRESS_NCCL_CHECK1环境变量跳过该检查谨慎使用版本不一致可能导致运行时错误。3.3 安装 NVSHMEM 依赖DeepEP 仍然依赖 NVSHMEM 以支持 V1 遗留方法legacyBuffer具体安装步骤见 docs/nvshmem.md。若只使用 V2 的ElasticBuffer路径可通过构建参数控制是否启用 SM90 特性与激进 PTX 指令见下文环境变量部分。3.4 开发模式构建与测试开发者可以使用以下流程构建并运行测试README.md# 构建并创建 SO 文件的符号链接 python setup.py build # 可根据自身平台修改具体的 SO 名称 ln -s build/lib.linux-x86_64-cpython-38/deep_ep_cpp.cpython-38-x86_64-linux-gnu.so # 运行测试用例 # 注意可根据集群设置修改 tests/utils/envs.py 中的 init_dist 函数并多节点启动 python tests/elastic/test_ep.py python tests/elastic/test_agrs.py python tests/elastic/test_engram.py python tests/elastic/test_pp.py其中tests/utils/envs.py的init_dist函数deep_ep/utils/envs.py默认读取MASTER_ADDR默认 127.0.0.1、MASTER_PORT默认 8361、WORLD_SIZE默认 1与RANK默认 0环境变量通过tcp://方式初始化 NCCL 分布式环境。多节点运行时需要为每个节点设置正确的WORLD_SIZE与RANK并保证端口互通。test_ep.py会枚举大量组合do_handle_copy、expert_alignment、use_fp8_dispatch、bias 数量、previous_event、async_with_compute_stream、allocate_on_comm_stream等见 tests/elastic/test_ep.py并使用 NCCL 参考实现deep_ep/utils/refs.py逐项对比正确性。3.5 常规安装与导入python setup.py install之后在 Python 项目中import deep_ep即可。导入时deep_ep/init.py会执行init_jit以库根目录、find_cuda_home()与find_nccl_root()初始化 JIT 运行时。CUDA 路径的探测逻辑见 deep_ep/utils/find_pkgs.py依次检查CUDA_HOME/CUDA_PATH环境变量、nvcc可执行文件位置最后回退到/usr/local/cuda。四、ElasticBuffer 接口Buffer 初始化与容量规划4.1 初始化方式V2 中所有 EP 操作高吞吐与低延迟统一在ElasticBuffer接口下。初始化时可以直接指定 MoE 配置由库自动计算缓冲大小也可以显式传入字节数deep_ep/buffers/elastic.pyElasticBuffer( group, # torch.distributed.ProcessGroup num_bytesNone, # 总缓冲区字节数GPUCPU不含 workspace需 2MB 对齐 num_cpu_bytes0, # CPU 缓冲区字节数如 Engram 存储需 2MB 对齐 # 或者直接给出 MoE 配置默认 BF16 num_max_tokens_per_rank0, # 每 rank 最大 token 数 hidden0, # 每个 token 的隐藏维度 num_topk0, # 每个 token 的 top-k expert 数 use_fp8_dispatchFalse, # 是否启用 FP8 转换收到的是 FP8 张量与缩放因子元组 # 配置项 deterministicFalse, # 是否使用确定性路由算法 allow_hybrid_modeTrue, # 是否启用混合模式scaleout scaleup 两段 allow_multiple_reductionTrue, # 是否允许 combine 中的多次归约 prefer_overlap_with_computeTrue, # 是否倾向于与计算重叠通信 sl_idx3, # RDMA service level 索引可用 EP_OVERRIDE_RDMA_SL 覆盖 num_allocated_qps0, # 分配的 RDMA QP 数0 表示自动 num_cpu_timeout_secs300, # CPU 同步超时秒 num_gpu_timeout_secs100, # GPU 操作超时秒 explicitly_destroyFalse, # True 时需显式调用 destroy() 释放资源 )关键细节缓冲大小计算当未提供num_bytes时调用 C 层的calculate_elastic_buffer_sizedeep_ep/buffers/elastic.py结果按 2MB 对齐。README 特别提醒V2 的缓冲区大小消耗比 V1 更大README.md。QP 自动分配混合模式默认分配 65支持快速 RDMA 原子操作时或 129 个 QP直接模式为 17deep_ep/buffers/elastic.py额外 QP 用于 notify warps。RDMA SLEP_OVERRIDE_RDMA_SL环境变量会覆盖构造函数中的sl_idxdeep_ep/buffers/elastic.py。超大 CPU 缓冲区当num_cpu_bytes 0且注册字节数接近 GPU 显存总量时会通过NCCL_WIN_STRIDE环境变量扩大 NCCL 对称窗口 stridedeep_ep/buffers/elastic.py。构造完成后会执行torch.cuda.synchronize()与group.barrier()确保所有 peer 可见初始化结果deep_ep/buffers/elastic.py。4.2 容量规划辅助函数README 推荐的编程模式是先调用get_buffer_size_hint检查能否复用已有缓冲区README.mdimport torch import torch.distributed as dist from typing import Optional from deep_ep import ElasticBuffer # 通信缓冲区运行时分配 _buffer: Optional[ElasticBuffer] None # 通信 Kernel 使用的 SM 数缓冲区创建时设定 _num_comm_sms: int 0 def get_buffer(group: dist.ProcessGroup, num_max_tokens_per_rank: int, hidden: int, num_topk: int, num_experts: int, use_fp8_dispatch: bool False) - ElasticBuffer: 为 EP 通信初始化或复用 ElasticBuffer。 global _buffer, _num_comm_sms # 检查能否复用已有缓冲区 required_bytes ElasticBuffer.get_buffer_size_hint( group, num_max_tokens_per_rank, hidden, num_topknum_topk, use_fp8_dispatchuse_fp8_dispatch, ) if _buffer is not None and _buffer.group group and _buffer.num_bytes required_bytes: return _buffer # 用 MoE 配置分配新缓冲区 # 注意V2 缓冲区大小消耗比 V1 更大 _buffer ElasticBuffer( group, num_max_tokens_per_ranknum_max_tokens_per_rank, hiddenhidden, num_topknum_topk, use_fp8_dispatchuse_fp8_dispatch, ) # V2 解析式计算最优 SM 数——无需再自动调优 # 也可以在 dispatch/combine 调用中手动指定 num_sms 覆盖 _num_comm_sms _buffer.get_theoretical_num_sms(num_experts, num_topk) return _bufferget_buffer_size_hint是静态方法直接调用 C 层的calculate_elastic_buffer_size返回 2MB 对齐的建议大小无需真正构造缓冲区deep_ep/buffers/elastic.py。get_theoretical_num_sms则基于带宽建模估算最优 SM 数结果会被缓存见 deep_ep/buffers/elastic.py其内部通过解析式期望 top-k 计算、RDMA/NVLink 带宽自动探测ibstat、nvidia-smi nvlink与每 SM 读写带宽模型默认sm_read_gbs200、sm_write_gbs50求得瓶颈再乘 1.25 系数并 2 对齐、下限 4。README 强调这是“解析式 SM 与 QP 计数计算——不再需要自动调优”README.md。此外ElasticBuffer还提供面向实验特性的容量辅助函数get_engram_storage_size_hintEngram 存储GPU/CPU 字节各 2MB 对齐条目大小按 32 字节LDG.256对齐、get_pp_buffer_size_hintPP send/recv考虑 send/recv 双向与前驱/后继 rank 的四倍因子、get_agrs_buffer_size_hintAGRS 会话见 deep_ep/buffers/elastic.py。五、dispatch 与 combine训练 / 预填充场景实战V2 将 dispatch 与 combine API 统一到ElasticBuffer接口。README 给出的训练含反向或推理预填充示例完整复现如下README.mdimport torch import torch.distributed as dist from typing import Tuple, Union from deep_ep import ElasticBuffer, EPHandle, EventOverlap def dispatch_forward(x: Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]], topk_idx: torch.Tensor, topk_weights: torch.Tensor, num_experts: int, num_max_tokens_per_rank: int, expert_alignment: int 1) - \ Tuple[Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]], torch.Tensor, torch.Tensor, EPHandle, EventOverlap]: MoE dispatch将 token 路由到所有 rank 上对应的 expert。 同时支持 BF16 与 FP8x 为 [data, scale_factors] 元组输入。 global _buffer, _num_comm_sms recv_x, recv_topk_idx, recv_topk_weights, handle, event _buffer.dispatch( x, topk_idxtopk_idx, topk_weightstopk_weights, num_expertsnum_experts, num_max_tokens_per_ranknum_max_tokens_per_rank, expert_alignmentexpert_alignment, num_sms_num_comm_sms, async_with_compute_streamTrue, ) # handle 携带后续 combine 所需的路由元数据 # handle.num_recv_tokens_per_expert_list 提供每个 expert 的 token 数供 GEMM 使用 # 使用结果前调用 event.current_stream_wait() 同步计算流 return recv_x, recv_topk_idx, recv_topk_weights, handle, event def dispatch_backward(grad_recv_x: torch.Tensor, grad_recv_topk_weights: torch.Tensor, handle: EPHandle) - Tuple[torch.Tensor, torch.Tensor, EventOverlap]: MoE dispatch 的反向传播实际上是一次 combine。 global _buffer, _num_comm_sms combined_grad_x, combined_grad_topk_weights, event _buffer.combine( grad_recv_x, handlehandle, topk_weightsgrad_recv_topk_weights, num_sms_num_comm_sms, async_with_compute_streamTrue, ) return combined_grad_x, combined_grad_topk_weights, event def combine_forward(x: torch.Tensor, handle: EPHandle) - Tuple[torch.Tensor, EventOverlap]: MoE combine将 expert 输出归约回其原始 rank。 global _buffer, _num_comm_sms combined_x, _, event _buffer.combine( x, handlehandle, num_sms_num_comm_sms, async_with_compute_streamTrue, ) return combined_x, event def combine_backward(grad_combined_x: Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]], handle: EPHandle) - \ Tuple[Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]], EventOverlap]: MoE combine 的反向传播实际上是一次 dispatch。 global _buffer, _num_comm_sms grad_x, _, _, _, event _buffer.dispatch( grad_combined_x, handlehandle, num_sms_num_comm_sms, async_with_compute_streamTrue, ) return grad_x, event通信-计算重叠通过EventOverlap接口管理通信流与计算流之间的依赖README.md# dispatch 之后在通信进行期间重叠计算 recv_x, recv_topk_idx, recv_topk_weights, handle, event dispatch_forward(...) # ... 在此执行一些相互独立的计算 ... # 使用结果前等待通信完成 event.current_stream_wait() # 现在可以安全使用 recv_x、recv_topk_idx、recv_topk_weights5.1 dispatch 的底层行为ElasticBuffer.dispatch的完整签名deep_ep/buffers/elastic.py支持以下关键参数xBF16 时为[num_tokens, hidden]张量FP8 模式为元组(data, sf)其中 data 为torch.float8_e4m3fnsf 为缩放因子。topk_idx[num_tokens, num_topk]的deep_ep.topk_idx_t通常为torch.int64-1表示该位置无选择。topk_weights[num_tokens, num_topk]的torch.float。expert_alignment将每个本地 expert 接收的 token 数对齐到该值默认 1。num_sms/num_qps传 0 时自动通过get_theoretical_num_sms/get_theoretical_num_qps计算deep_ep/buffers/elastic.py。注意num_qps不得超过构造时分配的num_allocated_qps。previous_event执行 kernel 前等待的事件设置时allocate_on_comm_stream必须为 True。async_with_compute_stream为 True 时当前流不等待通信 kernel 完成。do_cpu_sync是否同步 CPU 以获得精确的接收 token 数默认 True使用缓存 handle 时强制为 Falsedeep_ep/buffers/elastic.py。do_expand是否使用扩展布局每个 token 每个 expert 一个槽位。do_zero_padding仅do_expand时有效将扩展输出中对齐填充槽位清零。use_tma_aligned_col_major_sf缩放因子是否使用 TMA 对齐的列主序布局。dispatch返回(recv_x, recv_topk_idx, recv_topk_weights, handle, event_overlap)其中handle为EPHandle携带路由元数据event_overlap仅在async_with_compute_streamTrue时有效。5.2 EPHandle路由元数据与确定性排序EPHandle是 dispatch 返回的通信句柄deep_ep/buffers/elastic.py关键属性包括num_experts、expert_alignment、num_max_tokens_per_rank、num_sms上下文信息combine 时默认复用 dispatch 的 SM 数combine中num_sms0表示沿用handle.num_sms见 deep_ep/buffers/elastic.py。topk_idxdispatch 时克隆的 top-k expert 索引[num_tokens, num_topk]构造时会复制用户输入以防意外修改。psum_num_recv_tokens_per_scaleup_rank按 scale-up rank 去重后的接收 token 数包含前缀和最后一个元素即总接收 token 数。psum_num_recv_tokens_per_expert每个本地 expert 对齐填充后的接收 token 数前缀和。num_recv_tokens_per_expert_listCPU 侧每个 expert 的接收 token 数列表README 提示它供 GEMM 使用。num_recv_tokens、num_expanded_tokens接收 token 总数与扩展后的 token 数未做 CPU 同步时可能不精确。do_expand是否使用扩展布局。当ElasticBuffer以deterministicTrue构造时dispatch 返回的EventOverlap会注册一个等待后钩子deterministic_sortdeep_ep/buffers/elastic.py在current_stream_wait()之后于当前流上对recv_x、recv_sf、recv_topk_weights、recv_topk_idx与recv_src_metadata排序保证路由结果与接收顺序无关、完全可复现。同时check_torch_deterministicdeep_ep/utils/envs.py会阻止torch.are_deterministic_algorithms_enabled()与fill_uninitialized_memory同时开启——因为torch.empty()的初始化 kernel 可能与通信流重叠导致错误。5.3 combine 的底层行为combinedeep_ep/buffers/elastic.py将来自不同 rank 的 token 归约回原始 rank除handle外还支持topk_weights非扩展模式为[num_tokens, num_topk]扩展模式为[num_tokens]一维。bias0、1 或 2 个[num_combined_tokens, hidden]的 BF16 最终 bias追加到输出。num_sms/num_qps0 时分别沿用 handle 的 SM 数、按 SM 数自动推导 QP 数。返回(combined_x, combined_topk_weights, event_overlap)。5.4 EventOverlap通信-计算重叠的正确姿势EventOverlapdeep_ep/utils/event.py是对 CUDA 事件的封装提供以下使用方式event.current_stream_wait()让当前流等待事件完成可传release_handleTrue释放事件句柄。register_hook_after_wait(hook)注册current_stream_wait()之后触发的钩子确定性排序即依赖此机制。上下文管理器with event_overlap: ...在退出作用域时自动执行current_stream_wait()简化重叠代码event_overlap event_after_all_to_all_kernels() with event_overlap: do_something_on_current_stream() # 退出 with 作用域后当前流等待事件完成EventOverlap还通过extra_tensors模拟 PyTorch 的record_stream语义以兼容 CUDA graph 捕获deep_ep/utils/event.py。六、推理解码场景handle 缓存模式推理解码时若门控决策在多次迭代间保持不变可复用路由元数据避免冗余的 CPU 同步。README 给出的解码示例README.mdimport torch from typing import Tuple, Optional, Union from deep_ep import ElasticBuffer, EPHandle, EventOverlap def decode_dispatch(x: Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]], topk_idx: torch.Tensor, topk_weights: torch.Tensor, num_experts: int, num_max_tokens_per_rank: int, cached_handle: Optional[EPHandle] None) - \ Tuple[Union[torch.Tensor, Tuple[torch.Tensor, torch.Tensor]], torch.Tensor, torch.Tensor, EPHandle, EventOverlap]: 推理解码的 MoE dispatch。 若提供 cached_handle则复用布局而无需 CPU 同步。 global _buffer, _num_comm_sms if cached_handle is not None: # 复用缓存 handle跳过布局重算与 CPU 同步 recv_x, _, _, handle, event _buffer.dispatch( x, handlecached_handle, num_sms_num_comm_sms, async_with_compute_streamTrue, ) return recv_x, cached_handle.topk_idx, None, handle, event recv_x, recv_topk_idx, recv_topk_weights, handle, event _buffer.dispatch( x, topk_idxtopk_idx, topk_weightstopk_weights, num_expertsnum_experts, num_max_tokens_per_ranknum_max_tokens_per_rank, num_sms_num_comm_sms, async_with_compute_streamTrue, ) return recv_x, recv_topk_idx, recv_topk_weights, handle, event def decode_combine(x: torch.Tensor, handle: EPHandle) - Tuple[torch.Tensor, EventOverlap]: 推理解码的 MoE combine。 global _buffer, _num_comm_sms combined_x, _, event _buffer.combine( x, handlehandle, num_sms_num_comm_sms, async_with_compute_streamTrue, ) return combined_x, event缓存路径下dispatch会断言topk_idx is None复用 handle 中的布局并强制do_cpu_syncFalsedeep_ep/buffers/elastic.py由此避免每轮解码都做 CPU 同步与布局重算显著降低小批量场景的端到端延迟。topk_weights在缓存路径仍可单独提供例如缓存扩展模式下的反向传播。七、环境变量全览General / Networking / JIT / Debug / BuildREADME 完整列出了 V2 支持的环境变量README.md按其分类整理如下。General通用| 变量 | 取值 | 说明 | |--|--|--| |EP_BUFFER_DEBUG|0/1| 打印缓冲区初始化、SM 估算与后端调试信息默认0| |EP_SUPPRESS_NCCL_CHECK|0/1| 跳过 NCCL 版本不一致检查默认0| |EP_AVOID_RECORD_STREAM|0/1| 避免对输出张量执行record_stream默认0| |EP_NUM_TOPK_IDX_BITS| 整数 | 覆盖 top-k 索引编码位数默认0自动 |Networking网络| 变量 | 取值 | 说明 | |--|--|--| |EP_NIC_NAME| 字符串 | 查询 NIC 属性使用的默认网卡名默认mlx5_0| |EP_OVERRIDE_RDMA_SL| 整数 | 覆盖 RDMA service level 索引用于流量隔离 | |EP_DISABLE_GIN|0/1| 禁用 NCCL Gin 后端回退到非 Gin 路径默认0|EP_NIC_NAME在源码中的默认值同样是mlx5_0deep_ep/utils/envs.py并用于 RDMA 带宽自动探测ibstat解析速率与快速 RDMA 原子支持检测MT4131及以上网卡见 deep_ep/utils/envs.py。JIT运行时编译| 变量 | 取值 | 说明 | |--|--|--| |EP_JIT_DEBUG|0/1| 打印 JIT 调试信息默认0| |EP_JIT_CACHE_DIR| 字符串 | 编译 Kernel 的缓存目录默认$HOME/.deep_ep| |EP_JIT_NVCC_COMPILER| 字符串 | NVCC 编译器路径默认使用torch.utils.cpp_extension.CUDA_HOME| |EP_JIT_CPP_STANDARD| 整数 | C 标准版本默认20| |EP_JIT_PRINT_COMPILER_COMMAND|0/1| 打印编译命令默认0| |EP_JIT_PTXAS_VERBOSE|0/1| 显示详细 PTXAS 输出默认0| |EP_JIT_PTXAS_CHECK|0/1| 断言编译 Kernel 无 local memory 使用默认0| |EP_JIT_WITH_LINEINFO|0/1| 为分析工具嵌入源码行号信息默认0| |EP_JIT_DUMP_ASM|0/1| 同时导出 PTX 与 SASS默认0| |EP_JIT_DUMP_PTX|0/1| 导出 PTX 输出默认0| |EP_JIT_DUMP_SASS|0/1| 导出 SASS 输出默认0|Debug and profiling调试与性能分析| 变量 | 取值 | 说明 | |--|--|--| |EP_GIN_GDAKI_DEBUG|0/1| 启用 NCCL Gin GDAKI 调试输出默认0| |EP_USE_NVIDIA_TOOLS|0/1| 在外部 NVIDIA 工具下运行时跳过内部 profiling默认0| |EP_DISABLE_BARRIER_PROFILING|0/1| 在基准测试中禁用基于 barrier 的通信 profiling默认0|Build构建| 变量 | 取值 | 说明 | |--|--|--| |EP_NCCL_ROOT_DIR| 字符串 | NCCL 安装目录未设置时从 Python 环境自动探测 | |EP_NVSHMEM_ROOT_DIR| 字符串 | NVSHMEM 安装目录未设置时从 Python 环境自动探测 | |TORCH_CUDA_ARCH_LIST| 字符串 | 目标 CUDA 架构列表如9.0| |DISABLE_SM90_FEATURES|0/1| 禁用遗留方法的 SM90 特性默认0| |DISABLE_AGGRESSIVE_PTX_INSTRS|0/1| 禁用遗留方法中的激进 load/store 指令默认0|7.1 持久化环境变量README 特别强调部分环境变量是持久化的README.md它们在构建时被捕获并烘焙进安装包作为默认值导入时自动应用除非被当前环境变量覆盖。持久化变量包括EP_JIT_CACHE_DIR、EP_JIT_PRINT_COMPILER_COMMAND、EP_NUM_TOPK_IDX_BITS、EP_NCCL_ROOT_DIR。这与 deep_ep/init.py 的实现一致导入时从deep_ep.envs.persistent_envs读取构建期默认值仅当对应变量未在环境中设置时才写入。八、网络配置InfiniBand 调优指南DeepEP 在 InfiniBand 网络上经过完整测试理论上也兼容 RoCERDMA over Converged EthernetREADME.md。8.1 流量隔离Traffic IsolationInfiniBand 通过 Virtual LanesVL支持流量隔离。为避免不同流量相互干扰README 建议按以下类别隔离到不同虚拟车道专家并行工作负载其他工作负载DeepEP V2 通过ElasticBuffer构造参数sl_idx或EP_OVERRIDE_RDMA_SL环境变量控制虚拟车道分配。默认sl_idx3deep_ep/buffers/elastic.py。8.2 自适应路由Adaptive Routing自适应路由是 InfiniBand 交换机的高级路由特性可将流量均匀分布到多条路径。虽然自适应路由会引入额外延迟README 仍建议在所有网络负载条件下启用它。8.3 拥塞控制Congestion Control拥塞控制会损害最大带宽因此默认禁用。若某些场景不可避免拥塞建议将这些工作负载分配到低优先级的虚拟车道。8.4 PCI 原子模式PCI Atomic Mode若硬件支持推荐用以下命令设置网卡的PCI_ATOMIC_MODE以提升 RDMA 原子操作性能README.mdsudo mlxconfig -y -d mlx5_$i set PCI_ATOMIC_MODE4i为网卡序号请按实际环境替换。九、实验性特性与生态9.1 实验性 API 一览README 将 Engram、PP、CP 明确标记为实验性特性README.mdElasticBuffer已提供对应的实验 APIdeep_ep/buffers/elastic.pyEngram0 SMRDMAengram_write(storage, sf)将存储数据写入缓冲区前后各带一次 barrierengram_fetch(indices, num_qps, use_tma_aligned_col_major_sf)通过 RDMA 拉取远端条目返回一个可调用对象调用时等待 RDMA get 完成并返回(data, sf)。支持 BF16 与 FP8torch.float8_e4m3fn。PP0 SMRDMApp_set_config配置最大张量字节数与最大在途张量数pp_send(t, dst_rank_idx, num_sms)/pp_recv(t, src_rank_idx, num_sms)在 PP 环中与相邻 rank仅前驱/后继收发张量。CP0 SMCopy EngineCP 原语基于 Copy Engine 实现 0 SM 通信。AGRS实验create_agrs_session/destroy_agrs_session与agrs_new_session上下文管理器、all_gather等用于 all-gather reduce-scatter 探索。对应的测试位于 tests/elastic/test_engram.py、tests/elastic/test_pp.py、tests/elastic/test_agrs.py。9.2 实验分支与社区派生README 列出了若干实验分支README.md例如Zero-copy移除 PyTorch 张量与通信缓冲区之间的拷贝显著降低普通 kernel 的 SM 占用、Eager用低延迟协议消除 RDMA 原子操作引入的额外 RTT、Hybrid-EP基于 TMA 指令的最小 SM 占用与更大 NVLink 域支持、AntGroup-Opt 系列SMFree、LL-SBO、LL-Layered 等优化、Mori-EPROCm/AMD GPU 支持、nvDev基于 V2 的 Compute Fabric Transport 探索。这些分支与社区派生如 uccl-ep 的异构 GPU/NIC 支持均为上游实验读者可按需跟踪。DeepEP V2 本身构建于 NVIDIA NCCL 的 Gin 后端之上README 的 Acknowledgement 部分对 NCCL 团队的支持表达了致谢README.md。十、测试与基准验证tests/elastic/test_ep.py是 V2 EP 功能的核心测试tests/elastic/test_ep.py它构造可能不均衡的 gate 分数get_unbalanced_scores支持--unbalanced-ratio与--precise-unbalanced-ratio参数、支持 masked ratio 模拟无效选择topk_idx-1然后枚举所有 EP 模式组合对每个组合用随机数据执行 dispatch/combine并与基于torch.topk的 NCCL 参考实现deep_ep/utils/refs.py逐元素对比正确性。测试还借助deep_ep.utils.testing.bench_kineto进行 Kineto 性能基准。运行方式python tests/elastic/test_ep.py --help # 查看全部参数 python tests/elastic/test_ep.py # 默认配置单节点注意测试前需按集群环境修改 deep_ep/utils/envs.py 中的init_dist设置或通过MASTER_ADDR、MASTER_PORT、WORLD_SIZE、RANK环境变量控制多节点场景下在多个节点分别启动。V1 遗留方法的测试见 tests/legacy/test_internode.py、tests/legacy/test_intranode.py 与 tests/legacy/test_low_latency.py。十一、总结DeepEP V2 通过统一ElasticBuffer接口、NCCL Gin 轻量后端、解析式 SM/QP 计算与完全 JIT 编译将专家并行通信从 V1 的 NVSHMEM 时代推进到更简洁、更省 SM、可扩展至 EP2048 的新阶段高吞吐与低延迟路径共用一套 APIEPHandle承载路由元数据并支持解码场景的布局缓存EventOverlap提供灵活的通信-计算重叠控制deterministic模式保证结果可复现而 Engram / PP / CP 实验特性则为远程内存访问与更细粒度的并行策略预留了扩展空间。安装前请确认 Hopper 及以上架构、CUDA 12.3、PyTorch 2.10 与 NCCL 2.30.4 的环境前提并按 docs/nvshmem.md 与 docs/legacy.md 补齐遗留方法所需依赖。更多接口细节可查阅ElasticBuffer的 Python 文档字符串与测试用例。【免费下载链接】DeepEPDeepEP: an efficient expert-parallel communication library项目地址: https://gitcode.com/GitHub_Trending/de/DeepEP创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考