There is no single number that answers “H100 vs H200”. Both devices carry a published LynxBenchAI result under the 26Q3 release, and each of those results separates into three category scores — Training, Inference, and Compute — tied to the specific backend, driver, framework, and runtime present on the machine that produced it. The useful comparison is one category deep, not one headline wide.
That matters because the H200 is, in the terms that concern a buyer, a memory-bandwidth-led refresh sitting on the same compute architecture. A change of that shape does not move memory-bound and compute-bound categories by the same proportion. So the vendor bandwidth uplift figure — the number most “h100 vs h200” comparisons quote — is a specification statement about one subsystem, not a measured outcome for the work you intend to run.
Which 26Q3 score should you actually read?
Pick the category your workload resembles, then compare the two devices on that score alone.
| If your workload is… | Read this 26Q3 category | Why |
|---|---|---|
| Fine-tuning or full training runs | Training | Exercises the training path as measured, not a spec delta |
| Serving a deployed model under load | Inference | Serving behaviour is the score that maps to your cost per request |
| Numerical / kernel-level throughput work | Compute | Closest to raw execution, least flattered by a bandwidth refresh |
| None of the above | No published number applies | Pay for a measurement run before procurement, not after |
The last row is the one people skip. If your workload is out of catalogue, the honest read is that neither published result answers your question, and the cost of measuring it is smaller than the cost of a wrong capacity purchase.
The comparability conditions
A delta between two result pages is only a delta if the results are comparable. Two conditions have to hold before you trust it: both numbers come from the same named release (here, 26Q3 — never compare across release names), and you have checked the backend, driver, framework, and runtime recorded alongside each result. If those software stacks differ, part of the gap you are reading belongs to the stack, not to the silicon. In our experience this is the most common reason two people quoting “the same” comparison disagree.
Cost then reads per category, not per headline. A price difference divided by a collapsed average uplift produces a number that does not correspond to any workload. A price difference divided by the Inference score you will actually live on does.
Third devices — an A100, or a Blackwell-generation part — can join the read only under the same conditions: same release, comparable stack, same category. A three-way comparison inherits every constraint of the two-way one and adds none of its own leniency.
We work through the full framework for reading two same-release results side by side, including how the category separation is constructed, in how measured GPU performance diverges from specification-sheet expectations. The published per-device results themselves live on the LynxBenchAI results explorer, and the engineering side of an upgrade decision — what changes in your stack once the hardware does — sits with our GPU work.
So the sharper version of the question is not “how much faster is the H200” but: which category did you check, and was it measured on a stack that resembles yours?
