Key Takeaways

  • Virtualized GPUs of the same SKU often suffer up to a 40 percent performance drop across different operators and configurations, which prevents compute from trading like a standard commodity contract.
  • SF Compute bypassed rigid product catalogs by building a multi-constraint order book that matches bids and asks across variables like memory bandwidth, VRAM, NVLink domains, and rental duration.
  • Multi-constraint orders spread out market liquidity and widen bid-ask spreads, but they reward buyers who can accept varied hardware profiles.
  • Teams that write workloads flexible enough to run across non-standard capacity make an average of $25 back on every $100 spent by reselling their excess compute into the order book.

Why Cloud Compute Refuses to Trade Like Crude Oil

Every commodity market rests on interchangeability. A barrel of West Texas Intermediate is a barrel of West Texas Intermediate. Compute looks like it should work the same way: an H100 is an H100. But Conrad points out that virtualization destroys this assumption before trading even starts.

“To get closer to something that can be standardized, you first need to make all the operations of the thing the same,” Conrad explained. “A single operator can offer two different types of virtual machines. One type of virtual machine might have a 40% performance degradation versus another types of virtual machine.”

Because hypervisors, cooling, and network configurations swing performance by double digits, buyers cannot rely on simple ticker symbols. If you buy an hour of compute blind, you might receive 60 percent of the throughput you budgeted for. Traditional exchanges fail in compute because the underlying asset has no uniform operational baseline.

The Engine Behind Multi-Constraint Bidding

To solve the lack of standardization without forcing every operator onto identical hardware, SF Compute turned away from fixed catalog items. Instead, they built a matching engine that prices dimensions independently.

“What we did instead was we created an order book that had multiple different constraints,” Conrad said. “You can say, 'I want to have something that's between this and that. It runs from this time to this time.' It's a bunch of different properties that you can attach your order, and then we match that against sell orders that have those properties in a big matching engine.”

Buyers set acceptable ranges for VRAM, memory bandwidth, network topology like InfiniBand fabrics, and start times. The system finds matching inventory across disparate data centers. Conrad admits this approach comes with an immediate penalty: “The trade-off of this is that you have less concentrated liquidity, and so the prices are going to have more spreads between the buy and the sell.”

How Flexible Workloads Capture the Spread

Wider bid-ask spreads sound like a defect. For rigid buyers who demand a single exact instance type in one specific data center, wide spreads mean higher transaction costs. But for engineering teams that design fault-tolerant or hardware-agnostic jobs, those spreads create a revenue stream.

“If you have a product that can use lots of different types of capacity, then you might really like SF Compute because you will be able to use lots of different types of capacity and you'll make more money,” Conrad said. “You can take the spread.”

Buyers do not just consume capacity; they become market makers for their own infrastructure. Conrad noted that “a customer who buys capacity from us, and they spend $100 to buy that capacity, will make back $25 on average from selling it back to somebody else.” By picking up cheap, mismatched inventory that rigid training runs cannot touch, and offloading idle windows back into the engine, builders turn compute from a fixed operational bill into an active arbitrage operation.

What to Do With This

Audit your primary model training and inference pipelines by Friday afternoon. Determine whether your code genuinely requires a specific GPU cluster topology or if it can execute across varied VRAM tiers and looser interconnects. If your workloads can tolerate looser constraints, move your spot or batch requests into an order book that lets you bid on property ranges rather than fixed instance names.