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”?
The unit of performance is the executor: the device together with its software stack. 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 |
Two things follow. 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
Every number in the released 26Q3 LynxBenchAI run includes the device, backend, and software configuration present on the machine, transforming raw throughput into a verifiable claim about the complete executor stack rather than isolated hardware. 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.
