Skip to content
All insights
BUYER PRIMER

How to lock 12 months of GPU capacity without overpaying spot.

Jun 5, 2026 | 12 min read | Rillor
LOCK CAPACITYEXECDEPOSITBUILDDELIVER

Most GPU procurement is run as a spot-price optimization. The buildout team watches the street price, waits for a dip, and tries to buy at the moment the number looks best. That instinct is rational for a commodity you can take home today. It is the wrong instinct for an asset with a 36 to 52 week lead time, because the price you can see today is almost never the price for the hardware on the date your facility is actually ready to power it. You are optimizing the wrong variable. You are minimizing a number that does not correspond to a delivery you can use.

The variable that matters is the delivery month. A data center under construction has a power-on date, a colo contract has a ready-for-service milestone, and a model roadmap has a training start. Each of those is a date, not a price. The right procurement question is not "what is the cheapest GPU system I can buy this week," it is "what will it cost to take delivery of the systems I need, in the month my facility is ready to run them, with a counterparty bound to deliver." A forward contract is the instrument that answers that question. It lets you lock a price against a delivery date you choose, rather than chasing a spot quote against a delivery date the channel chooses for you.

Why the spot price is the wrong target

Data-center GPU lead times now run roughly 36 to 52 weeks, driven by constrained TSMC CoWoS advanced-packaging capacity, HBM shortages, and a spike in hyperscaler reservation activity. That single fact reorders the whole procurement problem. If the system you order today arrives in nine to twelve months, the spot price you optimized against was a price for hardware that someone else already reserved. It was never available to you on your timeline. You were comparing your buildout to a number that does not apply to it.

There is a second-order problem hiding behind the first. When you finally do place the order, you are committing to a delivery the channel does not guarantee in writing. A waitlist slot is an expression of intent, not an obligation. It can be re-sequenced when a larger buyer leans on the distributor, and your cluster slips a quarter while the colo lease keeps billing. You optimized the price and lost the date, which is the only thing that was scarce.

A forward inverts the optimization. You start from the date your facility is ready, you contract for delivery in that month, and you lock the unit price now so the number is known when you build the rest of your plan around it. The spot price becomes a benchmark you reference, not a moving target you chase. For a tier-2 cloud or an enterprise buildout team, that shift is the difference between a procurement plan you can underwrite and a series of opportunistic buys you cannot.

The three numbers that bind a forward

A Rillor forward contract carries a lot of structure, but the part that binds it, the part that turns intent into an enforceable commitment, comes down to three numbers.

The first is the delivery month. This is the term you actually came for. You name the month your systems must arrive, and the contract binds the seller to that window. Not "soon," not "subject to allocation," but a month written into the document. You set it against your facility-readiness milestone, with enough margin to absorb the integration and burn-in time between delivery and production.

The second is the locked unit price, expressed per complete OEM system. From the moment of execution, that number does not move. If the market reprices, your contract does not. This is what lets you quote your own customers, model your unit economics, and finance the buildout against a known input cost rather than a hope.

The third is the 10 percent deposit, held at execution by an independent escrow agent. This is the capital that makes the first two numbers real. It is not paid to the seller. It sits with a neutral third party, so neither side is trusting the other's treasury, and the balance is due at delivery. A 10 percent deposit on a Blackwell system is meaningful enough to filter out non-serious counterparties and small enough that you are not stranding capital for the life of the contract.

Delivery month
Bound, not indicative
Locked price
Per complete OEM system
10% deposit
Held in escrow at execution

Everything else, the bond, the transfer rights, the channel-compliance capture, exists to protect those three numbers. We walk the full instrument in the anatomy of a Rillor forward contract, and the deposit-and-escrow flow specifically in how independent escrow works in a Rillor forward contract.

Why a physical-delivery forward, and not a cash-settled bet

It matters which instrument you are using, because instruments that look similar settle very differently. A forward and a futures contract both let a buyer and seller lock a price for a transaction at a future delivery date. The difference, in CME Group's framing, is that forwards set custom delivery terms between a single buyer and seller, while futures are standardized exchange contracts. For a buyer who needs the actual hardware on a specific date, the customization is the point.

The deeper distinction is regulatory, and it works in the buyer's favor. Under CFTC guidance, intent to physically deliver the actual commodity is the essential element that excludes a forward contract from both the swap and the futures definitions. A forward is a commercial deferred-delivery transaction where delivery actually occurs but is delayed for commercial purposes. That is an exact description of what a buildout team is doing: a commercial transaction in physical systems, with delivery deferred to the month the facility is ready. Rillor's contracts are bilateral OTC forwards with the genuine intent of physical delivery, so they fall under the forward-contract exclusion. They are not exchange-listed futures, and they are never cash-settled.

The practical consequence is that the instrument cannot be hijacked by someone who only wants price exposure. A cash-settled position can be closed out for money before delivery ever comes due, which is exactly what a speculator wants and exactly what a buildout team does not need. A Rillor forward terminates in hardware on a loading dock. The deposit, the delivery obligation, the KYC, and the physical settlement all select for participants who actually intend to take systems. If you need the hardware, you want the instrument that guarantees hardware. We make the full case in why Rillor settles physically and never cash-settles, and the formal forward-versus-futures comparison in forward contracts versus futures for GPU systems.

A 12-month staged buildout, walked end to end

The clearest way to see this is to stage a real buildout across a year. Suppose you are standing up training and inference capacity in two phases, gated by two different colo milestones.

Phase one, Q1, against your first hall. Your first data hall reaches ready-for-service early in the year, air-cooled, with the power and thermal budget for HGX B200 systems. You contract RIL-GX-B200-2T, the standardized Rillor SKU that resolves to a complete 8-GPU OEM HGX B200 system on delivery, from whichever qualified OEM offers the best forward price for your delivery month: a Supermicro SYS-A22GA-NBRT, a Gigabyte G894-AD1-AAX5, a Dell PowerEdge XE9680L, a Lenovo SR680a V3, or an Aivres KR9288X3, among others. Each B200 GPU carries 180 GB of HBM3e, an 8-GPU baseboard totals up to 1.4 TB of HBM3e, and fifth-generation NVLink provides 1.8 TB/s of GPU-to-GPU interconnect. The DGX B200 reference for this platform delivers 3X the training and 15X the inference of the previous generation, which is why it is the workhorse buyers stage their first halls around. You lock the price now, set delivery to your Q1 milestone, and post the 10 percent deposit into escrow.

Phase two, Q4, against your liquid-cooled hall. Your second hall comes online in the back half of the year with direct-liquid cooling and the power density for rack-scale systems. Rather than wait and chase Q4 allocation when everyone else is, you layer in RIL-NVL72-GB300 racks now, against the Q4 delivery month. The GB300 NVL72 integrates 72 Blackwell Ultra GPUs and 36 Grace CPUs in a single rack-scale platform, with 130 TB/s of NVLink bandwidth, 20 TB of GPU memory, 17 TB of LPDDR5X CPU memory, and FP4 Tensor Core performance listed at 1,440 PFLOPS dense. You are contracting that capacity nine months out, at a locked price, with the deposit in escrow, while the rest of the market is still on a waitlist for the same quarter.

The point of staging is that each phase is locked against its own milestone, with its own delivery month and its own price, instead of being one undifferentiated order at the mercy of a single allocation calendar. Browse the standardized contracts on the marketplace and the full set of deliverable SKUs on the SKU index to see how the same approach extends across the catalog, from H200 and MI355X systems to the GB200 and GB300 rack lines.

PhaseSKUDelivery monthWhy it is locked now
Phase oneRIL-GX-B200-2TQ1, first hall readyAir-cooled B200 nodes against your earliest milestone, price fixed before lead times bite
Phase twoRIL-NVL72-GB300Q4, liquid-cooled hall readyRack-scale GB300 capacity reserved nine months out instead of fought for at the wire

The protections that make a forward safe to rely on

A forward only helps if you can rely on it, and a forward carries a risk that an exchange-cleared future does not: counterparty default. There is no clearinghouse standing behind a bilateral forward, so a buyer relying on actual hardware delivery needs independent protection. Rillor builds that protection into every contract through two mechanisms.

The first is the seller performance bond. In commodity markets, a performance bond is a guarantee from the seller to the buyer that, if the contracted commodity is not delivered, the buyer will be compensated for financial loss or other damages arising from the seller's failure to perform. On Rillor, the seller posts that bond at execution. If the seller slips the delivery month or fails to deliver, the bond gives you a real, pre-funded remedy, not a lawsuit you have to win before you see a dollar. It also changes the seller's incentives: a failure to deliver now has a direct cost to the seller, which makes the delivery month a commitment rather than a target.

The second is balance at delivery. You pay 10 percent at execution and the remaining 90 percent only when the systems arrive. The seller does not hold your full payment while you wait nine months for hardware that may or may not show. Your capital exposure during the life of the contract is the deposit, held by a neutral escrow agent, and the balance moves only against actual delivery. Together, the bond and the balance-at-delivery structure mean the seller carries the performance risk and the buyer carries almost none. What the bond covers, what it does not, and how default is handled on both sides is detailed in what a seller performance bond covers.

What it costs, against what a missed quarter costs

Rillor's economics are deliberately legible. The all-in take rate is 2 percent, split evenly, 1 percent paid by the buyer and 1 percent by the seller, plus roughly 1,000 dollars in escrow cost per contract. There is no hidden spread baked into the price you lock.

Put that against the thing it protects you from. The cost worth comparing is not the cost of the fee, it is the cost of a single missed quarter. If your first hall is energized and your B200 systems slip three months because a waitlist slot was re-sequenced, you are carrying the colo lease, the staff, and the power readiness against zero utilization for a quarter, while your own customer commitments slip with it. On a hall sized for even a few dozen systems, a stranded quarter runs well into seven figures of carrying cost and lost revenue. Against that, a 1 percent buyer fee on the contract value, plus 1,000 dollars of escrow, is a rounding error. You are not paying for a discount on the hardware. You are paying for the date to hold and for a bonded remedy if it does not. That is the trade, and for a buyer whose plan depends on the delivery month, it pencils easily.

When your forecast changes: transfer, not stranded capital

The objection a planning team will raise is that a forecast is a guess, and locking 12 months out means betting on a guess. The answer is that a Rillor forward is transferable. If your forecast changes, you are not stuck holding capacity you no longer need.

Before delivery, a contract can be transferred to another KYC'd buyer, with both Rillor and the OEM approving the handoff. That last condition is what keeps the transfer clean: the new buyer is verified, and the channel signs off, so the transfer does not break compliance. If you over-committed for a phase that shrank, or a workload moved to a different SKU, you can move the contract to a buyer who wants it rather than eat a position you cannot use. A forward you can transfer is an asset on your balance sheet, not just an obligation against it. The mechanics, step by step, are in pre-delivery transfer of a forward contract.

This is the structural answer to the forecast objection. Spot procurement gives you no way to unwind a commitment you regret, because there is no commitment until you buy, and once you buy you own depreciating hardware. A forward gives you a position you can resize, transfer, or hold, which is a more flexible instrument than the waitlist it replaces, not a more rigid one.

Channel compliance is captured at execution, so allocation cannot be re-routed

There is one more reason a forward holds where a waitlist drifts. NVIDIA is the channel and KYC authority for these systems, and channel compliance is enforced inside the Rillor contract, with the end-customer-of-record captured at the moment of execution.

That capture matters more than it looks. On a waitlist, allocation can be quietly re-routed between distributors and buyers because nothing pins the systems to you as the end customer. On a Rillor forward, the end-customer-of-record is recorded as a term of the contract from execution forward, which means the allocation is bound to you under the channel rules that govern these systems. It cannot be re-pointed at a larger buyer mid-stream without breaking the contract. The same capture survives a pre-delivery transfer, because the new end-customer-of-record is recorded when the channel approves the handoff. For a buyer, this is the difference between holding a slot the channel can move and holding a contract the channel has acknowledged. How that compliance is structured is covered in NVIDIA channel compliance inside a forward contract.

How to start

If your organization sources compute on the spot market, the change in posture is straightforward: start from your facility-readiness dates, work backward to the delivery months you need, and lock those months forward instead of chasing the spot quote that does not apply to your timeline. Rillor is invite only. Onboarding a buyer means verifying the entity, granting access to the marketplace and the forward curve, and walking the first contract through execution, deposit, escrow, and delivery. The buyer mechanics, the way tier-2 clouds, sovereign programs, and enterprise teams use the venue, are laid out on the for-buyers overview.

FOR BUYERS

Lock capacity before you need it.

Tier-2 clouds, sovereign AI programs, and enterprise buildouts use Rillor to commit forward delivery at a transparent price instead of negotiating one-off with each OEM.

See how buyers use Rillor
Sources & further reading
GET ACCESS

Trade the forward curve on Rillor.

Rillor is invite only. Verified buyers and sellers transact standardized forward contracts on OEM GPU systems, with physical delivery and independent escrow on every contract.

Become a Partner
NEWSLETTER

Get Rillor market reports in your inbox.

Allocation signals, forward-curve commentary, and product updates. No filler.