There is no single number that answers “L40S vs A100”. Both cards carry a published 26Q3 LynxBenchAI result, and each result breaks into three category scores — Training, Inference, Compute — that do not move together. A blended headline figure averages across all three, which is exactly where the answer to your question is hiding.
So the first move is not to look up a ratio. It is to decide which of the three categories your workload resembles.
Which category score should decide the question?
An inference-density card and a general-purpose datacentre accelerator were built for different jobs. Ranking them on one axis forces a spectrum neither was designed to sit on. Pick the axis that matches what you actually run:
| If your workload is… | Read this 26Q3 category score | What a spec-sheet ratio tells you |
|---|---|---|
| Serving a model under sustained request load | Inference | Very little — peak FLOPS is not a serving metric |
| Fine-tuning or training runs with optimiser state resident | Training | Memory capacity matters, but not the whole story |
| Numerical / general accelerated compute kernels | Compute | Closest of the three, still not a substitute |
| None of the above cleanly | No published score governs it | Nothing you should carry into procurement |
That last row is the honest one. Where the workload does not resemble the published catalogue, the correct output is a decision to measure it — not an extrapolated estimate dressed up as a figure.
What makes two results comparable
A published result is not a property of the card alone. It is tied to the backend, driver, framework and runtime present on the machine that produced it — the executor, not the silicon. Two conditions have to hold before an L40S number and an A100 number can be set against each other:
- Both results carry the same release name (here, 26Q3). Comparing across release names compares two different measurement contexts.
- Both were produced under a comparable software stack. If backends, drivers or framework versions differ, you can still describe each card in its own context — you cannot subtract one score from the other and call the difference hardware.
This is also why a vendor spec-sheet comparison answers a different question. A spec sheet describes theoretical device capability; a same-release measured comparison describes what two executors did on a defined workload. Both are legitimate; only one of them is checkable against a published result page. We keep that distinction explicit because it is the point where most procurement reasoning quietly goes wrong.
Price, and the H100 question
Dividing a category score by a purchase price produces a number, and the number is misleading unless the score matches the workload and the cost model includes the things that actually vary — power, host platform, rack density, utilisation. Price-performance is a defensible metric only after the category question is settled. Doing it in the other order just gives the blended-average problem a currency symbol.
Adding the H100 to the shortlist changes the candidate set, not the method. The governing category score is still whichever one your workload resembles; a third card does not turn a Training question into an Inference one.
The structural reasoning behind why spec figures fail to predict measured behaviour is developed in our work on how hardware performance claims diverge from measured results, and the executor framing that makes a result reproducible is the same one underpinning our GPU performance measurement practice.
So: before you compare the two cards, can you name which of the three 26Q3 category scores your workload actually lives in — and if you cannot, what would you have to run to find out?
