At AI Engineer New York, SF Compute CEO Evan Conrad explained how the company moved from trying to sublease GPU clusters to operating a marketplace that delivers physically settled, programmable compute. The company now runs much of the cloud‑like operating stack required to guarantee actual usable GPU capacity upon settlement.
From selling a room to running the hotel
Conrad uses a hotel analogy to describe the company’s trajectory. Early on (when the business was Junark) SF Compute attempted to sublease capacity. Customers quickly demanded additional services — cleaning, room service, security — and the company found itself operating more of the stack. Over several years SF Compute built the operational capabilities of a cloud so it could reliably deliver compute; it calls this approach ‘‘physical settlement.’'
Physical settlement means delivering compute, not cash
Physical settlement, a term borrowed from futures markets, means a buyer receives functioning compute resources rather than a cash payment tied to an index. Embedding the physical constraints of clusters into the market matters: can a workload be interrupted, how fast can it recover from storage, which GPU generation or networking configuration is required? Those factors affect contract terms and pricing.
Making non‑fungible compute tradable
Rather than waiting for all GPU clusters to become fully interchangeable, SF Compute designed an order book that allows buyers and sellers to specify multiple constraints. Orders can include properties such as whether the capacity is immediate or future, interruptibility, storage topology, GPU generation, and cohort preferences. The matching engine pairs compatible buy and sell orders, enabling liquidity while technology evolves. The trade‑off is more fragmented liquidity and wider spreads, but also arbitrage opportunities for participants who can accept diverse capacity.
Conrad said roughly 5% of SF Compute’s total capacity is currently on the order book and they are steadily moving more capacity there. As an operational metric, he noted that a customer who spends $100 to buy capacity typically recoups about $25 on average by selling it back — a measure they use to judge whether liquidity is commercially useful.
Time horizons and market shape
Clusters are typically financed on three‑to‑five year horizons, and SF Compute supports contracts from immediate spot hours up to multi‑year forward blocks. The company focuses on building liquidity in the forwards curve. Price behaviour varies: sometimes futures trade at premium to spot, other times at discount; Conrad described seeing a humped curve as near‑term unsold capacity discounts to clear and longer leads settle out.
He gave an example of significant arbitrage: running inference on a B300 can generate roughly $40/hour at full utilization, while B300 rental rates can be $5–$6/hour — a gap that drives market dynamics and strategic behaviour.
Hardware generations, cohorts, burn‑in and SKUs
SF Compute emphasises that GPU generation, VRAM, interconnect domain size and cohort effects (early shipments with firmware or hardware issues) are meaningful dimensions. Some customers accept abstracted SKUs (SF Compute’s SKU concept lets others define named product units like “Blackwells”), while others require precise hardware and will pay a premium. The platform exposes these dimensions programmatically via API queries so buyers can express constraints and be matched against seller inventories.
Independence and manipulation risk
Conrad argues a neutral market operator must be independent from major hardware vendors, cloud providers and large inference businesses. Those incumbents have economic incentives that could bias an exchange or hinder neutral price discovery. He likened risks to historical index manipulation (e.g., LIBOR) and warned that cash‑settled derivatives built before robust physical settlement risks creating markets with little relation to the actual cost of buying capacity.
Operational engineering: from site visits to virtualized fabrics
Delivering physically settled compute requires site visits, bill‑of‑materials design, OEM relationships, project management of rack rollouts, and operating the backplane — PDUs, switches, DPUs, BMCs and related systems. SF Compute does not position itself as a data center owner like Equinix; it partners with operators and handles the supercomputing layer.
One notable product capability Conrad highlighted is the ability to subdivide InfiniBand fabric on the fly for customers, enabling dynamic reconfiguration without manual provider intervention. In short, SF Compute aims to virtualize the data center and make it programmable for buyers and sellers.
Ecosystem and partners
Conrad noted an emerging ecosystem around compute markets: cash‑settlement exchanges, standardisation efforts (e.g., SemiAnalysis), insurance and residual‑value products, and financing/lending solutions for cloud capacity. He sees cash settlement and physical settlement as complementary, but believes physical delivery must underpin any reliable derivatives market.
Milestones and call to action
Conrad said SF Compute has closed ‘‘several hundred million dollars’’ of volume, added significant new clusters, and shipped features targeting platform‑as‑a‑service customers. The company is soliciting partners who own or plan to build GPU clusters: SF Compute can operate the supercomputing layer, take on SLAs and enable resale of unused capacity so that cluster owners do not carry full residual risk.
Conclusion
SF Compute’s approach centres on making GPU compute tradable while accounting for the messy reality of heterogeneous hardware and site constraints. By combining physical settlement, programmatic APIs and neutrality, the company aims to create a functioning market for compute where buyers can contract for specific properties and sellers can monetise capacity — even as hardware and deployment patterns continue to change.
