Blog ▸ Capex vs Opex for AI Infrastructure: What Your Board Wants to See
GPU Infrastructure
Meta extended assumed server life to 5.5 years and booked a $2.9 billion profit boost. Useful life is an estimate, and the component split decides what a board sees.
Capex vs Opex for AI Infrastructure: What Your Board Wants to See
GPUaaS.com Team
GPU Infrastructure
September 23, 2026
No items found.
Meta extended assumed server useful life to 5.5 years and booked a $2.9 billion profit boost in 2025.
Nothing about the hardware changed. One estimate in a footnote did.
Key takeaways
Useful life is a management estimate, not a fact. Extending it is legal, disclosed, and auditor-approved under ASC 250
GPU modules run 3.5 to 4.5 years with 30-35% salvage. Chassis, fabric, power and cooling run 6 to 8. Blending them into one life is the common error
GAAP depreciation is (cost minus salvage) divided by life. The salvage term gets dropped more often than it should
On a $500K AI project, correct capex/opex split cuts the year-one EBITDA hit from $500K to $200K
Contract structure decides what can be capitalised. Bundled contracts make capitalisation hard to defend
◆ THE STAKES AT SCALE
A $176 billion estimate hangs on one assumption
Shortening GPU lives from the four-to-six-year schedules now in use toward the two-to-three-year replacement cycle some analysts argue reflects real economic life would change reported earnings across major cloud providers by an estimated $176 billion across 2026 to 2028.
Working the arithmetic the other way shows the same sensitivity. With roughly 55% of capex going to GPU assets at 10% salvage, extending data centre asset life from three years to six cuts annual depreciation on about $300 billion of capex from roughly $51 billion to $28 billion. That is a 46% reduction in reported expense from a single estimate.
None of this is improper. Changes in depreciable life are treated as changes in accounting estimate under ASC 250 rather than corrections of error, they are disclosed in the 10-K, and auditors sign off. They do have to be supportable.
◆ THE SAME ASSETS, DIFFERENT ESTIMATES
Companies disagree with each other, publicly
The clearest evidence that useful life is a judgement rather than a measurement is that comparable operators have moved in opposite directions. Meta extended to 5.5 years while Amazon shortened to 5, and Oracle has run six-year schedules that look aggressive against either. Microsoft extended building useful life from 15 to 25 years, which moved some leases out of reported capex and brought calendar 2026 spending in around $175 billion against market expectations nearer $190 billion.
Those companies buy similar hardware and run similar workloads. The spread between their assumptions is not a disagreement about the silicon. It is a disagreement about what the estimate should reflect, and anyone building a comparison across providers inherits that spread whether or not they notice it.
◆ COMPONENTS DEPRECIATE AT DIFFERENT RATES
Component
Useful life
Realistic salvage
GPU modules
3.5-4.5 years
30-35%
Chassis and networking fabric
6-8 years
Higher
Power distribution and cooling
6-8 years
Higher
Rented compute
Not capitalised
Opex in period used
Source: Stanley Laman Group analysis of GPU useful life and salvage assumptions
◆ TWO TERMS THAT GET DROPPED
Salvage value and component segmentation
GAAP requires cost minus salvage value divided by useful life. Treating depreciation as cost divided by life drops a term worth 30 to 35% of the GPU's original value, which matters because used Hopper and Ampere parts continue trading well after their accounting life ends.
The second omission is segmentation. GPU modules obsolesce on a 3.5 to 4.5 year cycle while the chassis, networking fabric, power distribution and cooling around them last 6 to 8. A single blended life either overstates depreciation on the facility or understates it on the silicon.
The real tension is between two to three year technological obsolescence and five to seven year economic utility. A GPU that is no longer competitive for frontier training still serves inference profitably, which is why the two numbers disagree and why the choice between them is a judgement rather than a fact.
$2.9 billion
profit boost booked in 2025 from extending assumed server useful life to 5.5 years, with no change to the underlying hardware
Meta 10-K disclosure, via ValueAdd VC analysis of AI capex depreciation, 2026
◆ WHAT THIS MEANS BELOW HYPERSCALER SCALE
A $300,000 swing on a $500,000 project
On a $500,000 AI project with $300,000 of capex-eligible build work, full opex treatment produces a $500,000 hit to year-one EBITDA. The correct split produces $200,000, with roughly $100,000 of depreciation in each of years one through three.
That $300,000 difference comes from classification rather than from spending less. Owned hardware goes to property, plant and equipment under IAS 16 or ASC 360 and depreciates. Rented compute is opex in the period consumed. Implementation work for cloud services depends on project stage, and eligible application development can be capitalised.
Contract structure decides whether any of that holds up. A contract that separates build scope, ongoing retainer, and inference pass-through gives clean lines to capitalise against. A bundled contract makes capitalisation difficult to defend when an auditor asks which portion created a durable asset.
◆ WHAT AUDITORS WILL ASK FOR
Your own retirement history, not a default
Useful life for capitalised AI work should be based on the organisation's own model versioning and retirement history rather than a default software life. Auditors expect the chosen life to be supported by evidence, and retired models or workflows need testing for impairment.
That requirement cuts both ways. A team that has replaced its serving model three times in eighteen months cannot defend a five-year amortisation schedule, and a team running stable infrastructure for three years can defend more than a conservative default would allow.
◆ THE WARNING WORTH TAKING TO A BOARD
Do not let accounting pick the architecture
Capital treatment makes on-premises infrastructure look better on EBITDA. Operating treatment makes cloud look lighter on the balance sheet. Both effects are real, and neither says anything about which option actually costs less to run.
A board paper that presents one option in capital terms and the other in operating terms is comparing two different measurements. The useful version states total cost of ownership over the same horizon under both treatments, then shows the accounting effect separately, so the infrastructure decision and the presentation decision stay apart.
The question a board should be asking is not whether to capitalise. It is what useful life the organisation can actually defend, whether salvage value has been included, and whether the components have been segmented rather than blended.
Rented capacity priced against owned, before the accounting choice. No buyer fees. For single GPUs, packet.ai handles self-serve access with 24/7 human support.
Owned hardware is capex, recorded as property, plant and equipment under IAS 16 or ASC 360 and depreciated over its useful life. Compute rented by the hour or month is opex in the period consumed. Implementation work for cloud services depends on project stage, and eligible application development can be capitalised.
GPU modules run 3.5 to 4.5 years with realistic salvage of 30 to 35%, while chassis, networking fabric, power distribution and cooling run 6 to 8 years. Segmenting them is more defensible than a single blended life, which either overstates depreciation on the facility or understates it on the silicon.
Yes. Changes in depreciable life are treated as changes in accounting estimate under ASC 250 rather than corrections of error. They are disclosed in the 10-K and auditors sign off. The estimate does have to be supportable, which is where the scrutiny falls.
On a $500,000 AI project with $300,000 of capex-eligible build, full opex treatment hits year-one EBITDA for $500,000 against $200,000 under a correct split. That $300,000 swing comes from classification rather than from spending differently.
Total cost of ownership over the same horizon under both treatments, with the accounting effect shown separately. Presenting one option in capital terms and the other in operating terms compares two different measurements and lets the accounting pick the architecture.
Last reviewed: 24 September 2026. The $176 billion earnings estimate and ASC 250 treatment from the National Law Review's analysis of GPU useful lives. Meta's 5.5-year extension and $2.9 billion effect via ValueAdd VC's AI capex depreciation analysis, 2026. Component useful life and salvage figures from Stanley Laman Group's GPU useful life analysis. Depreciation sensitivity on $300 billion of capex from Cerno Capital's hyperscaler accounting analysis. Microsoft lease and building life figures from CRV's AI capex analysis, 2026. IAS 16 and ASC 360 treatment, auditor evidence requirements and the architecture warning from VDF's capex and opex accounting guide for on-premises AI, 2026. Project-level EBITDA figures and contract structure guidance from SFAI Labs' AI capex and opex analysis, 2026. Browse current GPU cluster availability on GPUaaS.com.
