Evan Conrad, chief executive of SF Compute, has one main message for the traders, index providers and engineers now entering the business of buying and selling GPU time. Asked what he wanted financial people and engineers to understand about compute trading, Conrad answered: "mainly just the requirement for physical settlement." He said his company had "spent three years learning why you need physical settlement," and summed up the reason in one line: "these things are not as fungible as you think."
Conrad made the case on Latent Space. The episode was published October 20, 2026, and recorded at the AI Engineer conference in New York, which had a new track on compute trading. Other financial players were arriving too. Jump Trading's compute trading co-leads gave a talk at the conference on October 14 titled "The Dark Pools of Compute". The conversation also touched on the research firm SemiAnalysis and the index provider Silicon Data.
SF Compute runs a market where companies buy and sell hours on GPUs, the chips used to train and run AI models, either for now or for future dates. Conrad's argument explains why that is harder than it sounds.
What physical settlement means
Conrad borrowed the term from futures markets. A futures contract is an agreement to buy or sell something at a set price on a later date. Under physical settlement, the buyer receives the goods. "Physical settlement means you get delivered the oil and the soybeans," Conrad said. Under cash settlement, the parties only exchange money based on how a price moved.
Delivery needs infrastructure, Conrad said. "If you would like the oil to be delivered to you, there has to be a way for it to get to you," which in oil means pipelines. For SF Compute, delivery meant usable GPU time at a reliable level. He said the company had spent the past several years building "the entire operating capacity of a cloud" to provide it.
The discussion turned to oil prices going negative during COVID as an example of how strange physical settlement can get, with oil described as sitting in a port while its owners paid others to take it away. The U.S. Energy Information Administration's account places the event somewhere else. It happened in the expiring May 2020 contract for WTI crude, a U.S. benchmark oil, whose delivery point was Cushing, Oklahoma. On April 20, 2020, that contract fell to an intraday low of minus $40.32 per barrel. Holders trying to get out of their positions found few buyers, and uncommitted storage was scarce and expensive after pandemic restrictions cut fuel use. Other benchmarks and longer-dated WTI contracts stayed positive. The EIA tied the plunge to contract expiration and delivery constraints, which fits the broader point about delivery.
Conrad added an example from electricity markets. Some fields on power-market orders exist because a boiler takes a while to cool off, and once stopped it can be started back up only within some period of time, so the order book has to account for that. The same kind of issue comes up in compute markets, he said, which is why SF Compute "co-designed physical settlement and the order book at the same time." That design lets the market handle real constraints. For example, a buyer may accept being interrupted, but only if the cluster has storage the job can recover from quickly.
Why standard contracts are "still pretty far away"
Traded commodities usually depend on standard contracts, so that one barrel or one bushel can be swapped for another. The conversation recalled that an earlier discussion had covered standardizing compute contracts and talking with regulators such as the CFTC, the U.S. agency that oversees futures markets. Conrad said standardization "is still pretty far away." His lesson from the intervening years was that "we just needed to operate the whole thing. Otherwise you cannot standardize the thing." Before contracts can be identical, he said, the operations behind them have to be the same.
His example: a single operator can offer two types of virtual machines, and one can perform 40% worse than the other. "And 40% is a lot," he said. In this case the difference lay in GPU kernel launches, meaning how long it takes the GPU to start each of the small programs it runs. Launches happen frequently in both training and inference, Conrad said, and the end result is worse MFU, or model FLOPs utilization: the share of the chip's theoretical arithmetic that a job actually uses.
The discussion then compared this to commodity grades. Oil trades as specific grades such as light sweet crude, and corn comes in grades too, so traders first have to agree on what counts as equivalent. The question was whether compute had established such equivalents yet.
An order book that accepts many conditions
Conrad said SF Compute took a different route. An order book is the list of bids and offers that a market matches. SF Compute's version accepts orders with several constraints: a range of acceptable values, a start and end time, and other properties. A "big matching engine" then pairs each buy order with sell orders that meet those conditions. This let the company create liquidity, meaning a ready supply of trading partners, without fixing standards while "the technology was shifting so quickly."
The cost is that trading is spread across more variants, so the gap between the price buyers offer and the price sellers ask is wider. Conrad pointed to the other side of that gap: "there's lots of arbitrage to make." A product that can run on many types of capacity can use whatever is available, make more money and "take the spread," he said.
SF Compute's SKU documentation describes how this works today. A SKU (stock-keeping unit) is a defined class of interchangeable hardware, set by the accelerator model, the network, the location and the machine shape. Each SKU has its own order book, and an order fills only against the same SKU. Conrad said the goal is for customers to be able to make their own SKUs. A buyer could say "I'm willing to buy Blackwells at $6 an hour or less" and be matched with either NVIDIA's B300 or GB300 systems. He said having a named query of this kind is "a new thing we're doing," while the query system as a concept is already how the order book works.
What makes one GPU-hour different from another
Asked which dimensions matter, Conrad started with timing. Capacity in use right now can only be resold by interrupting the workload running on it, so the seller has to decide whether that interruption is acceptable. Capacity that starts a month from now "you can buy and sell that all the time," so it trades easily.
How an interruption plays out also matters, and that depends on storage. Conrad named storage systems from WEKA and VAST, and their size, as factors that change how a job responds to being removed from a cluster. Training jobs save their progress at intervals in snapshots called checkpoints, so an interrupted job can resume instead of starting over. A VAST and NVIDIA walkthrough shows a job that writes checkpoints at one site and resumes at another through replicated storage.
That kind of move depends on where the data sits. If data can travel quickly between clusters, Conrad said, "you can be interrupted over here and then pop back up over there." That needs a wide area network, which he described as "basically cables that connect the clusters together," a kind of private internet. Many new clusters lack one. Traditional CPU data centers were built near customers to reduce delay. With GPUs, Conrad said, "you put the data center next to the power rather than next to the customer," often in places where no one expected data centers, so a fast link between sites may not exist.
Then there is the question of when the hardware was made. "The early GB200s broke. The early H100s broke," Conrad said, so a sophisticated buyer might pay more for units deployed after a certain date rather than "the first shitty ones off the rack." He described pricing by production batch as something SF Compute is thinking about but has not done.
When the conversation turned to whether defects are simply caught by testing, Conrad separated two problems. One is burn-in: a good cloud tries to "kill all the GPUs" before customers ever touch them, then returns broken units to the manufacturer for replacement, so customers never see the failures. The other is a flaw shared by a whole batch. In early H100s, he said, there were firmware bugs that might not even come from NVIDIA. A server maker such as Supermicro could have a firmware bug that "applies to all of them," and the fix was a firmware update or new boxes. SF Compute's published cluster requirements for B300 and GB300 systems, effective August 24, 2026, cover both kinds of check. They call for at least a 24-hour GPU stress test, cluster-wide testing that normally lasts 48 hours, and firmware versions that match the purchase specification.
Chip generation also matters, and Conrad said people "totally care" about it. He gave two reasons: VRAM, the memory on each GPU, and larger NVLink domains, meaning how many GPUs are joined by NVIDIA's fast direct links. NVIDIA's Blackwell Ultra explainer shows how much these can differ within one chip family. HGX and DGX B300 systems hold eight GPUs, while a GB300 NVL72 rack combines 72 GPUs with 36 Grace CPUs. Memory can reach 288 GB per GPU, depending on the configuration.
The discussion arrived at the view that there was no way to boil all this down to a generalized unit of compute. Conrad agreed, noting that "even oil isn't oil" since it comes in many types. A counterpoint followed: oil has refineries, a kind of black box that turns crude into whatever products are needed, whereas compute forces a market maker to expose its full complexity to customers. When SF Compute's job was characterized as dimensionality reduction, Conrad agreed in part: "we reduce a lot of the dimensions, but nonetheless, there are still dimensions." Some customers can use any Blackwell chip. Others need "this exact thing," he said, "and they're going to pay more for that."
The warning about cash settlement and indexes
This is why Conrad thinks the order of construction matters. If the industry builds "too much financialization" before physical settlement exists, he said, the result is "a market that's very easy to manipulate and a market that has a lot of basis risk." Basis risk is the danger that a hedge follows the wrong price. In his words, "the price you may be hedging against actually has nothing to do with the price" at which you "can actually buy the capacity."
The conversation drew comparisons from finance. It cited, roughly, that the market for credit default swaps (insurance-like contracts against bond defaults) is about 12 times the size of the bonds they insure, and likened cash settlement to the side bets in The Big Short, which may or may not have anything to do with the underlying asset. Conrad said cash settlement as a concept for futures is "a great idea," but "it should be derived from physical settlement." When the discussion noted that some people were already doing it the other way around, Conrad agreed. When made-up shares of OpenAI traded with no link to the real stock came up, Conrad said "lots of those go very poorly."
The discussion then turned to LIBOR, the interest-rate benchmark set from bank submissions that many contracts traded against. "So critically, LIBOR was manipulated," Conrad said. The CFTC's 2012 Barclays settlement describes two kinds of misconduct. Barclays traders requested rate submissions that would benefit their derivatives positions, and senior management directed artificially low submissions to ease concern about the bank's finances. The bank paid a $200 million penalty.
Conrad said compute faces "a very similar problem." Many indexes, he said, "are based on a very small amount of data that has not a lot of correlation with the actual price of buying a new reserve contract." He did not name a specific index. Index providers publish how they work. SemiAnalysis's methodology, for example, describes hourly rental-price indexes for H100, A100 and B200 chips. It allows each provider one price per hour, gives large cloud providers more weight than marketplaces and smaller clouds, and adds contract-price surveys for the H100 only.
Where cash settlement fits
Conrad was warm toward one group of cash-settlement players. "We're big fans of Silicon Data and Compute Exchange," he said. He described them as early to the field and called their decision to take that bet before anyone else "very honorable." The difference, in his telling, is that "they're doing cash settlement. We're doing physical settlement." He said both can and should exist, that they benefit each other, and that SF Compute will likely end up partnering with them. At the same conference, Carmen Li presented Compute Exchange as a marketplace for reserved GPUs, future delivery and used servers.
Conrad described the rest of the field by role. SemiAnalysis, he said, is working to set better standards. Other companies are trying to offer residual value insurance, which protects owners against hardware losing value faster than expected. Still others offer deposit lending, in which they "front your credit risk for the cloud." In Conrad's account, an ecosystem of companies is forming around "how do we resolve the financial bottlenecks of compute."