AI
The Three Lives of a Server
Someone asked a good question under one of our recent posts: how do you think depreciation affects hardware when scaling a business?
It deserves more than a comment reply, because the answer happens to be at the centre of the loudest accounting debate in tech right now. And because the answer for a hyperscaler and the answer for an enterprise point in opposite directions.
Three clocks, one machine
Every server runs on three clocks at once, and most infrastructure conversations conflate them.
Accounting life is the write-off schedule. Three to six years, set by management, reviewed by auditors, driven by tax and reporting logic.
Economic life is how long the asset earns. It depends entirely on what you run on it and what the alternatives cost.
Physical life is how long the machine works. GPUs have no moving parts. Memory fails at around half a percent per yearin field data, and the majority of CPU and memory faults in large-fleet studies are transient errors cleared by a reboot, not dead silicon.
Depreciation describes only the first clock. It is an accounting event, not an engineering one. Nothing happens to the hardware on the day the book value reaches zero. The confusion between these three clocks is where most of the bad procurement decisions come from.
What the hyperscalers are arguing about
The debate is worth understanding, because if you rent compute, you are on the other side of it.
Between 2020 and 2024, the major cloud providers extended their server depreciation schedules from three or four years to as much as six. Industry estimates put the collective effect at roughly 18 billion dollars a year in reduced depreciation expense. Critics argue this overstates earnings, since NVIDIA ships a new architecture every 18 to 24 months and a six-year schedule assumes hardware stays productive across multiple generations of replacement.
The hyperscalers answer with the value cascade: chips retired from frontier training move down to inference and other high-volume work, where they keep earning for years. And the physical evidence supports at least part of that claim. AWS still lists P3 instances running V100 chips launched in 2017.
Then, in early 2025, the industry split on its own question. Amazon shortened the useful life of a subset of its servers and networking equipment from six years back to five, explicitly citing the increased pace of AI development, and took a 920 million dollar accelerated depreciation charge for early-retired equipment. In the same month, Meta extended its estimate to five and a half years, reducing its expected 2025 depreciation expense by roughly 2.9 billion dollars. Same hardware cycle, same month, opposite conclusions, both signed off by auditors. The honest reading is that depreciation is an estimate, not a measurement.
Why the pressure is different at hyperscale
Here is the detail that matters, and that most of the coverage misses. What retires hardware at a hyperscaler is not failure. It is opportunity cost.
A hyperscaler sells the frontier. Its customers pay for the newest compute, and its data centres are power constrained. Every megawatt spent running yesterday's chips is a megawatt the newest generation does not get. The old hardware still works. It just competes with its own replacement for electricity and floor space. That is a real economic force, and it is why a short useful life can be a defensible assumption for a business whose product is the frontier itself.
None of that applies to an enterprise running inference on its own workload.
The enterprise curve bends the other way
An enterprise does not sell frontier compute. It runs a defined set of workloads: chat, drafting, summarisation, extraction, internal document work. And for those workloads, two trends push the useful life of fixed hardware out, not in.
The algorithms are improving faster than the silicon. Research from Epoch AI and MIT found that the compute needed to reach a given level of language model performance has halved roughly every eight months, faster than Moore's Law. What needed a large model two years ago is handled by something a fraction of that size today. At the same time, inference runtimes keep getting faster on unchanged hardware through better quantization, better batching, better decoding.
A hyperscaler's hardware loses value because the frontier moves. An enterprise's hardware gains capacity because the software moves. Same physics, opposite economics. The machine you bought handles more each year, not less.
What this means when you scale
So the answer to the question is this. Depreciation affects a scaling business mainly through whose schedule it is on.
Scale on rented compute, and you pay the provider's useful-life assumption plus margin as a permanent operating cost. The entire debate above is about whether that assumption is set honestly. Either way, you carry it, and the meter never reaches zero.
Scale on owned hardware, and depreciation is front-loaded and finite. For the first few years the write-off sits on your books. Then it ends, and the machine keeps producing at the cost of electricity. The gap between the accounting clock and the physical clock stops being an earnings debate and becomes your margin.
There is a caveat, and it is the same one the hyperscalers face in miniature. If your workload genuinely needs the frontier, the largest models, very long context, high-concurrency serving, then obsolescence pressure is real and a short replacement cycle is honest. But for the inference work most enterprises actually run, the workload is fixed and the software is improving underneath it.
The fleet data
One last data point from our side, because depreciation schedules quietly assume hardware dies on time, and it does not. On the fleet we have visibility into, the component that has actually needed replacing is the batteries: the backup units on RAID controllers, the cells in the UPS. Consumables, on a known schedule, at a cost that never appears in a capex discussion.
The silicon outlives its write-off. The books just aren't built to say so.
If you want to know what the machines you already own can do for your workload, we can benchmark them with you.
The blog post was drafted by human, proof checked by the Xinity team.