Publish wheels for torch 2.11 / 2.12 / 2.13 — the PyPI matrix has been pinned at 2.10 since February

TL;DR: Would you be open to publish wheels for recent torch versions?

Many thanks for the amazing work! I'm happy to hand in the (mini) PR for the above ask, if you prefer me to hand in a PR instead of "just" an issue.

Note: Claude-assisted context and concrete steps below:

Summary

.github/workflows/publish.yaml hardcodes the PyPI torch build matrix:

torch-version: ["2.6.0", "2.7.1", "2.8.0", "2.9.1", "2.10.0"]

torch has shipped three minor releases past that since:

The most recent release, v2.3.2.post1 (2026-05-09), still built against 2.10.0 as its ceiling — torch 2.11.0 was already seven weeks old at that point. So this isn't "a release hasn't been cut lately"; the matrix itself is the thing that has gone stale, and cutting a release without touching it wouldn't change anything.

Why it matters downstream

PyPI carries only sdists for mamba-ssm and causal-conv1d, so anyone whose resolver lands on torch >= 2.11 silently falls off the wheel path and compiles the CUDA kernels from source. On our side that is 15–35 minutes on a 48-core box, and considerably worse on the ~9-vCPU instances that are usually what's actually available to rent. It is also a silent fallback — no warning that a wheel was missed, the only symptom is half an hour of apparent hang.

Because a plain torch>=2.x constraint floats to the newest release, this is the default outcome for anyone not explicitly pinning. We ended up adding a hard ceiling to work around it:

# pyproject.toml
"torch>=2.9,<2.11",   # upper bound only because prebuilt mamba-ssm wheels stop at 2.10

[tool.uv.sources]
mamba-ssm = [{ url = "https://github.com/state-spaces/mamba/releases/download/v2.3.2.post1/mamba_ssm-2.3.2.post1+cu12torch2.10cxx11abiTRUE-cp312-cp312-linux_x86_64.whl" }]
causal-conv1d = [{ url = "https://github.com/Dao-AILab/causal-conv1d/releases/download/v1.6.2.post1/causal_conv1d-1.6.2.post1+cu12torch2.10cxx11abiTRUE-cp312-cp312-linux_x86_64.whl" }]

That works — we verified the full test suite on an A40 with torch 2.10.0+cu126 / triton 3.6.0 — but it pins every downstream consumer to the last torch you happened to build for, which isn't a great steady state for either side.

(The cu13torch25.11 … cu13torch26.04 NGC wheels don't substitute here: they're tagged by container version and built against NGC's torch, so they can't be resolved against a PyPI torch.)

The odd part: you already solve this for NGC

The NGC lane doesn't hardcode anything. .github/scripts/check_for_ngc_images.sh walks the last 7 months of nvcr.io/nvidia/pytorch:YY.MM-py3, probes each with docker manifest inspect, and emits whatever exists as JSON for build_ngc_wheels. That's why the latest release has wheels up to torch26.04 while the PyPI lane stopped at 2.10.

So the repo already has the "discover current versions at build time" pattern — it just isn't applied to the lane most users install from.

Proposed change

Minimal version, literal:

-        torch-version: ["2.6.0", "2.7.1", "2.8.0", "2.9.1", "2.10.0"]
+        torch-version: ["2.6.0", "2.7.1", "2.8.0", "2.9.1", "2.10.0", "2.11.0", "2.12.1", "2.13.0"]

         exclude:
           # CUDA 11.8 is not supported by PyTorch 2.8+
           - torch-version: "2.8.0"
             cuda-version: "11.8.0"
           - torch-version: "2.9.1"
             cuda-version: "11.8.0"
           - torch-version: "2.10.0"
             cuda-version: "11.8.0"
+          - torch-version: "2.11.0"
+            cuda-version: "11.8.0"
+          - torch-version: "2.12.1"
+            cuda-version: "11.8.0"
+          - torch-version: "2.13.0"
+            cuda-version: "11.8.0"

plus a release cut, since wheels are only built on tag.

On matrix cost: this is the obvious objection — three more torch versions is roughly a 60% larger build, and the matrix is already 2 os × 4 python × 5 torch × 3 cuda × 2 abi minus excludes. If that's the blocker, dropping 2.6.0 and 2.7.1 would add the three current versions at lower total cost than today. Both are over a year old and neither can use CUDA 13; anyone still on them can install from the existing v2.3.1/v2.3.2 release assets, which don't disappear.

Or, the durable fix: apply the NGC lane's approach to the PyPI lane — query the torch PyPI JSON API for the last N minor releases and build the matrix from that, so this stops recurring. Happy to write that if it's the direction you'd prefer; it's a small script and it mirrors check_for_ngc_images.sh closely.

Offer

I'm glad to send a PR for whichever of the three you'd take — the literal matrix bump, the bump-plus-drop-old, or the dynamic version. The matrix edit is trivial; the part only you can do is cutting the release that actually publishes the assets, so it seemed worth asking before opening a PR that can't land on its own.

Thanks for maintaining these — the prebuilt wheels save a lot of time when they match, which is exactly why the gap is noticeable.