What a GPU data-centre financing actually looks like, and where the numbers break
Portfolio sample. First-person byline. Numbers marked (illustrative) are round figures used to show the shape of a calculation, not statistics.
Most people outside the market assume an AI data-centre debt raise is a real-estate deal with servers bolted on. It is closer to aircraft financing with a power problem. The collateral is depreciating faster than the building around it, the revenue depends on a single counterparty, and the thing that actually decides whether the deal works is not silicon. It is whether the megawatts arrive on schedule.
I have spent the last year inside lender-side technical due diligence on these build-outs, including a multi-billion-dollar GPU financing, and I have watched the same five problems recur. They are not exotic. They are structural, and they are the reason a term sheet that looks fine at the model stage becomes a list of conditions precedent.
The stack, in practice
The capital structure on an AI build does not look like a traditional colocation deal. A typical shape (illustrative): 60 to 75 percent senior debt, split between a funded term loan and a delayed-draw facility, some private credit or mezzanine across the middle, and 25 to 40 percent equity. The delayed-draw piece is where the engineering enters the credit file. Money is not released against invoices. It is released against milestones: shell complete, power energised, racks delivered, cluster integrated, acceptance test passed. Each of those is a technical claim dressed as a funding condition.
On top of that sit the usual structural features a lender wants when the asset is fast-moving: a debt service reserve account, a cash sweep, minimum liquidity, restrictions on what the borrower can do with the cluster (no sub-leasing to a competitor of the anchor tenant, no reconfiguration without consent). None of these are unusual. What is unusual is how often the technical milestones underneath them cannot be tested.
Where the numbers break
One. The revenue term is shorter than the asset life, and both are shorter than the building. AI-capable capacity is commonly contracted on multi-year terms in the low single digits (illustrative), the servers are depreciated over five to six years depending on the operator, and the shell has a useful life measured in decades. That means the lender is underwriting a residual value for hardware whose resale market barely exists and whose second owner may not want it. When you see a base case that clears comfortably, check what the back half of the amortisation depends on. Often it is a re-contracting assumption, not a contract.
Two. Megawatts are the scarce good, not GPUs. Chips can be ordered. Interconnection cannot. If the utility slips the energisation date by two quarters, the acceptance test slips, the offtake start date slips, and debt service does not. In several deals I have reviewed, the entire downside case was a timing case rather than a demand case, and the timing risk sat with a party the borrower did not control and could not replace. A model that assumes power on day one and a contract start on day thirty is not conservative. It is optimistic by construction.
Three. Acceptance criteria are where deals are won and lost. An acceptance test defines what "delivered" means: throughput per rack, sustained performance, error rates, burn-in duration, who witnesses it, and what happens when it fails. I have read acceptance schedules that were technically unfalsifiable, either because they were written by the seller's own engineering team, or because they tested a configuration nobody would ever run in production. If the lender cannot point to a clause that converts a failed test into a payment holiday or a cure, the milestone schedule is decoration.
Four. Counterparty concentration is the whole risk, and it is usually under-described. A single offtaker on a take-or-pay contract looks like a strong credit. It is only as strong as the remedies behind it. Cure periods, termination for convenience, step-downs in committed volume, credit support, and whether the offtaker's obligation survives its own insolvency all matter more than the headline contract value. A take-or-pay commitment larger than the customer's balance sheet is a promise, not a credit.
Five. The base case is a price forecast in disguise. Contracted capacity is one thing. The uncontracted capacity that makes the equity return work is a bet on inference pricing, and inference pricing has almost no observable history. Every model I have stress-tested assumed a rate per GPU-hour that fell over time. Very few stress-tested what happens if it falls faster than the debt amortises, or if utilisation plateaus below the plan while the power bill stays fixed. Power is a fixed cost. That asymmetry is the quiet risk in the whole asset class.
The technical layer nobody puts in the model
Below the financial structure sits a set of engineering judgements that determine whether the cash flows exist at all. Whether the cluster design matches the vendor's reference architecture, and what "equivalent" means when a cheaper variant is proposed. Whether the fabric and the software stack are supported configurations, because an unsupported cluster is a support-ticket liability, not an asset. Whether spares and lifecycle coverage are contracted, since a failed accelerator with a twelve-week lead time is a revenue outage. Whether the cooling design is liquid-ready, because rack densities have moved from the tens of kilowatts to well over a hundred (illustrative, widely reported), and a building designed for air is a stranded asset.
In practice, the deliverable that credit committees actually use is not a 200-page report. It is a short list of red flags graded by severity, a view of the three outcomes (base, delayed, and impaired) with the trigger that separates them, and a clear statement of which assumptions the lender is being asked to accept without independent evidence. That last part is the one borrowers dislike and lenders need most.
What this means if you are lending
Ask for the milestone schedule and the acceptance test before the model. Put a technical adviser on the lender side, not the sponsor side, and give them access to the vendor contracts rather than the vendor's marketing pack. Model the power date, not the construction date. And treat the uncontracted revenue line as equity risk, because it is.
The deals that work are not the ones with the best projections. They are the ones where the lender can name, in one sentence, what would have to go wrong for the loan to be impaired, and can point to the clause that protects them when it does.
Chris Romei is a strategy and finance consultant who worked on data-centre and digital-infrastructure commercial and technical due diligence for lenders and investors at Altman Solon.