PyTorch Hardware Enablement: Updates from the Accelerator Integration Working Group

PyTorch's Accelerator Integration Working Group published a summary of its work in the first half of 2026, describing infrastructure, test refactoring and reference implementations intended to standardize how new accelerators connect to the framework. The post covers the Cross-Repository CI Relay (CRCR), test suite refactoring, PrivateUse1 profiling support, the OpenReg reference backend, distributed support and compile backend integration.

The Cross-Repository CI Relay addresses a coordination gap: PyTorch's upstream CI runs inside the pytorch/pytorch repository, so downstream projects such as Intel XPU, AMD ROCm, Apple MPS, Qualcomm AI Engine, PrivateUse1-based accelerators, vLLM, SGLang and Hugging Face Transformers had no standard way to test against upstream changes or report results. When a PR is opened or a commit pushed, a webhook dispatches events to registered downstream repos in parallel; each runs its own workflow and reports back via an authenticated callback using a GitHub OIDC token. Results appear in the PyTorch CI HUD at hud.pytorch.org/crcr within seconds. Four participation tiers (L1-L4) range from dispatch notifications to blocking checks on upstream PRs, and onboarding needs only an allowlist entry plus a lightweight workflow file.

On testing, PyTorch maintains over 600,000 test cases, many with hardcoded device strings and skip decorators. Contributors migrated more than 276 test files in H1 across dynamo, profiler, nn modules, linalg, optimizers, convolutions, serialization, multiprocessing and dataloader, replacing references like device="cuda" and @onlyCUDA with parameterized equivalents. A hw_classification attribute (GENERIC, DEVICE_GENERIC, CUDA, XPU, MPS) and a --hw-classification flag were added across unittest, pytest, subprocess, parallel, XML output and run_test.py. A linter enforces classification for new test classes; 1,191 unclassified files were allowlisted at launch and are being reduced toward zero.

For profiling, an OpenReg reference stub stack (RFC #177978) demonstrates kernel-level bring-up on the REGISTER_PRIVATEUSE1_PROFILER API, covering session lifecycle, activity types and correlation IDs. OpenReg is PyTorch's minimal, CPU-backed in-tree reference backend for PrivateUse1: not production software, but a way to isolate integration mechanics. OCCL, a reference c10d backend for OpenReg (RFC #176877), makes ProcessGroup registration, collective dispatch and Work completion semantics explicit.

Why it matters: Accelerator vendors get concrete reference paths for CI, testing, profiling, distributed training and torch.compile integration instead of patching tests or reverse-engineering production backends. Test selection, skip control and cross-repo signaling are handled through upstream mechanisms and a single dashboard. H2 priorities include driving the unclassified allowlist to zero, extending device-agnostic coverage to distributed, JIT and autograd modules, and wiring hw_classification into CI scheduling.