At AI Engineer New York (AIE NYC), Evan Conrad, CEO of SF Compute, outlined how his company is building both the software and physical operating stack required to make GPU compute tradable with actual delivery — "physical settlement" — rather than only cash-settled derivatives. The conversation traced SF Compute’s evolution from subleasing clusters to operating cloud‑like infrastructure and explained which technical and market constraints determine contract terms and prices.
From software-defined networking to software-defined compute
The hosts referenced Martin Casado’s early work on software‑defined networking (SDN) — a disruption so significant that Cisco paid $600 million for it and VMware later bid $1.3 billion — to draw a parallel: just as SDN abstracted routing by separating control and data planes, SF Compute aims to virtualize and programatize GPU compute, networks and memory. Historically, building your own supercompute cluster cost on the order of $50–100 million up front; SF Compute seeks to let buyers and sellers trade GPU hours now and in the future while enabling programmatic control of the underlying infrastructure.
"Selling a room" versus running the hotel
Conrad used a hotel analogy to describe the company’s trajectory: initially trying to sublease a cluster is like selling a hotel room, but customer demands for services (cleaning, room service, security) quickly reveal the need to operate the whole hotel. Over several years SF Compute has therefore built much of the operating capacity of a cloud so it can reliably deliver traded compute. That full responsibility for delivery is what they call physical settlement: instead of paying cash against an index, the buyer receives usable compute.
This approach makes the physical constraints of clusters first‑class market inputs: can a workload be interrupted, how fast can it recover from storage, which GPU generation and software configuration are required — all these details affect both contracts and pricing.
Making compute tradeable without prior standardization
Rather than wait for uniform, interchangeable clusters, SF Compute’s order book accepts orders with many different constraints (time windows, interruptibility, GPU generation, storage characteristics, etc.) and matches buyers and sellers via a multi‑property matching engine. This lets liquidity form even while technology evolves, but it spreads liquidity across more variants and widens spreads.
Conrad said about 5% of SF Compute’s total capacity is currently on the order book; while volume is small, liquidity on that subset is concentrated. As a rough customer metric, he said a buyer who spends $100 on capacity will on average recover about $25 by selling that capacity back — a way of measuring practical liquidity for commercial participants.
Important dimensions: preemption, storage, cohort effects, network fabric
Several concrete factors emerged as critical when defining and pricing compute contracts:
- Whether capacity is currently in use (interrupting a running workload) or booked for the future (easier to trade).
- How interruption occurs and how recoverable the workload is from storage. The availability and performance of underlying storage (Weka, Vast, etc.) change how tolerable preemption is.
- Transit paths between clusters: many GPU deployments are colocated where power is cheap rather than near customers, and inter‑cluster WAN/private interconnects can be limited — this affects the feasibility of moving workloads across sites.
- GPU cohort effects: early shipments of new GPUs (e.g., early H100s or GB200s) sometimes suffer firmware or hardware problems; more mature cohorts may command a premium because they’ve been burned in and are more reliable.
- Generations and SKUs: customers care about GPU generation, VRAM, and fabric sizes; SF Compute has introduced SKU and named‑query concepts so buyers can programmatically specify acceptable properties and be matched to an acceptable composition of sellers.
These dimensions mean compute is heterogeneous; the company reduces dimensionality where possible but argues you cannot abstract everything into a single fungible unit.
Spot vs forwards, batch vs live inference, and price shape
Clusters are typically financed over three to five years, and SF Compute supports contracts ranging from immediate hours up to multi‑year blocks. The company focuses on building a forwards curve with liquidity. Different use cases pay differently: batch inference can tolerate near‑term preemption, while live inference with SLAs cannot and is priced accordingly.
Conrad described how the forward curve can show both backwardation and contango depending on timing and participant incentives. He gave a concrete example: running inference on a B300 could theoretically generate about $40/hour at full utilization (or about $25/hour at lower utilization), while B300 capacity can be bought for roughly $5–6/hour — a significant arbitrage that market dynamics must resolve.
Independence of the market operator
A central claim is that the market operator must be independent. Hardware suppliers, hyperscalers, or large inference providers have incentives that would make them poor neutral operators because they could influence the market to favor their own demand or supply. Conrad argued that companies like NVIDIA, hyperscalers or large cloud providers cannot credibly be neutral market builders without giving up parts of their business, so a separate, independent operator is needed to reduce financing costs across the industry.
The "unsexy" engineering: site visits to programmable fabric
Delivering physical settlement requires extensive on-the-ground engineering:
- site visits and data‑center expertise,
- bill of materials and supply chain coordination with OEMs,
- cluster architecture and rack rollouts with partners,
- backplane and management of PDUs, switches, DPUs, UFM, BMC and other elements,
- features like on‑the‑fly subdivision of InfiniBand fabric so customers can redraw fabrics dynamically.
SF Compute does not typically own the hardware; it operates the supercomputing layer and partners with data‑center owners to turn powered land into usable GPU clusters. The company positions itself as the supercomputing partner that will operate the stack and, if needed, resell a cluster so the owner isn’t left holding stranded hardware.
Ecosystem players and milestones
Conrad mentioned other early entrants and ecosystem participants (SemiAnalysis, Silicon Data, Compute Exchange, Jump), and categorized activity into standards work, insurance/residual‑value products, deposit/lending/financing solutions and exchange operators. SF Compute pursues physical settlement while other firms focus on cash settlement; Conrad believes both can coexist but that cash derivatives should be derived from a robust physical market to avoid index manipulation and basis risk.
Milestones mentioned: SF Compute has closed several hundred million dollars of volume, has many new clusters being deployed, and shipped features that make their platform viable for platform‑as‑a‑service customers (for example, dynamic InfiniBand partitioning).
Conclusion
SF Compute is attempting to make GPU compute a deliverable, tradable commodity by combining market mechanisms with real world engineering and site operations. The company argues that physical settlement — and the on‑the‑ground work that enables it — is a prerequisite for a liquid, reliable compute market and that programmability of the data center (virtualizing the stack around hardware) is the next step in the cloud evolution.
Guest
Guest: Evan Conrad, CEO of SF Compute.
The discussion was recorded on the sidelines of the new Compute Trading track at AIE NYC and references prior talks and resources shared by the hosts.
