Energy, measured. Not claimed.

Latest measured reading

Read directly from the hardware power rails of NGARi Node-01 (NVIDIA Jetson AGX Orin, 64 GB), sampled every five seconds from tegrastats. The reading below was taken while a training job and the public preview were both active — a loaded machine, not an idle one.

Sample taken 2026-09-22 20:54 EDT. Source: /run/ngari-tegrastats.json, written by tegrastats-reader.timer every five seconds on the device. Load context: an active distillation training run plus the public preview API.

How it is measured

1. tegrastats reads the module's on-board power monitors — the same rails NVIDIA uses to enforce Jetson power modes.
2. Every five seconds the reader parses three rails: VDD_GPU_SOC, VDD_CPU_CV and VIN_SYS_5V0, sums them, and writes total watts plus temperatures and RAM to /run/ngari-tegrastats.json.
3. The inference engine's hardware abstraction layer exposes the same value at runtime via get_power_consumption(), so application code can attribute energy to work rather than guess it.
4. No power figure on this page is modelled, sampled from a vendor datasheet, or inferred from a cloud provider's disclosure. Anything not measured is labelled as derived below.

What "measured" does not mean. This is board-level input power from the module's own monitors, not a wall-plug meter. It excludes AC/DC adapter losses, and it does not yet separate the energy of one inference from another process on the same board.

Energy intensity — derived, with the arithmetic shown

We have one throughput figure we can stand behind today: our distilled 1.5B model sustains roughly 39 tokens/second on Node-01, documented in the serving code. Pipelined at the measured 37.7 W, the arithmetic is:

The carbon row uses the US grid average emission factor (0.39 kgCO₂e/kWh) as a stated assumption. Article 9.2 requires using measured or regional grid intensity where that data is available; sourcing it automatically is on the roadmap below, not in production. Change the factor and the carbon figure changes proportionally — the energy figure above does not.

What governance requires vs. what is automated

We would rather publish an accurate gap than a flattering claim. Article 9 and Tech Charter §3 require four things; here is the honest status of each.

Closing the gap

1. Add energy_joules and avg_watts to the signed inference attestation. The meter already records duration, tokens and network bytes; the power value is available at the same moment. This closes the main 9.1 gap.
2. Attribute board power to the inference window. Sample power for the duration of each request rather than the board's rolling state, so heavy co-tenant load stops contaminating the number.
3. Wire a regional grid-intensity source so 9.2 uses measured intensity instead of a hard-coded national average.
4. Make the power monitor a gate, not a log, per Tech Charter §3 — refuse inference when energy cannot be measured.
5. Publish a monthly energy ledger for the hosted preview and API fleet, with the same method shown here.

Until items 1–4 ship, treat hosted-preview energy figures as device-level measurements and treat per-request energy as unavailable rather than estimated. We would rather you know which is which.

Verify it yourself

Sovereign energy reporting is only meaningful if you can reproduce it. On any NGARi device you can:

# board power rails, updated every five seconds
cat /run/ngari-tegrastats.json

# the raw source, sampled live
tegrastats --interval 1000 | head -1

# outbound bytes since boot (loopback excluded) — the air-gap check
cat /proc/net/dev

On NGARi+ you can run all of the above with the network cable unplugged and get the same energy numbers, because inference never depended on the network in the first place. That is the point of measuring on your own board instead of trusting a provider's dashboard.