togethercomputer/xorl-wheels deepep_1.2.1_sm90_sm100

DeepEP 1.2.1+567632d (sm_90 + sm_100 / Hopper + Blackwell B200)

Repository: togethercomputer/xorl-wheels

Tag: deepep_1.2.1_sm90_sm100

Published: 2026-09-16T21:11:12Z

Prerelease: no

Release notes: DeepEP 1.2.1+567632d built for sm_90 (Hopper/H100) and sm_100 (Blackwell/B200).

The wheel in deepep_1.2.1 carries sm_90 kernels only and no PTX, so on B200 (compute capability 10.0) DeepEP's first kernel launch aborts with CUDA error .../csrc/kernels/layout.cu:138 'named symbol not found'. This build adds sm_100 while keeping sm_90, so a single wheel serves both the H100 pools and B200.

Build

• Source: deepseek-ai/DeepEP @ 567632dd5981 — the same commit as deepep_1.2.1, only the arch list differs.

(Mirrored at togethercomputer/xorl-DeepEP @ main; identical SHA, so byte-identical source.)

• ABI: Python 3.12 (cp312), PyTorch 2.10.0+cu129, CUDA 12.9 (nvcc 12.9.86). sm_100 requires CUDA >= 12.8.
• TORCH_CUDA_ARCH_LIST="9.0;10.0", built inside the RL trainer image so the torch/CUDA/Python ABI matches exactly.

Two things that will bite whoever rebuilds this:

1. Do not set `NVSHMEM_DIR`. setup.py only resolves the versioned soname libnvshmem_host.so.3 — the only host library the nvidia-nvshmem-cu12 wheel ships, with no unversioned symlink — on its auto-discovery path. Setting NVSHMEM_DIR takes the other branch, which hardcodes libnvshmem_host.so, and the link fails with cannot find -l:libnvshmem_host.so. Leave it unset and let setup.py find nvidia.nvshmem. 2. The trainer venv has no pip; install with uv pip install --python .

Version string is 1.2.1+567632d, which is what stock setup.py produces ('1.2.1' + '+' + git_short_sha). It lacks the .torch2.10.cu129 suffix used by the deepep_1.2.1 release, which is a local naming convention rather than something upstream emits. The ABI is unchanged; only the version label differs.

Verification

cuobjdump --list-elf on deep_ep_cpp*.so:

| wheel | ELF arch | .so size | |---|---|---| | deepep_1.2.1 (previous) | sm_90 | 19.8 MB | | this release | sm_90 sm_100 | 30.8 MB |

Runtime, on a real B200 (compute capability 10.0), same pod and same test, only the wheel swapped:

• Before (sm_90 wheel): CUDA error .../csrc/kernels/layout.cu:138 'named symbol not found'
• After (this wheel): Buffer constructs; get_dispatch_layout (the previously failing layout.cu kernel)

returns the correct routing totals; a real intranode dispatch over NVLink round-trips (recv_x (795, 1024) bf16); combine returns the original (512, 1024) shape with all-finite values.

Not yet verified: inter-node dispatch on B200 (needs a multi-node group with InfiniBand), and a no-regression run of the sm_90 half on H100. The sm_90 code is byte-identical source built with the same flag, so regression risk is low, but it has not been measured.