Contracts ·

Hyperscaler or neocloud: how the contract actually differs.

AWS, Azure, Google Cloud and Oracle sell GPU capacity one way. CoreWeave, Lambda, Crusoe, Nebius and the other GPU-first providers sell it another. The headline rate is the least of the differences.

Written for CIOs, VPs of Infrastructure, heads of AI platform and the procurement teams sitting between them — anyone with two GPU proposals on the desk that do not share a single line item.

The situation is common enough to describe from memory. One quote is a hyperscaler capacity reservation, priced per instance-hour with a discount tier attached to a commitment. The other is a neocloud proposal for a dedicated cluster on a three-year term with a deposit. Both are for roughly the same GPUs. The board wants a recommendation by Friday, and the two documents cannot be laid side by side because they are not the same product.

They are different products sold on different paper, and what is negotiable inside each is different too. Read them as the same thing and you will negotiate the wrong terms in both.

Where the capacity comes from

On a hyperscaler, GPU capacity is a slice of a shared fleet. AWS sells it as EC2 Capacity Blocks for ML, which reserve accelerated instances for a defined window with a start date up to eight weeks out and up to 64 instances per block, alongside longer-dated reservations. Azure and Google Cloud sell one- and three-year commitments that discount the running rate, with Microsoft citing savings of up to 72 per cent against pay-as-you-go for reservations generally. In every case the contract is largely the provider's paper. What you negotiate is the size and shape of the commitment, the discount that commitment earns, and the term — rarely the terms themselves.

On a neocloud, capacity is more often a dedicated cluster, bare metal or close to it, and sometimes built to your order. The contract behaves less like a cloud agreement and more like a lease. Term, deposit, ramp, hardware specification, network fabric and remedy are all on the table, and all of them need writing down because none of them are standard. On our desk today, build-to-suit B300 and GB300 NVL72 clusters run on three-to-five year terms with a deposit of roughly 30 per cent at three years and 20 to 25 per cent at five, inside an indicative band of four to five dollars per GPU-hour set primarily by term. NVIDIA's next-generation Vera Rubin platform is also newly reaching supply on the same desk — a 3,000-GPU position, US only, Q1 2027, five-year term only, at roughly eight dollars per GPU-hour, a premium reflecting how new the platform is. Those are the current numbers, and they move.

What is actually negotiable

The hyperscaler levers are real but bounded: commitment size and structure, discount tier, term length, ramp, credits across other services, egress treatment, support tier, and the strength of any capacity-assurance language. What tends not to move is the SLA definition, the liability cap and the core terms of service. Spending leverage on those is usually a poor trade.

The neocloud levers run wider. Price per GPU-hour is set primarily by term. Deposit size, ramp schedule, hardware generation and refresh rights, InfiniBand or Ethernet fabric, storage throughput, the SLA remedy mechanism, exit and assignment, and expansion rights are all negotiable. The flexibility is genuine. So is the obligation to specify everything, because a neocloud contract does not inherit a decade of settled defaults the way a hyperscaler's does.

Have both term sheets in hand? Send them to sales@thechiefnegotiators.com with the workload, the date and the region. We return a first read within one business day, at no cost to the buyer, with an MNDA available before anything specific is shared.

The counterparty question

With a hyperscaler, balance-sheet risk is not a serious concern. The risk is allocation: whether the capacity you were promised is actually there, in that region, on that date, and what the contract says if it is not. Capacity-assurance language and the remedy behind it are the terms to spend leverage on.

With a neocloud, allocation risk is often lower because the cluster is dedicated to you. Counterparty diligence matters more. Who owns the hardware. How the build is financed. Whether the site's power is contracted or studied. What happens to your deposit and your cluster if the provider's financing changes. None of that is a criticism of the category — it is a lease, and leases get diligenced. The same twelve questions apply.

Term and price

Both categories reward term, for different reasons. On the neocloud side the effect is large and mechanical: it is supplier funding cost, which is why five years prices materially below three on identical hardware. On the hyperscaler side a longer commitment buys discount but also locks you to a hardware generation across at least one refresh cycle. NVIDIA's current rack-scale platform, the GB300 NVL72, pairs 72 Blackwell Ultra GPUs with 36 Grace CPUs in a liquid-cooled rack; a three-year commitment signed on it today will outlive at least one successor. That successor, the Vera Rubin platform, is not hypothetical — it is already reaching production supply. In that case a right to migrate to the next generation at a defined price is usually worth more than a further two points of discount.

Remedies

Both categories publish an SLA percentage. What sits behind it is where they diverge. The credit mechanism, the cap, what counts as an outage, and whether a termination right exists at the outer bound — on hyperscaler paper these are fixed, and on neocloud paper they are negotiable. They are worth negotiating hard. A credit capped at one month's fee is not a remedy for a training run that costs more than that per day.

Which one, then

It is a match, not a verdict. Latency-bound inference with an existing hyperscaler estate usually stays on the hyperscaler. Large training with a known ramp often lands on a dedicated neocloud cluster for cost and control. Many requirements end up split, and the split is itself a negotiating position. The point is to read each contract as the product it actually is rather than the product the other one is.

The rate is what the two look like from a distance. The contract is what they look like from inside.

Asked about this

What is the difference between a hyperscaler and a neocloud for GPU capacity?

A hyperscaler sells GPU capacity as a slice of a shared fleet through reservations, capacity blocks or committed-use agreements on its standard terms. A neocloud more often sells a dedicated cluster on a multi-year term where price, deposit, ramp, hardware, fabric and remedies are all negotiated.

Is a neocloud cheaper than a hyperscaler?

Often, for large sustained training on multi-year terms, because term lowers the supplier's funding cost and dedicated bare metal avoids the shared-fleet premium. For latency-bound inference tied to an existing estate, the hyperscaler frequently wins once data movement and integration are priced in. It is a match to the workload, not a rule.

What should I send to get the two compared?

Both proposals, the workload profile, the ready-for-service date and region, and the term you can commit to. One business day to a first read, no cost to the buyer, MNDA on request.

Sources

Related: GPUaaS & AI cloud contract negotiation, GPU cluster procurement, and the ten terms that move price more than the rate.

Get these notes in Google. Add The Chief Negotiators as a preferred source and our insights are marked as such in Top Stories, AI Overviews and AI Mode.

Comparing a hyperscaler quote against a neocloud one?

Send both. We will tell you which terms are actually different, which ones are movable, and what the market is signing instead. One business day, no cost to the buyer.

Book 30 minutesSend both proposals →