Why AI Startups Will Disappear Without Compute Markets — Evan Conrad, San Francisco Compute

Read the talk

Why AI Startups Will Disappear Without Compute Markets

Evan Conrad traces San Francisco Compute’s origins in a struggling AI lab, then explains how GPU financing, unreliable delivery and locked reservations can turn compute access into a credit test—and why a market has to operate the hardware behind its trades.

From a talk by Evan Conrad

At a glance

Ideas worth remembering

  • San Francisco Compute combines an order book with operation of the underlying clusters. Physical settlement requires delivering working compute across hardware design, networking, orchestration and customer services.

  • Long-term take-or-pay contracts help finance GPU deployments, but without resale they can trap capacity with one customer while another buyer must finance a new cluster and wait.

  • Liquidity matters after deployment too: buyers need ways to replace failed capacity, sell surplus reservations and obtain more compute when demand exceeds their forecasts.

  • The financing goal is to underwrite the GPU cluster’s value rather than depend on one startup’s credit. Conrad presents this as a possible alternative to concentrating demand among a few creditworthy buyers.

  • If inference providers pass credit requirements to token buyers, the barrier can reach application startups. Conrad forecasts a reinforcing advantage for incumbents whose credit buys access and whose products generate revenue that improves their credit.

Physical settlement means running the stack

Owning data-center space does not make you good at running a supercomputer. That gap is the starting point for Evan Conrad of San Francisco Compute: a facility owner may have an asset that makes GPU hosting economical, yet still lack the operating expertise needed to deliver useful compute. San Francisco Compute combines that operating work with a physically settled forwards market—a market for reserved capacity whose delivery depends on hardware the company actually runs.

Physical settlement reaches much further down the stack than a booking interface. The work starts with the supercomputer’s design and bill of materials, includes the backplane fabric connecting its hardware, and extends through bare-metal orchestration to virtual machines and other services. A failure at any of those layers can become the customer’s problem. The market therefore sits on top of an operating capability, rather than substituting for one.

The company calls the operating side “supercomputing as a service.” Its prospective customers have different reasons to separate ownership from operation:

  • Aspiring clouds: Organizations want to sell GPU services without assembling the entire operating capability themselves.
  • Venture firms: A firm wants clusters available to its portfolio, with capacity that can move toward a company whose demand takes off.
  • AI companies: A company wants the compute asset’s residual value to matter in its financials, without having to run a supercomputer.

Above that infrastructure, a live order book lets customers buy reserved capacity for immediate or future use.

0:120:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:12 · section reference included

The music lab that had to sell its compute

The business began with a very different ambition: a music-generation lab in the vein of Suno or Udio, before those products. Conrad recalls a $10 million deposit as the entry requirement the team faced. Rather than raise that amount, it raised $500,000 and expected to rent from someone else. The resulting cluster commitment still left the company underwater every month. Subleasing capacity became necessary to avoid bankruptcy.

For the first year, keeping the company alive meant finding buyers for its cluster capacity. Conrad carried paper advertisements around NeurIPS; in his telling, the hurriedly made poster said both H100 and A100. The detail captures how improvised the brokerage business was. It did not begin with a theory of market design. It began with a compute bill the lab could not afford on its own.

Getting from that predicament to a functioning compute market requires what Conrad calls two “miracle problems.” A market has a cold-start problem: it needs participants and tradable capacity before it becomes useful. Physical delivery also requires building the capabilities of a cloud. Then comes the awkward part: having built a cloud, the company must resist simply becoming one. The rest of the talk unfolds the many folds between “starting a lab is financially miserable” and “build a compute market.”

2:122:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:12 · section reference included

Sold out, paid up, delayed—and still the wrong size

Conrad’s account of the market begins with a frustrating distinction: being willing to pay does not mean you can obtain compute now. When existing capacity is sold out, a customer must finance a net-new cluster and wait for physical delivery. More money cannot make an unbuilt cluster appear immediately. Meanwhile, the customer may have to commit its bank balance as a deposit because a lender cannot confidently assess a two-person startup promising to build superintelligence.

The financing arrangement also determines when construction can begin. If the lender underwrites the customer’s credit, it needs an identified customer before the cluster is deployed. Signing a contract therefore puts the buyer at the beginning of a risky deployment, not at the end of a completed one. Conrad would prefer the reverse order: build and land the cluster first, then sell access to it. That would expose the buyer to less delivery uncertainty.

Delivery is only one source of error. The provider may own cheap data-center space without knowing how to operate a supercomputer. And after the customer finally gets a working cluster, its demand forecast can still be wrong:

  • Underbuying: Insufficient capacity limits growth while a better-provisioned competitor serves the demand.
  • Overbuying: The company keeps paying for capacity it cannot use, repeating the predicament that forced Conrad’s lab to sublease.

In his comparison with SaaS, AI’s thinner margins leave less room to absorb either mistake.

These look like separate complaints—availability, deposits, deployment, reliability and forecasting—but Conrad groups them as one bundled risk problem. Technical risk affects whether compute arrives and works. Credit risk affects who can finance it. Demand risk affects whether the buyer needs what it committed to. A useful compute market has to address those actual exposures; an order book is not valuable merely because trading sounds attractive.

4:124:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:12 · section reference included

How financing turns available hardware into unavailable capacity

The next step is to explain why the capacity gets locked up. Conrad contrasts CPU-backed SaaS businesses with AI businesses using a price-doubling thought experiment. A SaaS company might hate its cloud after such an increase yet remain viable. An AI company with much less margin might have to switch providers to survive. In his financing model, that price sensitivity makes revenue from freely departing, on-demand customers a weak foundation for paying off an expensive GPU cluster.

Lenders instead want long-term take-or-pay contracts: commitments to pay for reserved capacity whether or not the customer ends up using it, preferably backed by investment-grade credit. Those contracts help finance construction. Without resale liquidity, however, they also trap capacity. The original customer cannot get out, and a different company whose product is suddenly taking off cannot simply buy that reservation from it.

The growing company is pushed back toward financing another cluster. That means waiting for hardware—and sometimes a data center—while also finding a deposit to compensate for its limited credit history. This is the basis for Conrad’s claim that companies hit credit limits before power limits: an inference company or new lab can exhaust its financeable commitments before reaching the physical scale where power becomes its immediate constraint. It is his diagnosis of the bottleneck facing those buyers, not a demonstration that power never constrains AI infrastructure.

Venture capital then funds infrastructure indirectly. An investor may prefer the model, application or inference layer because it does not want to finance capital expenditure. But the startup receives the investment and sends it to the cloud as a cluster deposit. The check still supports the capital-intensive deployment; it has simply passed through a software company’s bank account first.

6:417:11
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:41 · section reference included

Liquidity has to help with failures as well as forecasts

A delivered cluster can send the customer back into the same queue. Suppose more nodes fail than expected. If there is no capacity pool from which to bring in replacements, the customer must pursue a return-and-replacement process for the failed hardware. Obtaining a replacement node reintroduces the physical lead time. Liquidity does not prevent hardware failures; in this account, access to replacement capacity determines whether a failure also becomes a prolonged capacity shortage.

Even after surviving the deposit, delays and repairs, the buyer faces the forecast it made before it knew its demand. An over-provisioned company needs someone to buy its surplus. An under-provisioned company needs additional capacity without commissioning an entirely new deployment. Resale connects those needs: it gives the first company a way to reduce its exposure and the second a possible source of capacity already committed elsewhere.

The proposed financing change is to underwrite the value of the GPU cluster rather than rely primarily on the original customer’s credit. A liquid market would make the ability to sell that capacity to other buyers economically important. Conrad presents this as a route that could work, not a guaranteed financing outcome; the talk does not specify a lender valuation model or the market depth needed to support one.

There is another way to make the credit problem disappear for a lender: consolidate demand into a few large, creditworthy customers. Conrad invokes TSMC as an analogy for an industry concentrated around a small set of major buyers, then forecasts an AI market dominated by a few clouds and model labs. That possibility explains why the team stayed with the compute problem rather than starting another lab. Returning to model-building would not remove the financing obstacle; it would mean encountering it again later.

9:119:41
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:11 · section reference included

You have to operate the hotel

Why must the market operator also run the clusters? Conrad’s answer is that GPU compute is not sufficiently standardized or reliable to separate trading from delivery. Buying a reservation does not settle the practical questions of who maintains the service, fixes problems or makes the promised capacity usable. His case for integration rests on those operating responsibilities.

The hotel analogy makes the distinction concrete. A traveler might resell a room reservation, but the next guest still needs cleaning, room service and someone to call when something breaks. The traveler cannot provide those services merely by transferring the booking. Likewise, brokering a cluster commitment does not by itself deliver an operational supercomputer. In Conrad’s model, the market must be able to act on the underlying infrastructure when the buyer needs help.

That requirement creates a powerful commercial temptation. Building physical settlement means building the operating capacity of a GPU cloud. Once that capability exists, signing large cloud contracts can look much more attractive than solving a market’s cold-start problem. Conrad describes billion-dollar deals as the reason a would-be market can reasonably decide to become a conventional cloud instead.

San Francisco Compute’s reason to keep pursuing the market comes back to its original ambition. The team wanted to build a lab and concluded that it would not have that option unless this infrastructure existed. Running the cloud is necessary to deliver the traded compute. Preserving the market is necessary to give customers an alternative to being stuck with one large commitment.

11:4012:10
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:40 · section reference included

Passing the credit problem to token buyers

Conrad describes the minimum deposit for entering the lab business rising from $10 million to $100 million to $1 billion as cluster sizes grew. These are his account of the escalating entry requirement, not a universal price schedule for all AI startups. His concern is the direction: if the next step requires a $10 billion financing before product, traction or revenue, raising more venture capital stops being a plausible general solution.

An inference provider could try to solve its own credit problem by passing it downstream. Instead of selling tokens freely to new companies, it could seek customers whose commitments help support its financing:

  • Creditworthy buyers: Favor investment-grade customers, such as large established enterprises.
  • Long commitments: Require five-year token contracts.
  • Upfront cash: Require a substantial deposit.

These are alternatives or conditions a provider might impose, not a sequence every buyer must follow.

The provider has not eliminated the risk. It has made access to tokens depend on the application company’s credit or cash. That broadens the stakes beyond organizations that train models or operate inference fleets. If using intelligence becomes essential to competing, an application startup can face the same financing barrier without ever buying a GPU.

What lets incumbents keep widening the gap in this scenario? Established firms have credit, so they can obtain the tokens needed to build products. Product revenue then improves their credit, supporting further access. The feedback relationship below captures Conrad’s consolidation forecast: financing strength helps produce the revenue that strengthens financing again, while a new entrant must first find credit or a large deposit.

How credit-gated token access could favor incumbents

Established creditExisting firms can meet financing requirements that new startups may not.
Access to tokensCredit supports access when inference providers require credit or deposits.
Products reach customersIncumbents use their access to intelligence to make and ship products.
Product revenueRevenue from those products improves the firm’s credit.
Conrad’s proposed consolidation mechanism: existing credit enables token access, products generate revenue, and revenue improves credit. This is a forecast of a feedback relationship, not a measured growth model.
Read the diagram as text
  • Established credit. Existing firms can meet financing requirements that new startups may not.
  • Access to tokens. Credit supports access when inference providers require credit or deposits.
  • Products reach customers. Incumbents use their access to intelligence to make and ship products.
  • Product revenue. Revenue from those products improves the firm’s credit.
  • Established credit → Access to tokens: Meets credit-based access requirements.
  • Access to tokens → Products reach customers: Supplies intelligence for products.
  • Products reach customers → Product revenue: Generates revenue.
  • Product revenue → Established credit: Improves credit.
13:4014:10
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:40 · section reference included

The two-person startup facing a $100 million token bill

The closing example extends that credit barrier to an ordinary new company. Looking three to five years ahead, Conrad imagines founders competing against businesses already spending hundreds of millions of dollars on tokens. His extrapolation is that a new entrant might need $100 million of tokens to compete. This is a conditional forecast, not an observed requirement for starting a company.

Now put two founders with no operating history in front of the supplier. The supplier does not trust their ability to pay, so it asks for a large deposit. The founders must raise the money from a venture capitalist before they can obtain the intelligence needed to build the business. If they cannot pay everything upfront, a five-year commitment may be the alternative. The obstacle is no longer simply the price of a token; it is the size and duration of the obligation required to become a customer.

“There is no rule that says that startups have to exist.” Conrad ends with the small teams he knew in San Francisco, each trying to participate in the technology. Their value is not that every company will succeed. It is that some might grow into organizations that build cancer cures or invent products nobody anticipated. A financing system that filters those teams out before they can begin also filters out possibilities that established buyers may never pursue. That is the reason he gives for building compute markets: keeping entry possible, rather than accepting consolidation as the only way to finance the machines.

15:4016:10
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:40 · section reference included

Resources

Transcript & slides

Loading transcript and slides…

Transcript download