There is no single number that answers “A100 vs H100”. Both devices carry a published LynxBenchAI 26Q3 result, and that result is split into three category scores — Training, Inference and Compute — which do not move together. Picking the wrong one, or collapsing all three into one multiplier, is how a capacity plan inherits an assumption nobody tested.
What does “NVIDIA A100 vs H100” mean in practice?
Practically, this means comparing two result pages from the same release: the NVIDIA A100 SXM4 80GB and the H100 80GB HBM3, each measured as an AI Executor — the device together with its backend, driver, framework and runtime — rather than as a piece of silicon in isolation. A spec-sheet delta describes an architecture. A same-release measurement describes what a bounded, identically-prepared workload actually did on that stack. Substituting the first for the second is the moment the comparison stops being checkable.
The practical consequence is small and specific: before you read either page, decide which category your workload resembles. A fine-tuning pipeline is not an inference-serving deployment, and neither is a numerical-compute kernel. The generational uplift you care about is the one in that row.w.
The reading procedure
- Identify the category. Training, Inference, or Compute — whichever the workload most resembles. Do not average across them.
- Confirm the release name. Both result pages must carry the same release — here, 26Q3. Results are comparable within a release name, not across release names.
- Read the matching score on both pages. One category, two devices, side by side.
- Stop before extrapolating. If your workload was not run, the published score does not cover it.
| Question | What the published 26Q3 results support |
|---|---|
| Which device is faster overall? | Nothing — there is no “overall”. Three category scores, read separately. |
| Is the generational uplift the same for training and inference? | Not assumable. The three categories are reported separately because they diverge. |
| Can I compare an A100 26Q3 result to an H100 result from another release? | No. Comparability is scoped to a single release name. |
| Does the A100’s age invalidate its result? | No. Within one release both devices were prepared and run identically; age is a property of the part, not a defect in the measurement. |
| Can the score tell me which is cheaper per unit of work? | Only the numerator. Price per hour and purchase cost sit outside the benchmark entirely. |
| My workload is not in the catalogue — what now? | Run it. Extrapolating from an unrelated category is a guess wearing a number. |
Adding a third device — an H200, say — does not change any of this. The same-release rule applies identically to every additional result page you put next to the first two.
Why bounded optimisation effort matters here
The comparison is checkable because both devices ran prepared artefacts under bounded, identically applied optimisation effort. Nobody hand-tuned one side and shipped the other stock. That constraint is what separates a measurement from a demonstration, and it is why the interpretation rules are strict about the release name: the boundary of the effort is defined per release, and it does not travel.
We treat that as the load-bearing part of any device comparison, and it is the part vendor-published uplift figures cannot offer, because a manufacturer claim about an architecture carries no statement about the software stack you will actually deploy on. The full framework for reading a result this way — what the categories measure, how saturation is handled, where the published numbers stop — is developed in our LynxBenchAI benchmarking methodology, and the engineering side of getting a chosen device to perform sits with our GPU work.
So the sharper question is not “which is faster” but: which of the three categories does your workload actually resemble, and have you checked that one — or are you sizing against a number that was measured somewhere else?
