Line up two spec sheets, circle the bigger memory-bandwidth figure, and you have not compared GPUs. You have compared two marketing documents. The thing that actually runs your workload is the AI Executor — the device plus the backend plus the software that happens to be installed on that machine — and that is the unit a defensible comparison of GPU performance has to record on both sides.
The divergence point is easy to name: the moment the two machines differ in anything other than silicon. In practice they almost always do. Different driver, different CUDA or ROCm version, a model exported through TensorRT on one side and run in eager PyTorch on the other, a quantisation step applied once and not the other. Each of those moves the number, and none of them appear on a spec sheet.
What has to be recorded on both sides?
If a third party cannot re-run your comparison and land near your figures, it was not a comparison — it was an assertion. The minimum record is small enough to fit in a table row:
| Field | Why it belongs in the record |
|---|---|
| Device | The silicon, obviously — but it is one field of several, not the whole record |
| Backend | TensorRT, ONNX Runtime, ROCm, eager PyTorch — different execution paths, different numbers |
| Driver version | Kernel and scheduler behaviour changes across driver releases |
| Framework + runtime version | The same graph compiles differently across versions |
| Model artefact + precision | FP16 vs INT8 is a different workload, not a faster one |
| Load profile | Sustained throughput, not a transient burst reading |
Two numbers for the same GPU model disagreeing is the normal case, not an anomaly, and usually neither is wrong. They are measurements of two different executors that share a device name. The question “which is wrong” is the wrong question; the answerable one is “which executor tuple do I have, and which of these two records matches it”.
Where spec sheets are still fine
Bandwidth, VRAM capacity, and peak TFLOPS remain useful for elimination. If a model’s weights will not fit in memory, no software stack rescues it, and the spec sheet has told you what you needed. What specs cannot do is rank two devices that both clear the floor — at that point the software half of the executor dominates, and the comparison becomes an engine-and-port question as much as a hardware one.
Cross-vendor comparisons carry an extra hazard. Compare an NVIDIA device running a heavily tuned TensorRT engine against an AMD device running a stock export, and you have measured optimisation effort, not silicon. Either equalise the effort on both sides or state plainly that you did not.
Verify results independently
26Q3 LynxBenchAI publishes device, backend, and machine software alongside throughput figures so readers can reproduce or challenge any result instead of accepting it on faith. The free, non-commercial Personal Edition installs with pip install lynxbench-ai, so a 26Q3 comparison can be reproduced on consumer hardware you already own — details on the LynxBenchAI product page, and the measurement rules behind each number on the benchmark methodology page.
One boundary worth stating: results carry the name of the release that produced them, and figures from two different release names are not comparable against each other. The stack moved between them.
So the sharper version of the question a buyer should be asking is not “which GPU is faster” but: which executor tuple is my production deployment actually going to run, and did anybody measure that one?
