GPU Futures Explained: H100 vs B200 Compute Futures — 2026 Guide

GPU compute futures are derivatives linked to benchmark rental prices for graphics-processing-unit capacity. The underlying economic exposure is the cost of renting compute, not ownership of a graphics card, a data centre or shares in a chip manufacturer.

CME Group and Silicon Data designed the contracts around two widely followed Nvidia accelerator generations. GPU1 references H100 rental pricing and GPU2 references B200 rental pricing. This turns a normally fragmented infrastructure expense into a standardised futures exposure.

GPU1 is the Globex and ClearPort code for Silicon Data H100 Rental Index futures. GPU2 is the corresponding code for Silicon Data B200 Rental Index futures. Both use a 730 GPU-hour contract unit, are financially settled, carry a published $7.30 tick value and have monthly contracts listed out 36 months.

The difference is the underlying benchmark. GPU1 follows the Silicon Data Daily H100 Rental Index, while GPU2 follows the Silicon Data Daily B200 Rental Index. A trader is therefore taking exposure to the rental-price behaviour of one GPU generation rather than to a generic technology index.

Silicon Data's benchmarks measure hourly on-demand rental GPU costs from neocloud providers, meaning specialised compute providers outside the large hyperscaler category. CME describes the indexes as a way to bring price transparency to a market that has historically been fragmented and decentralised.

That distinction matters. A futures price based on rental benchmarks can react to changes in available capacity, demand for AI workloads, infrastructure build-out and the relative attractiveness of different GPU generations. It is not simply a proxy for Nvidia's share price.

Each GPU1 and GPU2 contract represents 730 GPU-hours. CME labels that amount as one month of capacity. The figure is close to the number of hours in an average calendar month, which makes the contract easier to relate to a monthly compute bill.

A buyer or seller is therefore dealing with a defined quantity of benchmark compute exposure. The unit standardisation is important because real-world cloud contracts can otherwise differ by provider, machine type, duration, utilisation and commercial terms.

CME publishes a value per tick of $7.30 for both GPU1 and GPU2. Because one contract represents 730 GPU-hours, a one-cent move in the index price per GPU-hour corresponds to 730 multiplied by $0.01, or $7.30.

The same relationship scales directly: a $0.10 move in the hourly index changes the contract value by $73, and a $1.00 move changes it by $730, before commissions, exchange fees, bid-ask spread and other execution costs.

Suppose the relevant rental index moves from $2.50 per GPU-hour to $2.60. The change is $0.10 per GPU-hour. Multiplying that by 730 GPU-hours gives a $73 change in contract value.

A long position would gain approximately $73 from that price move and a short position would lose approximately $73, before trading costs. The example is mechanical rather than predictive; it simply shows how the contract unit converts an index move into dollars.

GPU1 and GPU2 are financially settled contracts. Expiration therefore resolves through cash based on the contract's settlement process rather than requiring delivery of a physical H100 or B200 processor.

Financial settlement is especially logical for compute because the underlying service is rented processing capacity distributed across infrastructure providers. The futures contract standardises price exposure without attempting to standardise physical shipment, rack location, networking or cloud-account access.

CME lists monthly contracts as far as 36 months forward. That creates many more dated points than a futures market restricted to a small quarterly cycle and can potentially form a forward curve for expected compute costs.

For a business, different months could correspond to planned training runs, product launches or future infrastructure budgets. For a trader, the curve can also reveal whether distant compute prices are trading above or below nearer months, although a new market may initially have uneven liquidity across expiries.

H100 and B200 are different accelerator generations with different supply, demand and deployment cycles. A rental benchmark for one generation can therefore move differently from the other as customers migrate workloads, new capacity comes online or relative availability changes.

This is why GPU1 and GPU2 should not be treated as interchangeable tickers. Even if both respond to broad AI-compute demand, the spread between their rental prices can carry information about scarcity, adoption and the economics of each hardware generation.

The presence of Nvidia H100 and B200 hardware in the benchmark does not make GPU1 or GPU2 a derivative on Nvidia common stock. Nvidia shares reflect the value of a listed company with revenue, margins, competition, capital allocation and equity-market risk.

Compute futures instead reference the rental cost of access to specific GPU capacity. Nvidia shares could rise while rental prices fall if capacity expands faster than demand, or the reverse could happen. The exposures are related to the same AI ecosystem but economically distinct.

Potential commercial users include companies that expect future GPU rental expenditure and want a more predictable reference price. AI developers, model-training businesses, infrastructure operators and firms planning compute-intensive projects may all care about how rental costs evolve.

A hedge will not necessarily match an individual company's invoice perfectly. Provider discounts, geography, networking, storage, reserved capacity, service quality and specific machine configurations can create basis risk between a company's actual cost and the Silicon Data benchmark.

A speculative trader can use the contracts to express a view on future compute rental prices without operating a data centre or renting hundreds of GPU-hours directly. A bullish view on rental costs would generally favour long exposure, while a bearish view would generally favour short exposure.

The key word is exposure, not certainty. A new derivative can react sharply to small order flow, benchmark changes or new information about supply and demand. Position size should be based on the contract's dollar sensitivity and actual market liquidity rather than the novelty of the theme.

Because GPU1 and GPU2 reference different generations, traders may eventually focus on the relative value between H100 and B200 rental prices rather than the absolute direction of compute costs. CME's product notices include support for inter-commodity spread functionality between the compute contracts.

A spread view asks whether one benchmark will strengthen or weaken relative to the other. That introduces its own execution and basis risks, and early liquidity may be concentrated in outright contracts rather than every possible spread.

Contract specifications describe how a futures product works; they do not guarantee deep order books. New markets can have wider bid-ask spreads, fewer resting orders, low open interest and irregular activity while participants learn the product.

Before sending a live order, check current volume, open interest, spread and visible depth for the exact expiry. A market order that is harmless in a mature index future can behave very differently in a thin newly launched contract.

An exchange can list a new contract before every retail broker, data vendor and charting platform has completed symbol mapping, permissions and market-data support. A trader may therefore see the product on CME while it is still unavailable or read-only through a particular broker.

Confirm the exact broker symbol, exchange destination, contract month, trading permission and live data before building an execution workflow around GPU1 or GPU2. Do not assume a continuous or display symbol is the same identifier required for order routing.

Automation needs more than the text label GPU1 or GPU2. The system should resolve the active expiry, broker contract identifier, minimum tick, quantity, account permission and any rollover policy before an order becomes eligible for submission.

Risk logic should use the 730 GPU-hour multiplier and current contract specification rather than borrowing assumptions from equity-index, metals or energy futures. New instruments also deserve conservative paper or no-submit testing before live routing is enabled.

A benchmark hedge works best when the benchmark behaves similarly to the user's real economic exposure. A company renting H100 capacity under a long-term negotiated contract may experience a different price path from an index built from on-demand neocloud offers.

That difference is basis risk. It does not make the futures unusable, but it means hedge effectiveness should be measured against actual invoices or internal compute costs rather than assumed from the product name.

For a newly launched futures market, useful signals include daily volume, open interest, bid-ask spread, the number of active expiries, concentration of trading in near months and the behaviour of the GPU1-GPU2 relationship.

It is also worth watching whether broker coverage expands and whether the forward curve becomes consistently quoted. Those operational signs can matter more to execution quality than a compelling long-term narrative about AI demand.

Before trading GPU1 or GPU2, confirm the underlying index, contract month, 730 GPU-hour unit, $7.30 tick value, financial settlement, broker symbol, market-data permission, current spread, volume, open interest and expected round-trip cost.

Then define the maximum dollar risk for the trade, calculate how far the market can move before that risk is reached, and decide how rollover or expiry will be handled. Treat compute futures as a real leveraged contract first and an AI theme second.