A card name is a field in a record, not a score. When a LynxBenchAI result carries “RTX 6000 Pro”, the number beside it belongs to the whole executor that produced it: the device, the backend it ran through (cuda for an NVIDIA part), and the driver, framework and runtime present on that machine. Read the name as shorthand for that tuple and comparisons stay honest. Read it as an identifier that owns the number and the first side-by-side comparison you make will be wrong.
The two readings agree until someone stacks results. That is the divergence point — a vendor spec figure placed next to a measured one, or two measured numbers from differently configured machines treated as commensurable because the silicon matched.
What does the card name actually specify?
It fixes the hardware half and leaves the software half open. Memory capacity, board variant, silicon generation — those travel with the card. Kernel selection, graph compilation behaviour, precision handling and scheduler behaviour do not; they come from the CUDA driver, the framework build and the inference runtime installed on the machine. Two boxes with the same card and different stacks are two different AI Executors, and LynxBenchAI measures executors rather than silicon.
This is why a vendor figure and a measured figure for the same card can disagree without either being false. They describe different executors. The vendor number was produced under a software configuration that usually goes unstated; a published run record states it.
What a result records
| Field | Belongs to | Why it is in the result, not the metadata |
|---|---|---|
| Device (e.g. RTX 6000 Pro, desktop or Max-Q variant) | Hardware | Variants differ in sustained power and thermal envelope, so the variant is part of the executor |
Backend (cuda) |
Hardware/software boundary | Determines which execution path the workload actually took |
| Driver version | Software | Changes kernel availability and scheduling between releases |
| Framework and build | Software | Decides which operator implementations run |
| Runtime / inference engine | Software | Often the largest single lever on measured throughput |
| Memory capacity (e.g. 96GB) | Hardware | Bounds what fits; predicts nothing about throughput once the model fits |
Capacity is the field readers most often over-read. A 96GB figure tells you which models and batch sizes are feasible. It stops being predictive the moment the workload fits — after that, throughput is an executor question.
Using this when you are shopping
Treat “RTX 6000 Pro vs H100” or “vs 5090” as two questions wearing one coat. The hardware question — memory ceiling, form factor, power envelope — is answerable from the card. The performance question is not; it is answerable only against a stated stack, on your workload. Price and availability listings move on their own schedule and should be sequenced after you have a reproducible number, not before.
Reproducing a published result means holding the recorded tuple constant, not just buying the same board. pip install lynxbench-ai puts the Personal Edition on ordinary consumer hardware, so checking a claimed figure costs a local run rather than a purchase. The reasoning behind treating the executor as the unit of measurement is developed in the LynxBenchAI product overview.
So the question to carry into a procurement conversation is not which card is faster, but which executor — card, driver, framework, runtime — the number you are being shown was produced on, and whether you can run it yourself.
