fix: use a 64-bit operand for st.bulk's size in st_bulk()

[KeitaW]

Problem

The PTX ISA defines st.bulk's size operand as .u64, but st_bulk() in deep_ep/include/deep_ep/common/ptx.cuh passes kNumBytes through a 32-bit "r" inline-asm constraint. ptxas rejects the generated PTX with Arguments mismatch for instruction 'mov'. The call sits in the __CUDA_ARCH__ >= 1000 branch, so every JIT kernel that includes this header fails to compile on sm_100-family GPUs (B200/B300); Hopper takes the fallback loop and never compiles this branch — which is why Hopper validation doesn't surface it, and why this branch can never have compiled successfully on any target.

Repro

On 2× p6-b300.48xlarge (sm_103), tests/elastic/test_ep.py --test-first-only fails at the first dispatch on every rank:

NVCC compilation failed: ptxas kernel.ptx, line 400; error   : Arguments mismatch for instruction 'mov'
ptxas fatal   : Ptx assembly aborted due to errors

Minimal standalone repro (CUDA 13.0, --gpu-architecture=sm_100f): the st.bulk asm with "r"(size) fails ptxas with exactly this error; the same asm with "l"((uint64_t)size) compiles clean.

Fix

One line: pass the size as "l"(static_cast<uint64_t>(kNumBytes)). The value is unchanged (widening only); the address operand stays "r", which is correct for a 32-bit shared::cta address; Hopper is unaffected (the branch is preprocessed out there).

Validation

With this fix built from this branch, the two-node internode tests/elastic/test_ep.py --test-first-only passes end-to-end over EFA-GDA (NCCL GIN, GDAKI backend) on 2× p6-b300.48xlarge — RUN_EXIT=0 on both nodes with all correctness checks green; per-rank dispatch ~115 GB/s scale-out / ~375 GB/s scale-up, combine ~81 GB/s scale-out / ~267 GB/s scale-up (2026-08-21; NCCL 2.31.2, aws-ofi-nccl v1.21.1, libfabric v2.6.0amzn1.0). The passing combine correctness checks also exercise the zero-fill semantics this instruction provides.

Note

Separately, single-node intranode runs on the same stack fail earlier, at ElasticBuffer creation, with NET/IB : Requested properties for GIN GDAKI NIC 6, only 2 GIN GDAKI NICs have been created — that precedes any kernel and is unrelated to this change; happy to file it separately with logs.

Upstream deepseek-ai/DeepEP carries the identical constraint, so this applies there too.

[Xuan-1998]

Thanks Keita, fix looks good, and the repro/validation are solid.

One side note: the current PTX ISA spec actually allows a 32-bit size operand for st.bulk since PTX ISA 9.0 ("Support for size operand with 32-bit length is introduced in PTX ISA version 9.0", st.bulk docs (https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-st-bulk)). Your repro shows ptxas on CUDA 13.0 still rejects the "r" form in practice, so widening to "l"(uint64_t) is the right call anyway which is valid under every PTX version regardless of what the toolchain emits.

Since upstream deepseek-ai/DeepEP carries the same constraint, could you also open a PR there?

[Xuan-1998]

Could you try CUDA13.1, 32-bit size is now supported in CUDA13.1

[KeitaW]

Confirmed with CUDA 13.1.80: the original 32-bit "r" form and the widened 64-bit "l" form both compile for sm_100f. nvcc emits PTX .version 9.1, and the resulting object contains an sm_100 cubin.

I also tested the 32-bit form after changing the generated PTX declaration from .version 9.1 to .version 9.0; ptxas 13.1.80 still accepts it. In comparison, ptxas 13.0.88 emits PTX .version 9.0 but rejects the same 32-bit register form with Arguments mismatch for instruction 'mov'.

So you are right that the 32-bit operand is valid under PTX ISA 9.0. The observed compatibility boundary is the ptxas implementation: 13.0.88 rejects this form, while 13.1.80 accepts it. I have kept the 64-bit form because it works with both versions.

[KeitaW]

Thanks for catching this. I found that the equivalent upstream change is already open as deepseek-ai/DeepEP#692. It has the same one-line fix and includes CUDA 13.1 validation, so I will not open a duplicate PR.

I have also rebased this branch onto the current amazon-contributing/DeepEP main. The PR is now limited to the intended one-line change in deep_ep/include/deep_ep/common/ptx.cuh.