Financing Small AI Data Centers
4.30.26 a thought experiment to offload on-demand risk
Addressing the Small Cluster Financing Gap
The first question a lender asks during data center buildout is whether you have a contracted offtaker. Without that, your site will not be built. So one must ask, how can we build an on-demand supply when bringing that compute online requires multi-year dedicated contracts?
When solving a problem, look to history
The farm model. A perfectly competitive and volatile market for the output, variable input costs, large fixed capital expenses (interest, insurance, equipment).
Farms, power plants, oil refineries, natgas generators, bitcoin mines, and (soon) data centers.
All of these farms are essential to a functioning economy, yet as a lender who fronts the capital to purchase the machines that make modern farm businesses possible you are exposed to the volatility of the farm’s inputs and outputs (and the spread between them). So how could a farm finance the seeds, the fertilizer, and any other costs?
In the early 1800s economy, factor/commission merchants were the dominant model for cash crops like tobacco and cotton. A factor in a port city (New Orleans, Liverpool, Charleston) would advance credit to a planter against the anticipated harvest. The factor then sold the crop on consignment, took a commission, and netted out the advance. The factor bore price risk and crop risk simultaneously but in exchange, they captured the entire downstream margin (warehousing, transport, sale).
GPU data centers are at the same crossroads right now. Large scale lenders will only lend to build capacity for the hyperscalers and the frontier labs, while the average rental consumer is stuck with a fragmented and supply-constrained rental market. To build an economically efficient compute market, we need dedicated suppliers for on-demand markets.
Notes on the on-demand premium
On-demand GPU rentals fetch a higher rate than a long-term contract because the user gets flexibility and immediate availability. That flexibility translates into risk borne by the provider, where they take on the risk of having idle capacity and unpredictable utilization. While rental markets are by no means perfectly efficient, the liquidity premium compensates providers for absorbing utilization risk.
Recent on-demand pricing: credit to GPU.io
A Proposed Solution: Build the world’s best tenant
The core issue here is that data centers have massive fixed liabilities - they must finance PPE, their contracted power purchase obligations, service loans for their cooling equipment, the loans for the GPUs, energy inputs (gas / power), and the talent to build these facilities. Adding in the risks of the on-demand markets (which lenders will not price at the moment) is unacceptable to the majority of financing partners.
Now I don’t know much about computers, but I know a lot about loans.
I went through a thought experiment on how I would think about lending against GPUs for an on-demand only asset. As a lender I am equally as exposed to the whims of the on-demand markets as the operator (although the physical collateral does have a residual), and it is very, very volatile. Too volatile for any non-sophisticated trader to hedge well enough to cover my risks. What I want to see, like anyone else, is guaranteed, fixed cash flow and utilization on the parts that haven’t been paid back yet. How can we transform this cash flow volatility into a stable, cash-flowing asset that protects me (the lender) and makes sure I get paid back? We can’t fully eliminate it, but we can work to turn the revenue risk into counterparty risk.
What you need is the factor merchant, or in more modern terms, the commodity trader. The trader becomes the guaranteed offtaker, bearing the risk of the long term contract with the data center and earning the spread between its fixed contract and the premium for shorter-term on-demand rentals. The trader delegates its capacity on open rental markets to earn a premium, while being the investment grade offtaker that guarantees the baseline revenue a lender wants.
This is a tenancy swap. Buyers receive a fixed return on their hardware for some predetermined duration, sellers receive the floating rate and bear the utilization risk in exchange for the rental market premium. It’s a bit more complex in practice, but let’s take a look.
Here’s how it would work operationally
Terms and references:
Reference Cluster: specific GPUs, count, location, power envelope pinned to a reference deployment
Reference Capacity: GPU-hours available per calculation period
Reference Price: This is a very challenging bit as prices are difficult to benchmark, but this must importantly sit near the price for a rental contract of a similar duration as the weighted average life of the loan
(a) operator’s actual realized $/GPU-hr
(b) a published index from a trusted provider (SemiAnalysis)
(c) a basket of venues like Runpod, Lambda, Vast, SF Compute
(d) must reflect networking topology, storage tier, interconnect bandwidth. Indices are tough to do!
Strike Utilization: e.g. 65%
Realized Utilization: GPU-hours sold / reference capacity, per period
Realized Revenue: Reference Price x GPU-hours sold
Calculation Period: likely weekly, but flexible based on the contract
Notional Schedule: amortizing with the loan principal, so the trader’s obligation declines as the lender’s principal risk declines
Performance Covenant: SPV must achieve a minimum realized utilization on a trailing basis to avoid moral hazards
Reference GPU Loan Structure
The GPUs live in a bankruptcy-remote SPV separate from the PPE. This entity borrows capital secured by the hardware itself, with all cash flows from rentals flowing through the sweep account controlled by the lender.
Waterfall
Realized revenue → opex (power) → debt service → swap settlement → reserves → operator equity
Designing the Contract
Legs
Trader → SPV (Fixed Leg): Reference Price * Reference Capacity * Strike Utilization * notional factor. Trader pays as if the cluster ran at strike utilization at a contractually fixed price
**you could decompose the price and utilization risk into two legs here by having the trader pay the cluster a fixed $/period for reserved access which covers fixed costs, then having a pass-through leg where realized revenue - opex goes to the trader. Closer to a spark spread trade
It enables splitting price risk from utilization, but the correlation between them is so high right now because availability is super low
SPV → Trader (Variable Leg): min(realized revenue, reference price * reference capacity * strike utilization * notional factor). The SPV passes realized revenue up to the strike level
Net retained by SPV: max(realized revenue - strike revenue, 0). Upside above the strike stays with the SPV
Settlement: If the cluster underperforms at the end of the period, the trader will cover the gap between the realized revenue and the strike payment. If the rental rates overperform vs. the reference rate, the trader keeps the profits up until the strike utilization. Returns above the strike utilization rate are kept by the operator to incentivize the operator to keep utilization high.
The Amortization Schedule (a unique piece of the contract)
Earlier I said this: utilization on the parts that haven’t been paid back yet.
Most hardware loans are amortizing, meaning the borrower pays back their principal over time. As such, lenders shouldn’t really care too much if the already amortized components of their loan have a guaranteed revenue as that capital has already been recovered. Because of this, we can structure the swap agreement such that the operator retains the full economics of their hardware as the debt on each piece of hardware amortizes. The trader’s fixed liability is also decreasing over time as the operator pays their loan back.
This has several benefits for all parties:
The operator gets more ownership over the economics of their deployment in step with them paying back their loan
The trader’s biggest risk at the moment is new hardware making old hardware obsolete and lowering the long-term average on-demand basis that they can earn. While the agreement amortizes, the trader’s fixed payments decrease on the same schedule and their hardware exposure automatically tapers off
The lender has a baseline cashflow guarantee on the loan, especially in the riskiest stages (early deployment) when the majority of payments cover interest payments.
Credit and Collateral
Credit Support Annex: daily MTM with variation margin posted in a HQLA yield bearing instrument (it’s 2026, we have instantly transferable MMFs that you can liquidate in minutes, let’s use them)
Initial margin can be sized to cover a stress scenario (e.g. Spot price down 50%, utilization to 20% for 30 days). Can be reduced if the trader counterparty is highly creditworthy
Swap receivables are assigned to the lender at the SPV level
Cross-default scenario: if the trader defaults or the loan defaults, best efforts must be made to assign the swap agreement to another counterparty or it triggers a rate negotiation. If the operator defaults, the trader is junior to the lender and receives any residual value after the lender is made whole.
Trader credit degrades: increase initial margin
Risk and Returns
The trader is effectively long cluster revenue (price * utilization) up until the strike, and flat above it. They effectively have synthetic ownership of the baseload slice of cluster revenue and are short a put at the strike revenue. Their premium is the spread between the on-demand rate they expect and the fixed rate they pay you in exchange for absorbing the downside if revenue falls short. Fortunately, they are in the winning position as they are net long GPU rental rates and long utilization up to their strike. If the on-demand spot stays high and clusters stay full, both they and the operator are very happy.
Lenders are always short volatility and care about opportunity cost, P(default), and their loss-given-default after recovery. Their interest rates will likely come down from the 12-15% range we see now on the USD.AI facilities to ~7% that is more in line with high-yield/private credit rates that you may see with a highly creditworthy offtaker. While they give up some of their premium interest rates, agreements like tenancy swaps will result in more lenders moving into the GPU lending arena because the likelihood of default decreases.
The trader’s economics are quite favorable as well. If they are highly creditworthy, their margin ratio (initial and variation) enables them to access significantly more leveraged long exposure to GPU rental and utilization rates than you would be able to access anywhere else besides building a cloud.
Operators have effectively sold a floor of the combined price * utilization factor, and hold a call on revenue spikes. As their loan amortizes, they retain more and more of the cash flow from their hardware which enables them to focus on maximizing their utilization. If the financing gap closes, edges in orchestration and finding unusual sources of profitable on-demand revenue will make small deployments significantly more competitive.
Regulatory
Real swaps are a regulated product and any payment based on a reference price index lies within the jurisdiction of the CTFC. You would likely have to structure your contract in such a way that it falls under the FCA or Forward Contract Exclusion, which enables non-dealers to buy or sell nonfinancial commodities. This enables your agreement to be exempt from the incredibly stringent clearing and reporting rules required for swap dealers post-2008.
Your agreement must be a nonfinancial commodity (check), have deferred shipment/delivery (check), and the intent to physically settle (ehh). There are some nuances regarding cash-settled physical delivery obligations, which I think you could make a case for given the non-tangible nature of compute resources. I am not a securities lawyer and this is not legal/financial advice but be careful!
Hedging?
Your two stochastic, but not independent, factors are on-demand prices and utilization.
To be honest, I still haven’t figured out how a trader could effectively hedge their rental rate exposure in size. Compute forwards and futures are still quite early. Indices are not established. Utilization is impossible to hedge as it is highly operator specific. Traders simply need to find strong operators who have an edge in originating demand and operating GPU workloads, or they can set up systems that enable operators to route demand through an internal desk in exchange for a bigger piece of the pie. That would get closer to a mining pool model, where they pay miners a fixed rate and capture the premium, although the on-demand rental game is less of a dice roll.
Your best bet is to build a diverse portfolio of operators to hedge your operator-specific utilization exposure, then either wait for cash-settled compute forwards to become functional or accept the price risk.
**You could also rent on SF Compute or another cloud that offers long-term rentals + subletting, then transform your price risk into basis risk between SFC and small operators
Perhaps this is a company, if there is not one already.
NFA