Depreciation Schedules for AI Infrastructure Assets

That sentence, spoken by the CEO of a company spending tens of billions of dollars a year on GPU fleets, is an engineering judgment wearing an accounting costume. The choice between a two-year and a six-year useful-life assumption encodes a claim about how long a given hardware generation can sustain revenue-generating workloads, and infrastructure teams, not finance departments alone, are the ones positioned to evaluate whether that claim holds. If a company holding a sizable GPU fleet applies a different schedule to the same asset and the same cash outlay, its reported operating income changes dramatically, so the depreciation line on a 10-K is really a published forecast about silicon, workloads, and obsolescence. Treating it as a bookkeeping footnote misses what it actually says.

How Hyperscalers Arrived at Six-Year Schedules

The six-year standard did not emerge from a study of GPU longevity. It came out of a coordinated accounting posture built for general-purpose servers, and AI infrastructure inherited it before anyone had long-run data on how long a GPU generation stays economically useful. That timing matters: the convergence on six years happened before the massive wave of AI-specific capital expenditure, so the GPU fleets now filling data centers entered the books under a schedule designed for a different category of hardware, with a different obsolescence profile than chips built specifically to chase frontier model training and large-scale inference.

The neoclouds run fleets that are exclusively AI-intensive, with no general-purpose server legacy to inherit assumptions from, so they did not converge on the same number. CoreWeave adopted six years, betting on GPU value retention through sustained inference demand. Nebius initially used four years, reflecting an expectation of faster modernization. Lambda Labs used five. In the first quarter of 2026, Nebius moved from four years to five, citing usage patterns and current utilization commitments; an operational forecast triggered the change, not an accounting convenience. The spread across this peer group, four years, five years, five-and-a-half, six, is the real finding here. Useful life for AI hardware is still genuinely contested among the companies closest to the workloads, and the schedule a company picks is a specific bet on how those workloads will evolve over the asset's life.

The value cascade theory: what it assumes and what has to be true for it to hold

The six-year schedule rests on a specific theory of how a GPU generation earns its keep over time. Call it the value cascade: a chip spends years one and two running frontier training, years three and four serving high-value real-time inference, and years five and six handling batch inference and analytics work that tolerates lower performance. Each phase extracts less value per hour than the one before it, but the chip keeps earning, and six years of declining but nonzero revenue is what justifies spreading its cost that far out.

Evidence supports the early stages of this theory. Microsoft's retirement of its NCv3 series, powered by NVIDIA V100 GPUs, was announced for September 2025, roughly 7.5 years after the V100 launched, a timeline that partially supports the claim that silicon outlasts its original use case. A VP of AI infrastructure at a major cloud provider said the company runs seven generations of its custom TPU hardware in production at once, and its seven- and eight-year-old TPUs run at full utilization. TPUs are custom ASICs serving an internal, controlled workload mix, a different competitive position than commodity GPUs sold into an open market, so that data point supports the cascade's plausibility without proving it applies to merchant silicon.

The cascade needs several conditions to hold simultaneously, and none of them are guaranteed. Inference demand has to grow fast enough to absorb the hardware that training displaces. Models trained on newer hardware have to run efficiently enough on older hardware to make inference on it economical. Power, cooling, and space costs have to stay acceptable relative to the compute value delivered in years three through six. Secondary-market rental rates have to hold up: H100 spot rates fell sharply from their 2023-2024 peak to a fraction of that price at auction by late 2024, which complicates the cascade's economics even when the chips remain technically capable of the work. And NVIDIA's own release cadence puts pressure on the whole structure. At Computex 2024, Jensen Huang laid out a one-year rhythm for new architecture generations: Blackwell in 2024, Blackwell Ultra in 2025, Vera Rubin in 2026, Rubin Ultra in 2027, with Feynman added to the roadmap at GTC 2025 for 2028. At that pace, every generation is one or two years old by the time its successor ships, which compresses the window in which a given chip is the frontier-training workhorse the cascade's first phase depends on. The theory is coherent and partly supported by what CoreWeave, Microsoft, and Google have actually done with aging hardware. It is fragile in ways that depend on variables no depreciation schedule can fix in place.

KV Cache Architecture and the Hardware Cycle

The useful life of a GPU generation isn't fixed by the silicon alone, but by how efficiently the software stack uses that silicon, and that efficiency is improving fast enough to change the economics of aging hardware in the middle of its depreciation schedule.

KV cache management is the clearest example. During autoregressive generation, every new token attends to all previous tokens in the sequence; without caching, recomputing attention from scratch at each step creates quadratic cost that makes long-context inference impractical at any scale. Traditional KV cache allocation reserves contiguous memory sized for the maximum possible sequence length even when most requests are short, so it wastes much of the available memory. PagedAttention, introduced by vLLM, applies virtual-memory-style paging to KV cache allocation and eliminates most of that waste. The size of the KV cache a workload requires determines directly how many concurrent inference requests a given GPU can serve, which ties memory efficiency to the amount of hardware required per unit of inference revenue. The trajectory here moves fast: within a single generation of model development, KV cache size for long context windows dropped by nearly an order of magnitude, expanding the inference capacity of a fixed GPU fleet with no hardware change.

Precision formats move the same lever. Migrating a fleet's inference workloads from BF16 to FP8 to FP4 can defer the point at which older hardware becomes inadequate for a given task, extending the cascade's tertiary, batch-inference phase further than the hardware's raw compute would otherwise support. But that extension is a software bet made years after the hardware was purchased and depreciated on a schedule set at acquisition. The benchmark record shows how fast the ground moves underneath these assumptions: MLPerf Inference v6.0, published by MLCommons in April 2026, retired the GPT-J benchmark entirely because every major accelerator had saturated it, replacing it with a substantially larger text-generation benchmark. A test that once differentiated accelerators had become useless for that purpose within a few release cycles. A depreciation schedule written in dollars and years cannot see any of this directly. It inherits the consequences anyway.

How storage and memory hierarchies age differently from compute

GPU compute and the storage and interconnect layers that feed it do not age on the same curve, and a depreciation schedule that bundles them into a single server asset hides refresh decisions that infrastructure teams actually have to make. GPUDirect Storage enables direct transfer from storage to GPU memory at high throughput, decoupling checkpoint I/O from CPU bottlenecks, but the value of that capability depends entirely on whether the NVMe tier underneath it can keep pace with GPU memory bandwidth. A 100-billion-parameter model generates checkpoints ranging from hundreds of gigabytes to over a terabyte, and at training scale with thousands of accelerators, checkpoint frequency creates a sustained high-throughput write workload that separates fast-tier NVMe from mid-tier shared file systems and durable object storage in ways that matter operationally. The common three-tier checkpoint architecture, node-local NVMe for frequent fast checkpoints, shared file systems for mid-frequency checkpoints, and object storage for durable long-interval checkpoints, means the actual depreciation-relevant asset is three tiers with distinct write intensities, failure modes, and replacement triggers, and these rarely line up with the GPU refresh calendar.

Interconnect aging follows its own logic. A PyTorch fine-tuning job run on default networking took roughly three times the wall-clock time of the same job configured to use RDMA over Ethernet, which shows the interconnect tier determines training throughput as directly as GPU count does. InfiniBand is engineered for sub-microsecond latency and lossless RDMA bandwidth, and properly configured Ethernet RoCE delivers a large share of InfiniBand's training throughput for clusters in the hundreds to low thousands of GPUs. For many workloads at that scale, the gap between the two is not the binding constraint on performance. What matters for planning is whether an interconnect fabric bought for one GPU generation can still keep up once the next generation's memory bandwidth increases; a bandwidth mismatch can force a compute refresh even when the interconnect shows no physical degradation. This asymmetry carries directly into build-versus-lease structuring: leasing compute while owning storage locks in residual-value risk on the tier that ages more predictably, while the compute tier's obsolescence risk shifts to the lessor, who is better positioned to absorb or redeploy it.

What the Impairment Cliff Means for Operators

A depreciation schedule is a forecast, and when a forecast is wrong by enough, GAAP does not let the error correct itself gradually. It forces recognition in a single period, as an impairment charge that resets carrying values all at once. Under GAAP ASC 360, companies must test long-lived assets for impairment whenever circumstances suggest carrying values may not be recoverable, and if net book value exceeds the recoverable amount, they have to write off the difference immediately instead of spreading it across the remaining schedule. The fiber overbuild of the early internet era set the structural precedent for this kind of reckoning: a wave of impairment charges reset entire sector financials in a single quarter once assumed demand failed to materialize and carrying values detached from what the assets could actually recover in the market.

Leverage sharpens the risk. If you treat GPUs as long-lived assets, they look financeable, so operators borrow against them, and a fleet carried at six-year book value is a fundamentally different collateral proposition than the same fleet marked to current secondary-market rates. Amazon's 2025 adjustment shows how an operator manages this risk proactively: the company reduced the useful life of a subset of servers from six years to five and booked roughly $920 million in accelerated depreciation, voluntarily tightening its schedule in response to observed obsolescence rather than waiting for a forced impairment to create a larger charge later. The shape of the depreciation curve carries its own signal here too. GAAP ASC 360-10-35-7 notes that the declining-balance method may give the most satisfactory allocation of cost when productivity or revenue-earning power is front-loaded, or when maintenance charges tend to rise in later years, and these conditions describe GPU rental economics closely. Yet no major operator in the current peer group applies declining-balance depreciation to GPUs, despite the well-documented front-loading of GPU rental rates. That gap between the accounting guidance and what the industry actually does stands as an open invitation for the kind of correction Amazon already made once.

Mapping Depreciation Assumptions to Refresh-Cycle and Build-vs-Lease Decisions

The schedule an infrastructure team accepts, whether it owns hardware outright, leases it, or buys cloud capacity, determines who absorbs obsolescence risk and when. Schedule awareness is a prerequisite for sound capacity planning, not an afterthought for the finance team to handle separately.

Build-versus-lease decisions map directly onto useful-life assumptions:

• Owning hardware at a six-year book life assumes the operator can keep generating revenue from the asset through the cascade's tertiary phase, which requires inference demand growth, model-hardware compatibility, and manageable operating costs holding through years five and six.
• Leasing compute transfers residual-value risk to the lessor, and the operator pays a premium for that transfer, a premium that only pays for itself if the probability of early obsolescence is high relative to its cost.
• A conservative three-year ownership assumption with aggressive early depreciation maximizes early tax shields and reduces impairment exposure, at the cost of higher reported expense in years one through three, a trade-off that lands very differently for a startup optimizing for GAAP profitability than for a team running infrastructure as a cost center.

Refresh-cycle planning should treat compute and storage as separate tracks, because they age on separate curves:

• Compute carries architecture-generation risk on a one-to-two-year cadence; the cascade can provide some buffer against that risk, but only if inference workloads are actually ready to absorb hardware displaced from training.
• NVMe and interconnect have longer physical lives but can turn into bandwidth bottlenecks the moment the compute tier refreshes, so planning the storage refresh on its own schedule avoids buying a new GPU generation into a storage tier that constrains it from day one.
• Precision format roadmaps belong inside the refresh-cycle plan directly: a workload that requires BF16 today but can be served in FP8 or FP4 within the hardware's depreciation window extends the useful life of the current fleet, but that extension is a software bet that needs active tracking rather than an assumption baked into the schedule at purchase.

Bernstein's analysis of current rental-market margins gives you a useful reality check on all of this. A current-generation B200 runs at a high contribution margin in the rental market, and an A100, six years into its life, still earns a substantial margin, evidence that the cascade is functioning for at least some operators in the secondary market. Rental-market margin is not the same thing as on-premise workload adequacy, though, and planning models that conflate the two will overstate how far the cascade theory actually extends into owned infrastructure. Infrastructure analysts increasingly see a five-year midpoint as the defensible standard for AI-primary hardware: shorter than the hyperscaler six-year posture, longer than the bear-case two-to-three-year estimate, with storage and interconnect warranting longer assumptions and compute warranting shorter ones.

The depreciation schedule, in the end, is a forecast about how workloads will evolve over the life of an asset. Finance sets the number. Infrastructure teams are the ones who can actually tell whether that number describes a GPU generation that will still be earning its keep in year five, or one that will need a write-down before the schedule says it should.