GPU residual value and depreciation: the real curve

Most equipment loses value gradually and predictably, which is why straight-line depreciation is a reasonable description of reality for a turbine or a transformer.

Accelerators do not behave that way. Value holds while a part is current, then steps down when a successor is announced, again when it ships in volume, and again when the software ecosystem moves. Between those events the decline is modest. Around them it is abrupt.

Two consequences follow, and they are the reason this page exists.

Timing dominates. A structure whose end-of-term falls just after a generational transition faces a materially different value from one ending shortly before. The difference is not a matter of a few months of ordinary depreciation; it is a step.

The schedule is not the asset. An accounting life chosen for reporting purposes is a convention. Where a structure is sized against it rather than against the economic curve, the mismatch is invisible until the residual is tested.

Accelerators rarely stop working. They stop being worth running, which is a different threshold and arrives sooner.

The binding constraint is performance per unit of power and space. A deployed part occupies rack space and consumes power whose cost does not fall as the part ages. When a newer generation delivers substantially more work within the same power and footprint, the older part's output stops covering what it costs to keep it running — and at that point it is economically finished regardless of condition.

Three things move that threshold:

• Power cost. Cheap power extends economic life materially, because the operating cost the older part has to clear is lower. This is one of the direct links between the site layer and the compute layer.
• Workload. Inference, fine-tuning and research training have different sensitivities. Parts displaced from frontier training frequently have a genuine second life in less demanding work, which is what supports a secondary market at all.
• Software. Support in the dominant frameworks and libraries is what keeps an older part usable. When that attention moves on, the practical life ends ahead of the physical one.

Residual assumptions on most equipment rest on long observed histories. On accelerators three things undermine that.

The history is short. There is not a long record of AI accelerators moving through full ownership cycles at current scale. Assumptions drawn from a small number of recent transitions carry more uncertainty than the confidence with which they are usually stated.

The determining variable is someone else's decision. Product cadence is set by a small number of manufacturers. A residual assumption is therefore partly a forecast of a roadmap that is not public and can change.

Distress is correlated. The conditions in which one holder needs to realise value are usually conditions in which several do. Values observed in an orderly market are a poor guide to values in the market where the assumption is actually tested — thin bids, concentrated supply, and buyers who know why the equipment is available.

The honest conclusion is not that residuals cannot be underwritten. It is that they should be underwritten conservatively and stated as assumptions, because a residual presented as a projection is the most common piece of false precision in a compute financing.

The residual is where the analysis turns into structure, and it does so in four ways.

It sets the term. A structure running past the point where the equipment retains meaningful value is unsecured for its final period whatever the documents say. Matching term to economic life rather than to accounting life is the first adjustment.

It decides who should hold the asset. Parties able to redeploy or remarket equipment can hold residual risk economically. Parties who cannot are better served by structures that place it elsewhere, even at higher nominal cost — which is the reasoning behind most lease structures on this layer.

It forces the compute layer out of the infrastructure financing. A residual that behaves like this cannot sit inside a facility sized against thirty-year assets without distorting both. This is the mechanical basis for the tenor mismatch argument.

It raises the value of contracted cash flow. Where recovery is uncertain, the contract carries the underwriting. A firm compute contract from a counterparty that can pay is worth disproportionately more here than on assets with dependable resale.

Arguments about how long a GPU lasts often continue because the participants are answering different questions. The useful discipline is to give each life its own line.

Physical life is how long the hardware can continue to operate with maintenance. It is the longest of the four and usually the least relevant to value. A functioning unit can be economically obsolete.

Accounting life is the period over which an owner allocates cost through depreciation. It is a reporting estimate applied to a class of assets and may change as an operator accumulates experience. It does not promise a sale price at any point on the schedule.

Deployment life is how long the unit remains useful in the role and configuration for which it was installed. A system may leave frontier training and continue serving inference, fine-tuning, research or internal workloads. That second deployment can create real value, but only if the software, power, cooling, networking and customer demand for it still exist.

Recovery life is how long a financing party can realise enough net proceeds, within the time and control constraints of enforcement, for the collateral to protect an outstanding balance. It is shorter than an orderly deployment life because removal, testing, transport, remarketing time, fees and simultaneous market supply all sit ahead of the lender's cash. Recovery life is the one that sizes collateral value.

Public disclosures increasingly state the split plainly. Microsoft described roughly half of one quarter's capital spending as short-lived GPUs and CPUs and the other half as long-lived assets expected to support monetisation for at least fifteen years. (Microsoft FY2026 first-quarter earnings call, as of September 20, 2026) That is the four-layer stack expressed by an operator rather than an arranger: compute and the facility beneath it do not belong on one life assumption.

A model should therefore never contain one cell called useful life without a qualifier. It should show the accounting convention, expected primary deployment, plausible secondary use and lender recovery horizon separately. If the debt depends on the longest of those four, the structure is borrowing against continued operation, not against collateral.

A single end-of-term percentage creates the appearance of precision while concealing the two variables that matter most: when the term lands in the product cycle and what market exists for the configuration at that date. A scenario grid is more honest and more useful.

The first axis is generation status. Is the equipment still current, one generation behind with full software support, or several generations behind after the dominant workload has moved? The second is recovery channel. Can it remain installed for another user, move as complete racks, be broken into components, or only be sold through a specialist liquidation? The third is market condition. An orderly refresh by one operator is not the same market as correlated distress across several AI clouds.

Each scenario should produce net recovery, not a catalogue price. Deduct de-installation, data sanitisation, testing, packaging, freight, duties, refurbishment, missing components, broker or auction fees, storage and the operating cost incurred while a buyer is found. Then apply the time delay to the lender's balance. A nominal sale price six months after default does not cure six months of unpaid interest and site cost.

The scenario set below is qualitative on purpose; transaction models should replace the labels with evidence specific to the equipment and location.

A GPU does not have one residual value independent of where it sits. It has at least two: the value of continuing to earn in place and the value available after removal. The gap can be most of the recovery.

Installed value includes things the equipment lender may not own: commissioned power, cooling, network fabric, cabling, software configuration, customer connectivity, operating staff and a contract that pays for capacity. Removing the equipment can preserve the accelerator while destroying the system that made it productive. That is why the right to keep operating after an enforcement event can be worth more than a first-ranking lien over the boxes.

The hosting agreement therefore becomes a collateral document. A lender should know whether it receives notice of operator default, time to cure unpaid hosting charges, access to inspect and identify equipment, permission to continue operation during a sale, and a route to remove equipment if continued operation is impossible. It should also know whether the landlord has a lien, whether local law treats installed equipment as a fixture and whether another creditor controls the network and storage required to deliver a functioning service.

Configuration amplifies the distinction. A complete rack-scale system is not merely a set of interchangeable accelerators. Interconnect, switches, CPUs, cooling distribution and approved firmware create performance as a unit. Breaking the system apart may broaden the buyer pool for individual components while losing the premium attached to a working configuration. Keeping it together may preserve performance but require a buyer with the same facility specification and enough power available on the same date.

The recovery plan should state which path is expected and prove that the financier can execute it. "Movable equipment" is not a strategy. It is a physical characteristic. Financeable mobility requires documented access, technical capability, compatible destinations, insurance through transit and a buyer or operator capable of putting the asset back into service before its value moves again.

Residual support is evidence that somebody has agreed to bear a defined part of the downside. It is not independent evidence that the supported value is correct. The distinction becomes important as suppliers and hyperscalers use guarantees to unlock third-party infrastructure capital.

A support provider may have commercial reasons to stand behind a threshold: securing exclusive equipment deployment, accelerating a campus, protecting a supply ecosystem or gaining an option over future capacity. Those reasons can make the promise rational even where the provider would not buy the asset for the guaranteed amount in an ordinary sale. A lender should underwrite the provider and the instrument, not infer a market bid.

NVIDIA's 2026 financing-platform announcement contemplated project-by-project, limited residual-value support at the company's option, alongside independently underwritten third-party capital. (NVIDIA investor relations / Q2 FY2027 Form 10-Q, as of September 20, 2026) The limiting words do the work. Optional support is not part of a base case until granted to the specific project. Limited support requires the cap, covered asset, duration and loss formula. Project-by-project evaluation means there is no programme-wide residual floor available to every buyer of the equipment.

The same caution applies when infrastructure guarantees sit near compute. NVIDIA's PORTS-Pike guarantees support defined land, power and shell value following specified tenant defaults; they do not publish a future resale price for GPUs. (NVIDIA Form 8-K, as of September 20, 2026) A long-lived campus residual and a short-lived compute residual are different risks even when one supplier's commercial strategy connects them.

For underwriting, schedule the support on a separate line from asset value. Show the unsupported market recovery, the conditions under which support becomes payable, the maximum amount, the decline in coverage, exclusions, the credit of the provider and the remedies it controls before cash is due. That prevents a guarantee from being counted twice—once as a higher residual assumption and again as a payment after the residual falls short.

A lender cannot control the product roadmap, but it can stop a borrower from destroying the recovery options that remain. The useful covenants are operational and documentary rather than cosmetic.

Configuration control requires notice or consent before accelerators, interconnect or cooling components are removed, mixed or reconfigured in a way that prevents the financed system being sold as a whole. It should permit ordinary maintenance and failed-part replacement without turning every service call into a consent process.

Location and identification control keeps a current schedule of serial numbers, racks and facilities, supported by inspection rights and rules for temporary movement. A security filing over a class of equipment is not enough if nobody can locate the units at enforcement.

Maintenance and software control requires supported firmware, licences, service arrangements, environmental conditions and records. Deferred maintenance saves cash by consuming residual value, so the lender needs an early signal rather than a remedy after the equipment is impaired.

Contract and hosting control requires notice before the customer or site agreement is amended, terminated or allowed to expire where installed operation drives value. The aim is not to manage the operator's business. It is to prevent the cash flow and the physical access beneath the collateral from disappearing together.

Refresh control addresses replacement before maturity. A refresh can preserve the platform while removing the lender's original collateral. The documents should say whether sale proceeds prepay the facility, replacement equipment becomes collateral, or a borrowing-base test permits substitution.

Evidence refresh updates the residual case periodically using observed transactions, current deployment economics and actual secondary demand. Repeating the opening assumption each quarter is not monitoring. The review should identify what changed, which scenario moved and whether amortisation still outruns the downside case.

These controls are most effective when they preserve choices rather than prohibit change. Compute has to be upgraded, reallocated and serviced. A covenant package that prevents the operator from operating will be waived. One that makes the economic consequences visible can keep debt, equipment and contracts aligned as the asset moves through its short life.

When a residual appears in a model, four questions establish whether it is a position or a placeholder:

1. What is it based on? Observed transactions in comparable parts, a third party's published view, or an assumption chosen because the structure needed it to work. All three occur, and only the first two are evidence. 2. Where does the term land relative to the product cycle? If the expiry sits near an expected transition, the assumption is exposed to the step rather than the slope. 3. Does it assume an orderly sale? Recovery in a stressed scenario is the case that matters, and it is not the case most residual assumptions are drawn from. 4. Who is holding it, and did they agree to? The failure mode is not an aggressive assumption. It is a residual that nobody explicitly took, which therefore sits with whoever happens to own the equipment when it is tested.

A residual that has been argued for and deliberately allocated is a manageable risk. One that has been assumed into a spreadsheet is an unpriced position.