RFC: Deprecation timeline for CUDA 12

[hawkinsp]

As of JAX 0.7.2 we have started shipping support for CUDA 13 (in parallel with our previous support for CUDA 12)

We do not want to maintain support for both versions of CUDA indefinitely, because:

• this doubles the number of GPU builds and tests,
• this adds another configuration we need to think about and support
  and hence we need to plan for when we stop shipping CUDA 12

The most likely pain points are probably

• CUDA 13 drops support for Maxwell, Volta, and Pascal architectures (https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html#deprecated-architectures).
• CUDA 13 drops support for Ubuntu 20.04-era Linux distributions.

Tentatively, we are thinking of dropping support for CUDA 12 around 6 months from now, i.e., March-April 2026.

Comments? Feedback?

[PhilipVinc]

From my point of view (Academic, using EU HPC resources) it's easy to still access Volta GPUs (V100s) which we use from time to time for easy prototyping. We don't run any more serious calculations there, as they are slow/little memory, but they are handy for experiments, CI... etc as we don't really compete for access to them.

If Jax was not evolving at a rapid pace, it would be fair for me to test my downstream code with both newer and older jax versions.
However in recent months (0.5 -> 0.7) jax has evolved a lot in a way that is hard to maintain backwards compatibility (PositionalSharding removed, explicit sharding...). In a positive way! but still, we dropped jax <0.7 because it was hard to support both.

In an ideal world I'd wish Santa Claus the beloved Jax team to drop support for CUDA 12 at a point where the releases in the following ~6 months are not 'seismic changes', such that I can keep running my codes on older jax versions with a reasonable effort.
This would effectively give us 1 more year of Volta usage, which would be welcome.

[I understand that this might be a hard ask and/or difficult to plan]

[hawkinsp]

Can you say how long you would want support? Obviously "forever" is a possible answer, but it becomes an increasingly large amount of work for a small fraction of the users.

V100s don't have a good perf/TCO compared to newer GPUs, and they must be getting towards the end of any realistic depreciation schedule.

I don't think we can promise not to keep trying to improve JAX :-) That said, we certainly are trying fairly hard to remove some older features and add new ones: we think that pays off in a simpler more pleasant API for everyone. And we are trying to be fairly careful about the frequency of these breakages; currently every 3 months.

[PhilipVinc]

Ideally? 1 year from now. (Because European researchers will get 2 new 'big' HPC H200 machines in the next ~12 months, which should hopefully free up some A100 capacity for running CI/interactive tests).

But as I said, there's less and less people using V100s for research (On French HPC centers, where I have data, A100s are oversubscribed by a factor of 2.5x but V100s are vacant at ~30%). We use it for interactive experiments/testing out code. So it's not an high priority use case.

If I had to pick between CUDA and GLIBC, Volta support is much less priority than older GLIBC support in my view, because bumping GLIBC would impede me from using the largest HPC centers where I work on, while dropping Volta would have been annoying but I can work around it.

[cjchristopher]

Just to chime in here from an Australian perspective - one of our largest (if not the largest) infrastructures - the NCI's gadi - primarily provides V100s for GPU compute, with only a few A100s available - so for our research community I suspect maintaining support for CUDA 12 a bit longer would be desirable - but I absolutely can't speak to how many might be using jax on it.