🚀 The feature, motivation and pitch

Summary

This RFC proposes and documents the addition of torch.accelerator.current_device_name(), a new public Python API that returns the human-readable hardware name of the currently active accelerator device. The API is backend-agnostic and works uniformly across CUDA (NVIDIA) and XPU (Intel) devices, consistent with the existing torch.accelerator namespace design.

Motivation

PyTorch already exposes torch.accelerator.current_device_index() and torch.accelerator.get_device_capability(), but there is no way to programmatically retrieve name of the active device (e.g., "NVIDIA A100-SXM4-40GB" or "Intel(R) Data Center GPU Max 1550") without using backend-specific APIs such as torch.cuda.get_device_name() or torch.xpu.get_device_name().

This gap causes two problems:

1. Backend lock-in in user code. Code that needs to log, assert, or branch on device name must import torch.cuda or torch.xpu directly, coupling otherwise backend-neutral code to a specific accelerator.

2. Missing introspection for tooling and diagnostics. Training frameworks, profilers, and orchestration tools need to identify the hardware in use without writing vendor-specific branches. An example is distributed training launchers that emit hardware audit logs at job start.

Proposed API

torch.accelerator.current_device_name() -> str

Returns the name of the currently selected device for the active accelerator.

Examples

NVIDIA GPU (CUDA backend):

>>> import torch
>>> torch.accelerator.is_available()
True
>>> torch.accelerator.current_device_name()
'NVIDIA A100-SXM4-40GB'

Intel GPU (XPU backend):

>>> import torch
>>> torch.accelerator.is_available()
True
>>> torch.accelerator.current_device_name()
'Intel(R) Data Center GPU Max 1550'

Design

Interface Layer (DeviceGuardImplInterface)

A new pure virtual method is added to the device guard implementation interface, which is the existing extension point for all device backends:

// c10/core/impl/DeviceGuardImplInterface.h
virtual std::string getDeviceName() const = 0;

This follows the same pattern used by getDevice() and getDeviceCapability(). All concrete implementations must provide this method, ensuring the compiler enforces completeness across backends.

Backend Implementations

C++ Accelerator Namespace

A new free function is added in at::accelerator:

// aten/src/ATen/DeviceAccelerator.h
TORCH_API std::string getDeviceName();

It resolves the active accelerator type, constructs a VirtualGuardImpl, and delegates:

std::string getDeviceName() {
  const auto device_type = getAccelerator(true).value();
  c10::impl::VirtualGuardImpl impl(device_type);
  return impl.getDeviceName();
}

VirtualGuardImpl itself is updated to forward getDeviceName() through its held DeviceGuardImplInterface*, following the same delegation pattern used for every other virtual method in that class.

Python Binding

A pybind11 lambda in torch/csrc/DeviceAccelerator.cpp exposes the C++ function:

m.def("_accelerator_getDeviceName", []() {
    const auto device_type = at::accelerator::getAccelerator(true).value();
    torch::utils::maybe_initialize_device(device_type);
    return at::accelerator::getDeviceName();
});

The call to maybe_initialize_device ensures the device context is initialized before querying properties, matching the pattern used by _accelerator_getDeviceIndex and _accelerator_getDeviceCapability.

The public Python API in torch/accelerator/__init__.py is a thin wrapper:

def current_device_name() -> str:
    return torch._C._accelerator_getDeviceName()

Testing

A new test test_current_device_name is added to test/test_accelerator.py. It:

1. Iterates over known vendors ("nvidia", "intel"), skipping unavailable backends.
2. Uses a new helper get_gpu_name(vendor, device_id) in torch/testing/_internal/common_utils.py that queries the device name from the system CLI tool (nvidia-smi or xpu-smi) and returns it as a ground-truth reference.
3. Asserts that torch.accelerator.current_device_name() matches the CLI-reported name exactly.
4. Skips on MPS (Apple Silicon), which does not support this API.

Backward Compatibility

This is a purely additive change. No existing APIs are modified.

cc @albanD @guangyey @EikanWang