The alpha, twice a week
That was 3 min.
Get the best new moments in your inbox every Wednesday and Saturday. It's free.
Check your inbox
We sent a link to your address. Click it to finish signing up. Not there in a minute? Look in spam.
or
Latent Space · 3 min · Oct 20, 2026
A flexible order book can precede standard compute contracts
Evan Conrad says operations must be made consistent before compute contracts can standardize, but a flexible order book can match varying constraints now. The tradeoff is wider spreads and less concentrated liquidity.
SF Compute
Shawn Wang (swyx), Host · Co-founder, AI Engineer
Wrote “The Rise of the AI Engineer” and founded Smol AI, maker of AI News.
About this segment
Evan Conrad says operations must be made consistent before compute contracts can standardize, but a flexible order book can match varying constraints now. The tradeoff is wider spreads and less concentrated liquidity.
From “The Programmable Data Center — Evan Conrad, SF Compute”, Oct 20, 2026. Watch the full episode
Thanks. We'll look at and fix what's off.
“and the reason why we did it this way is it allows us to generate liquidity without having to standardize before you know what the technology can do”
Takeaways
- One operator can offer virtual machines with 40% performance differences.
- Flexible matching can generate liquidity before standards settle.
- Wider spreads leave room for arbitrage by buyers who can use varied capacity.
In this episode
Full episode- 9:35Compute contracts must price interruptions and hardware differences4:49
- 14:13Batch and live inference need different interruption terms5:22
- 23:23Financial compute markets need physical settlement first3:29
- 28:58SF Compute operates clusters without owning the GPUs3:27
6:58A flexible order book can precede standard compute contracts2:38
- 20:17Compute buyers can choose broad or exact GPU SKUs3:05Up next
- 26:51Compute trading needs a supporting financial ecosystem2:17
Transcript
Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.
- 7:04
And so last time we talked as well, there was a lot of conversation about standardizing the contracts. Yes. Talking with like the CFTC or whatever, what's the status of those things? So I think standardizing the contracts in general is still pretty far away. And what we were trying to do at the time was, or basically what we learned over the last several years was we just needed to operate the whole thing.
- 7:32
Otherwise you cannot standardize the thing. And so to get closer to something that can be standardized, you first need to make all the operations of the thing the same. To give an example of what can be different is a single operator can offer two different types of virtual machines. One type of virtual machine might have a 40% performance degradation versus another type of virtual machine. And 40% is a lot.
- 7:56
When you say performance degradation, are you talking like MFU type things or like amount of... burn-in that you've experienced, or what? It will affect, so in this particular case, I'm talking about GPU kernel launches and how long it takes for that to happen, which is a process that happens quite frequently when you're doing sort of either training or inference. The, that will basically, the end result is that you get a worse MFU, but like, it's the intermediate level.
- 8:21
Yeah, it's the intermediate level, basically. Yeah, so what I'm trying to, so for anyone who's traded commodities before, there's different grades of commodity, right? There's like, it's not oil, it's light sweet crude versus like whatever the opposite of light sweet crude is. Or it's like, you know, corn level A or corn B or whatever. And so people are trying to, well, you have to establish the equivalents of those things.
- 8:40
Correct, yes. And I'm wondering if they have been established. So what we did instead was we created an order book that had multiple different constraints. And you can say, I want to have, you know, something that's between this and that. It runs from this time to this time. it's like x to y it's a bunch of different properties that you can attach your order and then we match that against cell orders that have those properties in a big matching engine and the reason why we did it this way is it allows us to generate liquidity without having to standardize before you know what the technology can do and because the technology was shifting so quickly we wanted to basically be able to do that the trade-off of this is that you have less concentrated liquidity and so the prices are going to have there's going to be more spreads between
- 9:21
the the buy and the sell yeah it sucks yeah but on the other hand it means there's lots of arbitrage to make um if you can do that correctly so if you have a product that can use lots of