GPU Capacity Still Trades Through Private Quotes and Bespoke Contracts

? affaan-mustafa describes compute trading as a largely private market: capacity is sold in blocks through private quotes, brokers and long bilateral contracts, rather than on a widely used exchange. A transaction may combine a master services agreement, a service-level agreement and an order form, with terms specific to a cluster and its hardware. Negotiators may focus on the GPU model—an H100, H200 or B300, for example—but the price applies to a particular bundle of capacity and conditions.

That makes “dark pool” a description of where deals happen, not a claim that compute is traded like a standardized financial instrument. Mustafa says long-term capacity deals often move through Slack, X and Telegram chats. Public marketplaces and on-demand prices provide some reference points, but the larger commitments are negotiated out of view.

The market’s economics also resist a simple inference from falling token prices. Mustafa points to a chart comparing the cost of end-use technology across investment cycles: the cost of a given capability can fall sharply, but the total bill still depends on which model is used, how much it is used and how much capacity is purchased. A cheaper task can make more tasks affordable. In his account, teams are responding to lower token costs by using more tokens, and applications that were previously too expensive can become viable.

He frames the resulting demand response through the Jevons paradox: efficiency can encourage enough additional use to outweigh the resources saved per task. The chart he showed compared H100 rental prices with a token-price expenditure index. Its stated pattern was that token and compute prices first declined together, then token prices continued falling while base compute prices remained robust. Mustafa offered increased usage as one possible explanation, not the only one. More efficient inference can lead to more applications, more tokens served and a larger market for inference providers; app-layer companies can, in turn, serve more customers.

The distinction is between the price of intelligence, the number of tasks customers want to run and the hardware required to serve them. Lower cost per task does not itself remove the need to build and pay for capacity.

Mustafa reduces the supply chain behind usable compute to four ingredients: chips, power, buildings and money. GPUs do not become a usable GPU-hour on their own. Power, data-center space, grid connections and capital must also come together; Mustafa says costs and constraints upstream can affect compute costs and usage.

The figure, which Mustafa attributes to the IEA’s April 2024 update, covers global data centers. He connects the projected increase to questions about grid access, alternative energy sources and where land is available for new sites. Data-center operators, colocation providers and lenders are among the participants considering those buildout requirements.

The chain runs from chip and system vendors supplying GPUs, memory, servers and networking, through sites and operators that provide power, space, assembly and management, to capacity providers such as hyperscalers, neoclouds and dedicated-cluster operators. Compute users include labs, inference clouds, startups and enterprises. Mustafa cautions that these are functional categories, not sealed-off roles: one company can span several layers. An inference cloud, for example, might rent a cluster, sell tokens to customers and use the resulting revenue to pay for the capacity.

Mustafa says hyperscalers, frontier labs and larger neoclouds can make substantial commitments because they can raise significant equity, take on more debt and enter long-horizon deals. He identifies a gap for companies in the middle: who will underwrite a Series B startup’s commitment to a $200 million-plus compute contract over three years? And how many funding rounds would it take if the contract consumed most of the company’s equity?

Lenders financing infrastructure want evidence that the loan will be repaid. For a private, possibly pre-revenue company, Mustafa says contracted revenue can help provide that confidence. He points to CoreWeave’s public filings as a large-scale example of infrastructure financing supported by take-or-pay customer contracts.

But the supplier’s financing horizon and the customer’s willingness to commit may not match. Hardware financing may run for three years while a customer contract lasts two, leaving a period in which the asset must be re-let. The presentation labeled this an illustrative term mismatch, not an observed transaction.

The upfront payment can be difficult even when the total contract is within reach. Mustafa says CoreWeave has quoted median prepayments of 15 to 25 percent. On a $100 million cluster contract, that would mean $15 million to $25 million upfront—potentially a substantial share of a startup’s available capital.

One illustrative slide made the pressure concrete: a company raises $40 million, needs a $100 million contract over three years, and pays 30 percent upfront. That leaves $10 million to run the business. The example is not a forecast; it shows how the terms of capacity procurement can affect runway before the compute is used.

Capacity also arrives in blocks, while customer demand may grow unevenly. If demand exceeds a company’s committed capacity, it can turn customers away or use on-demand capacity to bridge the shortfall. If demand falls below the commitment, it may be paying for idle capacity. Mustafa also raises financing the prepayment as an alternative, but says the relevant comparison is economic: if the cost of financing that payment exceeds the cost of buying capacity on demand, the financing may not make sense.

That is why procurement terms matter to investors, not only to the team buying GPUs. Access to capacity and the timing of payments affect how much runway a portfolio company has, Mustafa says. Investors may have an interest in helping a company find suitable capacity or finance it, because those terms affect the underlying investment.

Companies can buy access to compute in different ways. They can build and operate the full stack, arranging hardware, power, permits, assembly and management themselves. They can own servers in a colocation facility and rely on a partner for some operations, or manage the equipment themselves. Or they can sign a capacity offtake contract, in which the provider owns and operates the infrastructure.

The last option does not necessarily provide full access to the underlying hardware. Mustafa says access may vary with the arrangement, including whether the environment is single- or multi-tenant. Physical access, confidential computing, topology changes and the ability to reconfigure a system may matter to some workloads. A company that values those capabilities may prefer greater control, even if operating its own infrastructure carries additional costs.

The comparison between owning and renting therefore depends on utilization and on what is included in the agreement. The presentation’s hypothetical chart showed ownership and rental costs meeting at 12,500 used GPU-hours under a specific set of assumptions: $25,000 in net fixed ownership costs, $1 per operating hour and $3 per rental hour. Mustafa described the chart as crude. Its crossover is not a general market price; it illustrates that assumptions determine where ownership becomes cheaper.

He also cautions that a term offtake contract is not necessarily equivalent to pay-as-used rental. A customer may pay for allocated hours even when they are idle. For a company spending heavily over several years, owning and operating a cluster may be worth considering, but that comparison must include the time and operating costs of ownership. A buyer with highly variable usage may find rental more suitable; one with sustained utilization may find control and ownership more attractive.

The roles forming around a GPU-hour range from price discovery and physical matching to financing and operations. Indices and benchmarks provide reference points, while venues, auctions and aggregators seek to match capacity offers with suitable workloads. Mustafa also describes decentralized marketplaces and liquid pools that coordinate on-demand capacity, as well as bare-metal resellers and neoclouds selling larger blocks.

Brokers and desks work differently from those matching venues. They source and negotiate bilateral quotes, and may be able to move quickly because they know buyers and sellers and can compare offers with similar specifications. Mustafa gives the example of a buyer that needs capacity urgently and is less sensitive to price: a broker may be able to secure the required capacity in time and charge a spread. The broker still has to source and negotiate the deal, and may carry or place risk or operate the cluster. The spread has to justify that work.

Financial markets address price exposure, not physical delivery. Mustafa says futures and derivatives may help participants hedge price or balance-sheet risk and support more complex agreements. But, as he puts it, a cash-settled financial hedge cannot deliver a cluster or guarantee utilization. A buyer looking to hedge a reference price still needs physical capacity; an inference cloud selling a fixed-price service while its GPU bill floats has a different risk to manage. Locking capacity for years may address some price exposure but can leave the provider paying for idle hours. Reselling spare capacity helps only if another buyer can take those hours.

Credit and financing providers address the funding required for hardware and commitments. The talk also points to insurance and operational services—including telemetry, metering, billing and collateral—as functions around the GPU-hour. These roles can overlap, but each structure should start with the particular risk it is meant to manage. Mustafa mentions flexible contracts, prepayment facilities, and possible buyback or sell-back clauses among the structures being considered.

The underlying transactions remain difficult to compare. Mustafa says spec sheets and formats differ; bills of materials may not line up; delivery can change if parts are unavailable; and long lead times complicate offers. Even familiar terms can mean different things. “Memory,” for instance, could refer to GPU memory, CPU memory or storage, distinctions that affect what workloads can run. Before comparing prices, the parties may need substantial back-and-forth to establish what is actually being offered.

Public H100 references can help, but Mustafa presents them as references, not quotes. A slide snapshot dated October 13, 2026, listed $2.85 per GPU-hour from Silicon Data, $3.32 from SemiAnalysis, $2.96 from Compute Desk and $3.17 from Ornn. The slide noted that the figures use different definitions and methods. Mustafa says prices can update daily or faster; a quote is a starting point; bids may be shopped; and creditworthiness affects the offer. A published figure for one specification does not settle the price of another cluster with different terms, delivery dates or buyer risk.

The standardization problem is deciding which parts of a deal can be made comparable and which remain specific to a cluster. Mustafa points to the GPU SKU as an important reference, while noting that other parts of the transaction may still be priced as a one-off product.

? alejandro-soumah places those market questions inside a policy environment. He says that in January 2026 the US Commerce Department moved qualifying H200-class license reviews for China and Macau to case-by-case review with conditions. He also connects open-weight AI policy to access to compute: according to Soumah, the US AI Action Plan encourages open-source and open-weight AI and recommends improving the financial market for compute so startups and academics can access large-scale computing power. The presentation also identifies power and permitting as factors affecting when capacity becomes usable.

The opportunity Mustafa identifies is among growing companies whose workloads are real but whose needs do not fit the long commitments available to the largest buyers. Suppliers may need a long-term commitment to finance a buildout; buyers may want to add capacity in smaller blocks as demand becomes clearer. Buyers also need a way to avoid paying too early for capacity they cannot yet use.

Mustafa argues that bridging this gap takes more than quoting a GPU-hour price. It requires assessing the workload, delivery and contractual terms, as well as the credit and capacity risks on both sides. A well-capitalized participant with a strong credit profile and the ability to assess those risks could help connect suppliers seeking longer commitments with buyers whose demand and financing arrive in smaller steps.

For that market to function more consistently, Mustafa says, participants need a standard capacity contract built around common specifications, terms and definitions. The problem is not simply that compute lacks a public price. Capacity is difficult to compare, expensive to commit to and financed on timelines that may not match a buyer’s growth. A more usable market would have to address those mismatches together.