Why We Don’t Need More Data Centers

If a startup needs a thousand GPUs, will building more data centers solve its compute problem? More capacity helps, but it does not automatically make existing GPUs affordable or available to the people who need them. Construction must be accompanied by better allocation. That is the qualification behind Jasper Zhang’s provocative title: he considers new data centers important, but insufficient on their own.

Zhang introduces himself as Hyperbolic’s CEO and co-founder, with a background in mathematical and financial efficiency. He says he completed his Berkeley mathematics PhD in two years—a university speed record in his account—and won several gold medals before working at Citadel Securities on AI and machine learning for market prediction and strategy execution. The practical concern carrying into Hyperbolic is cost: Zhang frames a 1,000-GPU operation as a multimillion-dollar annual expense. His proposed complement to construction is a GPU marketplace.

As AI spreads into more products and companies, demand for GPUs also becomes demand for buildings, power, and supporting infrastructure. Zhang attributes a stark forecast to McKinsey: by 2030, four times more data centers will be needed, built in one quarter of the time.

He then expresses demand in electrical capacity: 55 GW currently, 22% annual growth in a median scenario, and 290 GW needed by 2030. These are the figures presented in the talk, rather than a consistent restatement of McKinsey’s published scenarios. The relevant McKinsey analysis measures demand through power consumption, not building count, and separates its median and accelerated growth cases. The distinction matters: a multiple of capacity is not necessarily the same multiple of buildings.

A data center must pass several bottlenecks before its GPUs can serve a workload. Zhang’s examples move from capital to power delivery and then operating impact:

• Construction cost: he puts the first Stargate data center at more than $1 billion.
• Grid connection: he cites a seven-year wait to connect a 100 MW facility in Northern Virginia.
• Electricity consumption: he attributes 4% of total US electricity consumption to GPUs and data centers.
• Emissions: he also points to annual CO₂ emissions as a sustainability concern.

These are the talk’s infrastructure examples, not a site-specific construction or interconnection estimate. They explain why adding hardware and delivering usable compute are different tasks.

Even timely delivery of announced projects would not necessarily close the gap. Zhang cites a conditional US data-center supply deficit exceeding 15 GW by 2030, assuming the planned facilities arrive on time. That leaves a reason to improve the use of existing capacity while new capacity is being built.

The other side of scarcity is underutilization. Zhang attributes an estimate of 80% idle time for enterprise GPUs to Deloitte; the population and measurement window behind that estimate are not specified. He also cites more than 100 GPU clouds, a fragmented market described in SemiAnalysis’s GPU Cloud ClusterMAX analysis. A large supplier count does not mean every provider is ready to serve every workload. Buyers can struggle to locate affordable GPUs while capacity sits unused elsewhere.

A marketplace addresses that mismatch by aggregating data centers and GPU providers behind a shared access point. Zhang uses Hyperbolic as the example, but the allocation mechanism does not depend on that particular company: make dispersed supply discoverable and rentable by people outside the provider’s existing customer base.

Hyperbolic calls its orchestration software HyperDOS, short for Hyperbolic Distributed Operating System. Zhang initially describes it as Kubernetes-like software that brings a provider’s cluster into a global network. He says a cluster can join the network within five minutes of installing HyperDOS. The installation is the proposed bridge between a provider owning compute and that compute becoming accessible through the marketplace.

On the buyer side, Zhang describes several ways to consume that capacity:

The intended benefits are better matching between supply and demand, commodity-style purchasing instead of waiting for a new data center, and a wider choice of suppliers and rental arrangements.

Zhang reports modeled cost reductions of 50–75%, without presenting the derivation. He then gives the following price comparisons from the period of the talk:

The comparison does not specify equivalent configurations, regions, included resources, or contract terms. It illustrates the price differences Zhang is pointing to, rather than establishing a like-for-like procurement benchmark. His economic explanation is that aggregating more supply through a uniform distribution channel can lower prices.

He names M/M/c queueing theory as the theoretical basis for the pooling argument, but defers the mathematics. The useful intuition is that a shared route to multiple suppliers gives demand more opportunities to find available capacity. The talk does not provide the arrival rates, service rates, or other assumptions needed to derive its savings estimate from that model.

Pooling can also reduce procurement work. Zhang asks founders to recognize the experience of contacting more than five suppliers and sitting through sales calls to learn which facilities have suitable GPUs. In the marketplace he describes, users would select providers by ratings and price instead. GPU performance benchmarking is a planned addition, intended to make the comparison more informative than price alone.

Consider Zhang’s startup example. The company initially reserves 1,000 GPUs for a year, expecting to use them for training and later inference. Three months of experiments produce a better idea, and the team needs another 1,000 GPUs—but only for one month. By month six, training is finished. Hosting the resulting model needs just 500 GPUs, leaving 500 GPUs from the original reservation idle. The workload has changed twice, while the original annual commitment remains.

The marketplace path keeps the original reservation but changes how the startup handles the mismatch:

1. Reserve the baseline: rent 1,000 GPUs for the year.
2. Rent the temporary increment: at month three, add 1,000 GPUs for one month.
3. Offer unused capacity to others: at month six, relist the 500 idle GPUs from the original reservation.

Relisting proposes a new use for capacity already committed. It does not mean the reservation disappears, or that another customer has necessarily rented it.

Zhang contrasts this with a traditional-cloud scenario in which the extra 1,000 GPUs also require a year-long reservation. Combining rental flexibility, relisting, and different GPU prices, he quotes a reduction from $43.8 million to $6.9 million, which he describes as roughly sixfold savings. The talk does not supply enough contract, pricing, or resale assumptions to reproduce those totals. The mechanism is nevertheless clear: avoid a long commitment for a short experiment, then try to recover value from reserved capacity that the startup no longer needs. A successful relisting also makes that capacity available to another buyer.

Lower GPU costs can change what a startup attempts, not just its bill. Zhang invokes scaling laws to connect additional compute with improved model quality. He then extrapolates roughly sixfold savings into sixfold productivity at a fixed budget. That is his interpretation of the purchasing-power change, not a measured training or model-quality result: more affordable compute does not itself establish a proportional improvement in useful output. His example beneficiaries are startups relying on closed models from OpenAI and Anthropic that could now afford more of their own training.

The eventual product is a place to run AI jobs, not merely a place to rent GPUs. Zhang expects the marketplace to evolve into an all-in-one workload platform covering online inference, offline inference, and training. That progression follows the buyer’s goal: a GPU reservation is an input to getting a job done.

The resource argument returns to the physical costs of expansion. Data centers consume energy and occupy land; redistributing idle compute offers another way to serve demand. Zhang’s closing emphasis is smarter allocation alongside construction, with the marketplace reducing the friction of sending unused capacity to someone who can use it.

At the time of the talk, the left QR code on the closing slide points to the existing marketplace, while Business Cloud and Enterprise Cloud are presented as launching products. Zhang announces production-ready GPUs with 99.5% reliability, without defining a measurement period or service-level terms. These are the historical product names and promise in the presentation, rather than a statement of today’s offerings.

The Q&A makes the orchestration proposal more concrete: how does a data center with GPUs actually connect to Hyperbolic? Zhang clarifies that HyperDOS is a Kubernetes agent installed in a provider’s cluster. For a machine without Kubernetes, he offers MicroK8s as a way to make a MacBook or PC Kubernetes-ready. Kubernetes readiness is the point of that example; it does not by itself establish that a particular laptop GPU is eligible to supply the marketplace.

Zhang describes the internal naming through a feudal analogy: the central Hyperbolic server is Monarch, and the compute-owning providers are barons. A rental follows this sequence:

1. The user sends a GPU rental request to Monarch.
2. Monarch sends a request to the appropriate baron.
3. The baron provisions the machines.
4. The baron sets up an SSH instance for customer access.

The shared marketplace handles the customer’s request centrally, while provisioning happens through the provider that owns the compute. SSH access is where the allocation proposal becomes a machine the customer can actually use.