build(deps): make the torch CUDA build a uv group choice

[gdevenyi]

The problem

[tool.uv.sources] pins torch to the cu130 index unconditionally, so uv sync in a checkout can only resolve the CUDA 13 build.

CUDA 13 dropped Maxwell, Pascal and Volta. Its wheels carry no cubin below sm_75. On a pre-Turing card that resolution produces a torch that cannot address the GPU at all.

What this changes

The CUDA build becomes a group choice. cu130 stays the default, so nothing changes for anyone on supported hardware.

uv sync                                    # torch 2.11.0+cu130   (unchanged)
uv sync --no-default-groups --group cu126  # torch 2.11.0+cu126   (pre-Turing)

No version constraint moves. torch 2.11.0+cu126 exists on the pytorch index and already satisfies the torch>=2.11,<2.12 range. Its arch list is sm_50, 60, 70, 75, 80, 86 and 90, and the sm_60 cubin runs on sm_61 under CUDA's minor-version binary compatibility guarantee.

Verified against the real dependency set

130 packages resolved. All three paths checked:

$ uv export                                     | grep ^torch==
torch==2.11.0+cu130
$ uv export --no-default-groups --group cu126   | grep ^torch==
torch==2.11.0+cu126
$ uv export --group cu126 --group cu130
error: Groups `cu126` and `cu130` are incompatible with the conflicts:
       {`freetoken:cu126`, `freetoken:cu130`}

The groups are declared conflicting, so the two can never resolve into one environment. Asking for both is a clean error rather than a silent winner.

Why groups and not extras

Extras work, but every source entry then has to be disambiguated. uv rejects a list with one bare fallback entry, reporting Requirements contain conflicting indexes for package torch in all marker environments.

With extras there is no way to leave cu130 as the unconditional default, so a plain uv sync would fall back to PyPI instead of the pinned index. That changes the provenance of torch for every existing user. default-groups = ["cu130"] keeps today's behaviour exactly.

Testing

This changes dependency resolution only, so it has no unit test. The three uv export commands above are the check, and they are cheap to re-run.

[gdevenyi]

Re-tested against current main (fb7f732, i.e. after the #418 / #427 / #426 quantization refactor) on 2 x RTX 6000 Ada, TP=2 box.

Method. This PR's head merged onto main, then the full pytest tests suite. The run is CUDA-hidden (CUDA_VISIBLE_DEVICES="") on purpose: this box is serving a model on both GPUs, and with them visible 65-95 GPU tests fail on main itself with AcceleratorError: out of memory, with the count swinging ~10 between identical runs. Hiding CUDA makes the result deterministic, so a failure-set difference against main means something. Baseline: main = 1205 passed, 350 skipped, 0 failed.

Result: 1205 passed, 350 skipped, no new failures.

🤖 Generated with Claude Code

https://claude.ai/code/session_0173pf9k9fSVtwbm3f898HDt

[gdevenyi]

Closing this. It was written with heavy AI assistance, and the maintainers have indicated that do not want such contributions.

The description and the diff stay here for anyone who wants to pick the idea up.