Financing AI compute: how the GPUs are paid for, and who holds them.

A GPU cluster is underwritten as a contracted cash-flow stream first and as equipment second. The invoice value of the hardware sets an upper bound on recovery, not the size of the facility. What is actually tested is the quality of the compute contract behind it, the credit of the party paying, whether the cluster can keep running where it sits, and what the equipment is worth at the point anyone would need to sell it. A cluster with excellent hardware and no contracted demand is inventory, not a project.

An AI data center is four assets with four different economic lives stacked in one place. Land and interconnection endure for decades, the building for a generation, generation equipment for twenty years or more, and the accelerators inside it for a few. Financed as a single asset, the shortest-lived layer drags the terms of the longest-lived one and the longest-lived one subsidises the shortest. Separating the layers — so each is held and funded by capital matched to its life and its risk — is the central structuring decision in the sector.

Every lease structure on AI compute is, underneath, a decision about who carries the risk that the equipment is worth little at the end of the term. An operating lease leaves it with the lessor and keeps the user's commitment short. A finance lease transfers it to the user along with most of the economics of ownership. Fair-market-value and nominal purchase options sit at the two ends of that spectrum, and a sale-leaseback applies the same logic to equipment already owned. The right structure follows from the compute contract behind it and from who is genuinely able to price obsolescence.

Accelerator values decline in steps driven by product announcements rather than smoothly with age or use, which is why a straight-line depreciation schedule describes the accounting treatment and not the asset. Economic life is set by the point at which newer parts deliver enough more per unit of power and space that older ones stop clearing their operating cost. Because that point is set by other people's roadmaps, the residual is the least controllable variable in a compute financing — and the one that most determines its structure.

Contracted compute revenue is what makes a cluster financeable, but only a contract with specific characteristics functions as credit: a firm obligation to pay rather than a right to consume, a term long enough to cover the capital behind it, and a counterparty that can meet the obligation under stress. Most arrangements presented as offtake fail at least one of those tests. The gap between a signed document and a bankable one is where most compute transactions actually stall.

A security interest over compute equipment is only as good as the ability to find it, reach it and sell it. Accelerators are movable, they usually sit in a facility controlled by a third party, they are frequently commingled with other owners' hardware, and their value falls quickly. Each of those weakens a position that looks clean on paper. The practical answer is documentary rather than legal: identify the equipment specifically, secure access rights from the facility, and settle priority with everyone else who has a claim before capital is advanced.

Financing a GPU cluster began as a bilateral loan and has moved up the ladder to delayed-draw term loans, private placements and rated asset-backed securities, because the capital required outgrew the balance sheets willing to hold it whole. What is sold into the market is contracted cash flow, not the chips: the accelerators set a floor on recovery, and the compute contract behind them carries the rating. That is why the strongest GPU-backed debt is rated off the counterparty paying for the compute, while the depreciation curve and the tenor of that contract cap how far up the rating scale the structure can go.

Compute can be funded through the party supplying it, through independent equipment lessors, through banks, or through asset-backed capital — and most substantial transactions use more than one. Vendor programmes are fastest and most comfortable with the equipment, because the provider understands the product cycle and can remarket what comes back. They are also narrower: tied to that supplier's catalogue, and structured around moving product. Knowing which channel is appropriate for which part of a stack is most of the arranging work.

Identical equipment supports different structures depending on who the cash flow comes from. A neocloud sells compute to third parties, so it is underwritten as an operating business with contract quality, customer concentration and recontracting risk at the centre. An enterprise cluster serves its owner, so there is no external contract and the analysis moves onto the owner's balance sheet and its reasons for building. Neither is inherently easier to finance. They fail in different places, and the structure has to be built for the one in front of you.