A GPU stress test on Linux, such as gpu_burn on the accelerator with stress-ng on the host, is built to show whether a machine survives heavy, sustained work without crashing, overheating or returning bad results. It does not tell you which AI hardware to buy. To rank candidates you need a different kind of evidence: a measurement of the AI Executor, meaning the device together with the backend, driver, framework and runtime it runs through, with the telemetry and power readings kept alongside the score. A burn run that stays cool and stable is reassuring. It is not a ranking, and putting it in a procurement file as one confuses two separate questions.

What a GPU stress test on Linux proves, and where it stops

stress-ng was designed to exercise a computer’s physical subsystems and kernel interfaces, and to make a machine work hard enough to trip faults such as thermal overruns and operating-system bugs that only show up under heavy load. It can report throughput rates, but its manual says plainly that it was never intended as a precise benchmark suite and should not be used as one. Its bogo-operation counts are described as not a reliable measure of performance or throughput. Its stressor classes cover CPU, cache, memory, I/O, network, scheduler and similar subsystems, and the manual states that stress-ng has no GPU stress tests at all.

gpu_burn is a multi-GPU CUDA stress test, which covers the GPU side that stress-ng does not. It forks one process per GPU, allocates a large share of the card’s memory and runs continuous CUBLAS matrix multiplications while checking that the results are correct. Its options set memory use (in MB or as a percentage), switch to doubles, try to use Tensor Cores and pick a single GPU, and it takes the run time as a trailing argument. FIRESTARTER’s authors describe what processor stress tests are for: they target maximum power consumption and are typically used to test the cooling and electrical infrastructure of compute nodes or larger systems.

So why will none of these produce procurement-grade evidence for an AI workload? A comparison between GPUs depends on the workload chosen, the precision evaluated, the software stack on each candidate and the saturation conditions held constant, and changing any of those can reverse the result. gpu_burn runs one kind of kernel, continuous matrix multiplications, and checks the results for correctness. A 2025 study that measured GPU stress through telemetry and performance counters used GPU-Burn as its push-to-the-limit case, and found that CNN inference workloads put only moderate stress on the same GPU. In that laptop-GPU study the burn was the extreme case; a ranking has to reflect where your own workload sits.

A burn run’s power draw is a ceiling, not a forecast

A 2024 study at Brookhaven National Laboratory measured an 8-GPU NVIDIA H100 HGX node during real training runs and during a combined GPU and CPU burn. The burn’s median node power was 8.43 kW, only about 400 W above the 7.92 kW median of a Llama2-13b training run. A GPU-only burn sat at 7.97 kW. ResNet training on the same node drew a median of 4.68 kW at batch size 512 and 6.26 kW at batch size 4096. For the smaller-batch ResNet run, the burn therefore overstated node power by 3.75 kW (8.43 minus 4.68).

On that node the burn sat close to Llama2-13b training power and far above small-batch ResNet training power. The same study also found its highest observed draw, about 8.4 kW, to be 18% below the manufacturer-rated 10.2 kW. The rating did not predict the power either. The authors caution that their figures belong to one combination of IT and cooling hardware and may not generalise. Use burn power to size power supplies, rack feeds and cooling against a worst case. Plan energy from the workload’s own measured draw.

Which Linux telemetry to keep during a sustained run

Telemetry records how load turns into heat, power and clock behaviour. The 2025 stress study read sensor data through NVML and sampled telemetry once a second during each run. Separately, the DCGM documentation names fields for temperature, power, throttling and errors on NVIDIA hardware, and amd-smi monitor has flags for most of them. The table maps one to the other.

Evidence to keep	NVIDIA (DCGM field)	AMD (amd-smi monitor)
Temperature and headroom	DCGM_FI_DEV_GPU_TEMP_CELSIUS (150); DCGM_FI_DEV_GPU_TEMP_MARGIN_CELSIUS (153), the distance to the nearest slowdown threshold	-t / --temperature
Power	DCGM_FI_DEV_BOARD_POWER_WATTS (155); instantaneous DCGM_FI_DEV_BOARD_POWER_RAW_WATTS (157)	-p / --power-usage, with power cap
Energy over the run	cumulative GPU energy in joules since the driver was last reloaded	no energy option among the monitor flags cited here
Time spent throttled	DCGM_FI_DEV_GPU_POWER_THROTTLE_SECONDS_TOTAL and DCGM_FI_DEV_GPU_THERMAL_THROTTLE_SECONDS_TOTAL, which replace the deprecated violation fields 240 and 241	-V / --violation, power and thermal violation status
Why it throttled	clock-event reasons for software power cap (1420), software thermal slowdown (1422) and hardware thermal slowdown (1423)	not covered in the cited options
Errors	DCGM_FI_DEV_XID_ERROR (230); retired pages and row-remap counters	-e / --ecc, ECC and PCIe replay counts
Engine activity	DCGM_FI_PROF_GR_ENGINE_UTIL_RATIO (1001); the 0-100 DCGM_FI_DEV_GPU_UTIL is deprecated in favour of DCGM_FI_DEV_GPU_UTIL_RATIO	-u / --gfx and -m / --mem

A hardware slowdown entry means the core clocks were cut by a factor of two or more, because of high temperature, an external power-brake signal from the power supply, or power draw tripping fast protection. On AMD, amd-smi monitor --watch 1 --watch_time 120 keeps sampling for a set duration, and --csv or --json with --file writes the result to disk. Record the AMD SMI and driver versions as well. When the amdgpu driver is a release cycle newer than the installed AMD SMI, fields such as violations and socket power read N/A, a mismatch that ROCm 7.13 and later no longer suffer from. For the host CPU, stress-ng’s --tz option collects temperatures from the Linux thermal zones. For deeper work on sustained thermal and power behaviour, see our piece on thermal and power profiling under real load.

How long should an AI hardware stress test run on Linux?

Run it until the device reaches thermal steady state, then keep it there long enough to see whether the throttle counters keep climbing. A minute count copied from elsewhere is not the criterion. The 2025 stress study defines two stress metrics: the time taken to reach a steady-state temperature, and the average temperature once there. The FIRESTARTER authors ran 240-second tests and threw away the first 120 seconds before measuring.

A procurement-grade run measures time-to-steady-state on each candidate as installed, keeps going well beyond it, and stores the duration with the telemetry so a reviewer can see that the hold period covered the throttling window. Acceptance burn-in before a machine goes into service is a separate exercise with its own length, set by how much risk the site will accept.

What does a defensible AI hardware shortlist actually contain: a part number, or the device together with the backend, driver, framework and runtime it will run through?

A defensible shortlist entry names the AI Executor: the device, the backend it runs through (cuda for NVIDIA, cuda via ROCm for AMD, xpu for Intel, or CPU), and the driver, framework and runtime installed on that machine. A part number alone leaves out the software stack, and the comparison changes with the stack.

The backend string is a good example of why every layer needs naming. PyTorch for HIP deliberately reuses the existing torch.cuda interfaces so that CUDA code ports with few changes, if any. A run log reading “cuda” therefore does not, on its own, tell you the hardware was NVIDIA. ROCm and the HIP version have to be recorded beside it. On Intel, PyTorch 2.5 brought prototype support for Intel Client GPUs and Data Center GPU Max Series into official PyTorch on Linux and Windows, with training, inference, eager mode, torch.compile, FP32, BF16, FP16 and AMP supported. Choosing the compute API is where workload dependence lands on the software half of the executor; our comparison of CUDA, OpenCL and SYCL as GPU compute APIs goes into that choice.

Platform counts as well. In the 26Q3 results, the NVIDIA GeForce RTX 3080 appears as two executors: on native Linux it has Inference 240.5 and Compute 64.8, and under WSL it has Inference 231.7 and Compute 72.5. The differences run in both directions, and each test is a single timed window rather than a median of repeats, so small gaps should not be over-read. What the two rows do show is that the release records each stack separately, and so should your shortlist.

Can NVIDIA, AMD, Intel and CPU candidates be compared on the same footing?

Yes, provided one instrument runs the same work under the same rules on every candidate. Taking each vendor’s preferred test on its preferred workload and placing the results side by side does not meet that bar. LynxBenchAI runs one catalogue on NVIDIA GPUs (cuda), AMD GPUs (cuda via ROCm), Intel GPUs (xpu) and CPUs, and applies the same bounded optimisation to all of them. The 26Q3 results show what that looks like in practice: native-Linux executors from NVIDIA, AMD (the Instinct MI300X and the Radeon RX 9060 XT), Intel (integrated graphics in a Core Ultra 7 165U) and a CPU (the AMD Ryzen 5 9600X) sit in one table on one scale.

Telemetry is still vendor-specific, with DCGM on one side and amd-smi on the other. What has to come from a single instrument is the performance measurement.

Is the accelerator worth it over the CPU we already own?

Because CPUs run the same catalogue under the same rules, “is the accelerator worth it over the CPU we own” becomes something you can measure instead of argue. In the 26Q3 results, the AMD Ryzen 5 9600X scores Training 8.6, Inference 2.7 and Compute 6.3 on native Linux. Its inference score also swings sharply with precision: MobileNetV3 inference scores 2.6 at fp16 and 13.8 at int8. A CPU’s verdict depends heavily on which precision path your deployment will actually use.

CPU inference is still a reasonable choice when the inference is light or intermittent, when latency is dominated by things other than compute, or when the power, cost and operational burden of an accelerator would not be repaid by the throughput it adds. The way to settle it is not a rule of thumb. Measure the CPU you already own as an executor, measure the candidate accelerator the same way, and set the gap against what the accelerator costs to buy and run.

Inside LynxBenchAI: one instrument across the shortlist

LynxBenchAI is a performance measurement, not a burn-in or stress test. It measures sustained performance: for each test it discards a warm-up phase, then counts completed iterations inside a continuous timed window, at a workload size already scaled until throughput stops improving. Every device in a release runs the same catalogue under the same bounded optimisation. A laptop GPU and a data-centre accelerator are each measured at their own saturation point. A run reports four scores: Training, Inference and Compute, plus GT, an overall figure aggregated from them.

Category scores can order the same candidates differently. In the 26Q3 results, the NVIDIA GeForce RTX 5060 Ti scores higher in Training (133.2 against 37.2) and in Inference (240.4 against 122.7 on the LynxBenchAI 26Q3 Index), while the AMD Radeon RX 9060 XT scores higher in Compute (112.7 against 61.7). GT is an ordinal aggregate with no reference-device normalisation, so the two cards’ GT values (146.4 and 76.3) show an order, not a percentage gap. Scores are comparable within 26Q3 only.

Runs submit automatically to a public leaderboard, so a claim about a device can be checked against other people’s runs made with the same instrument under the same release, and a device that has no runs is itself useful information. A result covers the fixed catalogue of one named release, not your organisation’s application.

Measuring a candidate before you commit to it takes an afternoon. Run pip install lynxbench-ai on Python 3.11 or later, on Linux or on Windows via WSL2. A run needs about 15 GB of free disk, downloads about 2 GB of model data once, and takes 15 to 30 minutes. The Personal Edition is released and free for non-commercial use, and the Press, Pro and Enterprise editions are not released and are contact-gated. You can install the Personal Edition on the machine already on your desk.

How should Training, Inference and Compute scores be weighted for the work we run?

Weight them by the class of work your organisation actually runs, and do not collapse them into a single fastest-device ranking. Each category score is meant to be read on its own as how well that executor handles that class of work. An inference-serving shortlist orders by Inference, and a training cluster by Training. Where the work is mixed, weight each category by its share of the hours the hardware will spend, and write the weights down as an assumption rather than presenting them as objective.

The order changes with the category. In the 26Q3 results, the NVIDIA H100 80GB HBM3 scores higher in Inference (1678.1 against 1304.0), while the AMD Instinct MI300X scores higher in Compute (1023.3 against 487.1) and in Training (727.2 against 709.3). Precision moves things within a category too: the RX 9060 XT’s DistilBERT training score is 15.3 at fp32 and 95.5 at bf16. Read the per-test scores at the precision you plan to deploy.

Can a bounded catalogue run replace the sustained, workload-faithful test?

No. The two answer different questions, and a procurement file needs both. The catalogue run gives comparability: the same catalogue and the same bounded optimisation on every candidate, rather than each vendor’s preferred test. A workload-faithful run gives fidelity: your model, your batch and latency limits, your data path, held for hours on the one stack you will deploy.

Use the catalogue to narrow the field, then run your own workload under sustained load on the finalists. For that second phase, see our piece on what sustained GPU load reveals for AI.

How do we derive hardware requirements for our own AI workload instead of a published minimum?

Start from the workload, not from a vendor’s minimum. A published minimum specification is not a performance target. It says nothing about whether you will meet your throughput or latency target at the concurrency you plan to serve. Work out the class of work, the precision you will deploy at, the memory footprint of the model plus its batch or context, the throughput or latency target, and the power and rack envelope you have. Then map those onto category scores and per-precision results.

Precision support can rule a candidate out before speed comes into it. In the 26Q3 results, the NVIDIA A100-SXM4-80GB records 0.0 for every fp8 inference test, which means that precision produced no result on that executor. If your serving plan depends on fp8, that row rules the executor out for that plan, however it scores elsewhere. Software readiness on the target accelerator is its own question, covered in our readiness guide for on-premise accelerators, and turning requirements into cost per request is the subject of spec-ing the compute behind a production AI feature.

How should an AI hardware evaluation be structured beyond headline numbers?

Structure it as layers of evidence, each answering one question, and be clear about what each layer cannot answer. Every layer rests on assumptions (the workload mix, the precision, the stack versions), and a defensible evaluation states them instead of claiming to be objective.

Evidence layer	What it answers	What it cannot tell you
Specification sheet	What the vendor rates the device at	Real power draw; the H100 node above peaked 18% below its rated power
Stress test with kept telemetry	Whether the machine survives sustained load without faults or overheating; an upper bound on power	A precise benchmark ranking; the power of a lighter workload
Catalogue measurement of each executor	How candidates order on Training, Inference and Compute under identical rules	How your own application will perform
Public leaderboard population	Whether other runs under the same release back up a device’s result, or whether it has none	Your specific stack and chassis
Sustained run of your own workload on finalists	Fidelity to the thing you will deploy	A comparison of candidates under one set of rules
Commercial review	Cost, availability, lead time, support, power envelope	Nothing about performance; no benchmark sees these

The table is the frame. Our broader decision framework for choosing AI hardware places it in the wider selection process, and how benchmarks mislead procurement covers the misreadings that layering is meant to prevent.

How should the stress-test result feed into the procurement decision?

As a gate and a constraint, never as a score. The gate is pass or fail: no XID errors, no growth in ECC, retired-page or row-remap counters, and no correctness failures from gpu_burn’s result checks. The constraint is the burn’s power ceiling, which goes into power-supply, rack and cooling sizing. A candidate that fails the gate drops out, however well it scores. One that passes moves on to be judged on its executor measurement, in the category your work needs.

The real procurement decision comes after that. The candidate that scores higher in your category still has to fit your power envelope, availability and budget. None of that appears in a benchmark. Benchmarks inform that trade-off but do not decide it; good evidence makes it visible and states its assumptions. Once the hardware is in place, making workloads faster and cheaper on it is the territory of TechnoLynx’s GPU performance engineering. When the hardware is already bought and the cost still has to come down, porting inference across runtimes and hardware is how a selection decision continues after purchase.