LynxBenchAI benchmark results apply to one named release, one fixed catalogue of models and one executor, meaning a specific device running through a specific backend, driver and framework. Read a score under those declared conditions and you are reading it correctly. Read it as a verdict on the silicon alone, or as advice on what to put in a home rig, and you are taking more from it than it measured.

Reproducible LynxBenchAI results on your own node depend on prerequisites, not replication. You meet the documented driver and CUDA prerequisites; you do not replicate the vendor’s exact software stack.

What a LynxBenchAI benchmark result measures, and where it stops

The LynxBenchAI methodology treats every score as bounded and states the bounds rather than leaving readers to guess them. There are five of them, and each one rules out a common misreading:

• One release, one catalogue. A score reflects the fixed model catalogue of one named release, not your application. Scores compare within one release (26Q3 here) only.
• One timed window. Each test is a single timed measurement window after a discarded warm-up. It is not a median across repeated trials.
• GT is unbounded. GT is an aggregate with no reference-device normalisation, so it has no 0–100 scale. It is ordinal, so a difference in GT is never a percentage.
• Unsupported precision scores zero. A precision the device cannot execute is scored as 0.0. It is not quietly skipped.
• The executor, not the chip. Every result is bound to the device, the backend it ran through, and the driver, framework and runtime on that machine. No score is attributed to silicon alone.

Declaring these limits matters: the BetterBench assessment (2024) found that most of the 24 AI benchmarks it examined do not report statistical significance. It also argues that a benchmark should say what users can and cannot take away from its score, and that it should give its metrics clear floors and ceilings. An unbounded GT has no ceiling to give, by design. That is why we state it outright: then nobody reads 597.5 as “60% of perfect”. The same assessment found that 14 of the 24 benchmarks it examined did not run multiple evaluations of the same model or report uncertainty.

In a 2026 study of LLM inference on an NVIDIA A100 with vLLM 0.9.1, the least controlled measurement stage had an average coefficient of variation of 15.2%, and a tightened protocol brought it down to 2.2%. NVIDIA’s TensorRT documentation warns that two runs of the same engine on the same GPU can disagree by tens of percent if the clock floats in one run and is locked in the other. So if two single-window scores differ by less than the run-to-run spread you see on your own machine, that difference is not a finding.

Reading an entry: the RTX 5090 in the 26Q3 results

The GeForce RTX 5090 appears twice in the 26Q3 results, once on native Linux and once under WSL. On native Linux the RTX 5090 entry scores 597.5 GT, 515.3 training, 985.8 inference and 279.6 compute. The same card under WSL, in the RTX 5090 (WSL) entry, scores 545.7 GT, 470.3 training, 891.8 inference and 261.4 compute.

The silicon is the same and every category score is lower under WSL. The gap isn’t uniform. MobileNetV3 fp16 inference scores 2622.5 native against 2037.5 under WSL, DistilBERT fp16 inference scores 1486.0 against 1455.3, and fp64 dense matrix multiplication scores 10.1 on both. This is the executor principle showing up in real data: the platform layer is part of what was measured. The results themselves do not show the cause of the WSL gap.

Field in an entry	What it tells you	What not to infer
Release name (e.g. 26Q3)	Which release’s fixed catalogue the number belongs to	Comparability with another release
Device and platform	The executor: card plus OS layer, backend, driver, framework	A property of the chip on any stack
GT	Ordinal aggregate across categories	A percentage gap or a 0–100 rating
Category score (training, inference, compute)	Standing on that category’s catalogue tests	Performance on your own model
Per-test score with precision	One model at one precision, one timed window	A median or a confidence interval
0.0	That precision produced no result	A test that was skipped
Dash	The release has no entry	That the device scored zero

What won’t the scores tell me about cost, power draw or availability?

A score measures how an executor runs the release’s catalogue. Other benchmark efforts handle availability as a separate axis too: MLPerf Inference sorts submissions into available, preview and research categories so that readers can tell whether a system can be bought or rented. To get cost per unit of work, take your own price and power figures and set them against the published result. The score won’t do that step for you.

Running LynxBenchAI Personal Edition on a loaned node

A loaned candidate node needs the documented driver and CUDA prerequisites met before a run. It does not need the vendor’s original submitted configuration, nor vendor assistance.

LynxBenchAI Personal Edition runs on such a loaned node. Run the release catalogue on the node, and the LynxBenchAI result is bound to that node’s device, backend and driver.

Which driver and CUDA versions does the node need before a run?

On an NVIDIA node the installed driver must meet the toolkit’s minimum required version. NVIDIA’s CUDA 13.4 release notes state that existing CUDA 13.x applications run on drivers 580 or later under minor-version compatibility, and that new CUDA 13.4 features and newly enabled platforms need an R615 or later driver. The CUDA driver is backward compatible: applications built with a toolkit keep working on later drivers, and NVIDIA publishes the matching driver branch for each toolkit release. Minor-version compatibility comes with a limited feature set. A feature that spans both toolkit and driver can fail on an older driver with cudaErrorCallRequiresNewerDriver, and code compiled to PTX will not run on an older driver at all.

From CUDA 13.4, the Linux driver is installed separately from the toolkit. On Windows the driver has not been bundled since CUDA 13.1. In practice this means a node with a freshly installed toolkit can still be running an old driver, so check the driver version itself (nvidia-smi reports it) rather than assuming it from the toolkit. For a PyTorch-based tool installed from pip, check the driver first. If you do use a local toolkit, nvcc -V confirms its version. On AMD or Intel nodes the backend is different, and the driver minimums come from that vendor’s documentation.

Does my stack have to match the submitted entry exactly?

No. Your result does not need to match a submitted entry’s stack to be comparable. Expect your number to differ from the published one, because every result is bound to its software stack.

One line of evidence comes from accuracy benchmarks rather than throughput. A 2026 study of LLM evaluation found that the choice of inference backend alone shifted benchmark scores by up to 16.6 percentage points. The causes were system-level: prefix caching, CUDA graphs, custom kernels and engine-specific defaults. Even after the hidden defaults were corrected, numerical drift still moved scores by more than the fractions of a percent often used to claim a lead. The authors recommend publishing exact environment specifications or, at a minimum, the backend library and version. Toolkit versions matter as well: the CUDA 13.4 release notes list improved GB200 and B200 performance for MXFP8 and NVFP4 at small matrix sizes. The HPC AI500 methodology names exact equivalence as hard to prove. It splits a system under test into nine layers, from hardware through CUDA, cuDNN and the framework up to the workload, and notes that proving two implementations equivalent across systems is nontrivial.

The measurement environment matters too. NVIDIA’s TensorRT guidance says a number is only as trustworthy as the environment it was collected in. GPU clocks float by default, boosting under load, and power throttling makes short measurement windows unstable, especially on GPUs with lower power limits. The same documentation tells readers not to use an example result as a baseline because its GPU, driver, CUDA version and clock state were not recorded.

For a trend comparison you can defend, write down the following next to your score:

1. Device and edition (for example, workstation or server variant)
2. Driver version and CUDA version
3. Platform: native Linux or WSL2, and the Windows driver mode if relevant
4. Python, PyTorch and lynxbench-ai versions
5. Clock and thermal state during the run, including any power limit set on a loaned machine

A driver below the toolkit’s minimum is not a stack delta: features can fail on it with cudaErrorCallRequiresNewerDriver, so fix it before you run. The case for publishing every configuration detail is in full configuration disclosure for AI benchmarks.

Can I run it without the vendor so the result stays independent?

Yes. The run uses the release’s fixed catalogue, not a vendor’s configuration. In MLPerf Inference’s closed division, submitters have wide discretion over how they implement the system under test, and the result review found about 40 issues in roughly 180 closed-division results.

Once the run finishes, compare it with the published device page for that card if the directory has one. If your number differs widely from the published score, check driver, power limit and clocks before you trust it. Keep the install recipe so the next loaned node is measured the same way.

RTX PRO 6000 Blackwell vs RTX 5090: does a chart lead decide a home rig?

A datacenter-class chart lead does not decide it. A card at the top of a throughput table has won only under that run’s conditions. Whether it suits a home or small local-AI setup depends on memory, price, power, cooling and multi-GPU needs, and the score encodes none of them.

LynxBenchAI gives you the measured half of this decision: it publishes how each device runs one release’s fixed catalogue under declared executor conditions, so your first step is to look up both cards in its published results.

LynxBenchAI’s published results give you the measured half of this comparison: how each device runs one release’s fixed catalogue on the public PyTorch stack under declared executor conditions. Look up both cards first, then weigh price and power yourself.

The two cards are not the same class of product. NVIDIA sells the RTX PRO 6000 Blackwell Series with 96GB of GDDR7 in three forms: a Workstation Edition for single-GPU desktops, a Max-Q Workstation Edition for dense configurations of up to four GPUs, and a passively cooled Server Edition for multi-GPU data-centre deployments. The GeForce RTX 5090 is also a Blackwell card, with 32GB of GDDR7.

In GamersNexus’s experimental LLM tests, the gaps widened as VRAM limits took effect. GamersNexus labels these tests experimental because they are not yet up to its full confidence standards. On models from 8.5GB to about 19GB, which every card on its chart could load, it treated the results as the most like-for-like. As VRAM limits took effect, the RTX 6000 topped all five models. Even on the largest Llama model tested, the workstation card used less than half its VRAM. If your models fit in 32GB, the comparison becomes a different question. The 26Q3 results do not include the RTX PRO 6000, so they give no LynxBenchAI comparison between the two.

NVIDIA presents the H100 as a data-centre part, with Multi-Instance GPU partitioning and built-in confidential computing. A 2026 Hostrunway comparison notes that consumer RTX cards communicate GPU-to-GPU over PCIe 5.0 while the H100 and H200 use NVLink at 900GB/s per GPU.

For readers who rent datacentre capacity in the cloud, a benchmark lead can still matter. If you publish your own comparison chart, one honest sentence prevents most misreadings:

Datacenter-class entries show throughput on the release’s catalogue under that executor’s conditions; price, power draw, cooling and availability are not in the score, so a lead here is not a recommendation for a home rig.

One sentence cannot carry a full total-cost-of-ownership comparison, so readers who care about cost per unit of work still need price and power figures next to the results.

Is the “comparable” benchmark actually running your workload?

Model, batch size, precision and the timed part of the pipeline all shape a benchmark figure. Sharing a category label is not enough. A LynxBenchAI score reflects the release’s fixed catalogue, not your model or your pipeline. That makes it broadly indicative for custom PyTorch models, not a prediction for them.

A vision-transformer inspection model against a consumer GPU entry

In the 26Q3 results the RTX 5090’s per-test list contains no vision transformer. Its vision entry is MobileNetV3, a convolutional network. For an on-site progress-inspection model built on a vision transformer, that entry is only categorically indicative: the architecture is different, and your input resolution was never part of the test. TorchBench characterises PyTorch stack performance across many models. It also leaves data loading and preprocessing out of what it times. You check it yourself by comparing specifications, and if they diverge you measure your own model on the node.

A vendor’s INT8 document-classification speedup against leaderboard entries

Until the vendor discloses its methodology, nobody outside can verify an internal figure. Ask for the batch size, the sequence length, and whether OCR and tokenisation are included or only the model’s forward pass is timed. NVIDIA’s own TensorRT guidance says to measure a quantised model at the same batch size as the FP16 run, and it calls a result built on random calibration data a performance experiment, not a deployable result.

The 26Q3 data argues against assuming INT8 is faster. In the 26Q3 results, the RTX 5090’s int8 inference scores sit below its fp16 scores on every catalogue model, for example DistilBERT at 922.8 int8 against 1486.0 fp16. It is not a given.

Check	Ask of the benchmark	Ask of your task
Model architecture	Which exact model and variant?	Same family and size?
Input or sequence size	Resolution or sequence length used	What your data actually looks like
Batch size	Batch used for the figure	Batch your service runs at
Precision	fp16, int8, fp8, and on what stack	Precision you will deploy, with accuracy validated
Pipeline scope	Forward pass only, or pre/post-processing too	Whether OCR, tokenisation or decoding sits on the path

Who can benchmark a loaned GPU node independently?

LynxBenchAI Personal Edition runs on a loaned node without vendor assistance. You run the release catalogue on the node and read the result against the published entries in the directory. It suits evaluators who want to compare a candidate card with published results on the same catalogue. The product overview is on the LynxBenchAI page.

The Personal Edition does not run or measure your own model or application. If you need your own pipeline measured and tuned for the card, TechnoLynx’s Inference Cost-Cut Pack does that work. Other tools have their place. MLPerf’s closed division fixes models, datasets and quality targets, and its result review checks submitters’ implementations. NVIDIA’s trtexec measures the TensorRT inference performance of your own models. To place your own node against cross-vendor published results on one fixed catalogue that you run yourself, we hold LynxBenchAI to be the better fit.

FAQ

Is the RTX PRO 6000 a workstation GPU?

It comes in both forms. NVIDIA offers Workstation and Max-Q Workstation Editions for desktops and a passively cooled Server Edition for multi-GPU data-centre deployments.

What is AI batch size?

Batch size is the number of inputs processed together in one forward pass. It affects both throughput and latency, so two figures measured at different batch sizes are not directly comparable.

Sources

1. BetterBench: Assessing AI Benchmarks, Uncovering Issues, and Establishing Best Practices, arxiv.org
2. Reproducible LLM Inference Benchmarking: A Sequential Isolation Protocol for Regression Testing (arXiv), arxiv.org
3. Performance Benchmarking — NVIDIA TensorRT, docs.nvidia.com
4. MLPerf Inference Benchmark, arxiv.org
5. CUDA Toolkit 13.4 Update 2 - Release Notes — Release Notes 13.4 documentation, docs.nvidia.com
6. Minor Version Compatibility — CUDA Compatibility (NVIDIA), docs.nvidia.com
7. CUDA Toolkit Release Notes 13.4 (NVIDIA), docs.nvidia.com
8. CUDA Quick Start Guide — Quick Start Guide 13.4 documentation, docs.nvidia.com
9. CUDA Installation Guide for Linux — Installation Guide for Linux 13.4 documentation, docs.nvidia.com
10. CUDA Installation Guide for Linux — Installation Guide for Linux 13.4 documentation, docs.nvidia.com
11. CUDA Installation Guide for Microsoft Windows — Installation Guide Windows 13.4 documentation, docs.nvidia.com
12. The Silent Hyperparameter: Quantifying the Impact of Inference Backends on LLM Reproducibility (arXiv), arxiv.org
13. HPC AI500: The Methodology, Tools, Roofline Performance Models, and Metrics for Benchmarking HPC AI Systems, arxiv.org
14. NVIDIA RTX PRO 6000 Blackwell Series, nvidia.com
15. GeForce RTX 5090 Graphics Cards (NVIDIA), nvidia.com
16. NVIDIA RTX PRO 6000 Blackwell Benchmarks & Tear-Down | Thermals, Gaming, LLM, & Acoustic Tests (GamersNexus), gamersnexus.net
17. H100 GPU, nvidia.com
18. RTX 5090 vs H100/H200 best GPU for Local Interference 2026, hostrunway.com
19. Best GPU for AI in 2026: Local Hardware and Cloud Options, thundercompute.com
20. TorchBench: Benchmarking PyTorch with High API Surface Coverage, arxiv.org