A listed GPU still needs a compatible build and driver

Original research record

A listed GPU still needs a compatible build and driver

We connect a new vLLM build requirement with two XLA changes. vLLM now checks for GCC 13 when building CUDA code with GNU tools. XLA checks whether the driver can accept a requested GPU target, while a separate change adds early Vera Rubin target data. These are different readiness checks. A GPU appearing in source code does not establish that a chosen build, driver and workload work together.

We see a practical gap between a GPU being named in software and a job being ready to run. In vLLM, two dependencies use a C++ feature that the checked source says needs GCC 13. The new build check stops CUDA source builds with an older GNU compiler and explains the problem. This makes an existing dependency limit explicit; it does not show that previously working deployments have suddenly broken. [vLLM change](https://github.com/vllm-project/vllm/commit/242e4213fc9845ff6fe607af1aee626fd8acc990)

XLA addresses a different step. Its driver-based compilation path can request an accelerated GPU target that an older driver does not understand. The new code checks the driver version and returns a clearer unsupported-target error before constructing that target. It does not make an old driver support the target. [XLA driver check](https://github.com/openxla/xla/commit/d8d007fa6fa1b9d4ca27360f8a7611740d55f10d)

A separate XLA change adds the first part of Vera Rubin NVL72 target support, including target data and checks that the data can be read. Its author reports unit tests, but no execution tests or performance benchmark. We connect these records as three separate questions: can the software be built, can the driver compile for the target, and has the actual workload run? The two XLA changes share one project; they are not independent proof of deployment readiness. [XLA target data](https://github.com/openxla/xla/commit/f885ba6e8eae40fe5ab76476e01a004e02f95032)

Key points We distinguish a CUDA source build using GNU GCC/G++ from installing a prebuilt package. The new vLLM condition rejects GNU compiler versions below 13; it is not a requirement that every user rebuild or replace a GPU. We read the XLA version guard: its CUDA driver API minimum is 12.0 for the checked 9.0 accelerated target, 12.8 for 10.0, 10.1 and 12.0, and 12.9 for other accelerated targets in this branch. These are API-version checks, not NVIDIA operating-system driver package numbers or a complete compatibility table. We verified new Rubin target records and their unit-test definitions. The author explicitly states that this change has no execution test or benchmark. We do not turn the stored hardware numbers into measured OTR performance. We would record the exact software revision, compiler, driver and target, then test a small representative workload. Passing one check cannot replace the others.

What could change this view? We would narrow this view where teams use compatible prebuilt packages or do not use the affected XLA driver-compilation path. vLLM’s documentation says its default Ubuntu 24.04 image already ships GCC 13, so many such builds may already meet the compiler floor. The patches improve an explicit check and diagnostic; they do not measure how many users were affected. We have not run these builds or verified which released versions contain the changes. Rubin may have validation elsewhere, but this particular change supplies no execution result.

Bottom line We would check the compiler and driver before treating a newly listed GPU as ready for a workload. Record a real build and run on the intended setup. The useful output is a tested configuration, not a blanket hardware-support claim.

How likely is this call? · Three frameworks This signal has no investible bullish or bearish call. A market-direction percentage does not apply. Bayesian · what changed the estimate? We add exact source evidence about two compatibility checks and an early target description. We have no fitted prior or likelihood for deployment success, so no numerical update is made. de Finetti · are the comparisons fair? A source build, a driver compilation request and a target-data test are different trials; we do not pool them into a success rate. The two XLA records share one publisher. Kolmogorov · do the numbers agree? We propose no market-return event partition or percentages. Compiler versions, driver API versions and hardware target numbers are different quantities, not probabilities. Horizon, deadline, market neutral band and price basis: Not applicable. Research gaps: containing releases, independent build tests and representative workload results. Read the shared method: https://new.ontherice.org/how-otr-works/#probability-framework.

Evidence behind this view We connect OTR Database Data Technology attempts 92 and 93, then reopen three exact first-party commits. XLA’s first Rubin target data was committed at 15:59:31 UTC on 8 October; its driver guard at 16:22:51; vLLM’s compiler requirement at 16:43:39. They form two project-origin clusters. These events predate our prior edition cutoff but were not used in its published cards. Their new connection concerns build and driver prerequisites, rather than a newly announced GPU shipment.

What past price moves show Not applicable to market prices. Earlier OTR cards covered local-device model loading and memory limits, plus an XLA plan that stored the wrong device-specific memory property. We preserve those records. This view adds a distinct pre-execution mechanism: the chosen compiler may lack a dependency feature, or the driver may reject a target even when the GPU family is named in source.

Evidence against this view We would narrow this view where teams use compatible prebuilt packages or do not use the affected XLA driver-compilation path. vLLM’s documentation says its default Ubuntu 24.04 image already ships GCC 13, so many such builds may already meet the compiler floor. The patches improve an explicit check and diagnostic; they do not measure how many users were affected. We have not run these builds or verified which released versions contain the changes. Rubin may have validation elsewhere, but this particular change supplies no execution result.

Why the direction changed No investment direction applies and no locked forecast changes. We add newly connected evidence with its real repository clocks. This is not a claim that the changes occurred after the last OTR issue. A new code record, its containing software release and a successful workload remain different events.

What people say vs the facts We have not collected a representative developer-discussion or deployment sample for this card. The source changes document specific compatibility boundaries. They do not establish rising GPU failure rates, broad demand, customer losses or a need for every user to upgrade.

How past forecasts performed No matched set of resolved OTR forecasts estimates success for these configurations. We give no accuracy percentage, deployment-failure rate or expected cost saving. The source includes unit-test definitions, but reading them is not executing them. Market-price outcomes and investment performance do not apply.