Console

A fixed reference brief — 68 GB peak, 12 h on an A100, checkpointed, budget $60 — priced on each seller's own two rows. This is not your workload. It is here because it is the clearest published evidence that the cheaper accelerator per hour and the cheaper accelerator to finish are not the same accelerator.

The break-even column is one published price divided by another, so it assumes nothing. It runs from 1.4301× on Lambda to 3.0003× on Azure — a span of 1.57×. There is no speedup inside that range where one accelerator is the right buy on all four sheets.

assumed One number here is not published: how much faster an H100 is than an A100. We carry it at 2.2222×, and that is a judgement rather than a measurement — no benchmark result is cited behind it. Published per-accelerator comparisons of the two parts vary by benchmark instead of settling on a single multiplier, and that variation straddles the speedup at which this decision changes hands: below it the cheaper hourly rate finishes for less, above it the faster part does. Which accelerator is cheaper to complete is therefore a property of the workload rather than a fact about the hardware, and deciding it per workload is what the routing is for. The break-even column above is arithmetic on published prices and carries none of this assumption.

Where the right answer changes hands

Every rate, with its source

• These are other sellers' published prices and our arithmetic on them. Nothing here is a measurement of anything we ran.
• The only unsourced number is how much faster an H100 is than an A100. It is carried as an assumption, not a price, it is stamped [assumed] wherever it appears, and 2.2222x is our judgement rather than a measurement. The published spread it is read against: 1.6x-3.8x, spread across published per-accelerator MLPerf Training v2.1 results — a range across benchmarks, not a central estimate.
• What that judgement costs the argument, stated rather than characterised: 3 of these 4 sellers' break-even speedups fall inside the published spread of 1.60x-3.80x, so for those sellers moving the assumption anywhere within the spread changes which accelerator is cheaper to complete this brief. At the shipped 2.2222x, 2 of 4 sheets route to H100 and 2 to A100. Which part is correct is a property of the workload and the seller's price list, not of the part — the sweep below is published for that reason and the single count at any one speedup is never the finding.
• The break-even speedups are one published price divided by another. They carry no assumption at all and they are what the comparison actually rests on.
• Cost to completion here is rate x hours x performance factor. Every row is priced with interruption at zero, which is the assumption most favourable to the seller, so no reclaim reserve is included in any figure on this page.
• The router's non-compute reserve and recovery reserve shape only the bid ceiling, not expected cost. Claiming otherwise is checkable in internal/router and would be wrong.
• Sellers who publish no region are recorded with no region. AWS and Azure figures are US East; the AWS P family was verified identical in US West (Oregon) to the cent, and no other region was checked.
• Sweep rows that sit on a seller's own break-even read one short of the round number: 3.0003x shows three of four sheets, not four, because Azure's exact line is 3.000305x. At the line the two accelerators cost the same and neither is correct. The arithmetic is left as it falls rather than rounded in our favour.
• GCP is absent because its price tables render client-side and its legacy feed returns 404. It is not omitted for convenience and it will not be filled in from memory.
• Prices move in steps, not drift. Every figure carries an as-of date and the page states the capture's age.
• AWS sheet pairing: The only 80 GB A100 the seller publishes, against its division-free single-accelerator H100 SKU. Using the single-accelerator row rather than p5.48xlarge/8 removes our own arithmetic from one side of the comparison; the two agree to the cent anyway. Alternate considered: aws:p5.48xlarge:h100-80. p5.48xlarge / 8 is 6.880000, identical, so the choice between the two AWS H100 rows changes nothing.
• Azure sheet pairing: Matched interconnect. The seller's only 80 GB A100 shape carries InfiniBand, so it is compared against the H100 shape that also carries InfiniBand. Pairing it against the interconnect-free H100 would compare two different products and would make the seller look cheaper than the like-for-like buy actually is. Alternate considered: azure:nd96is-h100-v5:h100-80. The interconnect-free H100 at 11.061000 would move this sheet's break-even from 3.0003x to 2.7003x and narrow the four-seller span from 1.5702x to 1.2702x. Those two figures are NOT sourced to the same standard as the 3.0003x one: the alternate row's instance price is verified live, but its 8-accelerator divisor is inferred rather than read, because Microsoft's ND-H100-v5 page documents only the ND96isr size. Read 2.7003x and 1.2702x as illustrative, not as published. Either way it would not change the finding: the correct accelerator would still differ by seller across the speedup range, and Azure would still be the last sheet to switch.
• These are other sellers' published prices and our arithmetic on them. Nothing here is a measurement of anything we ran.
• The only unsourced number is how much faster an H100 is than an A100. It is carried as an assumption, not a price, it is stamped [assumed] wherever it appears, and 2.2222x is our judgement rather than a measurement. The published spread it is read against: 1.6x-3.8x, spread across published per-accelerator MLPerf Training v2.1 results — a range across benchmarks, not a central estimate.
• What that judgement costs the argument, stated rather than characterised: 3 of these 4 sellers' break-even speedups fall inside the published spread of 1.60x-3.80x, so for those sellers moving the assumption anywhere within the spread changes which accelerator is cheaper to complete this brief. At the shipped 2.2222x, 2 of 4 sheets route to H100 and 2 to A100. Which part is correct is a property of the workload and the seller's price list, not of the part — the sweep below is published for that reason and the single count at any one speedup is never the finding.
• The break-even speedups are one published price divided by another. They carry no assumption at all and they are what the comparison actually rests on.
• Cost to completion here is rate x hours x performance factor. Every row is priced with interruption at zero, which is the assumption most favourable to the seller, so no reclaim reserve is included in any figure on this page.
• The router's non-compute reserve and recovery reserve shape only the bid ceiling, not expected cost. Claiming otherwise is checkable in internal/router and would be wrong.
• Sellers who publish no region are recorded with no region. AWS and Azure figures are US East; the AWS P family was verified identical in US West (Oregon) to the cent, and no other region was checked.
• Sweep rows that sit on a seller's own break-even read one short of the round number: 3.0003x shows three of four sheets, not four, because Azure's exact line is 3.000305x. At the line the two accelerators cost the same and neither is correct. The arithmetic is left as it falls rather than rounded in our favour.
• GCP is absent because its price tables render client-side and its legacy feed returns 404. It is not omitted for convenience and it will not be filled in from memory.
• Prices move in steps, not drift. Every figure carries an as-of date and the page states the capture's age.
• AWS sheet pairing: The only 80 GB A100 the seller publishes, against its division-free single-accelerator H100 SKU. Using the single-accelerator row rather than p5.48xlarge/8 removes our own arithmetic from one side of the comparison; the two agree to the cent anyway. Alternate considered: aws:p5.48xlarge:h100-80. p5.48xlarge / 8 is 6.880000, identical, so the choice between the two AWS H100 rows changes nothing.
• Azure sheet pairing: Matched interconnect. The seller's only 80 GB A100 shape carries InfiniBand, so it is compared against the H100 shape that also carries InfiniBand. Pairing it against the interconnect-free H100 would compare two different products and would make the seller look cheaper than the like-for-like buy actually is. Alternate considered: azure:nd96is-h100-v5:h100-80. The interconnect-free H100 at 11.061000 would move this sheet's break-even from 3.0003x to 2.7003x and narrow the four-seller span from 1.5702x to 1.2702x. Those two figures are NOT sourced to the same standard as the 3.0003x one: the alternate row's instance price is verified live, but its 8-accelerator divisor is inferred rather than read, because Microsoft's ND-H100-v5 page documents only the ND96isr size. Read 2.7003x and 1.2702x as illustrative, not as published. Either way it would not change the finding: the correct accelerator would still differ by seller across the speedup range, and Azure would still be the last sheet to switch.

Captured 2026-08-03. Generated by ./bin/pricebook publish from one committed capture and regenerated by a test on every build, so this table and the rates above it cannot disagree.