PyTorch 2.15 Is Out—Check Your Python, GPU, and Checkpoints Before You Upgrade

PyTorch 2.15 Is Out—Check Your Python, GPU, and Checkpoints Before You Upgrade

PyTorch 2.15 shipped on October 28, 2026, as a full release. The highlights are genuinely tempting: one-sided transports for distributed training, finer memory control in FSDP2, and torch.compile working on Python 3.15. If your reaction is "upgrade now, read later," this article is the small pause in between. Below are the three things most likely to bite, plus a way to keep a working exit if the upgrade goes wrong.

One note up front: this guide is based on the official release notes, not on our own install-and-migrate testing. Treat it as a map of where the potholes are, not a promise about your specific machine.

Pitfall one: pip says the package does not exist

If you run pip install torch on Python 3.10, you simply will not find 2.15. PyTorch stopped publishing Python 3.10 wheels—there are no cp310 builds of torch or of the bundled Triton, and CI no longer tests on 3.10. The binary packages now start at Python 3.11 and run through 3.15, including the free-threaded 3.14t and 3.15t builds.

The fix is boring but real: upgrade your environment to Python 3.11 or newer. If your system Python is stuck at 3.10—common on older LTS Linux images—this is the moment to switch to a fresh virtual environment or container rather than fighting the OS. And if upgrading Python is off the table this quarter, staying on PyTorch 2.14 is a legitimate choice, not a failure.

Pitfall two: your GPU or driver quietly falls off the list

The official PyPI wheels now ship CUDA 13.2 by default, with a CUDA 13.4 build alongside. The CUDA 12.6 and 13.0 wheels are gone. That change carries a hardware floor: the CUDA 13 wheels need an NVIDIA driver of 580 or newer and a GPU of the Turing generation (compute capability 7.5) or newer.

In plain terms: Maxwell, Pascal, and Volta cards—think GTX 10-series, the original Titan X, Tesla P100/V100-era hardware—are no longer served by the official packages, and any host still running a CUDA 12.x-era driver is in the same boat. Those machines should stay on PyTorch 2.14, where the CUDA 12.6 wheel still works.

Two things worth saying clearly. First, this is not "everyone must buy a new GPU": anything Turing or newer with an updated driver is fine, which covers most cards from roughly 2018 onward. Second, check before you upgrade, not after: nvidia-smi shows your driver version, and on your current install, torch.cuda.get_device_capability() tells you where your card stands. AMD users have their own version of this shift—wheels move to ROCm 7.14 and 10.0, and the gfx900 and gfx906 kernels are dropped, so MI25, MI50, MI60, and Radeon VII owners stay on 2.14 or build from source. Mac users, one more: the MPS backend now requires macOS 15 or later; on macOS 14 it simply reports unavailable, though CPU builds still run.

Pitfall three: the checkpoint one-way door

This is the subtle one, and it matters most if you train.

PyTorch 2.15 changes the metadata format of distributed checkpoints—the ones written by torch.distributed.checkpoint, the standard way to save large multi-GPU training state. The metadata now records tensor strides, and there is no flag to write the old format. The consequence: a distributed checkpoint saved with 2.15 cannot be loaded by 2.14 or earlier. On the older version, dcp.load fails with a CheckpointException about "too many values to unpack."

The other direction is fine—2.15 reads 2.14 checkpoints without complaint. And this does not touch ordinary model files saved with torch.save; it is specifically the distributed checkpoint format.

But think about what the one-way door means for a training run. You upgrade, train for two weeks, hit something broken, and decide to roll back to 2.14. Your recent checkpoints now refuse to load there. Your rollback plan only works if your last good checkpoint from before the upgrade is still intact. So before you train anything on 2.15, decide: are you keeping a 2.14-era checkpoint as your lifeboat, and is it recent enough to be useful?

Smaller breaks worth a skim

A few more changes from the release notes, briefly, in case one of them is yours. The default NCCL backend is a new implementation; the old one survives this release only, as backend="nccl-legacy", and process groups are now bound to a single CUDA device, which can bite code that drives several GPUs from one process. Nested tensors are off the default weights_only allowlist, so torch.load on files containing them now fails unless you allowlist them explicitly. Linux CUDA wheels no longer bundle cuRAND, so native extensions that call its host API need to install it themselves.

The upgrade that leaves a way back

Here is the whole playbook, in order.

1. Check Python first: python --version. Below 3.11, fix that before anything else.

2. Check the GPU and driver: nvidia-smi for the driver (you want 580 or newer for the CUDA 13 wheels) and torch.cuda.get_device_capability() on your current install (you want 7.5 or higher).

3. Install 2.15 into a fresh virtual environment or container. Never upgrade the environment that currently trains in place—your old environment is your rollback.

4. Run your training script's smoke test and your eval harness in the new environment before any real run.

5. Before the first real training run, decide your checkpoint policy: keep the last 2.14-readable checkpoint untouched until 2.15 has proven itself on your workload.

6. If anything fails the checks above, pin the old version and move on with your quarter: pip install torch==2.14 with the index URL that matches your hardware.

Who should upgrade now, and who can wait

If you are on Python 3.11+, a Turing-or-newer NVIDIA card with a current driver, and you mostly fine-tune or run inference, 2.15 is a reasonable same-week upgrade in a clean environment. If you run long distributed training jobs, the checkpoint question is your gating item—upgrade when you can afford to start a fresh checkpoint lineage. And if your hardware or Python is below the new floor, 2.14 is not abandoned software; it is the version that still fits your machine.

The new features will still be there next month. A broken training environment, and a checkpoint that will not load on the version you fled back to, are the expensive way to find that out.