Validated on H100 silicon

See exactly what every GPU draws — and what it’s doing with the power.

DMS Core is a userspace daemon that reads NVML at 10 Hz on every host: real power draw, junction temperature, and gating decisions, per device, timestamped. It measures first, and acts only where the data justifies it.

See what we measured How it works
The constraint

You can't buy more power. Not for years.

The bottleneck for AI infrastructure is no longer GPUs, or capital. It's energized megawatts — and the supply chain for them is measured in years, not quarters.

3–5 yr
Lead time for high-power transformers, up from 24–30 months before 2020.
2028
Medium-voltage switchgear is sold out through the end of the decade.
4–7 yr
Grid interconnection queues in the markets carrying most of the buildout.
If you can't add megawatts, the only lever left is getting more useful work out of the ones already energized. No amount of capital shortens a transformer lead time.
What it does

One narrow path touches hardware. Everything else observes.

A single userspace service per host — no kernel modules, no reboot, no changes to tenant code. In shadow mode it writes nothing, so its decisions can be validated before it's ever given authority.

10Hz

Reads the silicon directly

NVML at 10 Hz — power draw, junction temperature, utilization, per device, keyed by UUID and timestamped.

Shadow mode writes nothing

Records what a power governor would have decided, without touching hardware. The safest way to see what it does on a live cluster.

10s

Forecasts thermal events

Projects junction temperature 10 seconds forward and flags it early, so an orchestrator can move a workload before a thermal trip, not after.

Advises, never commandeers

The advisory path issues zero hardware commands. It publishes; acting on it is your decision, run by your systems.

Validated on silicon

We found a serious bug in our own logic — and published it.

Most vendors tell you their software works. We'd rather show you what testing on real hardware actually surfaces, including in our own code.

Shadow-mode run · 10,848 samples @ 10 Hz
H100 SXM 80GB · driver 570.211.01

NVML reported under 5% utilization while the card was drawing up to 545 W. An idle H100 with a live context draws 124 W. Our gating logic keyed on that utilization signal — meaning it would have clock-gated a working GPU on 3,952 of 10,848 samples (36%).

False gates — before
3,952
working GPUs would have been throttled
False gates — after
0
across the same 10,848 samples

We redesigned the gate to require both utilization and power to indicate idle — power vetoes utilization, never the reverse. Re-tested on the same hardware, false gates dropped to zero, while still catching 23.4% of samples as genuinely idle. Gated cards drew 125–135 W; released cards, 129–721 W. Clean separation, no overlap.

Utilization isn't a safe idle signal on this silicon. Power draw is.
In development

Measurement first. Then more of the picture.

The daemon collects the raw signal today. These build on it — and ship the same way everything here did: validated on real hardware before we claim a number.

In active development

Fleet-level power aggregation

Coincident-peak analysis across a full fleet, timestamp-aligned at 10 Hz — to measure how much of a provisioned power envelope is real load versus margin no workload has ever touched.

Early experiments

Power / throughput characterization

Measuring the efficiency curve of capping GPU power, per silicon generation — how much throughput a cap actually costs, and where the useful knee sits.

The audit

Start with a measurement, not a leap of faith.

48 hours, read-only, one non-production node. The daemon writes nothing to your hardware. You get your real coincident peak at 10 Hz per-GPU resolution — a number facility metering and rack PDUs can't produce — and every figure labeled measured or modeled.

Request an audit