Capex, Depreciation and the Cost of a GPU-Hour

A rented GPU has a price. A purchased one has a cost that has to be constructed, and the construction involves an assumption about useful life that reasonable people disagree about by a factor of two. Since that assumption drives the hourly rate, it drives every build-versus-rent comparison downstream.

Building the number

The hourly cost of an owned accelerator is roughly

where \(L\) is useful life in years, \(u\) is utilisation, and 8,760 is hours in a year.

Capex is not only the accelerator. A datacentre-class server contributes CPU, memory, networking, and the interconnect fabric, and the accelerators are typically the majority but far from all of it. Opex covers power, cooling, datacentre space, network and the staff to operate it. Power alone is substantial: a rack of high-density accelerators draws tens of kilowatts continuously, and power usage effectiveness above one means cooling adds a further share on top.

Why the depreciation schedule is contested

The assumption is how long the hardware remains economically useful, and it is contested because two things pull against each other.

Hardware does not fail on a schedule; accelerators can run for years. But price-performance improves generation over generation, so a three-year-old accelerator is technically functional and economically uncompetitive: it costs more per unit of work than a current one, and it occupies power and rack space a newer part could use better.

Large operators have used depreciation schedules in the range of five to six years for AI and server hardware, and that choice has been publicly questioned by investors and analysts who argue the economic life of frontier training hardware is shorter. The disagreement matters because lengthening the schedule lowers reported hourly cost, which flatters margins, and shortening it does the opposite.

The honest position for a planning exercise is to state the assumed life explicitly, and to test the conclusion at three years and at five, because a build-versus-rent decision that flips between them was never robust.

Utilisation is the other lever

Utilisation appears in the denominator, so it scales the cost directly. Hardware at 50 percent utilisation costs twice per useful hour what the same hardware costs at full utilisation, and fleet utilisation is bounded well below 100 percent by fragmentation, failures and lumpy demand.

This is why the build-versus-rent comparison so often favours renting for organisations with variable demand: they are comparing a rental rate paid only when used against an owned rate divided by a utilisation they will not achieve.

When it breaks

Reserved cloud capacity is capex in a different form. A multi-year commitment is paid whether used or not, so it has the same utilisation sensitivity as ownership without the residual value or the control. Treating it as opex in a comparison misstates its risk profile.

Residual value is usually assumed to be zero and sometimes is not. A secondary market for previous-generation accelerators exists, and where it is liquid it changes the effective depreciation materially.

Power is a constraint before it is a cost. In many locations the binding limit on adding capacity is the available power and the interconnection queue, not the price of the hardware. A cost model expressed only in dollars misses the constraint that actually determines what can be built.

Financing structure changes the answer. Debt-financed hardware, vendor financing and leasing arrangements distribute cost over time differently, and a comparison that ignores the cost of capital compares two things that are not comparable.