deepseek-ai/DeepEP

Fork 0

mirror of https://github.com/deepseek-ai/DeepEP.git synced 2026-11-05 00:47:32 +00:00

[GH-ISSUE #698] `hybrid_ep_cpp` extension hardcodes `-std=c++17`; should inherit torch's C++ standard like `deep_ep_cpp` #404

New issue

Closed

opened 2026-10-26 10:00:08 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-26 10:00:08 +00:00

Owner

Originally created by @janbernloehr on GitHub (Jul 24, 2026).
Original GitHub issue: https://github.com/deepseek-ai/DeepEP/issues/698

Describe the bug

DeepEP's hybrid-ep branch hardcodes -std=c++17 for the hybrid_ep_cpp CUDAExtension in setup.py (get_extension_hybrid_ep_cpp()). Recent PyTorch builds require C++20 — their headers emit #error C++20 or later compatible compiler is required to use PyTorch when included from a C++17 translation unit. As a result, building hybrid_ep_cpp against a current-PyTorch environment fails at compile time.

The sibling deep_ep_cpp extension (get_extension_deep_ep_cpp()) sets no explicit -std flag — its nvcc_flags = ['-O3', '-Xcompiler', '-O3'] — and therefore inherits torch's default standard (now c++20). That is why deep_ep_cpp still builds while hybrid_ep_cpp does not.

To Reproduce

Install a recent PyTorch whose headers require C++20 (e.g. a current nightly).

Build DeepEP hybrid-ep with the hybrid-EP multinode extension enabled:

HYBRID_EP_MULTINODE=1 CUDA_HOME=/usr/local/cuda pip install --no-build-isolation .

Compilation of hybrid_ep_cpp aborts with the C++20 #error shown below.

Expected behavior

hybrid_ep_cpp builds against current PyTorch, the same way the sibling deep_ep_cpp extension already does.

Actual behavior

Building the hybrid_ep_cpp extension aborts at compile time. nvcc invokes the host compiler with -std=c++17 for the hybrid_ep_cpp sources, which include PyTorch headers (torch/all.h:5, ATen/ATen.h:5); those headers hard-#error under C++17:

error: #error C++20 or later compatible compiler is required to use PyTorch.
error: #error C++20 or later compatible compiler is required to use ATen.
...
ERROR: Failed building wheel for deep_ep

The build log shows a mix of -std=c++17 invocations (for hybrid_ep_cpp) and -std=c++20 invocations (for the sibling deep_ep_cpp, which inherits torch's standard); only the C++17 ones fail. pip install . then exits with code 1, so DeepEP is not installed and every downstream consumer is blocked.

Proposed fix

Remove the hardcoded -std=c++17 entry from the hybrid_ep_cpp nvcc compile args in setup.py, so the extension inherits torch's C++ standard from CUDAExtension/BuildExtension — exactly like deep_ep_cpp. This is portable: it builds against both C++17 torch (older) and C++20 torch (current), rather than swapping one hardcoded standard for another (a hardcoded -std=c++20 would instead break users still on a C++17 torch). The runtime JIT compiler (csrc/hybrid_ep/jit/compiler.cu) can keep -std=c++17, since its JIT-compiled kernels do not include torch headers and it relies on std::any.

Validated experimentally: with the hardcoded flag removed, the extension compiles cleanly and a DeepSeek-V3 MXFP8 expert-parallel (EP=8) training run completes end-to-end with healthy convergence (loss 12.02 decreasing to 6.60 across 50 steps) and no runtime regressions on GB200-class hardware (CUDA arch 10.0/9.0, PyTorch built for C++20).

Environment

DeepEP: hybrid-ep branch, commit 17cfb817bccec3a9c247013360cc550c2bac441e
PyTorch: current build requiring C++20 (arm64/aarch64)
CUDA arch list: 10.0 9.0
OS/arch: Linux aarch64

This issue was drafted with assistance from the opus AI model.

Originally created by @janbernloehr on GitHub (Jul 24, 2026). Original GitHub issue: https://github.com/deepseek-ai/DeepEP/issues/698 **Describe the bug** `DeepEP`'s `hybrid-ep` branch hardcodes `-std=c++17` for the `hybrid_ep_cpp` CUDAExtension in `setup.py` (`get_extension_hybrid_ep_cpp()`). Recent PyTorch builds require C++20 — their headers emit `#error C++20 or later compatible compiler is required to use PyTorch` when included from a C++17 translation unit. As a result, building `hybrid_ep_cpp` against a current-PyTorch environment fails at compile time. The sibling `deep_ep_cpp` extension (`get_extension_deep_ep_cpp()`) sets **no** explicit `-std` flag — its `nvcc_flags = ['-O3', '-Xcompiler', '-O3']` — and therefore inherits torch's default standard (now c++20). That is why `deep_ep_cpp` still builds while `hybrid_ep_cpp` does not. **To Reproduce** 1. Install a recent PyTorch whose headers require C++20 (e.g. a current nightly). 2. Build DeepEP `hybrid-ep` with the hybrid-EP multinode extension enabled: ``` HYBRID_EP_MULTINODE=1 CUDA_HOME=/usr/local/cuda pip install --no-build-isolation . ``` 3. Compilation of `hybrid_ep_cpp` aborts with the C++20 `#error` shown below. **Expected behavior** `hybrid_ep_cpp` builds against current PyTorch, the same way the sibling `deep_ep_cpp` extension already does. **Actual behavior** Building the `hybrid_ep_cpp` extension aborts at compile time. `nvcc` invokes the host compiler with `-std=c++17` for the `hybrid_ep_cpp` sources, which include PyTorch headers (`torch/all.h:5`, `ATen/ATen.h:5`); those headers hard-`#error` under C++17: ``` error: #error C++20 or later compatible compiler is required to use PyTorch. error: #error C++20 or later compatible compiler is required to use ATen. ... ERROR: Failed building wheel for deep_ep ``` The build log shows a mix of `-std=c++17` invocations (for `hybrid_ep_cpp`) and `-std=c++20` invocations (for the sibling `deep_ep_cpp`, which inherits torch's standard); only the C++17 ones fail. `pip install .` then exits with code 1, so DeepEP is not installed and every downstream consumer is blocked. **Proposed fix** Remove the hardcoded `-std=c++17` entry from the `hybrid_ep_cpp` `nvcc` compile args in `setup.py`, so the extension inherits torch's C++ standard from `CUDAExtension`/`BuildExtension` — exactly like `deep_ep_cpp`. This is portable: it builds against both C++17 torch (older) and C++20 torch (current), rather than swapping one hardcoded standard for another (a hardcoded `-std=c++20` would instead break users still on a C++17 torch). The runtime JIT compiler (`csrc/hybrid_ep/jit/compiler.cu`) can keep `-std=c++17`, since its JIT-compiled kernels do not include torch headers and it relies on `std::any`. Validated experimentally: with the hardcoded flag removed, the extension compiles cleanly and a DeepSeek-V3 MXFP8 expert-parallel (EP=8) training run completes end-to-end with healthy convergence (loss 12.02 decreasing to 6.60 across 50 steps) and no runtime regressions on GB200-class hardware (CUDA arch `10.0`/`9.0`, PyTorch built for C++20). **Environment** - DeepEP: `hybrid-ep` branch, commit `17cfb817bccec3a9c247013360cc550c2bac441e` - PyTorch: current build requiring C++20 (arm64/aarch64) - CUDA arch list: `10.0 9.0` - OS/arch: Linux aarch64 --- _This issue was drafted with assistance from the `opus` AI model._

bsakaguchi closed this issue

2026-10-26 10:00:09 +00:00

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

deepseek-ai/DeepEP#404

No description provided.

Rows
Columns

[GH-ISSUE #698] hybrid_ep_cpp extension hardcodes -std=c++17; should inherit torch's C++ standard like deep_ep_cpp #404

[GH-ISSUE #698] `hybrid_ep_cpp` extension hardcodes `-std=c++17`; should inherit torch's C++ standard like `deep_ep_cpp` #404