Data centers & AI compute

The physical reality behind the AI-compute story.

Public notes on where the economics of AI infrastructure get decided. That is rarely the headline compute number. It is the precision the hardware is built for, the watts and heat it moves, and the clock it depreciates on. The aim is to make the reasoning legible enough that the next question gets sharper.

Signal

A build or an investment is priced on headline FLOPS, while power, cooling, utilization, or the depreciation clock are treated as details rather than the decision.

Hypotheses

The precision the workload needs is drifting away from the hardware roadmap; the real constraint is watts and heat, not compute; the asset is depreciating faster than the model assumes.

Evidence

Public architecture specs, system datasheets, depreciation disclosures, reliability literature, and public power-market data. Ranges, not point forecasts.

Next question

Which single number would move the decision: utilization, power price, depreciation life, or aging failure. Another headline throughput figure will not.

01 · Who this is for

People who need the AI-compute story to survive contact with watts, heat, depreciation, and utilization.

Operators, founders, engineers, and commercially minded technical people around AI infrastructure, high-performance computing, and the power and storage that sit under it. Long-lived capital, fast-moving hardware, and the uncomfortable truth that "compute is abundant" is true for some workloads and false for others.

Capital view

The asset is physical and financial at once

At what utilization, power price, and depreciation life does the hardware pay? And who is answering the physical half of that question?

Technical view

Precision is not free

Which workloads are safely low-precision, and which structurally need FP64? Where does the hardware roadmap help, and where does it stop helping?

Infrastructure view

Watts and heat set the limit

Power and cooling, not the card's sticker price, decide where a build can run and whether it runs at all. They also set how fast it ages.

02 · The precision ladder and the FP64 gap

The GPU roadmap is racing down the precision ladder, stranding the science that needs full double precision.

As I read the public architecture specifications, each recent data-center GPU generation packs more of the low-precision arithmetic that model training and inference reward: FP16 and BF16, then FP8, now FP4. FP64, full double precision, has not scaled at the same pace. On the newest AI-first parts it occupies a small corner of the chip. This is a directional reading of public specs; check the current primary sources (NVIDIA architecture whitepapers, vendor datasheets) before any decision.

The trend

Down the ladder, for good reasons

Neural networks tolerate low precision well, so it is rational to spend transistors where the AI workload pays back. For most of the AI market this is the right call.

The stranded workloads

FP64 is physics, not habit

CFD, structural FEA, climate and weather, molecular dynamics, and computational materials lean on FP64 for conditioning. Stiff systems and long integrations accumulate rounding error that lower precision cannot absorb. The result is a wrong answer that still looks plausible.

The gap

Two curves drifting apart

Per watt, accelerators get faster at the math AI needs and slower at the math a jet engine or a new alloy needs. "Compute is abundant" is true for AI. It is much less true for double-precision science.

Open question worth holding: which FP64 workloads are non-negotiable, and which survive mixed precision and iterative refinement? The honest answer separates a real infrastructure gap from an engineering habit. My own numerical-simulation work uses FP64 solvers over real geometry, so I have a stake in the answer.

03 · Watts, heat, time

The AI-capex story is priced on compute; the risk lives in three quieter numbers.

the power number

Watts

A single dense AI server, eight accelerators plus the rest of the box, pulls the power of a small building at full tilt. Public system datasheets put top-end boxes around the ten-kilowatt mark. Power and cooling, not the card's price, set where a build can run.

the thermal number

Heat

Every watt becomes heat that has to leave. Sustained high power density is what ages the hardware: thermal cycling, solder fatigue, ordinary wear. Run it hot and busy and it does not only cost more to cool. It dies sooner.

the depreciation number

Time

A frontier accelerator can be the best in the world and still depreciate on a short clock, because the next generation resets the frontier. Accounting life, physical life, and market-value life are three different numbers. The gap between "obsolete for training" and "still useful for something" is worth more than most models assume.

Directional, public-source framing (system datasheets for power; public depreciation disclosures and reliability literature for aging). FLOPS purchased is the wrong measure. The asset pays at some combination of utilization, power price, depreciation clock, and aging failure. That combination is half physical and half financial, and the two halves are usually answered by different people.

04 · Source discipline

What this note is, and what it is not.

Provenance

Claims are dated and public

Hardware roadmaps, power figures, and depreciation conventions age quickly. A useful note keeps the source line close to the conclusion and never launders a private number into a public one.

Confidence

Ranges stay ranges

Where the evidence is directional, the language stays directional. False precision about watts, prices, or depreciation is worse than an honest band.

Boundary

Public note, not advice

Nothing here is a recommendation on any specific build, asset, or transaction. A real decision still needs primary specs, measured power, and current source checks.

Revision

Better evidence moves the note

New silicon, new datasheets, and disproved assumptions are supposed to change the weight of what is written here. Corrections are welcome.

05 · Contact

Questions, corrections, or public-source pointers are welcome.

Especially useful: better primary sources on FP64 throughput and system power, cleaner terminology, or cases where a physical reality was priced into an infrastructure decision, or missed.

Privacy & contact note →