What lenders underwrite on a GPU cluster

The most common starting assumption is that a cluster supports capital in proportion to what it cost. It does not.

Equipment cost sets a ceiling on what could theoretically be recovered in a forced sale. It says nothing about whether the asset will generate the cash to service anything in the meantime, and cash flow is what is actually being underwritten. The two questions are related only at the point of default.

This is why two clusters of identical hardware, bought on the same day at the same price, can support entirely different structures. One has a multi-year contract with a counterparty that can pay through a downturn. The other has a pipeline. The hardware is fungible; the contract is not.

The practical consequence: work on the contract before working on the equipment list. Sellers and sponsors routinely invert this, arriving with detailed configuration and nothing contractual behind it.

The first gate is whether there is contracted demand at all, and the second is who is behind it.

Tenor against the asset. A contract materially shorter than the period over which capital is repaid leaves a gap that someone has to carry. That gap is not a technicality — it is usually the single largest structuring problem on a compute transaction, and it is treated separately in the tenor mismatch page.

Who pays, and can they pay when it is hard. An investment-grade counterparty on a take-or-pay contract is a different credit from a well-funded startup on a contract with termination rights. Both are real; they are not interchangeable, and the difference shows up in structure rather than in enthusiasm.

What the contract actually obliges. Committed capacity paid whether consumed or not is credit. Consumption-based pricing with no minimum is a forecast. A framework agreement under which orders may be placed is neither.

Concentration. A cluster whose economics depend on one customer inherits that customer's credit entirely. Diversification helps, but only where the contracts are individually enforceable.

Compute is the only layer of the stack that can be physically moved, which makes it easy to underrate how tightly it is bound to its site.

A cluster generates revenue only while it is powered, cooled and connected. So the hosting position is part of the credit whether or not anyone has documented it that way:

• Power. Contracted, at adequate capacity, for at least as long as the compute contract runs. Power that expires first converts a performing asset into a relocation problem.
• The hosting or colocation agreement. Its term, its termination rights, and what happens to the equipment on termination. An agreement that allows the host to deny access on dispute is a serious impairment, because access is the precondition for every remedy.
• Cooling and density. Rack-scale systems are not deployable into arbitrary space. A facility that cannot cool the configuration is a constraint on the asset, not a detail of the fit-out.
• Who owns what. Where the equipment owner, the facility owner and the operator are different parties, the boundaries have to be written down before anyone advances capital against any of it.

Site quality is a financing input, which is why the site qualification questions belong in the same conversation.

Recovery analysis asks a narrow question: if this stops performing, what is realistically obtained, how quickly, and at what cost.

Three things make that harder for compute than for the rest of the stack.

The value moves fast. Accelerator values track the product cycle rather than a depreciation schedule, and the decline is neither smooth nor predictable. The residual value page covers how the curve behaves and why it drives structure.

The asset is movable. That sounds like a benefit and is mostly a complication — movable equipment can be relocated, commingled, or disputed, and securing it properly is its own discipline. See collateralizing compute.

Distress is correlated. The circumstances in which one party needs to sell a cluster are usually the circumstances in which several do. Recovery assumptions drawn from a strong market do not survive the market in which they would be tested.

None of this makes compute unfinanceable. It makes recovery a weak second line of defence, which is precisely why the contract carries the underwriting.

The difference between a transaction that progresses and one that stalls is usually preparation rather than merit. A package that can be reviewed rather than assembled contains:

• The compute contract, with tenor, committed volumes, pricing mechanics and termination rights visible rather than summarised.
• Counterparty information sufficient to form a credit view, and an honest statement where that information is thin.
• The hosting position — facility, term, power, cooling, access rights, and what happens on termination.
• The equipment schedule, with configuration, delivery timing and current status. Ordered, delivered and deployed are three different states and should not be presented as one.
• The ownership structure — which entity holds the equipment, which holds the contract, and what else sits in each.
• The operating assumptions, particularly utilisation and power cost, stated as assumptions rather than as facts.

Assembling this in advance is not presentation. It is the difference between asking capital to underwrite an asset and asking it to fund the discovery of what the asset is.