Change8

Migrating to PyTorch v2.12.0

Version v2.12.0 introduces 7 breaking changes. This guide details how to update your code.

Released: 5/13/2026

7
Breaking Changes
4
Migration Steps
13
Affected Symbols

⚠️ Check Your Code

If you use any of these symbols, you need to read this guide:

FindARM.cmaketorch.distributed.nn.functionaltorch.distributed._functional_collectivestorchruntorch.linalg.eightorch.linalg.lu_solvetorch.linalg.cholesky_inversetorch.linalg.cholesky_solvetorch.accelerator.Graphtorch.export.saveAdagradtorch.condtorch._inductor.config.max_autotune_defer_layout_freezing

Breaking Changes

Issue #1

Strengthened SVE compile checks in `FindARM.cmake`, which may reject previously accepted but incorrect SVE configurations. Source builds that enable SVE must update the compiler/toolchain flags to accurately describe the target SVE support, or disable SVE for that build.

Solution

Update the compiler/toolchain flags so they accurately describe the target SVE support, or disable SVE for that build.

Issue #2

Updated the minimum CUDA version required to build PyTorch from source to CUDA 12.6. Building PyTorch from source with CUDA versions older than 12.6 is no longer supported.

Solution

Users building custom binaries should install CUDA 12.6 or newer and make sure `CUDA_HOME` points to that installation.

Issue #3

Enforced a C++20 minimum in CMake build files. Source builds now require a compiler and build configuration that support C++20.

Solution

Update the compiler and remove assumptions that PyTorch can be built as C++17 if maintaining custom build scripts or downstream extensions.

Issue #4

`torch.distributed.nn.functional` ops now raise `RuntimeError` under `torch.compile`. Users should migrate to the functional collectives API in `torch.distributed._functional_collectives`.

Solution

Migrate calls from `torch.distributed.nn.functional.all_reduce(...)` to `torch.distributed._functional_collectives.all_reduce(...)` when used inside `torch.compile`.

Issue #5

`torchrun` now defaults to an OS-assigned free port for single-node training instead of port 29500 when `--master-port` or `--standalone` are not specified.

Solution

No action required unless you relied on port 29500 being the default. To explicitly use a fixed port, use `--master-port=29500`.

Issue #6

All MPS tensors are now allocated in unified memory unconditionally. Code that relied on device-only memory placement may observe different performance characteristics.

Solution

No specific fix required, but be aware of potential performance changes due to unified memory allocation.

Issue #7

The `max_autotune` layout-constraint deferral introduced in 2.11 is now opt-in. The default reverts to immediate layout freezing.

Solution

Users who relied on the deferred behavior for fusion opportunities should opt in explicitly via `torch._inductor.config.max_autotune_defer_layout_freezing = True` or setting the environment variable `TORCHINDUCTOR_MAX_AUTOTUNE_DEFER_LAYOUT_FREEZING=1`.

Migration Steps

  1. 1
    If building from source, ensure your compiler supports C++20.
  2. 2
    If building from source with CUDA, ensure you are using CUDA 12.6 or newer.
  3. 3
    If using `torch.distributed.nn.functional` ops inside `torch.compile`, migrate those calls to use the functional collectives API in `torch.distributed._functional_collectives`.
  4. 4
    If you relied on deferred layout freezing for `max-autotune` mode in 2.11, explicitly enable it in 2.12 using `torch._inductor.config.max_autotune_defer_layout_freezing = True`.

Release Summary

PyTorch 2.12 introduces significant performance improvements, notably in batched linalg.eigh on CUDA and fused Adagrad optimization. This release also enforces stricter build requirements, including C++20 and CUDA 12.6 for source builds, and updates distributed functional API usage within torch.compile.

Need More Details?

View the full release notes and all changes for PyTorch v2.12.0.

View Full Changelog