oneAPI Collective Communications Library (oneCCL)

Installation   |   Usage   |   Release Notes   |   Documentation   |   How to Contribute   |   License

oneAPI Collective Communications Library (oneCCL) provides an efficient implementation of communication patterns used in deep learning.

oneCCL is integrated into:

• Horovod* (distributed training framework). Refer to Horovod with oneCCL for details.
• PyTorch* (machine learning framework). Refer to PyTorch bindings for oneCCL for details.

oneCCL is governed by the UXL Foundation and is an implementation of the oneAPI specification.

Table of Contents

• Prerequisites
• Installation
• Usage
  • Launching Example Application
    • Using external MPI
  • Setting workers affinity
    • Automatic setup
    • Explicit setup
  • Using oneCCL package from CMake
    • oneCCLConfig files generation
• Governance
• Additional Resources
  • Blog Posts
  • Workshop Materials
• Notice of Deprecation
• Contribute
• License
• Security Policy

Prerequisites

See System Requirements to learn about hardware and software requirements before getting started with oneCCL.

Installation

See install instructions to familiarize yourself with the general installation scenario and the customizations you can make during the build process.

Usage

Launch an Example Application

Use the command:

$ source <install_dir>/env/setvars.sh
$ mpirun -n 2 <install_dir>/examples/benchmark/benchmark

Use External mpi

In the vars.sh file, the ccl-bundled-mpi flag can have values "yes" or "no" to control whether bundled Intel MPI should be used or not. Current default value is "yes", which means that oneCCL temporarily overrides the mpi implementation in use.

In order to suppress the behavior and use user-supplied or system-default mpi, use the following command instead of sourcing setvars.sh:

$ source <install_dir>/env/vars.sh --ccl-bundled-mpi=no

The mpi implementation will not be overridden. In this case, you need to ensure that the system finds all required mpi-related binaries.

Set Workers Affinity

There are two ways to set worker threads (workers) affinity: automatically and explicitly.

Automatic Setup

1. Set the CCL_WORKER_COUNT environment variable with the desired number of workers per process.
2. Set the CCL_WORKER_AFFINITY environment variable with the value auto.

Example:

export CCL_WORKER_COUNT=4
export CCL_WORKER_AFFINITY=auto

With the variables above, oneCCL will create four workers per process and the pinning will depend from process launcher.

If an application is launched using mpirun that is provided by oneCCL distribution package, then workers will be automatically pinned to the last four cores available for the launched process. The exact IDs of CPU cores can be controlled by the mpirun parameters.

Otherwise, workers will be automatically pinned to the last four cores available on the node.

---

Explicit Setup

1. Set the CCL_WORKER_COUNT environment variable with the desired number of workers per process.
2. Set the CCL_WORKER_AFFINITY environment variable with the IDs of cores to pin local workers.

Example:

export CCL_WORKER_COUNT=4
export CCL_WORKER_AFFINITY=3,4,5,6

With the variables above, oneCCL will create four workers per process and pin them to the cores with the IDs of 3, 4, 5, and 6 respectively.

Use oneCCL package from CMake

oneCCLConfig.cmake and oneCCLConfigVersion.cmake are included into oneCCL distribution.

With these files, you can integrate oneCCL into a project with the find_package command. Successful invocation of find_package(oneCCL <options>) creates imported target oneCCL that can be passed to the target_link_libraries command.

For example:

project(Foo)
add_executable(foo foo.cpp)

# Search for oneCCL
find_package(oneCCL REQUIRED)

# Connect oneCCL to foo
target_link_libraries(foo oneCCL)

oneCCLConfig Files Generation

To generate oneCCLConfig files for oneCCL package, use the provided cmake/scripts/config_generation.cmake file:

cmake [-DOUTPUT_DIR=<output_dir>] -P cmake/script/config_generation.cmake

OS File Descriptors

oneCCL uses Level Zero IPC handles so that a process can access a memory allocation done by a different process. However, these IPC handles consume OS File Descriptors (FDs). To avoid running out of OS FDs, we recommend to increase the default limit of FDs in the system for applications running with oneCCL and GPU buffers.

The number of FDs required is application-dependent, but the recommended limit is 1048575. This value can be modified with the ulimit command.

Governance

The oneCCL project is governed by the UXL Foundation and you can get involved in this project in multiple ways. It is possible to join the Special Interest Groups (SIG) meetings where the group discusses and demonstrates work using the foundation projects. Members can also join the Open Source and Specification Working Group meetings.

You can also join the mailing lists for the UXL Foundation to be informed of when meetings are happening and receive the latest information and discussions.

Additional Resources

Blog Posts

• Optimizing DLRM by using PyTorch with oneCCL Backend
• Intel MLSL Makes Distributed Training with MXNet Faster

Workshop Materials

• oneAPI, oneCCL and OFI: Path to Heterogeneous Architecure Programming with Scalable Collective Communications: recording and slides

Notice of Deprecation

Deprecation of C++ API

• In oneCCL version 2021.17 included with the 2025.3 oneAPI release, oneCCL will add support for a new C API that closely follows the NVIDIA Collective Communications Libary (NCCL)* API standard. The existing C++ API will remain available and will remain the default API for the 2021.17 release. Details explaining how an application may link against and use the new API will be shared in this release.

See the oneCCL C API RFC document to view the proposed API and provide any feedback.

• In oneCCL version 2022.0 included with the 2026.0 oneAPI release, oneCCL will use the new NCCL like C API by default. This is a breaking change. The legacy C++ API will remain available, and details explaining how an application may link against and use the legacy API will be included in the 2022.0 release.

Applications cannot use both the C and C++ APIs simultaneously.

Support for the legacy C++ API shall remain in the release until future notice. The schedule for legacy API removal will be announced here.

Contribute

See CONTRIBUTING for more information.

License

Distributed under the Apache License 2.0 license. See LICENSE for more information.

Security Policy

See SECURITY for more information.

Notices and Disclaimers

Intel technologies may require enabled hardware, software or service activation.

No product or component can be absolutely secure.

Your costs and results may vary.

© Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.

No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.

The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.