Skip to content

Install a CUDA wheel that exists on a pre-12.4 driver - #650

Merged
thcp merged 1 commit into
mainfrom
fix/cuda-wheel-tag-644
Sep 21, 2026
Merged

thcp merged 1 commit into
mainfrom
fix/cuda-wheel-tag-644

Conversation

@thcp

@thcp thcp commented Sep 21, 2026 •

Copy link
Copy Markdown
Collaborator

Closes #644
Closes #649

An RTX 4060 on Windows reported the NVIDIA build falling back to CPU with No matching distribution found for torch==2.6.0+cu121.

What was wrong

The wheel tag comes from the driver and the torch version comes from a table, and nothing held the two together. cuda_tag sent a driver reporting CUDA 12.0 to 12.3 to cu121, torch_version_for_tag answers 2.6.0 for every non-cu128 tag, and the cu121 index stops at 2.5.1. That is true for torch, torchaudio and torchvision alike, on every platform. So setup asked pip for a wheel that has never been published, the install failed, CPU torch was restored, and a working GPU went unused.

What changed

Every CUDA 12 driver now gets cu124. CUDA 12 is minor-version compatible, so a cu124 build runs on a 12.0 driver, and cu124 publishes the same 2.6.0 line the rest of the app is pinned to. cu121 is no longer reachable.

cu118 follows it as a second candidate, which is #649. wheel_candidates has returned a list since #502 so that a tag which fails falls through to the next, but every non-Blackwell branch returned one element, so the fallthrough had nowhere to go and cu124 failing meant CPU. cu118 runs on every 12.x driver and publishes the same torch line, so the second attempt is now a real one.

The guard that was missing

The new test walks every driver and compute capability combination setup can see, and asserts each tag it offers appears in a table of tag and version pairs confirmed against download.pytorch.org. A tag whose index does not publish what setup installs fails here instead of on someone's machine. Restoring the cu121 branch reproduces this bug as a test failure that names the tag.

Verified

  • cargo fmt, clippy --tests -D warnings and cargo test on Windows (99 passing) and on the Linux target via WSL (109 passing)
  • pytest (1060 passing), ruff check and format, bandit unchanged from main, JS unit tests and syntax, i18n coverage clean, uv.lock untouched
  • Wheel availability checked live against download.pytorch.org/whl/<tag>/ for torch, torchaudio and torchvision, cp312, win_amd64 and linux_x86_64

An RTX 4060 on Windows reported the NVIDIA build falling back to CPU with
"No matching distribution found for torch==2.6.0+cu121" (#644).

The tag comes from the driver and the torch version from a table, and nothing
held the two together. cuda_tag sent a driver reporting CUDA 12.0-12.3 to
cu121, torch_version_for_tag answers 2.6.0 for every non-cu128 tag, and the
cu121 index stops at 2.5.1 -- for torch, torchaudio and torchvision alike, on
every platform. So setup asked pip for a wheel that has never been published,
the install failed, CPU torch was restored, and a working GPU sat unused.

Every CUDA 12 driver now gets cu124. CUDA 12 is minor-version compatible, so a
cu124 build runs on a 12.0 driver, and cu124 publishes the same 2.6.0 line the
rest of the app is pinned to. cu121 is no longer reachable at all.

cu118 follows it as a second candidate. wheel_candidates has returned a list
since #502 precisely so a tag that fails falls through to the next, but every
non-Blackwell branch returned one element, so the fallthrough had nowhere to
go: cu124 failing meant CPU. cu118 runs on every 12.x driver and publishes the
same torch line, which makes it a real second chance.

The new test is the guard the original bug lacked: it walks every driver and
compute-capability combination setup can see and asserts each tag offered
appears in a table of tag/version pairs confirmed against
download.pytorch.org. A tag whose index does not publish what setup installs
now fails locally instead of on a user's machine. Re-running it with the cu121
branch restored reproduces #644 as a test failure.

Verified: cargo fmt, clippy --tests -D warnings and test on Windows (99) and on
the Linux target via WSL (109), plus pytest (1060 passing), ruff, bandit and
the JS unit tests. Wheel availability checked live against
download.pytorch.org/whl/<tag>/ for torch, torchaudio and torchvision, cp312,
win_amd64 and linux_x86_64.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@thcp
thcp merged commit 2687fde into main Sep 21, 2026
13 checks passed
@thcp
thcp deleted the fix/cuda-wheel-tag-644 branch September 21, 2026 08:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant