Why Compute Still Trades in Group Chats — Affaan Mustafa & Alejandro Soumah Fernandez, Jump Trading

A company buying a fixed block of GPU capacity for several years may negotiate the deal in Slack messages, X messages or Telegram group chats. Public marketplaces exist, but much of this longer-term business happens through private quotes and bilateral agreements. Affaan Mustafa and Alejandro Soumah Fernandez, compute-trading co-leads at Jump Trading, begin with that gap between visible prices and the way substantial capacity commitments actually change hands.

Mustafa calls this an “unlit market.” His use of dark pools describes negotiations outside public view, rather than establishing that compute trades through the same machinery as a financial dark pool. The underlying transactions are commercial agreements: some combination of a master services agreement, a service-level agreement and an order form, with language specific to the cluster and its hardware.

That specificity matters because pricing conversations often collapse the product into a chip identifier: H100, H200 or another SKU. The actual purchase includes a particular amount of capacity, a term, a total contract value and cluster-specific obligations. An on-demand price reference can help start the conversation, but it does not describe the entire agreement being negotiated. There is no widely adopted physical-compute exchange that brings all those transactions into one public venue.

Falling token prices seem, at first, to imply falling demand for expensive GPUs. The missing variable is how much work people choose to run. Mustafa introduces a capability-cost graph attributed to a16z: as a given capability becomes cheaper, a team can do more within the same budget. Previously uneconomic applications become possible. The price of intelligence, the number of tasks requested and the hardware needed to serve those tasks are three different quantities.

How can token prices keep falling while compute prices hold up? The comparison Mustafa describes shows those prices decoupling. He offers Jevons paradox as one possible explanation: more efficient inference reduces the resources needed per task, while cheaper tasks encourage enough additional use to outweigh that saving. This is a proposed explanation for the observed divergence, rather than a demonstrated allocation of its causes.

The causal steps are straightforward. More efficient GPUs and serving systems lower token costs; teams spend their budgets on more tokens; inference clouds serve more applications; application developers can reach more customers. The capacity supporting all that activity still has to be built and paid for. A cheaper unit of output therefore does not, by itself, establish that the aggregate hardware bill should fall.

A chip is only one input to usable compute. Power, buildings, grid connections and capital must arrive together before a customer can consume a GPU hour. Mustafa cites an IEA April update projecting global data-center electricity use rising from 485 terawatt-hours in 2025 to 950 in 2030. The projection frames the practical questions facing operators and lenders: where to obtain land, how to secure electricity and whether the grid can support the planned build-out.

Which activities converge to produce capacity, and who consumes it? The supply map separates equipment from the facilities that make it usable. Chip and system vendors supply GPU servers, memory and networking. Sites and operators supply power, space, assembly and management. Capacity providers—including hyperscalers, neoclouds and other bare-metal operators—make the resulting compute available to users. Upstream constraints feed into both its cost and its availability.

These are roles, rather than mutually exclusive kinds of company. A business can build the infrastructure, operate it and consume the compute itself. At the user end, the workloads span startups, inference clouds, labs, application companies and enterprises running open-weight models. The map explains the dependencies without requiring every GPU hour to pass through a separate company at each stage.

An inference cloud can rent a cluster, sell tokens from it and use that revenue to pay for the cluster. The difficulty is financing the commitment before the revenue arrives. Hyperscalers, frontier labs and larger neoclouds can raise substantial equity, take on debt and sign long-horizon agreements. A Series B startup facing a compute contract worth more than $200 million over three years has a much harder underwriting problem.

Lenders want confidence that a build-out will generate enough revenue to repay their loans. A young private company may have limited cash flow or no revenue at all, so contracted customer revenue becomes especially important. Mustafa points to CoreWeave's public filings as a large-scale example of infrastructure financing supported by take-or-pay customer contracts. Long commitments help support financing, while customers may be reluctant or unable to commit for 36 months.

The upfront cash requirement makes this mismatch concrete. Mustafa attributes a 15–25% prepayment range to CoreWeave; on a $100 million contract, that means $15–25 million paid before the startup can use the money elsewhere. He then switches to a separate illustrative case: a company raises $40 million, signs a $100 million compute contract over three years and prepays 30%. The $30 million prepayment leaves $10 million to run the business.

How does that financing constraint turn into a capacity constraint? The example describes contracted capacity growing as a step function: each new cluster requires another large commitment. Demand can sit below the purchased block, leaving capacity unused, then exceed the available capacity before the company can finance the next block. Growth can become tied to the next equity round, even when customers already want the service.

The company has several responses, each with a different cost:

• Turn customers away: Wait until another financing round supports the next capacity commitment, sacrificing business in the meantime.
• Bridge with on-demand capacity: Buy enough short-term compute to cover the shortfall, provided that capacity is available and its price works for the business.
• Finance the prepayment: Borrow the upfront amount and compare that financing cost with the cost of covering the same need on demand.

The recording leaves this as an economic comparison rather than supplying a rate at which borrowing becomes preferable. Availability matters alongside price: an attractive on-demand quote cannot bridge a shortage if the required capacity cannot actually be obtained.

Procurement also determines how much of the physical system a company controls. Mustafa lays out three operating models:

• Build and operate: Own the hardware and site, arrange power and permits, and handle assembly and management.
• Own servers in colocation: Retain server ownership while a partner handles more of the facility, assembly and operating work.
• Sign an offtake contract: Buy defined capacity from a provider that owns and operates the assets. Access can vary, including restrictions on root access and differences between single-tenant and multi-tenant configurations.

Those differences affect both price and what the customer can do with the system.

The value of ownership depends on the workload. Physical access, confidential compute, network topology and the ability to reconfigure a system can matter enough to justify more control and expense. Renting may carry an opportunity cost if the provider's configuration prevents the business from doing something valuable. A comparison based only on GPU-hour prices would miss that cost.

Utilization changes the comparison too. Mustafa describes an illustrative ownership-versus-rental graph and asks whether a $100 million commitment over three years approaches the cost of building and financing a cluster—or even buying the operator. Time and operating costs still belong in that calculation. The graph offers a way to think about the choice, without establishing a universal break-even utilization: sufficiently heavy use can make ownership attractive, while the expense and work of owning the stack remain consequential.

These decisions reach directly into startup runway. Access and payment terms determine how much cash remains for the rest of the company, giving venture investors a practical reason to help portfolio companies find and finance suitable capacity. Procurement can improve the underlying investment by matching the purchase to the company's needs. That leads into the market's next question: who finds the capacity, compares the offers and carries the risks between buyer and supplier?

Several kinds of intermediary work around the GPU hour, solving different parts of a transaction:

• Price discovery: Indexes, data and benchmarks provide reference prices. Mustafa describes benchmarks as possible foundations for future futures contracts, subject to their specifications and approval.
• Physical matching: Auctions, aggregators, on-demand marketplaces, pooled capacity services, bare-metal resellers and neoclouds connect available compute with buyers. Some pools divide capacity into smaller purchases under their own standardized contracts.
• Desks and brokers: Relationships and visibility into bilateral quotes help locate capacity and negotiate execution.
• Credit and financing: Equipment lenders, lessors and specialist credit providers finance assets or payment obligations.

A broker's spread can reflect more than access to a contact list. Consider a buyer that needs compute immediately and is relatively insensitive to price. A desk that sees comparable specifications across several quotes may find a cluster that can be ready in time, negotiate the source and charge for filling the urgent need. If it also carries risk or undertakes to operate the cluster for the buyer, the spread must compensate it for those responsibilities.

Financial structures address another set of needs. Mustafa describes prepayment facilities coming online and interest in futures, derivatives and options to hedge exposures already on companies' books. Buyers also want flexibility inside physical contracts: after committing for three to five years, could they upgrade when a new chipset arrives, roll the commitment forward or sell capacity back? These are different contractual rights, each changing who bears the cost of uncertain future demand and hardware changes.

Every deal being bespoke creates work before anyone can compare prices. Specification sheets arrive in different formats. A bill of materials can change when a part is missing or out of stock, and equipment manufacturers can have long lead times. Even a familiar word can hide a material difference: does “memory” mean GPU VRAM, CPU memory or additional storage? The answer changes which workloads fit, what the buyer needs and how the offer should be priced.

This is the market's non-fungibility problem: one cluster cannot automatically substitute for another. A chip SKU may carry much of the pricing weight, yet other specifications and delivery conditions can make the quote applicable only to that particular cluster. The standardization question is therefore which attributes can be made comparable and which must remain part of a specific product description. Without that distinction, a common GPU label gives a false impression of interchangeability.

What does a public H100 price comparison actually tell a buyer? Mustafa presents a snapshot of public on-demand or spot references with differing prices. Such quotes provide starting points alongside private transaction experience; a seller still adjusts for the actual cluster and the other terms. Prices can change daily or faster, bids can be shopped around, and credit wording changes the offer. The snapshot illustrates variation in visible references, rather than a single executable price for any H100 cluster.

The useful contract starts with the exposure a business needs to manage. An inference cloud selling a fixed-price service while paying a floating GPU bill faces price risk: its input cost can move without a matching change in customer revenue. Locking capacity for years can reduce part of that exposure, but it creates another obligation—the company pays for hours even when it cannot use them.

The available structures solve different problems:

• Long-term capacity commitments: Secure capacity and reduce some price exposure, while creating the possibility of paid but idle hours.
• Resale rights: Offer a way to recover value from spare capacity, provided another buyer can actually purchase those hours.
• Financial hedges: Address movements in a reference price. A cash-settled hedge cannot deliver the required cluster or guarantee that purchased capacity will be utilized.

Bridging capacity, flexible commitments, resale rights and price protection belong in the same conversation because a company may need several of them. Treating one as a complete solution merely moves the unresolved risk elsewhere.

Policy also shapes who can obtain compute and under what conditions. The closing policy section cites a January U.S. Commerce Department change moving qualifying H200-class license reviews for China and Macau to case-by-case review with conditions. It also cites the U.S. AI Action Plan's support for open-source and open-weight AI and its recommendation to improve compute financial markets so startups and academics can access large-scale computing power. These are policy examples presented in the recording; eligibility remains conditional, rather than a general promise of access.

The commercial opportunity returns to the middle market. Growing companies have real workloads, but their financing, timing and specification needs often do not fit the contracts that hyperscalers and frontier labs can sign. Suppliers want long commitments to support a build-out. Buyers want to expand in smaller blocks as volatile demand becomes clearer, avoiding payment for capacity they cannot yet use.

Common capacity contracts, specifications, terms and definitions would make offers easier to compare. They would not eliminate the mismatch in commitments. Mustafa's proposal also requires well-capitalized participants able to bridge buyer and supplier needs: firms with strong credit, the ability to assess the risks and balance sheets that are not all exposed to the same market movements.

That role requires understanding delivery and workloads as well as quoting a GPU hour. Hardware expertise matters because the intermediary must judge whether the promised system will serve the buyer's needs; financial strength matters because buyer demand and supplier obligations do not line up neatly. The closing invitation—“let's build this together”—is a proposal to combine those capabilities into a market that growing companies can actually use.