Change8

Migrating to PyTorch v2.7.0

Version v2.7.0 introduces 5 breaking changes. This guide details how to update your code.

Released: 4/23/2025

5
Breaking Changes
7
Migration Steps
9
Affected Symbols

⚠️ Check Your Code

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

torch.Tensor.new_tensortorch.onnx.dynamo_exporttorch.onnx.exporttorch.optim.lr_scheduler.LRScheduler.print_lrtorch.optim.lr_scheduler.LRSchedulertorch.export.capture_pre_autograd_graphtorch.export.exporttorch.fx.passes.graph_transform_observer.GraphTransformObserverlibtorch_python.so

Breaking Changes

Issue #1

The device for a newly created tensor using torch.Tensor.new_tensor() now defaults to the device of the calling tensor, instead of always defaulting to 'cpu'.

Solution

If you explicitly require the new tensor to be on the CPU regardless of the source tensor's device, you must now pass device='cpu' to new_tensor().

Issue #2

Custom C++ extensions built with py_limited_api=True might fail to build if they rely on non-limited Python APIs (like pybind).

Solution

Ensure your custom extension code adheres strictly to the Python Limited API when py_limited_api=True is set during compilation.

Issue #3

torch.onnx.dynamo_export is deprecated, and its associated ExportOptions like diagnostic_options, fake_context, and onnx_registry are no longer supported.

Solution

Migrate usage from torch.onnx.dynamo_export to torch.onnx.export with dynamo=True. Use the dynamic_shapes argument in torch.onnx.export for shape specifications.

Issue #4

The LRScheduler.print_lr() method and the verbose kwarg in LRScheduler constructors have been completely removed.

Solution

Replace calls to print_lr() with lrsched.get_last_lr() and manually print the result. Remove the verbose argument from LRScheduler constructors.

Issue #5

Linux wheel builds now use Manylinux 2.28 (based on AlmaLinux 8), which requires glibc2.28, dropping support for older OS distributions like Amazon Linux 2 and CentOS 7 (which use glibc2.26).

Solution

Ensure your deployment environment uses a Linux distribution compatible with glibc2.28 or newer. Upgrade your base OS images if necessary.

Migration Steps

  1. 1
    Review all usages of torch.Tensor.new_tensor(). If you relied on the old behavior of creating tensors on CPU, explicitly add device='cpu' to the call.
  2. 2
    If you maintain custom C++ extensions compiled with py_limited_api=True, verify that they only use APIs guaranteed by the Python Limited API.
  3. 3
    Update any code using torch.onnx.dynamo_export to use torch.onnx.export(..., dynamo=True) instead.
  4. 4
    Remove any usage of the 'verbose' keyword argument when initializing learning rate schedulers (e.g., torch.optim.lr_scheduler.ReduceLROnPlateau).
  5. 5
    Replace any calls to lrsched.print_lr() with print(lrsched.get_last_lr()).
  6. 6
    If you are building PyTorch from source or relying on pre-built Linux wheels, be aware that support for older Linux distributions (like CentOS 7 or Amazon Linux 2) requiring glibc2.26 is dropped due to the move to Manylinux 2.28.
  7. 7
    If you are using Triton, ensure your environment uses Triton version 2.2.0 or newer.

Release Summary

PyTorch 2.7.0 introduces Blackwell support and FlexAttention optimizations while enforcing stricter C++ API visibility and Python limited API compliance. It marks a significant shift in ONNX and Export workflows by deprecating legacy capture methods in favor of the unified torch.export API.

Need More Details?

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

View Full Changelog