mirror of
https://github.com/deepseek-ai/DeepEP.git
synced 2026-11-05 00:47:32 +00:00
[PR #690] DeepEP v2:Add experimental direct recv_x dispatch path. #709
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/DeepEP#709
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/deepseek-ai/DeepEP/pull/690
Author: @kzlxd
Created: 7/14/2026
Status: 🔄 Open
Base:
main← Head:Dispacth_Direct_recv_x📝 Commits (1)
6757592Add experimental direct recv_x dispatch path.📊 Changes
7 files changed (+594 additions, -185 deletions)
View changed files
📝
csrc/elastic/buffer.hpp(+74 -11)📝
csrc/kernels/elastic/dispatch.hpp(+18 -3)📝
deep_ep/buffers/elastic.py(+26 -1)📝
deep_ep/include/deep_ep/impls/dispatch.cuh(+179 -23)📝
deep_ep/include/deep_ep/impls/dispatch_copy_epilogue.cuh(+27 -9)📝
deep_ep/include/deep_ep/impls/hybrid_dispatch.cuh(+70 -4)📝
tests/elastic/test_ep.py(+200 -134)📄 Description
Add Direct Recv X dispatch path
Summary
This PR adds an experimental Direct Recv X path for compact EP dispatch.
The optimization removes the extra local hidden-state copy in the dispatch copy epilogue. In the original path, hidden states are first written into the NCCL symmetric staging buffer, then copied again into the final
recv_xtensor by the epilogue. With Direct Recv X enabled, dispatch writes hidden states directly into the final compactrecv_xwindow, while metadata and top-k tensors continue to use the existing staging + epilogue path.Direct Recv X is enabled by:
This PR also includes a small SM90 / H800 JIT compilation fix for an SM100-only shared-memory bulk-store instruction.
Background
The original dispatch path has two buffer layers:
stagingis NCCL symmetric / window memory and can be accessed by the communication path directly.recv_xis a normal PyTorch tensor. It is materialized after dispatch bydispatch_copy_epilogue.This means hidden states always pay one extra local copy:
The copy cost grows linearly with token count and becomes more visible with wider hidden sizes.
Direct Recv X design
The dispatch kernel already knows:
The receiver notify warp also knows how many tokens each source rank contributes. From those counts, it can compute the exclusive prefix base for each source rank in the compact
recv_xlayout.Direct Recv X publishes this receiver-side prefix information back to the source rank:
The hidden-state data path becomes:
The metadata / top-k path stays unchanged:
So the epilogue no longer copies hidden states, but it still materializes the metadata and top-k outputs.
Implementation
Reserve a Direct Recv X output window at the tail of the DeepEP symmetric communication buffer when
EP_V2_EXPERIMENTAL_DIRECT_RECV_X=1.Return
recv_xas a view into this symmetric-window tail in Direct Recv X mode.Extend dispatch runtime arguments and kernels so dispatch can write hidden states directly into the receiver-side
recv_xwindow.Let
dispatch_copy_epilogueskip the hidden-state copy when Direct Recv X is enabled.recv_topk_idxrecv_topk_weightsrecv_src_metadatachannel_linked_listSupport both compact dispatch variants:
Keep the feature behind one experimental env flag:
EP_V2_EXPERIMENTAL_DIRECT_RECV_X=1Add guardrails for unsupported modes:
previous_event_before_epilogueis rejected becauserecv_xis produced during dispatch instead of during the epilogue.H100 benchmark results
Configuration:
EP_V2_EXPERIMENTAL_DIRECT_RECV_X=1Parameter:
EP8
EP16
Result summary
Direct Recv X substantially reduces the copy epilogue cost by removing the hidden-state copy from staging to
recv_x.End-to-end dispatch + copy improvement:
In some BF16 cases, the dispatch kernel itself becomes slightly slower because it now performs direct remote
recv_xwrites. The removed epilogue hidden copy still more than offsets that overhead, so total latency improves.🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.