SF Compute: Making GPU Time Tradable

Why another GPU matters more than another web server

Once an HR service has enough web servers to serve its customers, adding servers does not automatically generate more revenue. Evan Conrad uses Gusto and Rippling to illustrate that capacity ceiling. Model training and test-time compute—spending more computation during inference to improve performance—create a different purchasing incentive: developers may keep benefiting from additional compute even as returns diminish.

The web-service buyer tries to minimize the cost of a required capacity; the AI buyer tries to maximize compute within a fixed budget. Conrad argues that this makes large GPU customers exceptionally price sensitive. His stronger assertion that every additional GPU produces revenue is an economic thesis, not a measured relationship.

His hypothetical software premium makes the stakes concrete: a 10% difference on $1 billion is $100 million. A buyer could spend $50 million reproducing a provider’s software and still save money. At that scale, convenience competes with a powerful incentive to switch.

Conrad credits CoreWeave with recognizing the financing consequence: sell long commitments to creditworthy customers, then use those contracts to obtain cheaper capital. He sees its financial structure as closer to banking or real estate than a conventional software business—and considers that a viable business in its own right.

The contract determines who carries the risk

Conrad identifies two ways to earn money from GPU customers: high hourly prices for small experimental users, or long commitments with substantial upfront payments from larger buyers. Customers that reach scale, he expects, will demand discounts. For the largest cloud providers, GPU resale also competes with other uses of capital, including model products and hardware that competes with NVIDIA. His prediction that they will lose money reselling NVIDIA GPUs is explicitly an intuition.

The financing framework turns on payment risk and falling rental prices. A long contract paid upfront reduces both exposures for the provider. Payments spread over time can still support attractive financing when the customer is creditworthy; the same promise from a fragile startup offers less reassurance to a lender.

High initial prices offer another possible cushion. In an illustrative example, a GPU rents for $5 an hour against an underlying cost of $1.50. Early profits must cover later periods when competition pushes rental prices toward or below that cost. But price-sensitive customers negotiate those margins down, and better-capitalized competitors can cut prices when they choose.

The worst position in this framework is short commitments, low prices, and payment over time: uncertain receipts and higher financing costs squeeze the provider from both sides. SF Compute’s representative says its early business approached this trap. A broad, high-margin cloud was an appealing fundraising pitch, but software differentiation could not resolve the underlying hardware economics.

Why would NVIDIA leave room for independent clouds? The tentative explanation is channel conflict: operating a competing cloud could damage relationships with its existing cloud customers. Independent providers could also diversify NVIDIA’s buyers, limiting the bargaining power of a few large purchasers. These are hypotheses about its incentives, not established accounts of its decisions.

Separate software from the hardware commitment

Owning a cluster—or signing a long compute contract—creates exposure that software margins must cover. SF Compute’s representative argues that this becomes especially difficult when customers already spend their available budgets on compute. A billion-dollar hardware commitment would require an enormous software business to justify the proposed economics.

SF Compute proposes separating the businesses: infrastructure providers finance and operate capacity, while software companies buy it through a market. Its representative offers Modal as the software-side example and CoreWeave as the infrastructure-side example. The recommendation is emphatic: building software on GPUs does not, by itself, justify buying a cluster.

A host extends the price-sensitivity argument to custom chips, crediting Martin Casado with the reasoning: hypothetical training budgets of $5 billion or $50 billion might justify designing specialized hardware. The reply adds a consequential condition: specialization requires a stable understanding of the workload. Established inference workloads appear better suited to it than training programs whose experiments benefit from general-purpose hardware.

One month of training became a year of selling compute

SF Compute began with plans to train music or general audio models. The founders wanted to avoid a large initial fundraising round that could leave them heavily diluted or carrying a valuation difficult to justify later. They expected to rent thousands of A100s for a month, much as they could obtain smaller quantities on demand. The providers they contacted required at least a year.

Their workaround was to sign a year-long contract with monthly payments, use one month, and sublease the remaining eleven. That changed the company’s immediate job: it owed approximately $500,000 every thirty days, with approximately the same amount in the bank. Selling the cluster each month became necessary for survival.

Repeated sales became brokerage. SF Compute could combine two six-month buyers to satisfy a vendor’s year-long contract, arrange the deal, take a cut, and typically operate the cluster directly for customers. Its growing book of buyers and sellers became a market with bids, asks, and a trading engine.

Resale connects long commitments to short experiments. A customer can buy a year and sell unused time to someone who needs a month. The representative says the market can offer thousands of H100s for as little as an hour, while emphasizing that this illustrates its range rather than typical behavior. A more practical example is a long-term buyer whose code is not ready reselling a month to someone ready to run.

Providers can sell idle capacity while SF Compute brokers their preferred long-term contracts; temporary customers make room when those commitments begin. Buyers can cancel through resale, with a fee tied to the difference between their contract price and the market price. The mechanism aims to provide flexibility while preserving the provider’s payment.

The representative claims that prices fall until cluster utilization approaches 100%, when hardware and software work properly. That concerns selling available capacity, not guaranteeing productive computation on every GPU. Broken switches or sections of the cluster’s InfiniBand network can still force capacity offline.

A glut can coexist with growing demand

Falling GPU prices need not imply falling demand. The tentative explanation offered is that rapid construction created bottlenecks beyond the chips: networking cables, generators, and data-center space delayed clusters. Once those bottlenecks cleared, substantial capacity arrived together. Supply could outgrow demand even while demand continued rising.

In the conversation published in April 2025, Evan tentatively forecasts a return toward shortage by winter, conditional on future chip deployments. He says proximity to the market has made him less confident in precise predictions. His firmer expectation is that test-time inference will expand compute demand; the price effect depends on how quickly new supply arrives.

The demand mix matters. The respondent describes inference demand as concentrated among a few large consumer products, while many enterprise workloads need large training runs and much less inference afterward. Bio and pharma are offered as a qualified example: organizations may buy thousands of H100s for training without running a consumer-scale inference service. The speaker disclaims biology expertise and acknowledges that their inference still involves multiple runs and batches.

Aggregating sellers does not require scattering a job across distant machines. Asked about peer-to-peer GPU networks, the respondent doubts that geographically distributed hardware can outperform a tightly interconnected cluster because of communication latency. SF Compute sells capacity from clouds and data centers and lets buyers require co-located nodes. Crypto might help payments or subsidize a market’s initial activity, but the company says it did not need token incentives to get started.

A host raises a possible counterpoint: model architectures could be redesigned to distribute computation more effectively across distant hardware. The respondent accepts that possibility. The skepticism applies to workloads without such changes, where communication latency remains a physical constraint.

Large bursts for smaller teams

Graduate students expose a mismatch in traditional GPU financing. A researcher may afford an intensive run but stop spending when the project ends or they graduate. That is unattractive to a provider seeking durable revenue, yet well suited to temporary capacity. An expiring $100,000 grant is the conversation’s example: enough for a concentrated burst, without a year-long commitment.

The customer discussion names Standard Intelligence, Phind, and Schmidt Futures grantees. The representative declines to characterize the grantees’ research. The broader opportunity is access to large-lab scale for a short period, for teams that cannot sustain that spending.

Venture-funded clusters addressed a related credit problem. A startup trying to borrow roughly $50 million for hardware and colocation faced a harder financing problem than a large fund or wealthy guarantor. Exchanging equity for compute exploited that difference in creditworthiness. The respondent considers the Andromeda Cluster useful in its original context, but would not recommend copying the strategy at the time of the conversation: additional financing and compute sources had reduced the opportunity.

An hour is reserved; the next hour has a price

A host notices an apparent pricing anomaly: a one-week offering costs more than both one-day and one-month offerings. The response explains the cheap immediate capacity through perishability. Yesterday’s unused GPU time cannot be sold today, so sellers lower prices on imminent idle time until it sells or reaches their floor. Reservations farther in the future need not receive that discount.

SF Compute’s primitive is a one-hour reservation, with automation to buy subsequent hours. The purchased hour cannot be reclaimed within that reservation; continued access depends on buying the next one. A price above the buyer’s limit can therefore stop renewal. The discussion compares this with spot-instance purchasing, familiar from Amazon Spot Instances, while emphasizing the buyer’s control over the purchasing threshold.

Two illustrative policies trade cost against continuity: - Favor continuity: renew at the market price with a high cutoff, such as $4 per hour. That is the maximum acceptable price, not the price paid every hour. Occasional expensive hours reduce interruptions. - Favor price: run a resumable job only when capacity costs less than a threshold, such as $0.90 per hour. Execution pauses when the price is too high. These are purchasing strategies, not current quotes or guarantees of an average price.

A host connects those controls to batch inference. Starting from OpenAI and Claude batch offerings described as half-price processing with a 24-hour return window, the host proposes one-, four-, or eight-hour windows. Background agents might tolerate a couple of hours without requiring a full day. SF Compute’s representative agrees that the market could support the financial structure; this remains a proposed service, not an implemented completion guarantee.

A tradable contract needs working compute

The financial roadmap begins with a spot market for compute that produces an index price. That index could eventually support cash-settled futures: contracts settled financially without requiring traders to receive GPUs. The proposed benefit is predictable revenue for data centers and cheaper financing through reduced risk. At recording time, SF Compute explicitly described itself as an online spot market; futures were a possible future initiative.

That ambition depends on reliable delivery. SF Compute describes building an infrastructure stack that operates directly on the machines and auditing every cluster. A price and a listing mean little unless the buyer receives usable compute.

The audit moves from stress testing to ongoing checks: 1. Burn in the deployed cluster with Linpack, using linear algebra workloads to expose defective components. Example durations are 48 hours or roughly seven days. 2. Run performance tests that more closely resemble customer workloads. 3. Run passive checks alongside customer work and active checks during idle periods, when disruptive testing can be scheduled. Burn-in tests the integrated hardware in its actual location. The representative recalls a cluster browning out and going offline under Linpack—a failure of the deployed system, beyond an individual GPU.

Failure handling connects operations to the contract. SF Compute describes replacement capacity, refunds, and proration, backed by automatic-refund guarantees in provider contracts and service-level commitments passed through to customers. Refund automation was only partially implemented. Unfamiliar failures can escape monitoring, requiring customers to report problems for manual resolution.

The marketplace also takes responsibility for troubleshooting. SF Compute reports remote machine-management access in almost all cases, allowing resets and debugging beyond its earlier reseller role. Its engineers join customer Slack channels and handle overnight problems, although they do not physically operate the hardware or data centers.

Standardize the promise and the deployment

Commodity contracts need a consistent promise, even when machines differ. SF Compute uses minimum specifications and approved components: customers receive a guaranteed amount of storage or better, and motherboards and other components must come from an approved list. A persistent storage layer intended to abstract away some cluster differences was still in development.

Consistent deployment starts at the firmware boot layer. SF Compute’s boot software downloads and starts a customer-specific image, above which Kubernetes or virtual machines can run. This firmware-level control lets the company image an entire cluster consistently and automate performance tests across it.

The intended progression is to serve compute buyers and sellers first, then standardize a segment of the market into a contract traders can trade. Long-term customer commitments already give data centers predictable revenue, but transfer the risk of unused capacity to customers. The representative argues that this risk then reaches venture investors through oversized startup funding rounds and valuations. Futures are proposed as a way to stabilize that chain; the claimed financial benefits remain an ambition.

Calmer promises and a reason to commit

SF Compute’s restrained presentation reflects its risk-reduction goal. The representative wants to promise something concrete: good prices for short compute bursts. The preference for calm partly comes from the company’s first year, when every thirty-day sales deadline threatened its survival. Enthusiasm for San Francisco is the admitted exception: the speaker readily promotes the city’s people, nature, and optimism.

The closing career discussion revisits an earlier AI email product. The speaker attributes leaving it to burnout after roughly four years of startup work, compounded by two prospective co-founders departing. Earlier attempts included a mental-health app with retention problems and RoomService, a distributed-systems business whose customers often preferred building in-house. Roughly forty product attempts led to a retrospective lesson: choose a direction and commit, rather than make survival the only objective.

Leaving the email project did not establish that the idea was intractable. The speaker nevertheless considers email clients difficult and crowded, and sees customer support as a clearer use for AI-written email than most personal correspondence. Intercom illustrates an incumbent already holding the customer relationships and product position to pursue it.

The recruiting discussion returns to the two engineering disciplines behind the market. At recording time, SF Compute sought low-level Linux expertise for a codebase described as mostly Rust, plus fintech engineering for its ledger, reporting requirements, and substantial money flows. Eric Park, a co-founder of Voltage Park, was identified as its chief technology officer at that time.

A host suggests TigerBeetle for the financial system. The response brings the requirement back to operations: preventing losses takes more than choosing a database. Accountants must be able to read the records, and auditors must be able to examine them.