Before comparing three NVIDIA generations, ask a narrower question than “which is faster”: does each device carry a published result under the same release name, and does that result separate Training, Inference and Compute rather than collapsing them into one figure? A “V100 vs A100 vs H100” search usually returns three spec sheets and two stacked uplift claims. Neither structure answers a refresh decision.
Why doesn’t the third device behave like the second?
A two-way A100-vs-H100 read already hides which category a workload resembles. Adding a V100 adds a second generational gap, a different memory and precision profile, and — the part most comparisons skip — a materially different chance that a same-release, same-conditions measurement exists for all three devices at once.
That last point is the one that decides whether the comparison is readable. On the LynxBenchAI 26Q3 leaderboard, the A100 SXM4 80GB and H100 80GB HBM3 each carry result pages split into Training, Inference and Compute category scores under one release name. Where a third device has no result under that same release name, the honest move is not to interpolate from generational marketing — it is to run the one category the workload actually loads and treat that bounded test as the evidence.
Stacked uplift claims are the other trap. A V100→A100 figure and an A100→H100 figure were produced under different conditions, on different workloads, with different precision assumptions. Multiplying them yields a number that no measured category reproduces. Architecture-level features described in vendor or encyclopedic write-ups — transformer engine, DPX instructions, memory hierarchy changes — explain why a delta could exist. They do not establish its size on your workload.
Structuring the three-way question
| Step | What to check | What it decides |
|---|---|---|
| 1 | Does each of the three devices have a published result under the same release name? | Whether a three-way read is possible at all, or only a two-way read plus a test |
| 2 | Which category — Training, Inference or Compute — does the workload actually load? | Which single score carries the decision; the other two are noise for that workload |
| 3 | Compare the matching category across devices, not headline figures | Whether the generational gap is real for this job |
| 4 | If one device is missing from the release, run a bounded in-house test on that one category | Replaces an unbounded extrapolation with a measurement |
| 5 | Only then attach price | Price-per-result is meaningless when two of three numbers come from different measurement conditions |
Step 4 needs discipline: a bounded test controls the software stack, precision, batch or sequence configuration, and sustained rather than burst duration. Otherwise it is a fourth incomparable number rather than a substitute for the missing one.
The practical consequence is that keeping older V100 or A100 capacity can stay defensible on the published categories, not merely on cost. If the loaded category still clears the threshold the workload needs, a two-generation refresh is a budgeting choice rather than a technical necessity. We see the reverse conclusion reached often — a refresh justified by a spec-sheet multiple that the measured categories never reproduced.
The reading procedure for two devices under one release is set out in our same-release A100 vs H100 comparison method; the published category scores themselves sit on the LynxBenchAI results pages.
So the question worth carrying into a refresh conversation is not how much faster an H100 is than a V100, but this: which single category score does your workload load, and do you have it under one release name for every device you are actually choosing between?
