[curnane-lab]

The pinned receive pool and its device copy path were CUDA-only. On NPU, the trainer received pageable host tensors and paid a blocking H2D copy on the training thread. This PR enables Ascend pinned receive and loader-side H2D while preserving the existing CPU and CUDA behavior.

This is an enablement/correctness change, not a demonstrated throughput win.

Modifications

• consumer_device() reports the rank's NPU for pinned consumers when the trainer device is NPU (LOCAL_RANK is mirrored, as for CUDA), so pooled reads finish H2D in loader workers. Explicit CPU trainers stay on the host.
• The pinned pool allocates through torch_npu's pinned host allocator when Ascend is available and still degrades to pageable host buffers on accelerator-less hosts.
• copy_stream() and the slot-copy path dispatch to the device type's stream module (torch.cuda / torch.npu). Slot release waits for copy completion before reuse, and NPU outputs record the consumer stream when supported.
• FeatureDataLoader records an NPU ready event after transform/collate. Consumption performs wait_event() and record_stream() on the consumer stream, covering both the execution dependency and allocator lifetime after collate.

Validation

Validated PR head: d58e652.

Clean PR head:

• 95 passed, 7 skipped, 1 xfailed with backend autoload disabled.
• 8 passed on Ascend 910B3.
• black and isort checks passed.
• Hardware checks covered exact NPU-delivered values with host integer features, A/B immediate slot-reuse safety, release followed by KeyError, and delayed-collate handoff to a separate NPU consumer stream.

Supplementary test-only validation:

• d58e652 + this test-only patch, SHA-256 d1f14c08b62ca3e59cb13f2113dfe9b684e61600004a761df6acf79ef1aff99d, adds two cases to the PR's eight NPU tests and passed 10/10 on 910B3. This is not a clean-PR-head test count.
• The positive handoff tests passed, but earlier negative controls also passed on pre-fix code; they do not demonstrate race-detection capability.

Benchmark & Profiling

• Training A/B (managed-local, 8 steps, same seed, main+N1 vs. this change): per-step losses were bit-identical. Steady-state step time and train_compute_time_s were unchanged within noise; data_wait_time_s was already zero after step 1 on both paths. Existing loader prefetch already hid receive latency at this scale, so no end-to-end speedup is claimed.
• A mock-backend receive/copy microbenchmark on clean d58e652 used _FakeMooncakeStore with a real NPU, not TCP/RDMA. For an 8.015625 MiB payload, it measured only get(npu:1) + torch.npu.synchronize(npu:1), with 10 warmups and 100 alternating-order iterations per mode. Median latency was 1.936 ms pageable vs. 2.220 ms pinned (0.872x pageable/pinned ratio). This microbenchmark shows no receive speedup at this size; raw samples and metadata are archived.

Validation archive and reproduction notes.

Checklist

• Format your code according to the Code Formatting with Pre-Commit.
• Add unit tests as outlined in the Running Unit Tests.
• Update documentation / docstrings / example tutorials as needed, according to Writing Documentation.
• Provide throughput / latency benchmark results and accuracy evaluation results as needed, according to Benchmark and Profiling and Accuracy Results.
• For reviewers: If you haven't made any contributions to this PR and are only assisting with merging the main branch, please remove yourself as a co-author when merging the PR.
• Please feel free to join our Slack channel at https://sgl-fru7574.slack.com/archives/C09784E3EN6 to discuss your PR.