Artificial Intelligence 6 min read

PyTorch Upgrade Checklist: 2.15 Drops Python 3.10

A PyTorch upgrade checklist for 2.15: Python 3.10 and old NVIDIA GPUs lose their wheels, and macOS 14 loses MPS. What I checked and what to pin.

Abstract illustration of amber crates riding a teal conveyor, with one odd-shaped crate stopped at a narrow gap in the track while the rest pass through.

PyTorch is the open source deep learning library most of us pull in with one pip install, and version 2.15.0 came out on October 28. On paper it is a normal bump. In practice it removes three things: wheels for Python 3.10, every CUDA 12.x wheel (so Maxwell, Pascal and Volta GPUs have no prebuilt PyTorch anymore), and macOS 14 as a place where the Apple GPU backend, MPS, works. Python 3.10 itself reached end of life on October 31, which is why the timing is tight.

In this post I go over what breaks, what I could check without a GPU, and the PyTorch upgrade checklist I would give a five-person team before anyone types pip install -U torch. My verdict: for most of you, bump the image to Python 3.11 or 3.12 and move on. The pain is real but narrow, and it lands on old GPU boxes and pinned Docker images.

Mettons. The team is made up: five people, one Dockerfile that starts from a Python 3.10 image, one V100 server under somebody’s desk, three MacBooks. It describes no real company of mine.

Abstract illustration of amber crates riding a teal conveyor, with one odd-shaped crate stopped at a narrow gap in the track while the rest pass through.
Most crates pass the gap. The odd-shaped one is your pinned Python 3.10 image, or your old GPU.

What did I test, and what did I not?

I tested the install, not the models. My sandbox is Linux with Python 3.11, no GPU and no Mac, so I never ran PyTorch 2.15 on any accelerator, and I claim nothing about speed, NCCL or MPS at runtime. What pip can tell you without hardware, I ran on October 29 (the version list is trimmed here, the rest is as printed):

$ pip download torch==2.15.0 --no-deps --only-binary=:all: \
    --python-version 3.10 --platform manylinux_2_28_x86_64 --implementation cp
ERROR: Could not find a version that satisfies the requirement torch==2.15.0
(from versions: 2.7.0 ... 2.14.0, 2.14.1)

$ pip download torch==2.15.0 --no-deps --only-binary=:all: \
    --python-version 3.11 --platform macosx_14_0_arm64 --implementation cp
Saved ./torch-2.15.0-cp311-cp311-macosx_14_0_arm64.whl

Two findings. First, a Python 3.10 pip sees 2.14.1 as the newest torch on PyPI. It does not explode, it just stays behind. I asked for 2.15.0 by name, so “plain pip install -U torch on 3.10 lands on 2.14.1″ is my inference, not something I ran. The release notes say it too: on Python 3.10, pip cannot find a 2.15 wheel.

Second, the Mac wheel exists and is tagged macosx_14_0. I opened its WHEEL file and read the tag myself. That matters below.

I also compared the PyPI metadata. 2.14.0 says Requires-Python >=3.10, 2.15.0 says >=3.11. The CUDA toolkit pin moves from 13.0.3 to 13.2.2 and Triton from 3.8 to 3.9. The cp312 Linux wheel went from 554.6 MB to 539.2 MB, wheel only, not the CUDA libraries beside it.

Which Python versions does PyTorch 2.15 still support?

3.11 through 3.15, including the free-threaded 3.14t and 3.15t builds, per PyTorch’s own Python 3.10 notice. Their policy (RFC-0038) is to drop an old Python in the last release before it reaches end of life, and 2.15 was that release.

Building 2.15 on 3.10 from source is not supported either.

If you cannot move today, the notice gives a stopgap: torch==2.14.0 together with torchvision==0.29.0. They call it “a stopgap, not a destination”, and 2.14 gets no more fixes. Pin both packages together, because a torch bump with an old torchvision is a classic way to lose an afternoon.

Python 3.11 is supported upstream until October 2027, per the Python devguide, so it buys you a year. I wrote about Python 3.15 lazy imports a couple of weeks ago, and the 2.15 notes say torch.compile now works on 3.15.

What happens to the old GPU box?

This is the one that can actually hurt. The CUDA 12.6 notice says 2.14 is the last release to ship any CUDA 12.x wheels. CUDA 13 does not support GPUs below Turing (sm_75), and CUDA 12.6 was the only build still covering them. So Maxwell (sm_50), Pascal (sm_60) and Volta (sm_70) lose their prebuilt wheels. Turing, Ampere, Hopper and Blackwell stay.

The V100 under the desk (made up, remember) is Volta. For that box you can stay on 2.14 with the CUDA 12.6 index (pip3 install torch==2.14.0 torchvision==0.29.0 --index-url https://download.pytorch.org/whl/cu126), or build 2.15 from source against CUDA 12.6 (the notice shows how, with TORCH_CUDA_ARCH_LIST). Me, I would not compile PyTorch on a five-person team unless a feature forces it.

One nuance I almost got wrong. The PyPI default has been CUDA 13 since the 2.11 line, per PyTorch’s March announcement, and CUDA 12.6 stayed on download.pytorch.org only. So a Pascal or Volta owner with a plain pip install torch was already off the working path months ago. What 2.15 removes is the cu126 fallback. The default moving from CUDA 13.0 to 13.2 is real, but it is not what breaks old cards.

The release notes also say CUDA 13 wheels need NVIDIA driver 580 or newer, so a host with an older CUDA 12.x driver should stay on 2.14 too. Check nvidia-smi first. How many people still run Pascal or Volta? The notice gives no number.

What about Mac laptops?

The release notes say the MPS backend now requires macOS 15 (Sequoia). On macOS 14 they say torch.backends.mps.is_available() returns False, and allocating on mps raises “The MPS backend is supported on macOS 15.0+”. CPU builds still run on older macOS.

Here is the odd part from my check. The wheel itself is tagged macosx_14_0_arm64, and pip downloaded it for that platform without a complaint. So pip will happily put 2.15 on a macOS 14 laptop, and then the notes say the GPU path is off. There is no Mac in my sandbox, so I only know what the notes say and what the wheel tag says. Test one laptop before you roll out to three.

What is on the PyTorch upgrade checklist?

Here is the PyTorch upgrade checklist in the order I would run it.

  1. Grep your Dockerfiles and CI config for python:3.10, python3.10, cu126 and cu130. Each hit is a job that will quietly keep an old torch.
  2. If a GPU box is Maxwell, Pascal or Volta, pin torch==2.14.0 and torchvision==0.29.0 today, and write a calendar date for the real fix. Retire the card, or accept the source build.
  3. Check the driver (580 or newer for the CUDA 13 wheels) and the macOS version of every laptop that uses MPS.
  4. Run your checkpoint loads in CI. The notes say torch.load(weights_only=True) now rejects checkpoints that use the NEWOBJ opcode without a matching BUILD, and after import torch.distributed pickled builtin exceptions need torch.serialization.add_safe_globals. An old checkpoint can be what trips it.
  5. If you train on several GPUs, know that the rewritten NCCL backend is now the default. The rollback is TORCH_DIST_USE_NCCL2=0 or backend="nccl-legacy", but the notes say both disappear in the next release, so it is an escape hatch and not a plan.
  6. Do not upgrade the training box on release week. Move one job, a small one, to 2.15 and let it run for a few days. Franchement, the rest is detail.

Do you even need to worry?

Probably not. If your laptops are on macOS 15, your GPUs are Turing or newer, and your Python is 3.11 or higher, the upgrade is pip install -U torch plus the checkpoint test. PyTorch’s own notice calls 3.10 to 3.11 low friction for most code.

The release lists speed gains: 1.32 to 1.34x tokens per second on MoE decode on Apple Silicon, and a grouped-query attention forward pass on an RTX 5090 (Windows) going from 11.5 ms to 0.49 ms. Those are PyTorch’s own benchmarks and I did not reproduce them. A 23x jump looks to me like an old fallback path getting fixed, so do not plan around it.

What I will do next is a real canary. I want one small job on a Python 3.12 image with 2.15, and I will write down the first stack trace I see, because that is where these upgrades always get interesting.

Dominic Plouffe

CTO of Trellis, with exits at FuseTalk, 360pi and DeadHeat. I write about making agents and big data work together safely, and I'm building yaaf, an open-source platform for running teams of AI agents that actually finish the job: yaaf.dplouffe.ca