PyTorch 2.15: rewritten NCCL backend is now default, Python 3.10 dropped

PyTorch 2.15 makes a rewritten NCCL backend the default for every distributed job that uses the nccl backend, adds a flight recorder that writes a post-mortem when a collective hangs, and drops support for Python 3.10 and macOS 14. If you train on NVIDIA GPUs across more than one process, the upgrade changes how your communicators are created, so it is worth testing before you move a production job.

Key points

• PyTorch announced 2.15 on 28 October 2026 (the project's release blog is dated that day); it is made of 3,117 commits from 583 contributors since 2.14.
• Every nccl process group now runs on the rewritten backend by default; setting TORCH_DIST_USE_NCCL2=0 or using the nccl-legacy backend name restores the old ProcessGroupNCCL.
• A backend-agnostic flight recorder writes a post-mortem to disk when a collective hangs, and a timeout on any rank triggers dumps from every rank.
• PyTorch 2.15 requires Python 3.11 or newer and, for Apple Silicon GPU (MPS) acceleration, macOS 15 or newer.
• The default wheel moves to CUDA 13.2, with CUDA 13.4 wheels alongside; torch.compile now works on Python 3.15.

What to do

• Check your Python. 2.15 builds no 3.10 wheels and no longer tests 3.10 in CI. Stay on 2.14 or move to Python 3.11-3.15 (including the free-threaded 3.14t and 3.15t builds).
• Check your Mac. On macOS 14, PyTorch may still run, but MPS is no longer tested there and issues will not be fixed.
• Test distributed jobs before upgrading production. Run one job with the default and, if something misbehaves, set TORCH_DIST_USE_NCCL2=0 (or pick nccl-legacy) to compare. The PyTorch release post lists this as the rollback path.
• Review FSDP2 gradient dtypes. The release notes list "FSDP2 separates sharded and unsharded gradient dtypes" as a backwards-incompatible change, and say gradients now follow each parameter's grad_dtype, which changes the default when reduce_dtype=None.
• Check C++ extensions and custom ops. C++ warnings from torch.ops and custom ops now propagate to Python, which can surface new warnings in test logs.

What happened

PyTorch published the 2.15 release post on 28 October 2026. The headline change is in torch.distributed: the rewritten NCCL backend, which 2.14 shipped as an opt-in preview named nccl2, is now what every nccl process group uses. NCCL is NVIDIA's library for moving data between GPUs, and the PyTorch post explains the stakes plainly: when a model trains across many GPUs, those GPUs constantly exchange data through it.

The Register covered the release on 6 November, after a live Q&A with PyTorch core developer Tristan Rice, a Meta engineer who works on distributed computing. According to that report, the old backend, ProcessGroupNCCL, could create dozens of communicators per process group, which led to intermittent deadlocks and unpredictable performance. The new backend enforces one communicator per process group at initialisation; a program that needs more parallelism has to create more process groups. The PyTorch post states the creation side of this too: communicators are now created eagerly together with the process group.

Fault handling is the other half. The PyTorch post says reconfiguration can opt into a shrink/grow fast path (it needs NCCL 2.29 or newer) so surviving ranks skip a full bootstrap, and that reconfiguration for fault tolerance is also enabled on AMD's ROCm with RCCL 2.30.7. The Register describes the practical effect: if a GPU crashes or slows down, a third-party orchestrator can exclude it and even assign a replacement worker. We have not tested this ourselves, and the project labels the related APIs "API Unstable", so expect changes.

For debugging, the post describes a backend-agnostic flight recorder that "writes a post-mortem to disk when a collective hangs", and says watchdog health is published to the debug server so a timeout on any rank triggers flight-recorder dumps from every rank. The Register reports that before this, a stalled cluster often produced only a generic message.

Background

The 2.x series has been moving PyTorch from a research tool towards production training and inference, a framing the project itself uses in the release post. In the 2.13 release, per the 2.15 post, the project added torchcomms for large-cluster training. The 2.14 post, dated 2 September 2026 (2,995 commits, 487 contributors), described the rewritten backend as "ported from torchcomms", made it available in-tree as a drop-in nccl2 backend, and said it "will be default from pytorch 2.15+". It also made fault tolerance a first-class c10d concept, with in-place process-group reconfiguration, and made the Flight Recorder work for any backend instead of NCCL only. So the 2.15 default switch is the planned end of a two-release rollout, not a surprise.

The Register adds one forward-looking detail: the legacy ProcessGroupNCCL ships in 2.15 as a rollback, and if the new backend works as expected the older one will be removed in 2.16, which it says is planned for early next year. That date comes from the Register's report of the livestream; the release post itself only says the legacy path is the rollback for now. Treat 2.15 as the window to find problems while the escape hatch still exists.

The numbers

Two release posts give directly comparable size figures. The 2.15 cycle was bigger on both measures.

2.14487

2.15583

Contributors per PyTorch release (contributors)

	contributors
2.14	487
2.15	583

Source: PyTorch 2.14 and 2.15 release posts (pytorch.org/blog)

2.142995

2.153117

Commits per PyTorch release (commits)

	commits
2.14	2995
2.15	3117

Source: PyTorch 2.14 and 2.15 release posts (pytorch.org/blog)

The release post also gives performance figures for Apple Silicon, all reported by the project and not independently tested by us:

• On an M3 Ultra, the new MPS grouped_mm with a decode fast path gives 1.32-1.34x higher mixture-of-experts decode throughput.
• F.linear now uses the existing gemv kernels for a 1.23x geometric-mean speedup, up to 5x on small projections.
• A single-row softmax over a 128,256-entry vocabulary is 8x faster, and upsample backward is up to 21.7x faster.
• A QR decomposition of a 512 x 512 matrix falls from about 7 seconds to 1.5 ms.

How it works

Under the old design, communicators could multiply inside one process group. Under the new one, a process group owns exactly one. Because communicators are created eagerly, problems with them show up at start-up rather than in the middle of a job, which is the behaviour you want when a fleet job is expensive to restart.

The same release adds a Python transport API for one-sided data movement in torch.distributed, with NIXL as the first backend. Transports connect to a peer through a store, with no process group or collectives needed, and Transport.read_stream and write_stream enqueue transfers on a CUDA stream so they can be captured with torch.cuda.graph. The Register points to training jobs that sync weights between trainers and generators as the natural use. The post marks it "API Unstable".

FSDP2 and pipeline parallelism get memory and communication controls: precision-sensitive parameters such as mixture-of-experts router gates and norm weights can stay in fp32 while the rest trains in bf16, a full gradient-accumulation step can be captured in a single CUDA graph, gradient reduction can overlap with subsequent compute, and pipeline schedules accept a max_outstanding_sends budget.

What it means

For teams running large NVIDIA clusters, the most concrete gain is diagnosability. A stalled collective that used to require reproducing the failure by hand now leaves a trace from every rank. For anyone building training platforms, the reconfiguration path is a hook to build on: the Register's description of an orchestrator removing a slow GPU and substituting a replacement matches what the post says the shrink/grow fast path is for.

Smaller teams may feel it mainly as a compatibility check. The Python 3.10 and macOS 14 cut-offs are the most likely cause of a failed upgrade, and the FSDP2 gradient dtype change is the most likely cause of a quiet numeric difference, so it deserves a look in any mixed-precision training run.

Other hardware vendors get attention as well. The post lists FlyDSL kernels on AMD gfx950, Tensor Data Mover support on gfx1250 (MI450), ROCm 10.0 wheels built on AMD's TheRock packages, simpler SYCL kernel authoring and multi-GPU profiling on Intel GPUs, and faster 4-bit NVFP4 decode on NVIDIA Blackwell through NVGEMM. The CUDA 13.4 wheels add experimental support for NVIDIA Rubin GPUs.

What we don't know yet

• Whether the new default causes regressions in real jobs. The sources we read are the project's own release post and one news report; we found no independent benchmark of the new backend.
• How long the rollback will stay. The 2.16 removal plan comes from a news report of a livestream, not from the release post.
• The final shape of the "API Unstable" features, including transports and the one-sided windows.
• We could not open the GitHub release notes from our tooling, so we relied on the release blog for the list of changes and did not check pull requests individually.

What to watch next

Watch for the 2.15 point-release notes and for bug reports on the new backend's reconfiguration path, and for the 2.16 plan that would delete the legacy backend. If you run a managed training platform, check when its images adopt 2.15, since the Python and macOS floors apply there too.

Sources

• PyTorch 2.15 release blog (PyTorch, 28 October 2026)
• PyTorch 2.14 release blog (PyTorch, 2 September 2026)
• PyTorch 2.15 tackles the 'one bad GPU' problem (The Register, 6 November 2026)