The Programmable Data Center — Evan Conrad, SF Compute
- SF Compute’s core bet is that a tradable GPU market requires operating the infrastructure that delivers the compute. Conrad says the company spent three years learning why physical settlement matters: “these things aren’t as fungible as you think.” Even two VM configurations can differ by 40% in performance; financial contracts built ahead of reliable delivery risk manipulation and hedges disconnected from executable prices.
- SF Compute reports useful resale liquidity on the 5% of capacity currently listed in its order book. Customers spending $100 recover $25 on average by selling capacity to someone else, a practical measure of whether liquidity helps commercial users. Conrad separately reports closing several hundred million dollars of volume, while describing order-book volume as small.
- Swyx’s B300 inference estimates expose the episode’s sharpest pricing tension. Swyx estimates roughly $40 an hour of inference revenue at 100% utilization, or around $25 at roughly 50%, against rental costs of $5–$6 an hour. Conrad agrees it is a “huge overcharge”; buyers expecting higher compute prices may pay more to secure future supply.
- SF Compute wants a liquid forward curve that prices customers’ ability to surrender capacity. Buyers can purchase from an hour through three years; batch jobs might tolerate minutes of notice, while live inference may need one to three months. Swyx describes a “hump” in prices: unsold imminent capacity gets discounted like expiring milk, while shorter lead times can command a premium over distant delivery. Conrad also notes that some buyers may pay more for future capacity if they expect prices to rise.
- Conrad argues that independence is the condition for turning compute trading into cheaper financing. His impression is that NVIDIA, clouds and major inference buyers are not independent enough for people to trade on their venue. SF Compute avoids hardware ownership: “we have to be Switzerland,” enabling liquidity that lenders can finance against.
- The programmable data center gives asset owners an operating layer for their GPU investments. Customers can subdivide their InfiniBand fabric themselves as capacity needs change, while SF Compute operates the infrastructure and owns the SLA. Its sovereign-compute pitch combines local clusters with San Francisco demand and expertise: “We’re going to make it financeable.”
1. Physical settlement requires the operating capacity of a cloud
Conrad’s origin story begins with subleasing a cluster, then acquiring responsibilities like a hotel-room seller being asked for cleaning, room service and security: “at a certain point, you’re just running the whole hotel.” SF Compute consequently built the operating capacity of a cloud to deliver compute reliably. “Physical settlement” borrows the futures-market distinction between trading a contract and actually receiving the oil or soybeans.
The order book and delivery system were co-designed around compute’s constraints. Conrad compares this with power-market orders incorporating boiler cool-down times: a compute customer might accept interruption only with storage that enables quick recovery. Contract standardization remains “pretty far away.” The lesson was that “we just needed to operate the whole thing,” because consistent operations must precede a standardized product.
Conrad initially calls the market “not very mature, deep, or liquid,” then distinguishes small order-book volume from concentrated liquidity within listed capacity. Only 5% of total capacity is on the book, with more moving onto it. Customers spending $100 recover $25 on average through resale. He reports closing several hundred million dollars of volume; his preferred liquidity test is “Is this solving the problem for the customer?”
2. Hardware differences prevent a single interchangeable compute product
Swyx’s commodity-grading analogy meets a substantial engineering problem: one operator’s VM configuration can impose 40% performance degradation relative to another. Conrad locates the difference in GPU kernel-launch latency, which ultimately worsens MFU. Establishing equivalence therefore requires understanding what the infrastructure delivers, beyond identifying the GPU model.
SF Compute matches orders across constraints instead of waiting for fixed standards. A buyer could accept any Blackwell at $6 an hour or less, matching against GB300s or B300s; another needs specific memory or NVLink domains. Swyx objects that exposing heterogeneity hurts a market maker. Conrad agrees that dimensions remain: flexibility creates arbitrage opportunities, while specificity costs more. Named queries are being introduced; query-based matching already operates.
Storage and connectivity determine whether capacity is genuinely substitutable. Conrad points to WEKA or VAST systems, storage size, and whether data can move quickly enough to restart a workload elsewhere. That requires a fast transit path, typically a WAN. GPU clusters follow power availability, whereas traditional CPU clusters followed customers for latency, so newer locations may lack strong connections between sites.
Even deployment cohorts could matter, though cohort-specific matching remains an idea under consideration. Swyx asks why ordinary burn-in would not remove defects. Conrad distinguishes faulty individual GPUs from firmware problems that may affect multiple systems: an early H100 issue could have been firmware in a Supermicro box rather than the GPU itself. Testing and replacing broken hardware would not resolve that; the firmware would need an update or a fix in new boxes.
3. The forward curve prices both expiring capacity and interruption rights
Conrad’s “3 to 5 years” answer initially concerns how clusters are financed across the broader market. SF Compute’s order book supports arbitrary blocks, with purchases spanning an hour through “the next 3 years and anywhere in between,” technically finer too. Blocks currently require full payment upfront; longer-term leases do not. His priority is building a forward curve with substantial liquidity.
Capacity already running a workload differs from capacity starting next month, which can trade without interrupting anything today. Batch inference might tolerate an hour’s notice, or even a minute or two; live inference might require one, two or three months because disruption can trigger customer SLA payments. Swyx’s realization—“the market for breaking leases”—captures why interruption rights command different prices.
Asked whether the curve shows backwardation or contango, Conrad asks whether Swyx means future capacity priced above or below spot. Swyx says, “We see a hump,” and offers expiring milk as an analogy: imminent unsold compute must discount because “it can’t be sold in the past.” He suggests prices then rise toward their preferred level, while distant capacity might cost less because buyers value shorter lead times. Conrad acknowledges the explanation, then adds that buyers expecting prices to rise may be willing to pay more for later supply.
Swyx estimates that a B300 could generate roughly $40 an hour selling inference at 100% utilization—“Any model, basically”—or around $25 at roughly 50%, versus $5–$6 an hour to rent it. Swyx says, “One of these numbers has to change”; Conrad agrees it is a “huge overcharge.” Buyers expecting compute prices to rise may consequently pay more for future delivery to lock in supply.
4. Cash settlement needs a credible physical market underneath it
Conrad’s warning follows three years spent learning the delivery problem: financializing compute before physical settlement is established risks manipulation and substantial basis risk. The price used to hedge might have little relationship to the price at which a customer can actually obtain capacity. Making compute more fungible remains, in his framing, the industry’s job.
Swyx proposes the familiar currency-and-rates model: participants agree on a fixing like LIBOR. Conrad’s immediate objection is that LIBOR was manipulated. His concern is that compute indexes can similarly rely on very small datasets with little correlation to the price of buying a new reserved contract. An agreed benchmark alone does not resolve that underlying measurement problem.
Swyx says cash settlement could be a great future concept if derived from physical settlement. Conrad calls cash-settled contracts the kind of side bet seen in The Big Short, which may have little to do with the underlying thing. He says people are already making such bets in some areas, while Swyx cautions against derivatives on an underlying that does not yet exist.
Conrad says SF Compute is a big fan of Silicon Data and Compute Exchange, describing them as early entrants. He characterizes their cash-settlement path and SF Compute’s physical-settlement path as mutually beneficial, and says they may partner.
The surrounding ecosystem is developing distinct functions. Conrad identifies SemiAnalysis with efforts toward better standards, alongside residual-value insurance and deposit lending that fronts credit risk for clouds. He acknowledges limited familiarity with individual providers; his broader observation is an ecosystem forming around compute’s financial bottlenecks.
5. Independence supports a programmable data center business
Conrad’s impression is that NVIDIA benefits from this market but cannot credibly run it; similar conflicts apply to Crusoe, CoreWeave, Lambda, hyperscalers, Baseten, Fireworks and Modal. They are not independent enough for people to trade on their venue, and without trading there is not enough liquidity for lenders to finance against the forwards market. That liquidity could lower industry financing costs. SF Compute therefore avoids hardware ownership. Building the venue requires giving up lucrative cloud and inference opportunities: “You have to kill your business in order to make this.”
The operating stack spans site visits, bills of materials, OEM coordination to ensure timely delivery, cluster architecture, rack deployment and backplane management. Customers can now subdivide their InfiniBand fabric without asking the cloud to do it for them, supporting expansion and contraction as capacity trades. The ambition is to virtualize “all the stuff that you would have gotten if you had owned the hardware,” making the data center programmable.
Owners can bring a data center, megawatts or powered land; SF Compute coordinates with partners to develop the facility and takes over supercomputing, while it does not self-perform builds. For investors seeking a GPU cluster’s residual value, Conrad offers operational responsibility—“We own the SLA”—and says SF Compute can immediately sell the capacity to someone else if they need to exit, so it does not hit their balance sheet.
The business operates primarily in the U.S. but deploys globally with partners seeking to become local clouds. Sovereign-compute customers receive cluster setup, San Francisco expertise and San Francisco offtake. Conrad’s pitch connects that operating work directly to funding: “We’re going to make it financeable.”
Full transcript
1. Why NVIDIA can’t build this market
NVIDIA is obviously the 800-pound gorilla in the room. Why didn’t they make a supercomputer?
Our impression is that NVIDIA can’t make it, but benefits tremendously from it existing. The reason they can’t make it is that they wouldn’t be independent enough for people to trade on it.
2. Welcome back to Latent Space
Anyway, Evan, welcome back to Latent Space. Welcome back to AIE. Actually, is this your first time at AIE?
I think so, yeah.
This is a very special one because I feel like you’ve been working on compute trading and compute markets for a while, and now it feels like the moment. Jump basically announced that they’re getting into compute markets, which is why I’m excited to sort of cluster people. You met Oliver from SemiAnalysis, who is basically initiating coverage on compute markets. This is my read on it, so people are going to watch your—
Talk.
I think it’s a very good explanation of both your origin story and why you need to exist, and the hard problems you work on.
Yeah.
It’s done in a very simple, engaging manner. I’m very jealous of your writing skills, because you showed the flyer you had at NeurIPS. It was pretty straightforward and simple, and it was good.
Yeah.
Anyway, congrats.
Thank you. I appreciate that. And congrats on AIE. It seems like you all are rolling.
We’re rolling. I just came back from the site tour for next year’s AIE.
Give me a hint.
It’s at Javits Center, the same place they do Comic-Con.
Okay, wow.
Which—
Wow. Wow. Damn.
I think the finance focus is really hitting for folks.
Yeah.
We’re going to try to split things up. Here, we just lump everything together in finance: your finance, their finance, insurance is finance. But they’re all super different.
Yeah.
So we’ll probably break things out more minutely in the future, because people want to go deep on hedge fund stuff, banking, personal wealth, or—
Yeah, especially in New York.
Yeah. Anthropic was like, “We’re all about RIAs right now.” RIAs, or registered investment advisors.
Yes.
That’s so different from you.
Yeah, no, I’m aware of this.
Yeah, yeah. Okay, so for listeners who don’t know, we did a podcast 2 years ago where you talked about where SF Compute was.
Mm-hmm.
3. From selling a room to running the hotel
Today, you’re much more into this sort of physical settlement. You’re talking about your backplane—what do you call it?
The backplane.
The backplane, which obviously takes a lot of hardcore engineering. Can you give a status update on where SF Compute is, for listeners who last heard you on a podcast 2 years ago?
When we started, we were this company called Junnar, and we were just trying to sublease our cluster. We started there in the technical stack. One way to think about it is that you’re in a hotel and you’re trying to sell that hotel room. Somebody asks you, “Hey, are you going to clean my room?” And then you say, “Oh, I guess I probably also need the hotel room, or I need the cleaning closet.”
So you get access to the cleaning closet. Then they want room service, so you get access to the kitchen. Then they want security, so you get access to the security closet. You get this, and you do that, and you do this. At a certain point, you’re just running the whole hotel.
The moment you’re running the whole hotel, you say, “Oh, wait a second. My supplier in this market is somebody that looks closer to a fund or a cloud that has access—in our case, a cloud that has access to the data center—and we’re going to level up.” What we’ve spent the last several years doing is building the entire operating capacity of a cloud in order to actually deliver the compute at a reliable level.
4. Physical settlement: actually delivering compute
We call that physical settlement. We’re taking a term from the futures markets, from other markets. In oil or soybeans, physical settlement means you get delivered the oil and the soybeans.
Yes.
In some markets, like oil and power, there’s a delivery network. In oil, you have to have pipelines. If you’d like the oil to be delivered to you, there has to be a way for it to get to you.
Yes.
And for people interested in financial history, during COVID, oil went negative because people were saying, “I will pay you to take oil from me,” since it was sitting there in the port and they couldn’t pay for it.
Yes.
And so I will pay you to take my oil.
Yes.
That’s the weirdness of physical settlement.
Yes. There are a bunch of weirdnesses like this in other markets as well. In power markets and the grid, parts of the orders that buyers and sellers fill out are there because the boiler takes a while to cool off. You can stop the boiler and start it back up again within some period of time, so that has to get factored into the order book. This Junnar thing is the same thing that happens in compute markets. We co-designed physical settlement and the order book at the same time, which meant we could handle the real constraints of compute. That might include something like, “I’m okay with being interrupted, but only if there’s storage on the thing that I can recover from really quickly.” They’re very similar types of problems.
Yeah. People can refer to your talk, and you’ve done a couple of other podcasts already. I want to be sort of 201 level instead of 101 level, partly because I’ve been a derivatives trader, so I can give people a bit more detail than you normally get into. For example, how mature, deep, or liquid is the compute market today?
5. Liquidity and the GPU order book
Not very mature, deep, or liquid. First, we had to get a bunch of supply online, which just takes a while, and then we had to build the entire platform to do this. We just got that working, so now we’re moving capacity onto the order book, which makes it liquid.
Five percent of our total capacity is on the order book, and we’re consistently moving more and more. Then we’re bringing on more capacity that’s all on the order book. The nice part is that maybe I should say the volume on the actual order book is small, but the liquidity on the order book is high. For that small amount of capacity, you have very concentrated liquidity.
A standard metric for someone using this would be a customer who buys capacity from us: if they spend $100 to buy that capacity, they’ll make back $25 on average by selling it back to somebody else. That’s one of the metrics we try to track, because we want the liquidity to be useful to the commercial participant. You can measure liquidity in a bunch of different ways. You can say, “Oh, I just want tons of makers,” or measure it in high-minded ways. We try to measure it by asking, “Is this solving the problem for the customer?”
Yeah, got it. Last time we talked, there was a lot of conversation about standardizing the contracts. What’s the status on those things? You were talking with the CFTC or whatever.
I think standardizing the contracts in general is still pretty far away. What we learned over the last several years was that we just needed to operate the whole thing; otherwise, you cannot standardize it. 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: a single operator can offer 2 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.
When you say performance degradation, are you talking about MFU-type things, or the amount of burning 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 either training or inference.
Okay.
The end result is that you get a worse MFU, but—
Is the intermediate level—
Intermediate level, basically.
Yeah, yeah. So what I’m trying to say is, for anyone who’s traded commodities before, there are different grades of commodity, right? It’s not just oil; it’s light sweet crude versus whatever exactly the opposite of light sweet crude is, or corn grade A or corn B. People are trying to—well, you have to establish the equivalents.
The equivalents of those things.
6. Trading nonstandard compute
Right, yes. And I’m wondering if they have been established.
What we did instead was create an order book that had multiple different constraints, and you can say, “I want something that’s between this and that.”
It runs from this time to this time. It’s like X to Y. There are a bunch of different properties you can attach to your order, and then we match that against sell orders that have those properties in a big matching engine. The reason we did it this way is that it allows us to generate liquidity without having to standardize before we know what the technology can do. Because the technology was shifting so quickly, we wanted to be able to do that.
The trade-off is that you have less concentrated liquidity, so there are going to be wider spreads between the buy and the sell.
Yeah.
But on the other hand, there’s lots of arbitrage to make if you can do that correctly. If you have a product that can use lots of different types of capacity, you might really like SF Compute because you’ll be able to use lots of different types of capacity and make more money. You can take the spread.
Okay. What dimensions matter in this grid of things?
7. Interrupting and moving workloads
One category is whether there’s a workload running on it right now or whether it’s capacity in the future. Is it capacity right now? To sell capacity right now, you have to interrupt your current workload, so you have to think about whether you care if your current workload is interrupted. Capacity that’s being sold starting a month from now, you can buy and sell all the time, so you get liquidity on that really easily. There is some concern about whether you’ll have capacity next month, but it’s very different from interrupting a workload right now.
The way the interruption happens matters. For example, if you’re on a cluster and it doesn’t have as amazing a storage system as you want, do you have a WEKA or VAST system under the hood? Do you offer that, and what’s the size of it? This changes how you respond to being preempted or removed from the cluster.
Meanwhile, the location of that storage matters. If you’re able to move that data from one cluster to another quickly, maybe you can spread across multiple clusters. You can be interrupted over here and then pop back up over there. To make that work, you also need a fast transit path between one cluster and another. Typically, this is implemented with a WAN, but—
Most of these clusters don’t necessarily have a wide area network.
Yeah, a wide area network. Basically, cables that connect the clusters together. A private internet is another way to think about it. A lot of clusters being spun up today aren’t attached to traditional CPU clusters, which were next to the customer for latency reasons. With GPUs, they’re next to the power. You put the data center next to the power rather than next to the customer.
A lot of stuff is getting put in places where they previously weren’t expecting data centers, so you may not have as excellent a transit path from one cluster to another. That starts to matter.
Other examples are things we theoretically support but don’t actually support yet. This is something we’re thinking about but haven’t done, basically. The early GB200s broke. The early H100s broke. If you were buying H100s or GB200s, you might really want the ones that were deployed after a certain time, because you’re not getting the first GB200s off the rack. If you’re a sophisticated customer, you may be willing to pay more for that.
8. Why hardware cohorts matter
Oh, so it’s about what cohort they were produced in, and they get better over time?
The first ones off the rack may have had some faults or problems. If you got the first ones, or the first ones from the first shipment, then, yeah, they would be broken or have some problem.
I assume that sort of process is like, look, there are defects everywhere. It just happens, right?
Totally.
And so you get a new shipment from TSMC or whatever, run your tests, figure out which ones are bad, and throw them out. Isn’t that how it works? I didn’t know about this element of cohorting where, say, Q4 2026 B300s are way worse than 2027 B300s.
Yeah, I’ll give an example. You’re describing burn-in. When you get a cluster, a good cloud tries to kill all the GPUs before they ever get in the hands of the customer. The GPUs or nodes that are broken get RMA’d. You basically go and replace them. You return them and get new ones, and there’s a lead time, but whatever, you’ll get—
Yeah.
—you’ll get some back. Then the customer never has to experience this. The thing I’m referring to is that, in early H100s, there were firmware bugs that may not even be related to the specific GPU. They may not be NVIDIA’s; they might be a firmware bug in the Supermicro box you bought. It applies to all of them. The solution was to get them to update their firmware or ship a new thing in every new box.
Yeah. Cornelis had this for the B200s that we got, and then you had to use DevCloud to go fix it.
Yes, correct. Different types of problems like this can happen.
9. How far out do compute contracts go?
Interesting. Okay, that seems small compared to the overall picture. I want people to understand the shape of this market. You mentioned preemption, and we talked about spot instances and how that’s an analogy. There’s also booking a month out. How far out do these markets go? Is real-time preemption more interesting to you, or is it further out?
To answer your first question: 3 to 5 years.
Wow.
We’re starting to see—
Month by month or quarter by quarter? How does this work?
Are you asking how the cash flow works?
The contracts. The futures contracts, right? Again, I’m a former contracts and derivatives trader.
In the market itself—
Yeah.
—like in the broader market.
Yeah.
Clusters are financed for 3 to 5 years.
Okay.
The payments—
—are over that period of time.
Yeah. There are also blocks of capacity in our order book that can extend to any arbitrary time. There’s some stuff we have to do for the cash flow on that. Right now, we just ask people to pay entirely upfront for a block. We don’t ask them to do that for a lease, for a longer-term contract. This gets into something I definitely need a whiteboard to explain.
But you had another question I was about to answer. I forgot what it was.
Do you want real-time, or do you want something further out? What’s more interesting to you: real-time or further out?
We care more about further out because we’re trying to build a forward curve that has a lot of liquidity on it. These are kind of the same thing and kind of not. You can buy an hour out, from right now to the next hour. Or you can buy from right now to the next 3 years, and anywhere in between.
That’s wild.
10. Batch versus live inference leases
I know. And you can go even finer, technically. There’s a difference that depends on each customer. If I have a batch inference workload where I can be interrupted at any point, I don’t really care. I might need an hour’s notice that I’m going to be cut off, and then I’m good. I can even be notified in a minute or two.
But if I have live inference customers who are expecting me to be online, you can interrupt me, but it has to be in a month. Maybe 2 months, maybe 3 months. Then I can adapt to that capacity over that period of time, but you cannot interrupt me in a minute.
Those two things are priced differently. The price you would pay to interrupt your batch job is very different from the price you would pay to interrupt your live job. If you have a live job, you’re probably paying an SLA when you break it for your customer. Does that make sense?
Yeah, I see. So this is actually the market for breaking leases.
These are markets for breaking leases, basically.
God.
And then there’s also the market for future leases, or leases that are—
Oh, I thought this was a subletting situation. This is like—oh, the lease break.
One way to think about it is that, in power markets, there are actually 2 markets. There’s the day-ahead market, and there’s the live market. Compute kind of has the same thing, where there’s capacity that’s coming online, or capacity that’s about to arrive to you, and then capacity that’s currently in use. These have different price dynamics.
11. The shape of compute prices
Okay, interesting. Backwardation or contango?
Backwardation or contango?
Do you mean, is compute further out priced higher than spot or lower than spot?
Does compute further out go like this or like that over 1 year out, 2 years out? I find it fascinating that you don’t know.
Yeah, I mean, both. It depends on who you are. I’ll make the case—wait, so you’re asking whether a unit of compute sold today, or maybe a month out versus 1 year out versus 2 years out, is priced on a curve that’s going up or going down?
We see a hump.
Oh my God.
Okay, so—
Explain.
I think this will make intuitive sense. If I have milk and it’s about to expire, I’ll lower the price on it.
Yes.
That’s basically what we see.
So it’s the end of the lease cycle, basically, right?
Well, we’re saying that if there’s a block of compute approaching now, it can’t be sold in the past, so it has to drop its price in order to clear. Initially, you see this drop: anything that’s on the market right now is something that hasn’t been sold, so the price will drop.
Mm-hmm.
Then it goes up to where it wants to be.
Mm-hmm.
Maybe compute in the future is worth less because people would like the compute now, so they’re paying for the shorter lead time. They pay less for compute that’s further out in the future. This is what I think a normal, healthy curve looks like.
Yeah.
The place where I’m like, “Oh man, no shit,” is that right now, if you took a B300 and tried to run inference on it, you could make $40 an hour or so selling that.
Any model?
Any model, basically. That’s if you use it at 100% utilization. Maybe if you only have 50% utilization or something, it’s more like $25 an hour.
Yeah.
So, $25 an hour. Meanwhile, you can buy B300s at like $5 to $6 an hour. One of these numbers has to change.
Yeah. It’s a huge overcharge.
It’s a huge overcharge. You’ve mentioned this in your talks a lot.
Yeah. A bunch of people are basically looking at this and thinking, “If I think prices are going to go up, I might be willing to pay more than I previously thought in the future. If I can buy some now, but can’t buy any more, then maybe I’ll be willing to pay even more in the future just to lock it in, if it’s going to come online later.” So we see the other side as well. It kind of depends on who you are.
12. GPU generations, specifications and SKUs
Cool. I really want to make this super clear. Do you care about the different generations of chips, or do you just care about overall FLOPs and spread them among whatever chips you want?
We care about different generations of chips because—
You care? I guess, do your customers care?
Yes.
Right. When you say different generations of chips, do you mean, like—
Like B300 generation?
Yeah, exactly. Or even AMD or whatever, right?
Yes, I think people totally care about the generation of chips. Part of this is because of things like VRAM, and part of it is because of larger NVLink domains and things like that.
So there’s no way to abstract all this into some generalized unit of compute that you can mush around however you like?
I think, like you were saying with oil, even oil isn’t just oil. It’s a bunch of different types of oil.
Yeah, like jet fuel or car fuel or whatever.
I think it’s the same thing. You’re going to get a bunch of different types of—
It is, but you have oil refineries that you can effectively use as black boxes: you put oil in and get whatever you need out. If compute is so heterogeneous, I guess the word is, then you have to expose the underlying complexity to your end customer, which is bad for you as a market maker.
Maybe.
You want to identify the one choke point—or I don’t know what the better word for choke point is—a Schelling point, where everyone agrees, “Okay, this is kind of the standard,” and we all agree to it. It’ll be somewhat inefficient.
Yes. We’ve been able to reduce the problems to a certain level.
Yeah, your job is dimensional reduction and all that.
We reduce a lot of the dimensions, but there are still dimensions. They’re still going to exist.
Do you know how many SKUs you have?
So—
Like 5 times 100 times 5,000? That equals, I don’t know. What’s the number?
We actually made SKUs a concept, and the goal is to make it so that somebody else can make their own SKU. If I want to buy Blackwells, I can say I’m willing to buy Blackwells at $6 an hour or less. You can match me against GB300s or B300s, and I don’t care which Blackwell, as long as it’s less than $6 an hour.
But you just said you care about memory and other stuff.
Totally, but not every customer does. Some customers can work on Blackwells, whatever they are. Some customers are super specific and need this exact thing, and they’re going to pay more for that because the market’s going to charge them more. That’s what we do.
So people use your APIs to programmatically define what they want, and then you match that with whatever composition of sellers might be able to fulfill it?
Yes, with the caveat that having a named query is a new thing we’re doing. But the query system as a concept is how the order book works right now.
13. Physical versus cash settlement
Okay, interesting. I think that’s a lot of the nitty-gritty. Is there anything you want to educate people on, whether financial people or engineers, about the state of the compute trading market as you’ve developed it? You guys are effectively defining it.
Mainly, just the requirement for physical settlement. We spent 3 years learning why you need physical settlement. Our entire conversation today is about how these things aren’t as fungible as you think. We’re going to try and make them fungible; that’s the industry’s job. But without that, you run a lot of risks. If you try to build too much financialization before the industry has had time to build out physical settlement, then you have a market that’s very easy to manipulate and has a lot of basis risk. The price you may be hedging against may have nothing to do with the price—
Yeah.
—you can actually buy the capacity for.
Yeah. For listeners, we talked about this briefly last time, but people are often shocked to find out that the market for credit default swaps is 12 times the size of the bonds they insure, something like that. The markets for mortgage reinsurance and things like that are larger than the underlying physical settlement. That’s why physical versus cash-settled matters.
Yeah. Cash settlements are exactly the kind of side bet you see in The Big Short.
Mm-hmm.
They may or may not have anything to do with the underlying thing itself, and they may be used as a proxy for other things overall. You don’t want that to go out of control.
Yes. To be clear, we think cash settlement as a future concept is a great idea. We just think it should be derived from physical settlement. As you said, it’s a side bet. It would be kind of like if you made a cash-settled future before you made physical settlement.
Which I think people are kind of doing already.
Not yet, totally. People are trying to make cash settlement before they make physical settlement.
You do that for all sorts of things, including startup stock.
Yes. You can buy and sell a made-up share on OpenAI, but it has nothing to do with the actual share.
Yes.
Lots of those go very poorly. It would be kind of bad if you started selling the derivative on a stock that doesn’t exist yet.
Yeah.
Well, one thing we do—I used to be a currency trader, and interest rates as well—is you have a board that gets together and says, “This is the London Interbank Offered Rate, LIBOR.” We all agree this is the monthly fixing, and we all trade to that fixing.
Yes.
Is that even meaningful at some point 3 years from now?
So, critically, LIBOR was manipulated.
Yes.
Our concern at the moment is—
12 banks. Yeah.
Yes. Well, our concern is that there’s a very similar problem where you can manipulate an index. Our impression is that you can manipulate that index because a lot of the indexes are based on a very small amount of data that doesn’t have a lot of correlation with the actual price of buying a new reserve contract.
14. The emerging compute market ecosystem
Okay. Interesting. All right, I think that’s the rough state of things. I think the other part of today is that you talked with Oliver, you’re doing an event with Jump, and you’re friends with Silicon Data. What are you learning from all these other players? Who are the major players you’d call out as doing interesting things?
We’re big fans of Silicon Data and Compute Exchange. I think they were also very early to this, and they’re doing a reasonable job on the path that we think we’ll likely end up partnering with.
Can you distinguish your different paths?
The general gist is that they’re doing cash settlement, and we’re doing physical settlement. We think both can exist and should exist, and that they’re sort of mutually beneficial to each other. I think they’re one of the earliest in the space, and they very clearly took the bet well before anybody else did. I think that’s very honorable to do. You mentioned Jump.
SemiAnalysis, Jump. Are these other players emerging? You were my first introduction to this, and then I see all these other guys coming in, and I’m like, “Okay, something’s happening here.” I don’t know the landscape as clearly as you do.
The categories of folks we’ve seen include people trying to set better standards. SemiAnalysis, I think, is working to create better standards. There are folks trying to do residual value insurance, and so on. There are a number of different companies in the space. I don’t know any of them super well, but I know this is a concept, and I think that’s important.
There are folks trying to do deposit lending, where they’ll front your credit risk for the cloud. There’s an ecosystem of companies forming around the question of how we resolve the financial bottlenecks of compute, and it’s cool to see.
I think effectively what you want in this ecosystem is buyers and sellers, an analyst, and, we said, insurance—or what’s the—
Residual value insurance.
Residual, and you want this healthy ecosystem out there.
Mm-hmm.
But obviously, you guys are owning the problem of physical settlement, which is really interesting. We can go into the hard-tech side, because you’re also hiring—
Yeah.
15. What it takes to deliver a GPU cluster
—for extremely cracked engineers. Describe your stack.
We do all the things the cloud does without being the cloud. We don’t own the hardware. The reason we don’t own the hardware is that, if we did, we’d be able to manipulate the forwards market. So we have to be Switzerland; we have to be independent, which creates a lot of strange things about the company.
In order to do physical settlement, you have to do site visits. You have to visit the data center. You have to design the bill of materials. You have to do supply-chain consulting, where you have relationships with different OEMs that ensure things get delivered on time.
Then you have to do cluster architecture, so you’re designing the cluster itself. Then you’re rolling out racks, or working with partners to roll them out, and supervising that. Then you’re doing backplane management, taking over the PDUs, switches, DPUs, UFM, and BMC, and operating your harness around the nodes you’re settling.
You, as an SF Compute employee?
Yeah.
Wow.
All right. When you buy a node from a cloud, there’s the bare metal, but there’s all this around the bare metal. In order to make that bare-metal node work, you have to operate everything else. Then we—
Because traditionally, the job of the data center is to extract some of this away from you.
Yeah. We’re the ones that do that.
Yeah, yeah. Okay, all right. But you’re not in the data center business. You’re not the Equinixes of the world.
We’re not in the data center business, sort of. What we do work with is—so, we offer supercomputing as a service. What this means is folks come to us and say, “I’ve got X,” where X is, “I’ve got X megawatts here.” Sometimes they mean, “I’ve got a data center that I’d like to turn into a GPU cluster. My options are I could sell the GPU cluster, I could sell the data center to somebody, or I could become the cloud.”
Then we go to them and say, “Great, we’ll turn you into the cloud. We’re the supercomputing part; you’re the data center cloud. Let’s partner together, and then we’ll sell and all make money.” Sometimes it’s people who have something that could turn into a data center. In that case, we’re going to project-manage that up to the layer, and then work with those folks to turn their powered land or whatever they have into a data center by working with partners. Then we take over at the supercomputing part.
This requires us to have some data center expertise in-house, but we don’t self-perform builds.
Yeah, so it’s somewhat modular because you have different scenarios you need to deploy under.
Yeah. Someone once described us as Palantir for compute, because each time it’s this new rodeo. But we deeply partner with folks on both sides.
And primarily the U.S.?
Primarily the U.S., but we operate around the world.
At some point, does SF Compute become a misnomer?
We’re deploying clusters all around the world, and when we do that, we’re working with people who are themselves trying to be clouds all around the world. They look like sovereign compute players. Our pitch to sovereign compute is, “Amazing. Let’s help you set up a cloud in your own country. We’ll bring the San Francisco offtake. We’ll bring the San Francisco expertise. We’ll set up the clusters.” That’s our whole business.
Ah.
We’re going to make it financeable.
Who are your biggest announced partners that you can name?
Nobody I can name, basically. We’ll have some announcements in a week or two that we expect to come out.
Sure, sure. Good luck. I think this is really interesting for every country investing in sovereign AI to figure out. It’s interesting that SF is still that brand name, and that it’s very marketable.
I think one of the interesting things is just thinking through this market.
Mm-hmm.
Nvidia is obviously the 800-pound gorilla in the room. Why didn’t they make SF Compute? Again, I know the answer’s going to be market manipulation, but let’s really get into the incentives of the multiple players.
Our impression is that Nvidia can’t make it but benefits tremendously from it existing. The reason they can’t make it is that they wouldn’t be independent enough for people to trade on it. If you don’t trade on it, then you don’t have enough liquidity for lenders to finance against the forwards market.
This is also why Crusoe, CoreWeave, and Lambda can’t make it; why the hyperscalers can’t make it; and why Baseten, Fireworks, and Modal can’t make it, because they have too much demand on that side. This benefits the entire industry because it makes the financing costs go down. But nobody can make it unless they give up the ability to do all the big inference money and all the big cloud deals. You have to kill your business in order to make this.
That’s why nobody does it. Structurally, they’re not set up to do that. You’re basically reducing friction, and that’s all your revenue. You’ve announced some benchmarks, some milestones. Actually, I forgot to say that up front. Can you repeat what they are and take a victory lap a little bit?
16. A programmable data center
We closed several hundred million dollars of volume. We have a significant number of new clusters on the way. The things I’m most excited about are the new features we’ve shipped that make SF Compute very viable for platform-as-a-service companies.
For example, we allow customers to subdivide their InfiniBand fabric without having to ask us. Many clouds, when you go to buy from them, will give you one InfiniBand fabric. If you want to redraw the lines of that fabric, you need to contact them, and they’ll do something for you. We can now do that on the fly for customers, which I think is really great because it interfaces with the market really well. You want to be able to redraw things in order to scale your clusters up and down.
Would you describe this as virtualizing the data center and making it programmable?
Yeah, we’re virtualizing the data center and making it programmable. All the stuff that you would have gotten if you had owned the hardware, we’re trying to virtualize that, which I think is exciting to us.
It’s funny, the last time this happened was with the cloud.
Yeah.
Which is really cool. And then finally, what is your call to action for people? Is it engineers? Is it, like, “Give me your supply”? What is it?
If you would like to own a GPU cluster and you want the residual value from it—you want to have it in your portfolio—we would love to work with you to build that GPU cluster. We’ll take over and do the supercomputing portions of it and ensure things go right. We own the SLA. If it turns out that was a bad idea and you need to get out of that cluster, we can immediately sell it to someone else so it doesn’t hit your balance sheet.
Very simple pitch. Well, thank you so much for your time. You’re doing a great service to the industry, and I’m just happy to be your friend.
I appreciate it.
All right. That’s it.