mirror of
https://github.com/deepseek-ai/DeepEP.git
synced 2026-11-05 00:47:32 +00:00
[GH-ISSUE #584] deep_ep.cpp:200 init fails on partial CUDA peer access; preflight and report unsupported device pairs (cudaErrorPeerAccessUnsupported) #359
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#359
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?
Originally created by @stewtong on GitHub (Feb 20, 2026).
Original GitHub issue: https://github.com/deepseek-ai/DeepEP/issues/584
Problem
DeepEP initialization (
runtime.sync(...)indeep_ep.cpp:200) aborts with a CUDA peer accesserror on an 8-GPU PCIe-only host where only 4 undirected GPU pairs support
cudaDeviceCanAccessPeer. The error fires on the first unsupported pair without validating thefull required set upfront or reporting which pairs are incompatible. (The SGLang wrapper path that
triggers this is shown in the stack trace under Evidence.)
A secondary CUDA error at
runtime.cu:29also appears in the exception chain — see crashexcerpt for details; its relationship to the primary peer-access failure is unclear.
Steps to reproduce
Use an 8-GPU host with partial CUDA P2P: only same-PCIe-switch pairs support peer access
(e.g.,
{0,1},{2,3},{4,5},{6,7}). All other 48 of 56 off-diagonal pairs returncudaErrorPeerAccessUnsupported(err=217).Launch with EP=8 and DeepEP normal mode:
Evidence
On this host, 4 undirected PIX pairs support P2P (
{0,1},{2,3},{4,5},{6,7}); in thedirected 8×8 matrix this appears as 8/56 off-diagonal 'Y' entries, and the remaining directed
pairs fail with
cudaErrorPeerAccessUnsupported(217).nvidia-smi topo -m (8-GPU PCIe topology, no NVLink)
CUDA peer access matrix — cudaDeviceCanAccessPeer (8×8)
Crash log excerpt
Request
Two improvements that would help users on non-NVLink / partial-P2P hardware:
1. Document the peer-access assumption.
It would help to know whether DeepEP requires full-mesh peer access across all intranode EP devices,
or whether partial P2P is supported in some configurations. If full-mesh is required, noting this
in the README would let users rule out DeepEP before attempting it on PCIe hosts.
2. Validate all required pairs at init, report them together.
Rather than calling
runtime.syncand aborting on the first unsupported pair, a preflight loopover all required pairs would let users understand the full scope of incompatibility:
The "Only use 20 SMs" warning already fires before the crash, so partial connectivity is detectable
at this stage. An actionable error at the same point — before any token dispatch — would improve
the experience significantly.
Environment