An H100 quote prices one half of what produces the number you care about. The device is on the invoice; the backend, driver version, framework build, and runtime that the workload actually passes through are not. That second half is where measured throughput is decided, which is why “nvidia h100 price” is a budgeting input rather than a cost-per-performance answer.
The habit is understandable. You collect quotes — per card, per server, per GPU-hour — divide by a headline FLOPS or memory-bandwidth figure, and rank the results. The arithmetic is clean. The problem is the denominator: a peak specification is a property of the silicon, while the number a machine actually delivers is a property of the AI Executor, the device together with the software stack present on it. Two H100 quotes at different prices may sit behind different container images, driver versions, and framework builds. Two H100 quotes at the same price can hide the same divergence.
What does an H100 price quote actually specify?
Enough to sign a purchase order. Not enough to compare throughput.
| On the invoice | Left unspecified |
|---|---|
| Device model and count (H100 SXM / PCIe) | Driver version on the machine |
| Memory capacity per card | Container image and its framework build |
| Interconnect topology, chassis, power | Inference backend and runtime (e.g. TensorRT vs a stock PyTorch path) |
| Price per card, per server, or per GPU-hour | Precision policy actually used at run time |
| Region, reseller, contract term | Whether the observed figure was sustained or a burst |
Rental and purchase leave different halves dark. A per-hour price usually comes with someone else’s image and driver — chosen for you, rarely pinned in the contract, and free to change between billing periods. A per-card purchase leaves the software half entirely to you, which is more work and more control. A used H100 quote tells you about the device’s condition and the market, and nothing at all about delivered throughput on your workload.
Constructing a cost figure that survives contact with reality
The useful metric is dollars — or GPU-hours — per unit of measured work, not per advertised peak. Three conditions make that division honest:
- Pin the software half before comparing quotes. Record driver, framework, and runtime versions on both sides. Otherwise you are comparing a price against an unrecorded configuration.
- Use a sustained figure, not a burst. A transient peak divided by a monthly bill is not a cost model.
- Stay inside one release name. LynxBenchAI comparability holds within a release — 26Q3 figures against 26Q3 figures. A procurement spreadsheet that mixes release names is answering two different questions in one column.
The same discipline applies when the comparison crosses devices. An H100 quote against an A100 or H200 quote only means something if the backend, framework, and precision policy are held constant across both; otherwise the delta you measure is partly a software delta wearing a hardware label.
There is a practical consequence for capacity planning. When throughput falls short, buying or renting more H100 time is one lever, and changing the backend, framework build, or runtime is another — and the second is often the cheaper one. You cannot tell which applies from a price sheet. You can tell from a recorded executor.
This is the structural reason spec figures fail as purchasing predictors, developed at length in why GPU specifications do not predict AI performance. The released 26Q3 run records the device, the backend, and the software present on the machine alongside the number, which is what converts a price-per-device figure into a price-per-executor figure; the free Personal Edition on the LynxBenchAI product page lets you reproduce that recording discipline on hardware you already have before committing to a quote.
Published results cannot rank vendors and cannot forecast what an H100 will cost you — that is not what a measurement records. So the question worth carrying into the next procurement review is narrower than a budget: which software versions were present on the machine that produced the throughput number you are dividing your price by, and can you name them?
