
The Programmable Data Center — Evan Conrad, SF Compute
Latent Space podcast episode with Evan Conrad, CEO of SF Compute, recorded at AI Engineer New York in 2026. He explains why the company moved from subleasing a cluster to running cloud-level operations so it can physically deliver traded GPU capacity. Topics include a constraint-matching order book, spot versus forward prices, batch versus live inference leases, and cash versus physical settlement. The transcript was truncated near the end.
What it claims
Evan Conrad, CEO of SF Compute, argues that GPU capacity cannot be safely financialized until it can be physically delivered. He says SF Compute has spent about three years building cloud operations for that reason. He says the company does not own hardware, so that it cannot manipulate the forwards market. He also says NVIDIA, CoreWeave, Crusoe, Lambda, the hyperscalers, Baseten, Fireworks and Modal cannot run a neutral exchange, because each has too large a stake on one side of the market. He reports "several hundred million dollars" of closed volume.
How it works
The order book does not use standardized contract grades. Each order carries constraints, such as a hardware range, a start and end time, and other properties. A matching engine pairs it with sell orders that meet those constraints. Conrad's stated trade-off is that liquidity is less concentrated and bid-ask spreads are wider. In return, a buyer whose workload can run on many hardware types can capture that spread.
The dimensions that affect matching and price, according to Conrad:
- Now versus future capacity. Selling capacity that is running now means interrupting a workload. Capacity starting a month out trades easily.
- Interruption tolerance. Batch inference can accept minutes to an hour of notice. Live inference needs one to three months of notice, so the two are priced differently. He describes this as a market for breaking leases, similar to the day-ahead and live power markets.
- Storage and transit. It matters whether the cluster has WEKA or VAST storage, and of what size. It also matters whether a WAN links clusters so that a preempted job can resume elsewhere. Many GPU sites are built near power, not customers, and lack that link.
- Hardware cohort. Early H100 and GB200 units had faults. Some were vendor firmware bugs, for example in Supermicro boxes. SF Compute hit a similar issue with its B300s. Cohort-based pricing is "theoretically" supported but not yet done.
- VM implementation. Two VM types from one operator can differ by 40% in GPU kernel launch latency, which lowers MFU.
For physical settlement, SF Compute does site visits, bills of materials, OEM supply-chain work, cluster architecture and rack rollout supervision. It also runs the backplane: PDUs, switches, DPUs, UFM and BMC. It does not self-perform data center builds.
Evidence
All figures are Conrad's spoken claims:
- About 5% of SF Compute's total capacity is on the order book. All newly added capacity goes there.
- A buyer who spends $100 on capacity recovers $25 on average by reselling it. This is the company's main liquidity metric.
- Contracts can run from one hour to three years. Clusters are generally financed over three to five years.
- The forward curve is hump-shaped. Prices drop for capacity near "now", because unsold time expires. They rise further out, then fall for distant dates.
- A B300 can earn about $40/hour serving inference at full use, or about $25/hour at 50% use. It can be bought for $5 to $6/hour. Conrad says one of these numbers has to change.
How to use it
Orders are placed through queries, and customers can define their own SKUs. One example is buying "Blackwells at $6 an hour or less," matched against either GB300 or B300 capacity. Named queries are described as new. Block purchases must be paid fully upfront. Longer-term leases are not paid this way, but the terms are not explained.
Customers can subdivide their InfiniBand fabric on the fly without contacting SF Compute. The company pitches this to platform-as-a-service companies. For cluster owners, SF Compute offers to run the supercomputing layer, own the SLA, and resell the cluster if the owner wants out.
Limits
The transcript is automated, and speaker labels are not verified. Conrad says the market is "not very mature or deep or liquid," that order book volume is small, and that contract standardization is "still pretty far away." No partners are named. Cash-settled indexes run by Silicon Data and Compute Exchange are described as complementary. Conrad warns that thin indexes carry LIBOR-style manipulation risk and basis risk.
Organisations named here
- SF Compute
- Latent Space
- AI Engineer New York
- NVIDIA
- Cisco
- VMware
- Jump
- SemiAnalysis
- Silicon Data
- Compute Exchange
- Super Micro
- CFTC
- Anthropic
- TSMC
- Junark
- EIA
- Barclays
- Equinix
- Palantir
- Devin
- Evan Conrad
- Martin Casado
Technologies named here
- SF Compute
- Abel
- Elastic InfiniBand partitions
- WEKA
- VAST
- UFM
- BMC
- Devin
- InfiniBand
- NVLink
- VAST Data
Techniques named here
- Physical settlement of compute
- Multi-constraint order book matching
- Named SKU queries
- Selling interruptible versus future capacity
- Burn-in and RMA of GPU nodes
- Software-defined networking analogy
Related in ai-infra
kerpopule/hermes-jev-skills
Wire It, Run It, Deploy It: AI Workflows in Gradio
