[NPU] reduce_sum_across_dp_group builds the all_reduce tensor on CPU when CUDA is unavailable #2126

What happens

On a host without CUDA (for example an Ascend NPU host, where torch.cuda.is_available() is False), reduce_sum_across_dp_group() in xtuner/v1/datasets/dataloader.py builds the tensor for the DP all_reduce on CPU:

if torch.cuda.is_available():
    device = torch.device(f"cuda:{torch.cuda.current_device()}")
else:
    device = torch.device("cpu")
tensor = torch.tensor([local_value], dtype=torch.int64, device=device)
dist.all_reduce(tensor, op=dist.ReduceOp.SUM, group=dp_mesh.get_group())

The process group comes from dp_mesh, i.e. it is an NCCL/HCCL group on the accelerator, so handing it a CPU tensor fails.

Real-machine evidence

Ascend 910B4, torch 2.15.0.dev + torch_npu, 2 processes via torchrun, real HCCL process group, reduce_sum_across_dp_group(DeviceMesh("npu", [0, 1]), 3) with the unmodified file:

[rank0] current npu device=0 mesh.device_type=npu
[rank0] RAISED RuntimeError: No backend type associated with device type cpu
[rank1] current npu device=1 mesh.device_type=npu
[rank1] RAISED RuntimeError: No backend type associated with device type cpu

This is not an exotic path: it is reached from Dataloader.get_state_dict(), which is used when saving/restoring dataloader state, so on Ascend the dataloader state cannot be written at all.

Proposed fix

dp_mesh is guaranteed non-None at that point (the early return above handles None), and it already carries the device type of the collective, so use it instead of assuming CUDA:

device = torch.device(dp_mesh.device_type)

That is device-agnostic (cuda / npu / xpu / cpu) and keeps a CPU mesh working. I have the fix ready and verified on the same 2-rank HCCL setup (RESULT=6 expected=6 on both ranks) - opening a PR right after this.