A spec sheet settles what the silicon is capable of in principle. It does not settle what your machine will measure. When a benchmark figure is labelled “MI300X”, the card is only half of what produced it — the other half is the backend, driver, framework and runtime that were present on the machine when the number was taken.
That distinction is not pedantry. It is the reason two MI300X boxes running the same prepared model artefact can report different numbers while nothing about the hardware differs.
What is actually being measured when a result says “MI300X”?
Performance lives in the executor—device plus software stack combined. On AMD hardware, PyTorch keeps its familiar cuda device surface and ROCm sits underneath it, which means code that looks device-agnostic is in fact bound to a specific ROCm build at runtime. Upgrade ROCm, or swap the framework wheel, and the same artefact meets a different executor. The number moves; the card is untouched.
This is why we treat an MI300X figure without its stack as an unattributable scalar. It cannot be reproduced, and it cannot be compared — not because the measurement was careless, but because the label omits half the subject.
What the datasheet settles, and what it leaves open
| Question | Settled by the spec sheet | Settled only by measurement |
|---|---|---|
| Memory capacity and interconnect topology | Yes | — |
| Peak theoretical throughput at a given precision | Yes | — |
| Throughput your model actually sustains | No | Yes — and only for the recorded stack |
| Effect of a ROCm or framework upgrade | No | Yes — re-run required |
| Settled clocks under sustained load | No | Yes — requires a thermally settled run |
| Comparability with another vendor’s part | No | Only if both sides record their full executor |
This yields two consequences. First, the datasheet is a bound on the possible, not a prediction of the observed. Second, a cross-vendor comparison is readable only when both sides publish the device and the stack, and when optimization effort was held equal by shipping the same prepared model artefact to each — rather than hand-tuning one side.
The minimum record for an MI300X figure
Record:
- Device — the exact part, not the family name.
- Backend — ROCm version, as reported by the runtime, not as installed by intent.
- Framework build — the specific PyTorch wheel, since the ROCm-linked build differs from the NVIDIA one.
- Driver and runtime present on the machine.
- Release name of the benchmark run.
The last item is the one most often dropped. Comparability is scoped to a single release name: a 26Q3 MI300X record is comparable to other 26Q3 records, and not to figures carrying a different release name. That scoping is what lets a team re-run after an upgrade and attribute the delta to the software half instead of re-opening the hardware decision.
Published MI300X write-ups diverge so widely for exactly this reason. Same model, same card, different executor — and usually no record of which executor.r.
Procurement decisions require executor context
LynxBenchAI 26Q3 figures bundle device, backend, and software configuration into a single measurement, delivering verifiable executor claims instead of bare silicon numbers. The reasoning behind treating hardware and software as one measurable unit is developed in our methodology for reading benchmark results. pip install lynxbench-ai puts the same recording discipline on ordinary consumer hardware, if you want to see the effect of a stack change on a machine you control.
Nothing here orders MI300X against any other vendor’s part. That ordering, if it exists, belongs to a measured comparison with both executors recorded — so the question worth carrying into your next capacity plan is whether the MI300X figures already in it name a backend, or just a card.
