“Which is faster for AI, MI300X or H100?” is the question almost everyone asks, and it is the wrong shape. There is no single number that answers it, because the two devices do not have one score each — they have three, and the three do not move together. Under the 26Q3 LynxBenchAI release, both the AMD Instinct MI300X and the NVIDIA H100 80GB HBM3 carry a published result broken into Training, Inference, and Compute category scores. The useful comparison starts by asking which of those three your workload actually resembles.
That reframing is not pedantry. It is the difference between a purchase decision you can defend in a review and one you cannot.
Why the headline number is the problem
A blended “MI300X vs H100” figure — whether it comes from a vendor slide, a forum thread, or a rental provider’s marketing page — collapses three category scores into one. The collapse is where the information goes. A device can look strong on Compute-class kernels and considerably less so on the Inference category that matters if you are serving a transformer model under concurrency, and a single blended figure will not tell you which side of that split you are standing on.
We see this pattern repeatedly when teams bring us a hardware shortlist. The shortlist has one number per device. The workload has one shape. Nobody has checked whether the number and the shape are talking about the same thing.
The three published categories exist precisely because they diverge:
- Training stresses sustained multi-step throughput, optimizer state traffic, and how well the collective-communication path (NCCL on NVIDIA, RCCL on AMD) holds up as the step count grows.
- Inference stresses latency under concurrency, attention-kernel efficiency at realistic sequence lengths, and how gracefully the runtime handles batching.
- Compute stresses the raw kernel-level work — GEMM-shaped and bandwidth-shaped operations closer to what a spec sheet describes.
A workload that is 90% low-latency serving has almost nothing to learn from a Training-weighted comparison. That is the first citable point: the category split is the decision surface, and any comparison that discards it has discarded the decision.
What a published result is actually tied to
Neither result belongs to the silicon alone. A LynxBenchAI result is a measurement of an AI Executor — the hardware together with the software stack that ran on it. The MI300X result under 26Q3 is tied to the ROCm-era backend, driver, framework, and runtime versions present on the machine that produced it. The H100 result under 26Q3 is tied to its own CUDA-side equivalents. Change the runtime and you have changed the executor, which means you have changed the measurement.
This is why we treat the AI Executor as the unit of performance rather than the card. It also explains a common source of confusion in cross-vendor arguments: two people quoting different numbers for the same device are often both right, because they are quoting different executors.
The practical consequence is narrow and firm. Two results are directly comparable only when they carry the same release name. A 26Q3 MI300X result reads against a 26Q3 H100 result. It does not read against a result from a different release, and it does not read against a vendor’s own published benchmark, which is a different claim produced under different conditions with different incentives. Both may be honest. They are not the same evidence class.
Comparison matrix: what each kind of evidence can and cannot settle
| Evidence source | Answers “which device is faster on my workload?” | Optimization effort declared | Cross-vendor comparable | What it is good for |
|---|---|---|---|---|
| Vendor spec sheet (peak TFLOPS, HBM bandwidth) | No | N/A — no workload run | No | Ruling devices out on memory capacity |
| Vendor-published benchmark | Partially, for that vendor’s chosen configuration | Rarely bounded or symmetric | No | Understanding what the vendor optimised for |
| Same-release LynxBenchAI result, per category | Yes, for workloads resembling that category | Yes — bounded and applied identically | Yes, within one release name | Category-level shortlisting |
| Your own run of the Personal Edition on your workload | Yes, for that workload | Yes, by construction | Against your own baselines | The decision itself |
Read the table as a hierarchy of narrowing scope, not a ranking of quality. A spec sheet is genuinely useful for one thing — checking whether a model fits in memory at all — and useless for the rest. We go further into that gap in our discussion of why spec-sheet TFLOPS do not predict AI throughput.
Why does optimization-effort parity matter in a cross-vendor comparison?
This is the question that separates a checkable comparison from a marketing one, and it is the reason cross-vendor benchmarking has such a poor reputation.
Suppose one device’s artefact was hand-tuned for weeks by engineers who know its kernel library intimately, and the other’s was run through a default path. The resulting numbers are real measurements. They are also a measurement of effort asymmetry, not of hardware. Most published cross-vendor comparisons — in either direction — contain some amount of this, usually unintentionally, because the team producing them knows one stack better than the other.
The 26Q3 results avoid it by construction: optimization effort was bounded and applied identically to the prepared artefacts that ran on both devices. Bounded means there is a declared ceiling on tuning. Identical means the same ceiling on both sides. Neither device got a specialist’s thumb on the scale, and neither got the default-path penalty.
What you give up is the ceiling. A bounded comparison does not tell you what a dedicated AMD kernel team or a dedicated TensorRT specialist could extract from either card. It tells you what the same disciplined effort yields on each. For a shortlisting decision that is the more useful quantity, because most organisations will not staff a per-vendor kernel team. If you will, the bounded number is a floor, not a forecast — and the role of bounded optimization in fair benchmarking covers where that floor stops being informative.
A worked reading of the two results
Here is the sequence we would actually walk through, with the reasoning made explicit. The specific numbers live on the MI300X result page and the H100 result page; this is how to read them, not a restatement of them.
Step 1 — Classify the workload before opening either page. Write down, in one sentence, what the machine will spend most of its time doing. “Serving a 70B model at p95 under 400ms with bursty concurrency” is a classification. “LLM stuff” is not. If the sentence contains both training and serving, you have two decisions, and they may not point at the same device.
Step 2 — Confirm both results carry the same release name. If one is 26Q3 and the other is not, stop. The comparison is not available yet; what you have is two unrelated observations.
Step 3 — Read only the matching category. A serving workload reads Inference. A pretraining or continued-pretraining workload reads Training. A workload dominated by custom kernels, simulation, or scientific compute reads Compute. Reading all three and averaging them reconstructs exactly the blended number that caused the problem.
Step 4 — Check the executor line, not just the score. If the published stack is materially older or newer than what you will deploy, the score still carries information, but the delta between the two devices is the durable part and the absolute figure is the perishable part.
Step 5 — Ask whether your workload resembles the catalogue at all. This is the step people skip. The benchmark catalogue covers recognisable workload shapes; it does not cover your fine-tuned mixture-of-experts model with a custom attention variant and a retrieval sidecar.
What to do when your workload isn’t in the catalogue
Extrapolating from a published category score to a workload that does not resemble the catalogue is the failure mode we would most like readers to avoid. It feels rigorous — you are, after all, using measured data — but the measurement was of something else.
The honest move is to run the workload. The Personal Edition of LynxBenchAI is free for non-commercial use and installable now, and running it on the model and sequence profile you actually care about produces the one result nobody can produce for you. It is also the only way to catch the interactions that category scores cannot express: a memory-capacity cliff at your batch size, a kernel your framework version dispatches badly on one backend, a padding pattern that wastes a third of your attention compute.
The other editions — Press, Pro, Enterprise — are not something you can obtain, price, or trial today. Personal Edition is what has shipped, and for a two-device shortlist it is sufficient.
Where a measured comparison ends and engineering begins is a clean handoff. Once you know which device your workload prefers and by roughly how much, the remaining question is how much of the gap is architectural and how much is a fixable software problem — which is GPU inference optimisation and hardware-selection work rather than a measurement question. We have seen shortlists reverse at that stage, when a runtime change on the apparently slower device closed most of the difference.
FAQ
What does “MI300X vs H100” actually compare once a published benchmark separates Training, Inference, and Compute scores?
It compares three separate things, not one. Under the 26Q3 release each device carries a Training, an Inference, and a Compute category score, and those scores do not move together — a device can lead on one and trail on another. The comparison only becomes decision-grade once you have identified which single category your workload resembles and read that one.
Why can’t a vendor-published spec sheet for either device answer the same question a same-release, cross-vendor benchmark result can?
A spec sheet describes theoretical peaks — TFLOPS, HBM bandwidth, capacity — with no workload actually run and no software stack declared. A same-release result is a measurement of an executor: the device plus the specific backend, driver, framework, and runtime that produced the number. Spec sheets are useful for ruling a device out on memory capacity; they cannot predict achieved AI throughput.
What has to be true for an MI300X result and an H100 result to be validly compared against each other?
Both results must carry the same release name — 26Q3 against 26Q3. Within one release, the catalogue, the measurement conditions, and the optimization ceiling are held constant across devices, which is what makes the two figures readable side by side. Results from different releases, or a LynxBenchAI result against a vendor’s own benchmark, are different claims and should not be subtracted from each other.
Why does optimization-effort parity between the two devices’ prepared artefacts matter for trusting a cross-vendor comparison?
Because an unbounded comparison measures engineering effort as much as hardware. If one artefact was hand-tuned by stack specialists and the other ran a default path, the gap you observe is partly a staffing gap. Optimization effort on the 26Q3 artefacts was bounded and applied identically to both devices, which is what makes the comparison checkable rather than a vendor claim.
If a workload doesn’t resemble the benchmark catalogue’s Training, Inference, or Compute categories, what should a reader do instead of extrapolating from either device’s published score?
Run the Personal Edition on the workload in question. Extrapolating from a category score to a workload the catalogue does not cover produces a number that looks measured but describes something else. A local run is also the only way to surface workload-specific effects like memory cliffs at your batch size or bad kernel dispatch on your framework version.
Why doesn’t a single blended “MI300X vs H100” number tell a buyer which device fits their specific workload?
Because the blend averages away the divergence that matters. A serving-dominated workload and a pretraining-dominated workload can rationally choose different devices from the same pair of published results, and a blended figure hides that entirely. The blend answers a question no buyer has: how the two devices compare on a workload mix that is nobody’s actual workload.
The question to settle before you open either result page
The hard part of “MI300X vs H100” is not the arithmetic. It is committing, in writing, to which category your workload lives in and which release name you are reading — before you look at any number, because after you look it is very easy to select the category that agrees with the decision you had already made. Write the sentence first. If you cannot write it, the comparison is not the blocker; the workload definition is.
