The Programmable Data Center — Evan Conrad, SF Compute

The host opens by noting that this is a particularly timely conversation: SF Compute was discussed on the show about two years earlier, and companies such as Jump and Semianalysis are now drawing attention to computer markets. Evan Conrad explains that SF Compute began as Junark, essentially trying to sublease access to a compute cluster. He compares the evolution to selling a hotel room: customers first ask whether the room will be cleaned, then whether there is room service, security, and other infrastructure. Eventually, the company is operating the entire hotel. That is what SF Compute has spent the intervening years doing. Rather than merely matching buyers with unused GPU capacity, it built the operating capabilities of a cloud so that compute can be delivered reliably. Conrad calls this “physical settlement,” borrowing the term from futures markets in oil, soybeans, and power: the buyer is not receiving a cash proxy for compute, but actual usable compute capacity. The company co-designed the physical-settlement process and its order book because compute has operational constraints—such as whether a workload can be interrupted, how quickly it can recover, and what storage and networking exist underneath it.

Asked how mature the compute market is, Conrad says it is “not very mature or deep or liquid” overall. SF Compute first had to bring enough supply online and build the platform that could reliably trade it. It has only recently begun moving capacity onto the order book; roughly 5% of its total capacity is currently listed, with that share increasing as more capacity comes online. Conrad distinguishes low volume from low liquidity. The order book has little total capacity, but liquidity is concentrated in that small amount. One practical measure is that a customer who spends $100 buying capacity from SF Compute earns, on average, $25 by selling capacity back to another participant. He prefers this customer-centered measure over simply counting market makers: the question is whether the market actually solves a commercial participant’s problem. The host returns to an earlier discussion about standardized contracts and asks about progress with regulators such as the CFTC. Conrad says standardization is still far away. The company learned that it first had to operate the whole system and make the underlying processes consistent. For example, two virtual-machine types from the same operator might differ by 40% in performance because of GPU kernel-launch behavior, ultimately producing different MFU. Instead of forcing standardization prematurely, SF Compute lets orders specify multiple constraints and matches them against sell orders with compatible properties. The trade-off is less concentrated liquidity and wider spreads, but also more potential arbitrage for participants able to use varied capacity.

The order book can describe whether capacity is available now or in the future. Selling currently used capacity may require interrupting an active workload, while capacity beginning a month later can be traded more easily. The interruption mechanism matters too: a cluster with stronger storage—Conrad mentions systems such as Weka or VAST—can let a workload recover quickly after preemption. Location and networking also matter. If data can move rapidly from one cluster to another, a customer may tolerate being interrupted in one place and restarted elsewhere. That requires a fast wide-area network, effectively a private internet connecting clusters, but many new GPU clusters are built next to power rather than next to customers. As a result, they may lack the transit paths that make this flexibility possible. The speakers also discuss hardware cohorts. Early H100 and GB200 deployments could have firmware or system-level problems, including bugs in a Supermicro box, even when the GPU itself was not defective. Standard cloud operators use burn-in testing to identify broken GPUs or nodes before customers see them and return them under RMA. But some early-generation issues require firmware updates or newer shipments, so sophisticated buyers might pay more for hardware from a later deployment cohort. Conrad says the market theoretically supports expressing such preferences, although not all of them have yet been implemented.

Compute can be purchased from the next hour out to several years ahead. Conrad says clusters are generally financed over three to five years, and SF Compute can list capacity for an arbitrary future period, although it currently asks customers to pay upfront for longer-term blocks. The company is more interested in building a liquid forward curve than in focusing only on real-time or spot capacity. The price depends on the customer’s tolerance for interruption. A batch-inference workload might be willing to receive only a minute or two of notice, or perhaps an hour, because it can restart elsewhere. A live-inference workload serving customers cannot be interrupted on that timetable; it may need one, two, or three months to adapt, and its operator may owe an SLA when service is disrupted. The host summarizes the market as “the market for breaking leases,” while Conrad adds that it also includes future leases. He compares it with power markets, which have both day-ahead and live markets. The forward curve is not simply upward or downward. Conrad says SF Compute sees a hump: capacity approaching the present may become cheaper because unsold capacity has to clear before it expires, then prices rise farther out before potentially falling again because customers prefer immediate capacity. He gives a striking example: a B300 could reportedly earn around $40 per hour running inference, or about $25 at 50% utilization, while the same kind of capacity could be bought for roughly $5–$6 per hour. He calls this a major arbitrage that should eventually force one of the numbers to change.

The host asks whether SF Compute can treat all GPUs as interchangeable units of compute. Conrad says customers care about generations—such as Blackwell variants, AMD hardware, and other product families—as well as attributes such as VRAM and the size of the relevant domain. The host compares this with oil, where different grades can be refined into other products; Conrad agrees that compute is similarly heterogeneous, but there is not yet a universal refinery that makes every type equivalent. SF Compute tries to reduce the number of dimensions without pretending they have disappeared. Some customers may simply request Blackwell-class capacity below $6 per hour and accept a match against different Blackwell products. Others need a very specific configuration and will pay more for it. The system’s query model lets customers define what they require and matches those requirements against sellers’ available compositions; named, reusable queries are a newer feature. Conrad says the central lesson from SF Compute’s first three years is that physical settlement must come before excessive financialization. If derivatives are created before the industry has made the underlying compute sufficiently fungible and deliverable, the market can be manipulated and develop substantial basis risk: the price used for hedging may have little relationship to the price of actually obtaining a new compute contract. He is not opposed to cash-settled products, but believes they should be derived from a functioning physical market rather than created first as a proxy.

The host compares the proposed market with cash-settled derivatives such as credit-default swaps and mortgage reinsurance, where the notional market can greatly exceed the underlying physical asset. He also invokes LIBOR, where a fixing based on limited data could be manipulated. Conrad’s concern is that a compute index based on a small amount of poorly correlated trading data could become detached from the real cost of buying new compute capacity. Conrad says SF Compute must remain independent and therefore does not own the hardware it trades. If it owned the supply, it could manipulate the forward market. He argues that Nvidia, hyperscalers, and specialized providers such as Crusoe, CoreWeave, Lambda, Base10, Fireworks, and Modal all benefit from a liquid compute market but cannot credibly operate it themselves: they have either too much supply, too much demand, or too strong an incentive to prioritize their own cloud and inference businesses. To become a neutral market, they would have to give up some of the large cloud and inference deals that make their existing businesses valuable. The emerging ecosystem therefore includes multiple roles. Conrad cites Silicon Data and Computer Exchange as early companies pursuing cash settlement, while SF Compute focuses on physical settlement. Other participants are working on standards, residual-value insurance, and lending that finances a cloud’s credit risk. Conrad believes cash and physical markets can coexist and reinforce one another, provided the cash market is anchored to real deliverable capacity.

Although SF Compute does not own the hardware or operate as a traditional data-center landlord, it performs much of the work required to make a facility function as a cloud. Its staff conduct site visits, design bills of materials, coordinate OEM supply chains, architect clusters, supervise rack deployment, and manage the “backplane”: PDUs, switches, DPUs, UFM, BMCs, and the rest of the infrastructure surrounding the bare-metal nodes. It does not self-perform construction, but partners with data-center owners or people holding powered land and takes responsibility for the supercomputing layer. The company works primarily in the United States but intends to deploy globally. Conrad describes a model in which a local operator supplies a data center or the ingredients to build one, while SF Compute turns it into a cloud and brings San Francisco-based demand and expertise. He says there are no major partners he can name yet, though announcements were expected within a week or two. Conrad reports that SF Compute has closed $700 million in volume and has a significant number of new clusters coming. He highlights new features for platform-as-a-service companies, including the ability to subdivide an InfiniBand fabric without asking the cloud operator to reconfigure it manually. The host characterizes this as virtualizing the data center and making it programmable. Conrad’s call to action is aimed at owners who want GPU exposure and residual value: SF Compute can build and operate the supercomputing portion, own the SLA, and, if the cluster later becomes undesirable, sell it to another customer without leaving the original owner with the asset on its balance sheet.