Why a Perfectly Healthy V100 Gets Rejected by vLLM

Mr. Latte ∙ Software Development Expert

Somewhere in a lab or a server room there is a V100 with its fans still spinning. The card came out in 2017, it is physically fine, and it still draws power. Then you try to install vLLM, the LLM serving stack everyone reaches for now, and the install refuses outright. vLLM requires a minimum Compute Capability of 7.5, and the V100 is 7.0[1]. Nothing is broken in the hardware. The software on top of it is what says no.

The point of this piece is simple. How many more years you get out of an accelerator is decided not by the physical life of the hardware but by the end-of-life dates that upstream open source projects have set for it.

This matters right now because of cost. Bloomberg reported in August 2026 that servers built on NVIDIA chips are going up more than 15% for major customers[2]. The driver is not the compute silicon but the surge in memory prices, HBM in particular. The cost of the money to buy those servers went up too. A $3.9 billion five-year bond issued for a Microsoft data center priced at 7.228%[3][4].

With both equipment and financing more expensive, the corporate response is obvious. “Run what you already have for as long as possible.” Microsoft’s fiscal 2026 annual report shows the estimated useful life of servers and network equipment stretched to as much as six years[5]. That means spreading the purchase price across six years of expense. The problem is that a company’s books can say six years while the software ecosystem never promised any such thing.

One Version Number Decides a GPU’s Fate

NVIDIA assigns each GPU generation a version number called Compute Capability. Libraries use that number to draw a line and refuse anything below it[6].

Generation	Compute Capability	Representative card	Where it stands today
Pascal	6.x	P100	Dropped from offline build targets as of CUDA 13.0
Volta	7.0	V100	Below vLLM’s minimum, no new builds
Turing	7.5	T4	Out of the main FlashAttention repo, no bf16
Ampere	8.0	A100	No hardware FP8 compute (weight-only FP8 possible)
Ada / Hopper	8.9 / 9.0	L40S / H100	FP8 compute supported, FlashAttention-3 from Hopper on
Blackwell	10.x	B200	The architecture FlashAttention-4 targets

Support Ends in Three Steps, Not One

Hardware support does not stop all at once. It comes off in three stages.

Compiler stage (CUDA Toolkit): CUDA 13.0 dropped offline compilation support for GPUs below Compute Capability 7.5, meaning pre-Turing. If you need to keep building for those generations you have to stay on CUDA 12.9 or earlier, and driver support on the R580 branch also ends around mid-2028[7][8]. If your books say you will run Volta hardware bought in 2022 for a full six years, the last of those years runs on a combination the vendor never committed to.
Framework stage (PyTorch): PyTorch 2.8 removed Maxwell and Pascal from its distributed builds to keep binary size down. What is interesting is that the same notice brought Volta back[9]. Every project applies its own criteria, so the answer to “how long can I use this card” differs by project.
Kernel library stage (FlashAttention and friends): Attention kernels, the parts that decide LLM throughput, are the most fragmented of all. FlashAttention-2 wants Ampere or newer, 3 is Hopper only, and 4 targets Hopper and Blackwell. Turing was pushed into a separate repo and does not even get bf16[10]. A card running at all and a card running fast enough are different questions.

The Illusion Behind “Existing Binaries Still Work”

Removing support does not immediately mean the card cannot run anything. Binaries built with an older toolkit keep working exactly as before, as long as the driver allows it. The catch is that most of the serving stacks we actually use pull down packages someone else built.

When the distributor drops an architecture to keep binary size down, you end up building from source. At that moment the burden of pinning toolkit and driver versions and maintaining a dedicated CI environment lands entirely on your team.

None of this means older cards are junk. For embedding generation, reranking, and overnight batch inference, where you need neither the newest attention kernels nor low-precision compute, a T4 or a V100 still earns its keep. The question is not whether to retire the card. It is how to split the cluster’s job queues.

What Lowers Cost per Token Lives in New Silicon

Running equipment longer looks like saving money, but it can mean giving up the chance to lower your inference cost. The techniques that cut inference cost the most recently are tied to newer hardware.

By vLLM’s own numbers, FP8 compute, available on Ada and Hopper and up, halves the model’s memory requirement and raises throughput by up to 1.6x[11]. Ampere and Turing have to convert only the weights to FP8 and compute in 16-bit, an approach known as W8A16, so the actual compute does not speed up proportionally. With server memory prices spiking, there is a certain irony in the fact that the technique which halves memory consumption exists in full only on the newest GPUs.

What You Can Try Without Owning a GPU

A free Google Colab session, which often hands you a T4, is enough to build all of the following.

A dependency CC scanner: a script that reads requirements.txt or a lock file and reports the minimum Compute Capability each library demands. Put that table next to your asset register and the real software lifespan of a GPU becomes visible at a glance.
A cluster inventory checker: collect torch.cuda.get_device_capability() per node and match it against the table above to see which nodes fall off first at which library update.
A PTX fallback benchmark: when an older toolkit build does run on an older card, measure how much latency and throughput you lose against a current environment on the same prompt. Note that once driver support ends, security patches stop too, so treat production use carefully.
A generation-split queue experiment: push embedding and reranking work to the older nodes, keep generation on the newest, and measure end-to-end latency and cost efficiency.

The first and the fourth are worth trying now. Real operational data on how to split job queues across a mixed-generation cluster is still scarce. Rather than scrapping older GPUs outright or forcing the newest models onto them, the practical skill right now is reading exactly where the software has drawn its lines and placing work accordingly.