wehub/deepseek-ai--deepep
1
0
Fork 0
Code Issues Pull Requests Actions Deployments Models Agent Notes Packages Projects Releases Wiki Activity

docs: make Chinese README the default
Code Format Check / format-check (push) Has been cancelled
Details

Browse Source
This commit is contained in:
wehub-resource-sync
2026-07-13 10:14:38 +00:00
parent 2c4c6e4023
commit d7e28c34cf
1 changed files with 117 additions and 111 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+117 -111
View File
@@ -1,46 +1,52 @@
<!-- WEHUB_ZH_README -->
> [!NOTE]
> 本文档由 WeHub 基于上游 README 翻译整理，属于社区翻译，非官方中文文档。
> [English](./README.en.md) · [原始项目](https://github.com/deepseek-ai/DeepEP) · [上游 README](https://github.com/deepseek-ai/DeepEP/blob/HEAD/README.md)
> 原作者、版权与许可证归属以原始项目及本仓库 LICENSE 文件为准。
# DeepEP
DeepEP (DeepEveryParallel) is a high-performance communication library for modern machine learning training and inference. The library currently focuses on expert parallelism (EP) — providing high-throughput and low-latency all-to-all GPU kernels (MoE dispatch and combine) with low-precision support including FP8 — while also offering experimental primitives for pipeline parallelism (PP), context parallelism (CP), and remote memory access (Engram), all designed for zero or minimal SM occupation. All kernels are compiled at runtime via a lightweight Just-In-Time (JIT) module, requiring no CUDA compilation during installation.
DeepEP (DeepEveryParallel) 是一款面向现代机器学习训练与推理的高性能通信库。该库目前聚焦于专家并行（Expert Parallelism，EP）——提供高吞吐、低延迟的全对全（all-to-all）GPU 内核（MoE dispatch 与 combine），并支持包括 FP8 在内的低精度；同时也提供面向流水线并行（Pipeline Parallelism，PP）、上下文并行（Context Parallelism，CP）以及远程内存访问（Engram）的实验性原语，均设计为占用零或极少量 SM。所有内核均通过轻量级即时编译（Just-In-Time，JIT）模块在运行时编译，安装时无需进行 CUDA 编译。
Despite its lightweight design, DeepEP's performance matches or exceeds hardware bandwidth limits across various configurations.
尽管设计轻量，DeepEP 的性能在各种配置下均可达到或超过硬件带宽上限。
## News
- **V2 release**: A complete refactoring of Expert Parallelism — achieving extreme performance with several times fewer SM resources compared to V1, while supporting significantly larger scale-up and scale-out domains. V2 has also switched from the NVSHMEM backend to the more lightweight **NCCL Gin backend**.
- **V2 发布**：对 Expert Parallelism 进行了完整重构——相较 V1 以数倍更少的 SM 资源实现极致性能，同时支持显著更大的 scale-up 与 scale-out 域。V2 也已从 NVSHMEM 后端切换为更轻量的 **NCCL Gin 后端**。
### New features
- **Fully JIT** (Just-In-Time compilation)
- **Fully JIT**（Just-In-Time 编译）
- **NCCL Gin backend**
- Header-only & lightweight
- Able to reuse existing NCCL communicators
- **EPv2**
- High-throughput and low-latency APIs unified into a single `ElasticBuffer` interface, with a new GEMM layout
- Larger scale-up & scale-out domain support (up to EP2048)
- Analytical SM & QP count calculation — no more auto-tuning needed
- Both hybrid & direct modes remain supported
- For V3-like legacy training, SM usage reduced from 24 to 4 - 6 while maintaining equivalent or better performance
- **0 SM Engram** (with RDMA)
- **0 SM PP** (with RDMA)
- **0 SM CP** (with Copy Engine)
- 高吞吐与低延迟 API 统一为单一 `ElasticBuffer` 接口，并采用新的 GEMM layout
- 支持更大的 scale-up 与 scale-out 域（最高 EP2048）
- 解析式 SM 与 QP 数量计算——不再需要自动调优
- hybrid 与 direct 模式均继续支持
- 对于类 V3 的传统训练，SM 占用从 24 降至 4 - 6，同时保持相当或更优的性能
- **0 SM Engram**（with RDMA）
- **0 SM PP**（with RDMA）
- **0 SM CP**（with Copy Engine）
### Notes
- Buffer size consumption is larger than V1
- 0 SM RDMA low-latency EP is no longer supported
- Engram, PP, and CP are experimental features
- Buffer 大小占用大于 V1
- 不再支持 0 SM RDMA 低延迟 EP
- Engram、PP 与 CP 为实验性功能
### Still on-going features
- **Elastic GPU & CPU buffers**: A contiguous virtual address space that maps to a hybrid of GPU and CPU physical memory under the hood, enabling fully automatic and transparent Engram or imbalanced EP
- Reducing intermediate buffer sizes by leveraging EP replay to handle load imbalance
- All-gather updates and reduce-scatter implementations for DP & TP
- **Elastic GPU & CPU buffers**：连续的虚拟地址空间，底层映射到 GPU 与 CPU 物理内存的混合体，从而实现全自动、透明的 Engram 或不均衡 EP
- 通过利用 EP replay 处理负载不均衡，以减小中间 buffer 大小
- 面向 DP 与 TP 的 all-gather 更新与 reduce-scatter 实现
For the legacy V1 documentation (NVSHMEM-based), see [docs/legacy.md](docs/legacy.md).
有关传统 V1 文档（基于 NVSHMEM），请参阅 [docs/legacy.md](docs/legacy.md)。
## Performance
Following V3's configuration, we tested with 8K tokens per batch, 7168 hidden dimensions, top 8 experts, FP8 dispatching, and BF16 combining, and obtained the following results:
按照 V3 的配置，我们以每 batch 8K tokens、7168 隐藏维度、top 8 experts、FP8 dispatching 与 BF16 combining 进行测试，得到如下结果：
| Arch | NIC type | Topo | Dispatch Bottleneck Bandwidth | Combine Bottleneck Bandwidth | #SMs |
|--|--|--|--|--|--|
@@ -50,30 +56,30 @@ Following V3's configuration, we tested with 8K tokens per batch, 7168 hidden di
| 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) |
Notes: the results are logical bandwidth. For example, under the `EP 8 x 2` case, 90 GB/s actually contains local rank traffic.
说明：结果为逻辑带宽。例如，在 `EP 8 x 2` 情形下，90 GB/s 实际包含本地 rank 流量。
Comparing with V1, **V2 achieves up to 1.3x peak performance, while saving up to 4x SM count**.
与 V1 相比，**V2 峰值性能最高可达 1.3 倍，同时最多可节省 4 倍 SM 数量**。
We omit results for larger EP configurations for the time being, but encourage interested users to benchmark them directly. Based on our internal experience, we expect the kernel to continue saturating hardware bandwidth at scale.
我们暂时省略更大 EP 配置的结果，但鼓励感兴趣的用户自行 benchmark。根据我们的内部经验，我们预期内核在规模扩展时仍将持续饱和硬件带宽。
For V1 performance data, see [docs/legacy.md](docs/legacy.md#performance).
V1 性能数据请参阅 [docs/legacy.md](docs/legacy.md#performance)。
## Quick start
### Requirements
- Hopper (SM90) GPUs, or other architectures with SM90 PTX ISA support
- Python 3.8 and above
- Hopper (SM90) GPU，或其他支持 SM90 PTX ISA 的架构
- Python 3.8 及以上
- CUDA version
- CUDA 12.3 and above for SM90 GPUs
- PyTorch 2.10 and above
- NCCL 2.30.4 and above
- NVLink for intranode communication
- RDMA network for internode communication
- SM90 GPU 需 CUDA 12.3 及以上
- PyTorch 2.10 及以上
- NCCL 2.30.4 及以上
- 节点内通信需 NVLink
- 节点间通信需 RDMA 网络
### Install NCCL dependency
We recommend using pip to install NCCL so that DeepEP can automatically locate it within the Python environment. You can install it using the following command:
我们建议使用 pip 安装 NCCL，以便 DeepEP 能在 Python 环境中自动定位它。可使用以下命令安装：
```bash
pip install "nvidia-nccl-cu13>=2.30.4" --no-deps
@@ -81,7 +87,7 @@ pip install "nvidia-nccl-cu13>=2.30.4" --no-deps
### Install NVSHMEM dependency
DeepEP also depends on NVSHMEM to provide support for legacy methods. Please refer to our [NVSHMEM Installation Guide](docs/nvshmem.md) for instructions.
DeepEP 也依赖 NVSHMEM 以支持传统方法。请参阅我们的 [NVSHMEM Installation Guide](docs/nvshmem.md) 获取说明。
### Development
@@ -106,13 +112,13 @@ python tests/elastic/test_pp.py
python setup.py install
```
Then, import `deep_ep` in your Python project, and enjoy!
然后，在你的 Python 项目中 import `deep_ep`，即可开始使用！
## Interfaces and examples
### Buffer initialization
In V2, all EP operations — high-throughput and low-latency — are unified under a single `ElasticBuffer` interface. The buffer can be initialized by specifying MoE settings directly, and the optimal SM and QP counts are calculated analytically.
在 V2 中，所有 EP 操作——高吞吐与低延迟——均统一在单一 `ElasticBuffer` 接口下。可通过直接指定 MoE 设置来初始化 buffer，最优 SM 与 QP 数量将以解析方式计算。
```python
import torch
@@ -164,7 +170,7 @@ def get_buffer(group: dist.ProcessGroup,
### Example use in model training or inference prefilling
V2 unifies the dispatch and combine APIs into a single `ElasticBuffer` interface. The example below shows how to use them for training (with backward passes) or inference prefilling.
V2 将 dispatch 与 combine API 统一为单一 `ElasticBuffer` 接口。以下示例展示如何在训练（含反向传播）或推理 prefilling 中使用它们。
```python
import torch
@@ -252,7 +258,7 @@ def combine_backward(grad_combined_x: Union[torch.Tensor, Tuple[torch.Tensor, to
return grad_x, event
```
For communication-computation overlap, use the `EventOverlap` interface to manage dependencies between the communication stream and the compute stream:
为实现通信-计算重叠（communication-computation overlap），请使用 `EventOverlap` 接口来管理通信流与计算流之间的依赖关系：
```python
# After dispatch, overlap computation while communication is in-flight
@@ -266,9 +272,9 @@ event.current_stream_wait()
# Now safe to use recv_x, recv_topk_idx, recv_topk_weights
```
### Example use in inference decoding
### 推理解码中的示例用法
For inference decoding, the same `ElasticBuffer` is used. The handle-caching pattern allows reusing routing metadata across iterations when the gating decisions remain unchanged, avoiding redundant CPU synchronization.
在推理解码中，同样使用 `ElasticBuffer`。handle-caching 模式可在门控决策保持不变时跨迭代复用路由元数据，从而避免冗余的 CPU 同步。
```python
import torch
@@ -328,115 +334,115 @@ def decode_combine(x: torch.Tensor,
return combined_x, event
```
### Environment variables
### 环境变量
The library provides some environment variables, which may be useful:
本库提供了一些可能有用的环境变量：
- General
- `EP_BUFFER_DEBUG`: `0` or `1`, print buffer initialization, SM approximation, and backend debugging information, `0` by default
- `EP_SUPPRESS_NCCL_CHECK`: `0` or `1`, suppress NCCL version mismatch checking, `0` by default
- `EP_AVOID_RECORD_STREAM`: `0` or `1`, avoid `record_stream` on output tensors, `0` by default
- `EP_NUM_TOPK_IDX_BITS`: integer, override the number of bits for top-k index encoding, `0` (auto) by default
- Networking
- `EP_NIC_NAME`: string, the default NIC name used to query NIC properties, `mlx5_0` by default
- `EP_OVERRIDE_RDMA_SL`: integer, override the RDMA service level index for traffic isolation
- `EP_DISABLE_GIN`: `0` or `1`, disable the NCCL Gin backend (fall back to non-Gin path), `0` by default
- 通用
- `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`（auto）
- 网络
- `EP_NIC_NAME`: 字符串，用于查询网卡属性的默认网卡名称，默认 `mlx5_0`
- `EP_OVERRIDE_RDMA_SL`: 整数，覆盖用于流量隔离的 RDMA 服务等级索引
- `EP_DISABLE_GIN`: `0` 或 `1`，禁用 NCCL Gin 后端（回退到非 Gin 路径），默认 `0`
- JIT
- `EP_JIT_DEBUG`: `0` or `1`, print JIT debugging information, `0` by default
- `EP_JIT_CACHE_DIR`: string, cache directory for compiled kernels, `$HOME/.deep_ep` by default
- `EP_JIT_NVCC_COMPILER`: string, NVCC compiler path; defaults to `torch.utils.cpp_extension.CUDA_HOME`
- `EP_JIT_CPP_STANDARD`: integer, C++ standard version, `20` by default
- `EP_JIT_PRINT_COMPILER_COMMAND`: `0` or `1`, print compilation commands, `0` by default
- `EP_JIT_PTXAS_VERBOSE`: `0` or `1`, show detailed PTXAS output, `0` by default
- `EP_JIT_PTXAS_CHECK`: `0` or `1`, assert no local memory usage in compiled kernels, `0` by default
- `EP_JIT_WITH_LINEINFO`: `0` or `1`, embed source line info for profiling tools, `0` by default
- `EP_JIT_DUMP_ASM`: `0` or `1`, dump both PTX and SASS, `0` by default
- `EP_JIT_DUMP_PTX`: `0` or `1`, dump PTX output, `0` by default
- `EP_JIT_DUMP_SASS`: `0` or `1`, dump SASS output, `0` by default
- Debug and profiling
- `EP_GIN_GDAKI_DEBUG`: `0` or `1`, enable NCCL Gin GDAKI debugging output, `0` by default
- `EP_USE_NVIDIA_TOOLS`: `0` or `1`, skip internal profiling when running under external NVIDIA tools, `0` by default
- `EP_DISABLE_BARRIER_PROFILING`: `0` or `1`, disable barrier-based communication profiling in benchmarks, `0` by default
- Build
- `EP_NCCL_ROOT_DIR`: string, path to the NCCL installation directory; auto-detected from the Python environment if not set
- `EP_NVSHMEM_ROOT_DIR`: string, path to the NVSHMEM installation directory; auto-detected from the Python environment if not set
- `TORCH_CUDA_ARCH_LIST`: string, list of target CUDA architectures, e.g. `"9.0"`
- `DISABLE_SM90_FEATURES`: `0` or `1`, disable SM90 features for legacy methods, `0` by default
- `DISABLE_AGGRESSIVE_PTX_INSTRS`: `0` or `1`, disable aggressive load/store instructions in legacy methods, `0` by default
- `EP_JIT_DEBUG`: `0` 或 `1`，打印 JIT 调试信息，默认 `0`
- `EP_JIT_CACHE_DIR`: 字符串，已编译内核的缓存目录，默认 `$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`，断言已编译内核不使用本地内存，默认 `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`
- 调试与性能分析
- `EP_GIN_GDAKI_DEBUG`: `0` 或 `1`，启用 NCCL Gin GDAKI 调试输出，默认 `0`
- `EP_USE_NVIDIA_TOOLS`: `0` 或 `1`，在外部 NVIDIA 工具下运行时跳过内部性能分析，默认 `0`
- `EP_DISABLE_BARRIER_PROFILING`: `0` 或 `1`，在基准测试中禁用基于 barrier 的通信性能分析，默认 `0`
- 构建
- `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`
Some environment variables are **persistent**: they are captured at build time and baked into the installed package as default values. At import time, these defaults are applied automatically unless overridden by current environment variables. The persistent variables are: `EP_JIT_CACHE_DIR`, `EP_JIT_PRINT_COMPILER_COMMAND`, `EP_NUM_TOPK_IDX_BITS`, `EP_NCCL_ROOT_DIR`.
部分环境变量是**持久化的**：它们在构建时被捕获，并作为默认值写入已安装的包中。在导入时，除非被当前环境变量覆盖，否则会自动应用这些默认值。持久化变量包括：`EP_JIT_CACHE_DIR`、`EP_JIT_PRINT_COMPILER_COMMAND`、`EP_NUM_TOPK_IDX_BITS`、`EP_NCCL_ROOT_DIR`。
For additional details, please refer to [the test code](tests/elastic/test_ep.py) or review the corresponding Python documentation.
更多细节请参阅[测试代码](tests/elastic/test_ep.py)，或查阅相应的 Python 文档。
## Network configurations
## 网络配置
DeepEP is fully tested with InfiniBand networks. However, it is theoretically compatible with RDMA over Converged Ethernet (RoCE) as well.
DeepEP 已在 InfiniBand 网络上完成充分测试。不过，理论上它也兼容融合以太网上的 RDMA（RDMA over Converged Ethernet，RoCE）。
### Traffic isolation
### 流量隔离
Traffic isolation is supported by InfiniBand through Virtual Lanes (VL).
InfiniBand 通过虚拟通道（Virtual Lanes，VL）支持流量隔离。
To prevent interference between different types of traffic, we recommend segregating workloads across different virtual lanes as follows:
为避免不同类型流量之间的相互干扰，我们建议按以下方式将工作负载划分到不同的虚拟通道：
- expert-parallel workloads
- other workloads
- 专家并行（expert-parallel）工作负载
- 其他工作负载
For DeepEP V2, you can control the virtual lane assignment by setting the `sl_idx` argument or the `EP_OVERRIDE_RDMA_SL` environment variable.
对于 DeepEP V2，可通过设置 `sl_idx` 参数或 `EP_OVERRIDE_RDMA_SL` 环境变量来控制虚拟通道分配。
### Adaptive routing
### 自适应路由
Adaptive routing is an advanced routing feature provided by InfiniBand switches that can evenly distribute traffic across multiple paths. Even though adaptive routing introduces additional latency, we still recommend enabling it under all network load conditions.
自适应路由（adaptive routing）是 InfiniBand 交换机提供的高级路由特性，可将流量均匀分布到多条路径上。尽管自适应路由会引入额外延迟，我们仍建议在所有网络负载条件下启用它。
### Congestion control
### 拥塞控制
Congestion control is disabled because it hurts maximum bandwidth. If congestion is unavoidable in some scenarios, we recommend assigning those workloads to low-priority virtual lanes.
拥塞控制已禁用，因为它会损害最大带宽。若在某些场景下拥塞不可避免，我们建议将这些工作负载分配到低优先级虚拟通道。
### PCI atomic mode
### PCI 原子模式
If the hardware supports it, we recommend using the following command to set the NIC's `PCI_ATOMIC_MODE` to improve RDMA atomic operation performance:
若硬件支持，建议使用以下命令设置网卡的 `PCI_ATOMIC_MODE`，以提升 RDMA 原子操作性能：
```bash
sudo mlxconfig -y -d mlx5_$i set PCI_ATOMIC_MODE=4
```
## Experimental branches
## 实验分支
- [Zero-copy](https://github.com/deepseek-ai/DeepEP/pull/453)
- Removing the copy between PyTorch tensors and communication buffers, which reduces the SM usages significantly for normal kernels
- This PR is authored by **Tencent Network Platform Department**
- 消除 PyTorch 张量与通信缓冲区之间的拷贝，可显著降低常规模核的 SM 占用
- 该 PR 由**腾讯网络平台部（Tencent Network Platform Department）**编写
- [Eager](https://github.com/deepseek-ai/DeepEP/pull/437)
- Using a low-latency protocol removes the extra RTT latency introduced by RDMA atomic OPs
- 使用低延迟协议可消除 RDMA 原子操作（atomic OPs）引入的额外 RTT 延迟
- [Hybrid-EP](https://github.com/deepseek-ai/DeepEP/tree/hybrid-ep)
- A new backend implementation using TMA instructions for minimal SM usage and larger NVLink domain support
- Fine-grained communication-computation overlap for single-batch scenarios
- PCIe kernel support for non-NVLink environments
- NVFP4 data type support
- 基于 TMA 指令的新后端实现，实现最小 SM 占用并支持更大的 NVLink 域
- 针对单批次场景的细粒度通信-计算重叠
- 为非 NVLink 环境提供 PCIe 内核支持
- 支持 NVFP4 数据类型
- [AntGroup-Opt](https://github.com/deepseek-ai/DeepEP/tree/antgroup-opt)
- This optimization series is authored by **AntGroup Network Platform Department**
- [Normal-SMFree](https://github.com/deepseek-ai/DeepEP/pull/347) Eliminating SM from RDMA path by decoupling comm-kernel execution from NIC token transfer, freeing SMs for compute
- [LL-SBO](https://github.com/deepseek-ai/DeepEP/pull/483) Overlapping Down GEMM computation with Combine Send communication via signaling mechanism to reduce end-to-end latency
- [LL-Layered](https://github.com/deepseek-ai/DeepEP/pull/500) Optimizing cross-node LL operator communication using rail-optimized forwarding and data merging to reduce latency
- 该优化系列由**蚂蚁集团网络平台部（AntGroup Network Platform Department）**编写
- [Normal-SMFree](https://github.com/deepseek-ai/DeepEP/pull/347) 通过将通信内核执行与 NIC token 传输解耦，从 RDMA 路径中消除 SM 占用，从而释放 SM 用于计算
- [LL-SBO](https://github.com/deepseek-ai/DeepEP/pull/483) 通过信令机制将 Down GEMM 计算与 Combine Send 通信重叠，以降低端到端延迟
- [LL-Layered](https://github.com/deepseek-ai/DeepEP/pull/500) 使用 rail 优化转发与数据合并优化跨节点 LL 算子通信，以降低延迟
- [Mori-EP](https://github.com/deepseek-ai/DeepEP/tree/mori-ep)
- ROCm/AMD GPU support powered by [MORI](https://github.com/ROCm/mori) backend (low-latency mode)
- 基于 [MORI](https://github.com/ROCm/mori) 后端（低延迟模式）的 ROCm/AMD GPU 支持
- [nvDev](https://github.com/deepseek-ai/DeepEP/tree/nvDev)
- V2-based branch with the latest CUDA features, such as Compute Fabric Transport (CFT) that brings better latency on small token sizes.
- 基于 V2 的分支，集成最新 CUDA 特性，例如 Compute Fabric Transport（CFT），可在较小 token 规模下带来更优延迟。
## Community forks
## 社区分支
- [uccl/uccl-ep](https://github.com/uccl-project/uccl/tree/main/ep) - Enables running DeepEP on heterogeneous GPUs (e.g., Nvidia, AMD) and NICs (e.g., EFA, Broadcom, CX7)
- [Infrawaves/DeepEP_ibrc_dual-ports_multiQP](https://github.com/Infrawaves/DeepEP_ibrc_dual-ports_multiQP) - Adds multi-QP solution and dual-port NIC support in IBRC transport
- [antgroup/DeepXTrace](https://github.com/antgroup/DeepXTrace) - A diagnostic analyzer for efficient and precise localization of slow ranks
- [ROCm/mori](https://github.com/ROCm/mori) - AMD's next-generation communication library for performance-critical AI workloads (e.g., Wide EP, KVCache transfer, Collectives)
- [uccl/uccl-ep](https://github.com/uccl-project/uccl/tree/main/ep) - 支持在异构 GPU（如 Nvidia、AMD）和 NIC（如 EFA、Broadcom、CX7）上运行 DeepEP
- [Infrawaves/DeepEP_ibrc_dual-ports_multiQP](https://github.com/Infrawaves/DeepEP_ibrc_dual-ports_multiQP) - 在 IBRC 传输中添加多 QP（Queue Pair）方案及双端口 NIC 支持
- [antgroup/DeepXTrace](https://github.com/antgroup/DeepXTrace) - 用于高效、精确定位慢 rank 的诊断分析工具
- [ROCm/mori](https://github.com/ROCm/mori) - AMD 面向性能关键型 AI 工作负载（如 Wide EP、KVCache transfer、Collectives）的下一代通信库
## Acknowledgement
## 致谢
DeepEP V2 is built on top of the [NCCL](https://github.com/nvidia/nccl) Gin backend. Thanks to @sjeaugey, @pakmarkthub, @sb17v, @xiaofanl-nvidia, and the NCCL team for their support!
DeepEP V2 基于 [NCCL](https://github.com/nvidia/nccl) Gin backend 构建。感谢 @sjeaugey、@pakmarkthub、@sb17v、@xiaofanl-nvidia 以及 NCCL 团队的支持！
## License
## 许可证
This code repository is released under [the MIT License](LICENSE).
本代码仓库在 [the MIT License](LICENSE) 下发布。
## Citation
## 引用
```bibtex
@misc{deepep2025,