[Draft] RFC: Add XCCL Backend Support for Intel GPU in TorchComms

[zhangxiaoli73]

Summary

This RFC proposes adding XCCL (Intel GPU Collective Communications Library) backend support to TorchComms, enabling efficient distributed communication on Intel GPUs. This backend leverages Intel's oneCCL library and integrates with PyTorch's XPU device support via SYCL runtime.

---

Motivation

Currently, TorchComms supports NCCL (NVIDIA), RCCL (AMD), and Gloo (CPU) backends, but lacks native support for Intel GPUs. Since PyTorch provides distributed support for Intel GPUs through the xccl backend, we plan to integrate XCCL into TorchComms as well.

Design Overview

Architecture

The XCCL backend follows the same architectural pattern as existing backends (NCCL/RCCL):

Python API (torchcomms)
    ↓
TorchCommBackend Interface
    ↓
TorchCommXCCL Implementation
    ↓
    ├── XcclApi (oneCCL wrapper)
    ├── XpuApi (SYCL/XPU abstraction)
    └── TorchCommXCCL (Collectives implementation)
    

Key Components

Core Files

File	Purpose
TorchCommXCCL.cpp/.hpp	Collectives implementation
TorchWorkXCCL.cpp/.hpp	Asynchronous work tracking
TorchWorkXCCLQueue.cpp	Work queue management
TorchCommXCCLBootstrap.cpp/.hpp	Communicator initialization
TorchCommXCCLUtils.cpp/.hpp	Utility functions (type conversion)
TorchCommXCCLPy.cpp	Python bindings

API Abstraction Layers

File	Purpose
XcclApi.cpp/.hpp	oneCCL API wrapper
device/XpuApi.cpp/.hpp	SYCL/XPU runtime abstraction

Build System

File	Purpose
xccl/CMakeLists.txt	CMake configuration for XCCL backend
setup.py	Python package build (USE_XCCL flag)

API Surface

The XCCL backend implements all standard TorchComm operations:

Point-to-Point Operations

• send() / recv()
• batch_op_issue() (batched P2P)

Collective Operations

• broadcast()
• all_reduce()
• reduce()
• all_gather() / all_gather_single()
• reduce_scatter() / reduce_scatter_single()
• all_to_all() / all_to_all_single() / all_to_all_v_single()
• scatter() / gather()
• barrier()

Advanced Operations

• split() - Create sub-communicators

Build from Source

# Install Intel oneAPI baskit

# Enable XCCL backend in TorchComms source code build
USE_XCCL=ON python setup.py install

# Or for development
USE_XCCL=ON pip install -e .

Usage Examples

Basic AllReduce

import torch
import torchcomms
from torchcomms import new_comm

# Initialize communicator
device = torch.device('xpu')
comm = new_comm("xccl", device, name="main_comm")
rank = comm.get_rank()
current_device = torch.device(f"xpu:{rank}")

# Perform collective operation
tensor = torch.randn(1024, device=current_device)
work = comm.all_reduce(tensor, torchcomms.ReduceOp.SUM, async_op=True)
work.wait()

# Cleanup
comm.finalize()

PR plan

✅ Core Infrastructure

• TorchCommXCCL class with full backend interface implementation
• TorchWorkXCCL for asynchronous operation tracking
• TorchWorkXCCLQueue for work management
• Python bindings (_comms_xccl module)
• CMake build system integration

✅ API Abstraction

• XcclApi wrapper for all oneCCL operations
• XpuApi for SYCL/XPU runtime operations

✅ Collective Operations

• AllReduce collectives as an entry point
• other collectives

---

[d4l3k]

@zhangxiaoli73 , thanks for submitting this RFC and PR! This is super exciting to see

I had some high level questions to figure out the best plan to support this.

• Are there PyTorch nightlies for XPU builds?
• Do we have XPU access in meta-pytorch for running CI on this?
• What's your commitment level on maintaining this integration?
• Thoughts on maintaining this out of tree (i.e. in the XCCL repo) rather than as part of torchcomms? We do support being able to pip install backends without having them in the main repo

[zhangxiaoli73]

Hi, @d4l3k Thanks for noticing our RFC so quickly. Regarding your questions,

Are there PyTorch nightlies for XPU builds?

Yes, https://download.pytorch.org/whl/nightly/xpu

Do we have XPU access in meta-pytorch for running CI on this?

We currently have XPU for PyTorch CI, and we can provide XPU for meta-pytorch CI.

What's your commitment level on maintaining this integration?

We are committed to long-term maintenance, similar to what we do for PyTorch, such as on-call for all the XPU related issues.

Thoughts on maintaining this out of tree (i.e. in the XCCL repo) rather than as part of torchcomms? We do support being able to pip install backends without having them in the main repo.

We prefer in tree support and we are committed to support the CI and maintain the integration, similarly as what we have been doing for PyTorch XPU support. PyTorch has already provided XCCL binary releases since PyTorch 2.8 (PyTorch 2.8 Release Blog – PyTorch), and we aim to deliver a similar user experience by integration XCCL in torchcomms repo. Once torchcomms is eventually merged into PyTorch core, XCCL would naturally become part of it as well.

By the way, we learnt from the torchcomms blog that there is a plan to merge torchcomms into core eventually, may I know if there is a defined timeline or criteria for it?

[d4l3k]

Got it, sounds good! We can chat on Slack about the specifics on the CI support

We're aiming to merge in 2026 but active work is being done now to support torchcomms in existing functionality such as in DeviceMesh/DTensor/etc