Why Compute Is Difficult to Trade

The problem: compute is difficult to trade

AI teams often describe compute shortages as a simple capacity problem: there are not enough GPUs, so more GPUs must be built. The deeper problem is that compute is not a homogeneous commodity. A machine-learning workload needs a particular kind of accelerator, in a particular topology, with enough memory, network bandwidth, power, storage, and uptime, at a time when the software stack can actually use it.

That makes “available capacity” an ambiguous number. An idle accelerator in another region may be useless for a latency-sensitive service. A cluster with enough chips may still fail a distributed training job if its interconnect is slow or if instances are preempted. Even a machine that satisfies a hardware specification can be impractical if the required drivers, kernels, or libraries are unavailable.

The constraints interact. A buyer may accept a lower price in exchange for interruptibility, but only if the job can checkpoint and resume. A provider may advertise a large pool of devices, but the useful capacity depends on whether those devices can be assembled into the required placement at the same time. Network, storage, and power limits can turn nominal accelerator supply into much less usable capacity.

The argument behind treating compute as a new kind of resource is therefore not that GPUs resemble barrels of oil. It is that AI systems need a tradable input whose value depends heavily on location, timing, technical properties, and reliability. The unit being exchanged must describe the conditions under which computation can actually be completed.

How it works

A compute market has several layers. At the bottom is physical capacity: accelerators, host CPUs, memory, networking, cooling, electricity, and data-center space. Above that is an allocation layer that turns this capacity into jobs, reservations, or services. The allocation layer must match a workload’s requirements against machines that satisfy them, while accounting for when the resources will be available and how long they can remain available.

For inference, the important variables may be accelerator memory, tokens per second, batching behavior, and tail latency. A system that is inexpensive at full utilization may perform poorly when requests arrive unevenly or when batching increases response time. For training, the problem is more constrained: a job may require many similar devices connected with low-latency links, and its cost can rise sharply when workers wait for the slowest participant. The scheduler is not merely selecting cheap machines; it is selecting a topology and execution plan.

A market can represent a supply offer as a multidimensional contract rather than a single price:

offer = {
    "accelerator": "GPU",
    "memory_gb": 80,
    "count": 64,
    "region": "eu-west",
    "network": "high_bandwidth",
    "start": "2026-11-01T00:00:00Z",
    "duration_hours": 12,
    "interruptible": False,
}

A buyer can then submit constraints and preferences: minimum memory, acceptable regions, deadline, interruption tolerance, and maximum price. The matching engine can reserve capacity, split a job across providers, or reject the request when the constraints cannot be met. Splitting may be useful for loosely coupled workloads, but it is not automatically valid for tightly synchronized training, where placement and communication can dominate the result.

Settlement is another part of the mechanism. A reservation should specify whether the buyer pays for wall-clock time, successful work, or a committed block of capacity. It should also define what happens when a host fails, power is curtailed, a network link degrades, or a provider returns fewer usable devices than promised. Without those terms, a market can appear liquid while leaving the buyer to absorb nearly all operational risk.

What the evidence actually shows

The strongest evidence is operational rather than rhetorical: teams routinely struggle to turn nominal capacity into dependable training and serving capacity. The existence of specialized offerings, high-speed variants, and provider-specific configurations indicates that users care about more than the number of accelerators. They care about performance characteristics and the conditions under which that performance is delivered.

Those conditions affect the economics of a job. A lower-priced machine may deliver less useful work if communication stalls, if data must be moved across regions, or if a failure forces a restart. Conversely, a more expensive reservation can be valuable when it provides stable placement and makes completion time predictable. The relevant comparison is therefore between end-to-end outcomes, not just listed rates.

Energy is part of the same evidence. The carbon intensity of a workload depends on where and when it runs, not only on how much computation it performs. A job moved between grids can have a materially different environmental cost even when the model, batch size, and accelerator count remain unchanged. Location and timing are consequently operational attributes as well as environmental ones.

These observations support a market with location- and time-aware pricing. They do not prove that a single global exchange is the right design, nor that open trading will automatically reduce costs. They show that the abstraction of one universal “GPU-hour” is too coarse for many real workloads.

Using it

Start by describing workloads in terms that a scheduler or provider can verify. Record accelerator type, memory use, interconnect needs, expected utilization, checkpoint behavior, data location, latency targets, and whether interruption is acceptable. Separate hard constraints from preferences; otherwise a matching system will either overconstrain requests or make unsafe substitutions.

The distinction matters during procurement and scheduling. A data-location rule may be non-negotiable, while a preference for one accelerator family may be relaxed if an equivalent option passes a performance test. Similarly, an inference service may tolerate changes in capacity if routing can move traffic, whereas a synchronized training job may require a fixed group of devices for the duration of a run.

Measure effective work, not just rented time. For training, track useful steps per hour, restart time, checkpoint transfer cost, and synchronization stalls. For inference, track tokens per second at the required percentile latency, including queueing and cold-start effects. These measurements let you compare offers that look different on paper and identify which parts of a contract are creating real value.

Use flexible capacity only when the application is designed for it. Training jobs should checkpoint frequently enough to tolerate eviction, and inference systems should have routing, warm spares, or graceful degradation. A portable container is not sufficient portability if kernels, drivers, model-parallel libraries, or network assumptions tie the workload to one provider.

Keep an internal record of the full cost:

effective_cost =
    instance_cost
  + storage_and_egress
  + orchestration_overhead
  + failed_work
  + migration_or_restart_cost

This makes market quotes comparable and exposes the value of reliability. A cheaper interruptible instance can be more expensive if it repeatedly destroys long-running work. It also gives engineering and finance teams a shared way to evaluate a reservation: the best offer is the one that completes the required work under the required conditions.

Limitations and failure modes

Compute is difficult to standardize because hardware performance depends on software and workload shape. Two systems with the same accelerator count can produce different results because of compiler versions, kernel availability, memory pressure, communication libraries, or placement. A market may therefore need executable tests or performance attestations, not just provider-supplied specifications.

Attestations themselves need context. A result measured on one model, batch size, or communication pattern may not predict performance for another workload. Buyers should be able to distinguish a guaranteed property, such as a location or device count, from an estimate based on a benchmark. Otherwise precise-looking listings can create false confidence without making offers genuinely comparable.

There are also serious coordination risks. Providers may report capacity optimistically, reserve the best machines for internal customers, or make offers hard to compare. Buyers can create instability by canceling reservations, flooding the market with speculative requests, or concentrating demand in one region. A matching system must account for these behaviors rather than assuming every listing represents firm, independent supply.

A compute exchange cannot remove physical scarcity. Power interconnection, cooling, construction time, and chip supply remain bottlenecks. Nor does geographic optimization automatically solve emissions: moving work to a cleaner grid may conflict with data-residency rules, latency requirements, or available network capacity.

Finally, fragmentation can worsen portability. If every provider exposes a different scheduling model, billing contract, and reliability definition, users may become dependent on intermediaries rather than gaining a liquid market. The interface may look standardized while the underlying operational assumptions remain provider-specific.

What to watch

The most revealing developments will be the interfaces between providers and schedulers: portable workload descriptions, verifiable performance claims, and contracts that price interruption and failure explicitly. Watch whether buyers can compare effective completed work across heterogeneous systems, rather than merely comparing hourly rental rates.

It will also matter whether contracts make capacity commitments enforceable. A useful offer should communicate what is reserved, what can change during execution, and how compensation or replacement works when the promised service is unavailable. Those details determine whether a buyer can plan a training run or serving deployment around a market purchase.

Carbon-aware scheduling will test whether environmental attributes can be treated as first-class constraints without making jobs unpredictable. A scheduler may need to balance cleaner execution against data location, deadline, latency, and capacity availability rather than optimizing any one variable in isolation.

The practical outcome will depend less on a slogan about compute as a resource than on whether these details become machine-readable, enforceable, and useful to engineers.