GPU Leases Are Rising While Model Prices Fall

What changed

• Nvidia announced an approximately 20% price increase for H100 rentals in 2026. That is a stated move on rental pricing, not a market observation.
• Separately, market H100 rental costs have climbed by nearly 40% since October 2025. Different measurement, different mechanism — this is what the market has actually done, not what anyone announced.
• Separately again, H100 one-year lease contract prices rose approximately 40% over five months into early 2026. That is the contract market, and it is the one that carries lock-in risk.
• AWS raised H200 GPU instance prices by 15% on 4 January 2026. The p5e.48xlarge, which carries eight NVIDIA H200 GPUs, went from $34.61 to $39.80 per hour. It was the first GPU price increase in roughly two decades and broke a twenty-year precedent of cloud prices only ever going down.
• All of it comes off a collapsed base. H100 rental rates fell from roughly $8 per hour at their 2023 peak to as low as $1 to $2 per hour through the 2024-2025 oversupply. By early 2026 rates were still down roughly 64% to 75% from launch-era highs. A 40% rise from $2 an hour is not a return to $8.

Those five bullets are the whole story, and the fifth one is the reason this piece is not a panic. But the direction of travel matters more than the absolute level, because it inverts a piece of advice that has been reflexively true since 2023.

The inversion, stated plainly

The standard cost-reduction ladder for an AI product went: start on an API, watch the bill grow, then move the highest-volume workload onto rented GPUs and serve an open-weight model yourself. Each rung was cheaper than the last, and the arithmetic got easier every quarter because rented compute kept getting cheaper.

Both ends of that ladder are now moving, and they are moving in opposite directions. Labs have cut per-token prices repeatedly through 2026, so the top rung keeps getting cheaper. The rented compute on the bottom rung is getting dearer. The gap you were arbitraging is closing from both sides at once.

This is not a contradiction, and it is worth understanding why rather than treating it as an anomaly. A per-token API price is set in a competitive market by a small number of operators who pool every customer's traffic into one serving fleet. They run near-perfect utilisation because someone in the world is always sending a request, they amortise a single model over enormous aggregate volume, and several of them are willing to compress margin to hold share. A rented GPU is a scarce physical asset priced by supply and demand, and you pay for wall-clock hours whether you use them or not. Falling token prices are evidence of scale and competition at the serving layer. They are not evidence that the silicon underneath got cheaper.

There is a structural pressure on the other side too. Purpose-built inference silicon is arriving, financing structures are maturing — we looked at the first AI loan backed by inference chips rather than GPUs earlier this year — and that competition is the main thing keeping GPU rates from rising faster. It just has not arrived in time to help anyone's 2026 budget.

What you actually pay right now

The single most useful thing in this article is the spread. Before anyone debates leasing versus owning, look at how wide the same GPU-hour is priced across suppliers.

Read that table twice. The two AWS rows and the p5e row are measuring different things and must not be merged into one number — the $39.80 figure is an eight-H200 instance after a specific 15% rise, while the roughly $12.29 per-GPU figure is a separate on-demand measurement on a different basis. Similarly, the three headline percentage rises at the top of this piece are three distinct measurements of three distinct markets. Anyone adding them together to claim GPUs got 100% dearer is doing arithmetic on numbers that do not belong to each other.

What the table does show unambiguously is a four-to-eight times spread on the same class of silicon. A team paying hyperscaler list rates and complaining about GPU inflation has a much larger and much easier saving available than anything leasing or owning will produce.

The break-even, worked out

Here is the arithmetic, with every assumption stated so you can substitute your own numbers. The worked example uses an eight-GPU H100 node, because that is the unit most teams actually reason about.

ON-DEMAND, 8x H100 node
  mid-market rate per GPU-hour        $3.00   (bulk of market: $2-$4)
  x 8 GPUs                           $24.00   per node-hour
  x 730 hours per month           $17,520     per month, node up 24/7

  Useful work at 70% utilisation
    $24.00 / 0.70                    $34.29   per USEFUL node-hour
    $3.00  / 0.70                     $4.29   per USEFUL GPU-hour

OWNED HARDWARE at 70% utilisation
  effective all-in per GPU-hour  $2.50-$4.00  (3-yr amortisation + colo + power)
  x 8 GPUs                      $20.00-$32.00 per useful node-hour
  x 511 useful hours/month     $10,220-$16,352 per month

  Monthly delta vs on-demand    $1,168-$7,300 saved
  Annualised                    $14,016-$87,600 saved

SAME OWNED HARDWARE at 35% utilisation
  fixed costs unchanged, useful hours halved
  effective per GPU-hour         $5.00-$8.00
  x 8 GPUs                      $40.00-$64.00 per useful node-hour
  -> now MORE expensive than on-demand at every point in the range

Three conclusions fall straight out of that block.

First, there is a hard floor below which none of this is worth discussing. If your monthly spend on the equivalent API workload is under roughly $17,500, on-demand self-hosting cannot beat it on cash alone, because that is simply what the node costs to keep up. Under roughly $10,000 a month, even owned hardware at good utilisation cannot beat it. Everything below that threshold is an engineering preference, a data-residency requirement or a latency argument — all legitimate reasons, but not cost reasons. Dress them as what they are.

Second, the saving at good utilisation is real but modest: somewhere between $14,000 and $88,000 a year for one node. The whole engineering overhead of running your own serving stack has to fit inside that envelope — the on-call rotation, the driver upgrades, the capacity planning, the person who gets paged when a node falls over at 3am. At the bottom of that range you are not hiring anyone. At the top you are funding a fraction of one engineer. That is the honest size of the prize, and the reason serious teams model cost per task rather than cost per hour; our guide to LLM unit economics and cost per task works through that translation properly.

Third, and most important: utilisation is the whole game. The $2.50 to $4.00 figure for owned hardware is not a property of the hardware, it is a property of the hardware at 70% utilisation. Halve the utilisation and you double the effective cost, because amortisation, colocation and power do not care whether the GPUs are busy. At 35% sustained utilisation, owned hardware costs $40 to $64 per useful node-hour against $34.29 for on-demand — the arithmetic flips completely, and it flips without anything in the market changing.

This is why spiky workloads are so unforgiving. If your traffic peaks during Indian office hours and again during UK office hours with a trough between, your utilisation figure is not the peak, it is the average — and the average is what the arithmetic uses. Teams who have run this properly on concrete hardware, including the memory and batching constraints, will recognise the shape from our breakdown of the DeepSeek V4 Pro self-host break-even on eight H100s.

The number that quietly decides everything: inference versus training

One figure reframes the whole exercise. Over a model's production lifetime, inference costs dominate budgets at roughly 15 to 20 times training expense.

Most cost conversations are still shaped by the training era, when compute was a large, lumpy, project-shaped expense that you planned for and then finished. Inference is not project-shaped. It is a utility bill that arrives every month for as long as the product lives, it scales with success rather than with ambition, and it is where a 15 to 20 times multiplier compounds. A team that optimises its training run by 30% and leaves inference untouched has optimised the small number.

It also explains why GPU rental price movement matters more than it used to. When compute was mostly a training cost, a 20% rise was a one-off hit to a budget line you had already ring-fenced. When compute is mostly an inference cost, the same 20% rise lands on a recurring, growing bill that sits directly against gross margin every month for the life of the product. And it explains why the market itself is being priced for growth: the AI GPU rental market was valued at $3.34 billion in 2023 and is projected to reach $33.91 billion by 2032. Suppliers are not pricing for a glut any more.

What breaks the maths

Four things, in rough order of how often they actually bite.

Utilisation below 70%. Covered above, and worth repeating because it is the one teams get wrong most often. The failure is rarely dishonesty; it is measuring peak throughput during a load test and quietly treating that as the sustained figure. Pull the number from production telemetry over at least four weeks, including weekends and holidays.

Lease lock-in at the top of the market. A one-year term signed after a roughly 40% five-month run-up is a bet that the run-up continues. Given that the same asset traded as low as $1 to $2 an hour eighteen months earlier, that bet has visible downside. Shorter terms cost more per hour and are worth it while the market is this volatile.

Spot interruption treated as free. Spot and preemptible capacity looks like the obvious answer to a rising on-demand rate, and it genuinely can be — but only with checkpointing and resume logic that actually works, which is engineering time you must count on the self-host side of the ledger. The verified position is worth stating precisely: owned hardware at 70% utilisation lands at roughly $2.50 to $4.00 per GPU-hour, which is comparable to spot pricing but without interruption risk. If you are going to use spot, use it deliberately and build the machinery — our checkpoint-and-resume playbook for spot and preemptible GPUs covers the patterns that survive a mid-batch eviction.

Falling API prices you did not model. If your break-even is eighteen months out and the labs cut per-token prices twice more in that window, the break-even never arrives. Any self-hosting business case with a payback period longer than about a year should include a sensitivity line for further API price cuts, because on current evidence that is the base case rather than the pessimistic one.

What it looks like in Bengaluru and in London

The same arithmetic produces different advice on each side, mostly because the two markets have different floors.

Indian teams have an option UK teams do not: subsidised GPU access through the IndiaAI programme, priced administratively rather than by the market. That is a genuine advantage while it lasts, and it also creates a specific trap. A team that builds its cost model on subsidised capacity and then plans to graduate onto commercial rates in the AWS Mumbai region is implicitly forecasting a commercial price — and if that forecast was set during the 2024-2025 crash, it is now wrong in the expensive direction. Rebuild the graduation model against current rates, and note that hyperscaler regional pricing does not necessarily track the specialist providers where the $2 to $4 cluster sits. If the plan is to serve a large mixture-of-experts model on your own kit once you leave the subsidised tier, check the hardware envelope against today's prices rather than the model you built last year.

UK teams have no subsidised floor and feel commercial movement immediately. The AWS increase on 4 January landed on London-region workloads the same day it landed everywhere else, and for a startup running inference on the London region that was a 15% rise on a line item with no offsetting programme. The compensation is that the UK market has good access to specialist European and North American providers, so the supplier spread is available to anyone willing to move workloads. For UK teams the highest-leverage decision is almost always provider mix and commitment length, not build-versus-buy.

Both markets share one conclusion. The four-to-eight times spread between hyperscaler list rates and specialist provider rates is a larger lever than the difference between renting and owning. Pull that lever first. It requires no capital, no term commitment and no new on-call rotation.

A decision framework you can apply this week

Work through it in order, and stop at the first honest "no".

Is your monthly equivalent API spend above roughly $17,500? If not, stop. You cannot beat it with an on-demand node, and anything below roughly $10,000 a month cannot be beaten with owned hardware either. Optimise prompts, caching, model routing and batch composition instead — all cheaper and faster than buying anything.

Have you measured four weeks of production utilisation? Not a load test. Real traffic, including the quiet weeks. If the sustained figure is below 70%, the owned-hardware arithmetic does not work and the on-demand arithmetic is worse than it looks.

Have you audited at least three alternative providers on your real workload? If the answer is no, do that before anything else. The spread on the table above is the cheapest saving in this article.

Is your traffic steady or spiky? Spiky traffic favours the API, because you are renting someone else's utilisation. Steady, predictable, high-volume traffic is the only shape where owning wins comfortably.

Can the saving fund the operational burden? The realistic envelope is $14,000 to $88,000 a year per node. If your honest estimate of the engineering and on-call cost exceeds that, the arithmetic has already answered you.

Answer all five in your favour and self-hosting is still the right call — the case has not disappeared, it has just narrowed. What has changed is that it is no longer the automatic answer to a growing bill, and the direction of GPU rental pricing means the margin of safety is thinner than it was even a year ago. The teams who get burned in 2026 will not be the ones who chose the API. They will be the ones who signed a three-year commitment on an assumed utilisation figure at the top of a rising market, and discovered eleven months later that their traffic never got there.