Before Compute Can Trade: Evan Conrad on Delivering a Programmable Data Center

1. Guest Background

Evan Conrad joins Alessio Fanelli and Shawn swyx Wang on Latent Space to discuss SF Compute’s approach to compute trading and the programmable data center. The supplied guest background identifies him as a member of the SF Compute team without specifying an exact title. His relevant experience in this conversation concerns the company’s order book and the infrastructure required to deliver the capacity traded through it. He speaks as a participant explaining his company’s operating choices and market thesis.

Conrad traces that work to a simpler problem. The team, originally called Junark, wanted to sublease its own cluster. Finding a buyer exposed further obligations: the buyer also needed a functioning service. His analogy is a hotel room seller who progressively takes responsibility for cleaning, room service, and security until, effectively, the seller runs the hotel.

That progression explains the interview’s focus. The subject is how a capacity marketplace acquires enough operational control to make its promises credible. Conrad’s account supplies useful detail about that effort, while his position also matters when assessing claims about which market structure will succeed. The episode is an examination of SF Compute’s approach, rather than independent validation of its commercial outcomes.

2. What the Episode Covers

Conrad calls reliable delivery of compute service “physical settlement,” borrowing language from commodity markets. In this setting, the deliverable is usable capacity under agreed conditions. His point is that matching a buyer with a seller does not resolve whether a workload can run, recover, or leave. SF Compute therefore designed its settlement infrastructure and order book together. A customer’s willingness to accept interruption, for example, can depend on having storage from which recovery is fast enough.

The operational scope is broader than a trading interface suggests. Conrad says SF Compute does not own the hardware, but undertakes site visits, bill-of-materials design, supply-chain coordination, cluster architecture, rack deployment supervision, and management of systems surrounding the nodes. He describes a partnership model in which a data center or power-resource owner supplies the underlying resources and SF Compute provides the supercomputing layer. The company works with partners on construction rather than performing builds itself. He also discusses sovereign compute participants, without naming major partners in this interview.

The programmable data center becomes concrete in a feature Conrad says has shipped: customers can subdivide their InfiniBand fabric themselves and change those boundaries dynamically. This connects infrastructure control to capacity decisions. Expanding or shrinking a cluster is more useful when the customer can also redraw the relevant network boundaries without requesting a manual change each time.

The market remains at an early stage by Conrad’s own description. He says approximately 5% of total company capacity was on the order book at the time, distinguishing its small size from what he describes as concentrated liquidity within it. His customer-oriented metric is that a buyer spending $100 on capacity recovers $25 on average through resale. The interview supplies neither the sample nor the measurement period or time required to sell, so the figure describes a reported average rather than an exit guarantee.

SF Compute’s stated priority is a liquid forward curve. Conrad describes purchases spanning the current hour through multiple years, while distinguishing current capacity blocks, for which the company asks for full upfront payment, from longer-term leases. That distinction matters: the discussion does not establish a single payment convention for every maturity or a uniform financial contract merely because trading terminology is used.

3. Core Views: Reasoning, Examples, and Limits

The strongest argument in Conrad’s account is that standardization depends on what operators actually deliver. A GPU model name cannot capture every performance-relevant difference. He illustrates this with two virtual-machine implementations from one operator that, he says, could differ in performance by approximately 40%. He locates the issue in GPU kernel-launch overhead, with consequences for model FLOPs utilization, or MFU. The interview does not provide a benchmark protocol or establish a general virtualization penalty. Its analytical value is narrower: apparently equivalent hardware can arrive through meaningfully different operating environments.

SF Compute responds by allowing buyers to express multiple constraints and matching those against seller properties. This postpones the need to define one rigid commodity while technology is changing. Conrad’s Blackwell example makes the buyer’s role clear. One customer might accept several configurations below a price threshold; another needs an exact configuration and may pay more for that restriction. Fungibility is therefore partly a property of the workload’s acceptable alternatives. The cost is market fragmentation: additional dimensions can disperse liquidity and widen bid-ask spreads. Conrad also separates the existing query-based order book from named queries, which he describes as a new development.

A second argument is that interruption rights carry economic value. Capacity beginning next month can change hands without immediately displacing a running job. Reselling capacity in use may require that displacement. Conrad contrasts batch inference, which might tolerate a minute or two of notice or an hour, with live inference serving customers under an SLA, which might need one to three months to adapt. Those are illustrative operating scenarios, not universal requirements. They explain why two rights to use the same GPU can deserve different prices: continuity and preparation time are part of the service being purchased.

The interruption argument also exposes the connection between market design and data movement. Conrad discusses storage systems, where data resides, and the fast transit path needed to resume work on another cluster. He observes that GPU facilities built near power resources may lack excellent inter-site connectivity. A workload that can stop is not automatically a workload that can move economically. Recovery and transfer constraints can consume the apparent advantage of cheaper interruptible capacity. The relevant comparison is between usable alternatives, including their recovery conditions, rather than isolated hourly prices.

Conrad’s account of forward pricing similarly resists a single rule. He describes a hump-shaped curve: an unsold capacity block approaching its start time may be discounted because that time cannot later be sold retroactively. Prices can then recover at another maturity, while distant capacity may be discounted because customers prefer earlier access. Yet expectations of future scarcity can encourage buyers to pay more to secure later supply. His account combines observations with his interpretation of a healthy curve; it does not establish that compute must always trade in one particular term structure.

His financialization argument follows from these delivery differences. Conrad favors cash settlement as a future concept, but wants its pricing to derive from physical settlement. An index built from sparse observations that correlate poorly with the price of an actual reserve contract could leave a buyer hedged against the wrong thing. He also worries about manipulation. The interview explains that concern rather than demonstrating that a particular index has failed. His willingness to describe cash-settlement businesses as potential partners further clarifies the dispute: it concerns the price anchor and sequence of market construction.

Finally, Conrad presents hardware independence as part of the platform’s credibility. He argues that not owning hardware helps avoid conflicting incentives, and links credible forward liquidity to financing. This is a coherent strategic thesis, but its empirical status should remain visible. The episode provides no quantified reduction in financing costs and does not prove that other kinds of operators cannot build trusted markets. The useful distinction is between a proposed mechanism for improving financing and evidence that the improvement has already occurred.

4. Learning and Application

For a compute buyer, the practical starting point is an acceptance specification for the workload. Conrad says chip generation, memory, and NVLink domains still matter to customers. A procurement comparison should therefore identify which properties are mandatory and which can vary. A team could test representative jobs on several acceptable configurations before broadening its purchasing query. The potential benefit is access to more supply; the tradeoff is the engineering and validation needed to establish that those alternatives are useful. A broader label alone does not make capacity interchangeable.

Teams considering interruptible capacity can turn the discussion into a recovery exercise. Measure how long it takes to pause work, restore its state, transfer required data, and resume on another suitable cluster. Use the result to define an acceptable notice period and the necessary storage and connectivity conditions. For live services, work backward from customer commitments as well. Conrad’s minute-scale and month-scale examples explain why requirements differ; they should not become default contract terms without examining the actual workload and SLA.

Reliability diligence should distinguish two questions that the interview separates. What burn-in process is used to expose defective GPUs or nodes before customer use? What known system-wide problems require firmware changes or another remedy? Passing a stress test does not answer the second question. Conrad’s suggestion that sophisticated buyers might pay for later deployment cohorts is also useful as a question to investigate, but he explicitly identifies cohort-based support as something not yet implemented. It belongs in an evaluation of future possibilities, not an assumed feature list.

Resale should be assessed with equally specific questions. Ask how much capacity is covered by the order book, which contract properties affect matching, and how long comparable sales take. Conrad’s reported average recovery of $25 per $100 purchased and his claim of several hundred million dollars in cumulative volume describe different aspects of the business. Neither establishes that a particular block will sell immediately. If an acquisition depends on resale, evaluate the cost of holding capacity when the expected exit does not occur, rather than automatically deducting an average recovery from the budget.

The B300 revenue comparison offers another exercise in separating a provocative estimate from a decision model. Conrad cites roughly $40 an hour in inference revenue at full utilization, about $25 under a lower-utilization example, and a rental price around $5–6 an hour. These are his oral estimates; the interview supplies no complete demand or cost model, and the utilization arithmetic should not be treated as a precise formula. A usable business case would need to establish sustained demand, achievable utilization, realizable revenue, and necessary costs beyond the quoted rental price. Subtracting the two headline figures does not establish net profit.

For a buyer considering a financial hedge, compare the proposed index with the actual procurement obligation: hardware, configuration, delivery period, and service conditions. Any mismatch should be examined before assuming the hedge offsets the bill. For an asset owner considering SF Compute’s partnership pitch, the same discipline applies to contractual promises. Conrad says the company takes responsibility for the SLA and can help an owner exit, including a closing claim about the balance sheet. The interview does not specify the contractual or accounting conditions. Those claims should become concrete diligence questions about responsibility, exit terms, and accounting treatment before they enter an investment decision.

Source

• Original episode: The Programmable Data Center — Evan Conrad, SF Compute