InfraPulse is the accounting layer between the telemetry your GPUs already emit and the number your budget owner actually needs: how many of the GPU-hours you paid for did real work, and where the rest went.
Read-only. NVIDIA DCGM and AMD amd-smi. Kubernetes and Slurm aware. No scheduler changes, ever, without you asking.
Most monitoring stacks stop at the coarse device metric. InfraPulse reads the fine-grained fields underneath it and does the arithmetic that turns them into an account.
| Signal | Source fields | What it tells you |
|---|---|---|
| Effective compute | SM active, SM occupancy, tensor active, DRAM active (DCGM profiling fields); amd-smi activity counters on AMD |
How much math the device completed against its rating — the "delivered" number the busy metric hides. |
| Throttle attribution | clock throttle reasons bitmask, SM/memory clocks, power draw, temperature |
Why clocks dropped (thermal, power cap, HW slowdown, sync boost) and how many effective hours each reason cost. |
| Reliability drift | ECC counters, XID events, per-GPU baselines over time | The node that has quietly become the slow one, before it shows up as a failed job or a "flaky" application. |
| Allocation vs. delivery | Kubernetes pod / Slurm job context, read-only | Which allocations produced throughput and which held a device warm — by tenant, by job class, by hour of day. |
| GPU-hour accounting | Your cost basis (rental rate or amortized capex) per SKU | Every shortfall priced in the unit your budget is written in. Nothing here is a vendor's estimate; it is your fleet's own numbers. |
A single container or systemd unit per node reads DCGM or amd-smi and, if present, the local scheduler's read-only API. Or skip it: export 24 hours from Prometheus and send the file.
A device's normal is learned from its own history under real load, then compared against its SKU rating and its siblings in the same rack. Drift is detected as drift, not as noise.
Each hour's shortfall is assigned to a cause with a signal timeline — before and after, not correlation — and priced in GPU-hours from your cost basis. The output is a finding you can act on and a number you can defend.
The telemetry is the ground truth; the agents are the labor. Four of them do the watching, attributing, and recommending that a fleet team never has hours for — and hand every conclusion to a person with the evidence attached.
Continuous per-GPU baselining. Flags drift from a device's own normal — ECC slope, throughput separating from siblings, a rack warming faster than its neighbors — before a threshold alarm would fire.
Lines up throttle bits, power, temperature, tensor activity, and scheduler context into a cause with a signal timeline. Distinguishes hot-because-working, hot-because-cooling, and cool-because-starved.
Turns a confirmed cause into a specific, reversible next step — move, drain, rebalance, check — priced in GPU-hours and explained in plain language. Recommends only; automation is opt-in, later.
Writes the daily account of delivered vs. paid-for GPU-hours and answers questions against the same data: "why did D2 lose 400 GPU-hours this week?" The Path B written analysis is this agent's output, run once on your export.
Agents propose; operators dispose. They run on the same numeric metric samples the collector emits, carry a confidence level and their evidence on every finding, and have no write path to your scheduler, your clocks, or your BMCs unless you turn one on. See them at work on the demo hall →
A willing operator usually stalls on one question: what leaves my network? Here is the answer, and it is also available as a one-page PDF on request before anything is installed.
The collector has no write path to your GPUs or your scheduler. What it emits is numeric metric samples keyed by a hostname alias you control. It carries no job names, no code, no workload payloads, and no credentials. There is no inbound connection from DataStelio to your environment at any point. Path B involves no software from us at all — you export, you send, we return a document.
Nothing is replaced. If you have DCGM or amd-smi and a scheduler, you have everything InfraPulse needs.
Measurement first. Recommendations only once the measurement has been confirmed real by the operators who own the fleet. Automation last, and only when asked.
amd-smi and ROCm SMI, so the delivered-throughput picture on MI300X-class hardware is nearly unstudied. Path B works the same way: send amd-smi metric output for 24 hours.dcgmi dmon capture with the profiling and throttle-reason fields enabled, a Prometheus range export of your dcgm-exporter metrics, or amd-smi metric output on a loop. Twenty-four continuous hours from a handful of nodes is enough to start. We reply to your first message with the exact two-line command for your exporter.No agent, no access, no NDA. Tell us the fleet and the exporter and we will reply with the export command.