The Energy Blind Spot: NVIDIA’s Flagship Edge AI Hardware Cannot Support Process-Level Energy Attribution Deepak Panigrahy
Aakash Tyagi
Independent Researcher Bentonville, USA [email protected]
Texas A&M University Dept. of Computer Science and Engineering College Station, Texas, USA [email protected]
arXiv:2605.27599v1 [cs.LG] 26 May 2026
Abstract Agentic AI workloads — where a single user goal triggers multistep orchestration, tool calls, retries, and failure recovery — are being targeted for edge deployment, with NVIDIA, Dell, HP, ASUS, MSI, Acer, and Gigabyte all shipping GB10-based desktop AI systems in 2026 [2, 13]. We recently demonstrated that orchestration structure dominates agentic energy cost, with workflows consuming 4.33× more energy per successful goal than linear baselines and OOI reaching 7.63× for multi-step reasoning tasks [1]. Separately, Rajat et al. show that CPU-side processing accounts for up to 90.6% of total latency and 44% of total dynamic energy in agentic workloads [14]. We report a systematic energy-observability audit of the ASUS Ascent GX10 (GB10 SoC) and find that the platform exposes no CPU energy counter, no INA power-rail monitor, no IPMI/BMC, and no SCMI powercap protocol through any supported software interface. The only on-device energy telemetry is instantaneous GPU power via NVML. We further discover that the MediaTek firmware already computes per-rail energy internally via an undocumented ACPI interface (SPBM), but NVIDIA states there are "no plans to expose CPU rail information.” [11]. On-device per-process energy attribution — as performed on x86 via RAPL — is therefore not reproducible on this platform through supported interfaces. We formalize a hardware requirements specification for energy-attributed AI, propose an interim calibration bridge using external DC metering combined with GPU subtraction, and identify a standards-track path via SCMI powercap. Our findings motivate the low-carbon computing community to demand energy observability as a first-class hardware requirement.
Keywords Energy measurement, ARM, agentic AI, RAPL, SCMI, edge computing, GB10, energy attribution
1
Introduction
The agentic AI paradigm—where autonomous agents decompose goals into multi-step plans involving tool calls, retries, and failure recovery—is rapidly moving from cloud infrastructure to edge devices. NVIDIA’s GB10 Grace Blackwell superchip, shipping in the DGX Spark ($4,699) and ASUS Ascent GX10 ($3,499), is explicitly positioned for this transition: a 1-PFLOP (FP4) ARM+Blackwell SoC designed for local AI agent execution [2]. We recently established that orchestration structure—not inference compute—dominates the energy cost of agentic AI [1]. Across eight task families, agentic workflows consumed 4.33× higher mean energy per successful goal (888.1 J vs. 205.3 J) than linear baselines, with the Orchestration Overhead Index (OOI) ranging from 0.62×
to 12.68×. Crucially, this finding depended on per-process energy attribution: combining Intel RAPL hardware energy counters with Linux scheduler accounting (/proc/{pid}/stat) to compute the CPU-fraction-scaled energy consumed by each process within each goal attempt. This raises a critical question: can the same measurement be performed on the hardware NVIDIA is shipping for edge AI? We conducted a systematic hardware audit of the ASUS Ascent GX10 (GB10 SoC) and found that no per-process energy attribution is possible on this platform. The CPU—where all orchestration work executes—has no energy measurement interface whatsoever. The implications extend beyond a single product: the entire ARM edge AI ecosystem lacks the hardware energy counters that x86 has provided via RAPL since 2011 [3].
1.1
Why Now
The measurement gap we document coincides with three accelerating trends that make it practically significant today rather than a future concern. Energy scale. Global AI inference demand is projected to grow from 15 TWh in 2025 to 347 TWh by 2030 [9]. Agentic systems consume substantially more energy per interaction than singleturn inference: a 280-fold decline in inference costs since 2022 has driven a rebound effect where cheaper inference enables more agentic deployments, each consuming more energy per user goal [1] than the single-shot queries they replace [9]. The shift from singlepass inference to closed-loop iterative reasoning moves the primary energy bottleneck from computation to orchestration overhead [1]. Regulatory context. The EU AI Act (Regulation 2024/1689) [10] requires providers of General-Purpose AI (GPAI) models to document known or estimated energy consumption under Annex XI, Section 1(e), with the AI Office empowered to demand this documentation without prior notice. These obligations apply to GPAI model providers and came into full force in August 2025. Separately, California’s SB 253 [9] requires Scope 1–3 emissions disclosure starting 2026. While neither regulation explicitly mandates per-process energy counters at the hardware level, both create a compliance environment in which organizations deploying GPAI-class models on edge hardware require accurate, reproducible energy measurement. Hardware that cannot support such measurement impedes compliance efforts for the agentic systems deployed on it. Edge deployment trajectory. NVIDIA positions the GB10 explicitly for agentic AI: the DGX Spark ships with NemoClaw, an autonomous agent development platform [2]. Dell, HP, and ASUS all
Deepak Panigrahy and Aakash Tyagi
ship GB10-based systems targeting AI researchers and developers. Every deployed unit represents an orchestration energy measurement gap — the orchestration overhead that our prior work shows dominates total cost cannot be measured directly on this hardware. Attribution using external metering and statistical disaggregation is possible, as we discuss in Section 6, but introduces estimation uncertainty and cannot support the per-process, per-goal reproducibility that research-grade energy accounting requires. The gap we document is therefore not absolute but structural: on-device, perdomain counter-based attribution — the reproducible, low-overhead methodology the research community depends on — is unavailable.
2
Hardware Audit Methodology
We performed an exhaustive enumeration of every known energy measurement interface on the ASUS Ascent GX10 (firmware version GX10DGX.0104.2026.0326.1657, kernel 6.17.0-1018-nvidia, Ubuntu 24.04.4 LTS, aarch64). The system contains a MediaTek-designed SoC with 10× ARM Cortex-X925 performance cores (up to 3.9 GHz) and 10× ARM Cortex-A725 efficiency cores (up to 2.8 GHz), coupled via NVLink-C2C to an NVIDIA Blackwell GPU, with 128 GB unified LPDDR5X memory. Table 1 summarizes the results across seven energy measurement interfaces. Note on scope. This audit covers all known standardized energy measurement interfaces available to unprivileged and root userspace on Linux aarch64 as of kernel 6.17.0-1018-nvidia. It does not cover proprietary vendor extensions or undocumented ACPI methods (discussed in Section 3), nor does it evaluate non-standard or community-developed drivers as measurement infrastructure. The audit was conducted on a single GX10 unit ; cross-device and cross-firmware generalizability is addressed in Section 9.
3
The SCMI Smoking Gun
The most significant finding is not the absence of RAPL—that is expected on ARM—but the selective implementation of SCMI protocols. ARM’s System Control and Management Interface (SCMI) [4] is the standard firmware interface for power, performance, and system management on ARM SoCs. The SCMI specification defines protocols for clock management, power domain control, performance management, sensor reading, and—since SCMI v2.0—powercap with measurement capabilities. On the GX10, the SCMI protocol bus is registered and active: scmi_core: SCMI protocol bus registered
Four SCMI protocol drivers are loaded: scmi-clocks (clock frequency management), scmi-regulator (voltage regulation), scmi-mpam-driver (memory partitioning), and scmi-imx-bbm-key (battery-backed memory). However, neither scmi-powercap nor scmi-sensor drivers are present, and zero SCMI devices are registered in /sys/bus/scmi_protocol/devices/. This means the System Control Processor (SCP) firmware on the GB10 implements SCMI but does not expose the powercap or sensor protocols. The Power Management IC (PMIC) on the SoC must monitor per-rail current for thermal protection and DVFS decisions—the energy data exists inside the chip. The firmware
Table 1: Energy measurement interface audit on ASUS Ascent GX10. The GB10 SoC contains 10× Cortex-X925 and 10× Cortex-A725 ARM cores (MediaTek big.LITTLE design) coupled via NVLink-C2C to an NVIDIA Blackwell GPU. Every CPU-side and system-level energy interface is absent through supported channels. Interface
Probe Method
Result
ARM SCMI powercap
/sys/bus/scmi_ protocol/drivers/
Bus active. Only clock, regulator, MPAM loaded. No powercap. No sensor.
ARM PMU energy events
perf list | grep energy|power|rapl
Zero hardware energy events. Only tracepoints for CPU idle/freq transitions.
INA3221/ INA226
i2cdetect -y on all 6 I2C buses (NVIDIA GPU adapters)
Zero devices at 0x40– 0x4F. All 6 buses empty.
IPMI/BMC
ipmitool sensor list ipmitool dcmi power
/dev/ipmi0: no such file or directory
hwmon energy/power
find /sys -name "energy_uj" find /sys -name "power*_input"
No results. hwmon0 (acpitz): temp only. hwmon1 (nvme): temp only. hwmon2 (mt7925): temp only.
Power supply subsystem
/sys/class/ power_supply/*/
Empty—no batteries, no PMIC reporting.
NVML (GPU only)
nvidia-smi -q -d POWER
GPU: 3.84 W avg. Power limit: N/A. Memory power: N/A. Only energy interface on entire platform.
chose not to expose it. The standard is ARM’s, the kernel support is being built, but the firmware decision is MediaTek’s and NVIDIA’s. Recent kernel patches (February 2026) by Radford [5] add SCMI Powercap Measurement Averaging Interval (MAI) support, and SCMIv4.0 patches [6] extend powercap with per-domain configuration. The Linux kernel infrastructure to consume SCMI energy data is being built. What is missing is the firmware-side decision to expose it. The SPBM discovery. During the preparation of this paper, we discovered that a community developer had independently identified the same energy observability gap on the DGX Spark [11] and reverse-engineered a software interface to the underlying data [12]. The MediaTek SSPM firmware on the GB10 maintains a System Power Budget Manager (SPBM) shared memory region, populated continuously at approximately 100 ms intervals, containing per-rail power in milliwatts, cumulative energy accumulators in millijoules
The Energy Blind Spot: NVIDIA’s Flagship Edge AI Hardware Cannot Support Process-Level Energy Attribution
(covering the P-core cluster, E-core cluster, GPU, and total SoC package), and per-zone temperatures. This data is accessible via an ACPI _DSM method on device NVDA8800 as demonstrated by the community driver. We confirmed the presence of the NVDA8800:00 ACPI device on our GX10 via find /sys/bus/acpi/devices, with ACPI path _SB_.MTEL (MediaTek). We did not independently decode the DSM call parameters (UUID, function indices) or validate accumulator semantics, resolution, or stability on our unit, as the community driver uses an undocumented interface with a placeholder UUID that is explicitly unsupported by NVIDIA. We therefore treat the SPBM evidence as corroborating — establishing that the firmware infrastructure for per-rail energy measurement exists — rather than as first-party validation of accumulator behavior. A complete characterization of the SPBM interface (including DSM call semantics, resolution, and update stability) would substantially strengthen this finding and is identified as a priority for follow-on work. The key observation is structural: the SCMI bus is active with four loaded protocol drivers; kernel support for SCMI powercap MAI is being actively developed; and NVIDIA has officially stated there are "no plans to expose CPU rail information". Together, this evidence establishes that the absence of energy exposure through supported interfaces reflects a product prioritization decision rather than a silicon limitation. The firmware already performs the measurement; the pathway to expose it via SCMI powercap is documented and its kernel-side support is being built; the decision not to enable it is reversible via a firmware update without hardware changes.
4
What the GB10 Could Expose
The absence of energy counters on the GB10 is a firmware decision, not a silicon limitation. We establish this by examining three layers of evidence. The PMIC knows. The GB10’s MediaTek-designed SoC implements Dynamic Voltage and Frequency Scaling (DVFS) across its big.LITTLE CPU cluster—the kernel’s cpu_frequency tracepoints confirm active frequency transitions between 338 MHz and 3.9 GHz. DVFS requires real-time current sensing at each voltage rail; the PMIC must monitor per-rail current to make scaling decisions. This current data, integrated over time, yields energy—the same principle underlying Intel RAPL’s energy counters [3]. The data exists in the PMIC; the community spark_hwmon driver [12] confirms this by reading 14 power channels and 4 cumulative energy accumulators directly from the MediaTek SSPM firmware via an undocumented ACPI interface, including separate readings for the P-core cluster, E-core cluster, GPU, and total SoC package. The SCMI bus is ready. As detailed in Section 3, the SCMI protocol bus is active with four drivers loaded, but the firmware does not expose powercap or sensor protocols. The Linux kernel is being prepared to consume SCMI energy data [5, 6]; the GB10’s firmware simply does not produce it. The Jetson precedent. NVIDIA’s own Jetson Orin platform—also ARM-based, also targeting edge AI—includes three Texas Instruments INA3221 triple-channel power monitors on the board, providing per-rail voltage, current, and power for CPU, GPU, SoC, CV,
DRAM, and system rails. These are accessible via /sys/bus/i2c/ drivers/ina3221/*/hwmon/*/power*_input and have enabled an entire ecosystem of energy-aware robotics research. The GB10, despite being a more expensive and more capable platform, provides strictly less energy telemetry than the Jetson. The I2C bus scan on the GX10 (six NVIDIA GPU I2C adapters, all empty) confirms no INA monitors were populated on the board. The cost to fix this is zero. Exposing the PMIC’s existing currentsense data through SCMI powercap requires only a firmware update— no board redesign, no additional components. Even a hardware solution (an INA3221 power monitor, as used on NVIDIA’s own Jetson Orin) costs only $2.50 per board. The GB10’s SCP runs ARM’s SCP-firmware reference implementation; adding powercap protocol support is a documented extension point. The SPBM discovery (Section 3) confirms the firmware already computes per-rail energy—the decision to omit a supported interface was a product prioritization choice, not a technical constraint.
5
What the GB10 Does Expose: Rich Telemetry, No Energy
The GB10 has plenty of telemetry—just not for energy. Our audit reveals extensive performance and thermal telemetry across CPU, GPU, and system components, summarized in Table 2. The contrast between what is measurable and what is not sharpens the argument: the platform has the infrastructure for fine-grained observability but deliberately excludes energy from it. The IPC gap. The ARMv8 PMUv3 on the GB10 exposes a rich set of microarchitectural events with per-cluster granularity. A 5-second system-wide sample at idle reveals the depth of available performance telemetry—and the absence of energy telemetry alongside it: Listing 1: PMU counters on GB10 (5s idle). PMUv3_0 = CortexX925, PMUv3_1 = Cortex-A725. X925 cluster cycles 332,432,917 inst_retired 61,414,460 IPC 0.18 stall_front 212,597,931 L3 refills 3,937,713 mem_access 22,337,281 energy ---
A725 cluster 173,742,892 19,433,976 0.11 128,076,898 2,371,854 8,163,037 ---
The performance counters decompose workload behavior to a fine grain: per-cluster IPC, pipeline stall breakdown (frontend vs. backend vs. memory), complete cache hierarchy hit/miss rates from L1 through L3, and bus/memory access counts. These are precisely the inputs a power model requires—instructions, cache misses, memory accesses, and stall cycles are the dominant predictors in validated ARM power models [15]. But without a ground-truth energy measurement to calibrate against, the model coefficients (joules per cache miss, joules per bus access) are unknown for this specific SoC. The Cortex-X925 performance cluster consumed 332M cycles while the A725 efficiency cluster consumed 174M cycles—but whether the X925 burned 2× or 5× more energy per cycle is unmeasurable through any supported interface on this hardware. On x86, these counters combine with RAPL energy readings to build calibrated power models. On the GB10, the energy readings do
Deepak Panigrahy and Aakash Tyagi
Table 2: Observable vs. energy-dark telemetry on the GB10. The platform exposes 70+ PMU events, 7 thermal zones, full DVFS control, and GPU utilization—but zero energy counters for the CPU, DRAM, or SoC through any supported interface. Domain
Available
CPU perf
ARMv8 PMUv3: No energy/power events. 70+ events incl. No RAPL equivalent. cpu_cycles, No AMU energy counter. inst_retired, mem_access, stall_backend/frontend, L1/L2/L3 cache hits/misses, branch prediction, bus access
CPU freq
Per-core DVFS: 338 MHz–3.9 GHz (X925), 338 MHz– 2.8 GHz (A725). 6 governors available. Currently: performance.
No per-frequency-state energy cost. Cannot compute energy from frequency without power model.
CPU idle
4 LPI states (LPI-0 through LPI-3) with usage counts and residency times. LPI-3: 33,146 s residency.
No idle power per state. Cannot compute idle energy from residency alone.
Thermal
7 ACPI zones (54.7– 55.8 ◦ C idle), NVMe composite (52.9 ◦ C), Wi-Fi sensor
No TDP. No thermal-to-power mapping exposed.
GPU
NVML: power (3.84 W avg), utilization (0– 100%), clocks (208–3003 MHz), temperature
No cumulative energy counter. No per-process GPU energy.
128 GB unified LPDDR5X
No DRAM energy counter. No bandwidth PMU.
Memory
Absent
not exist through any supported interface, so the counters remain useful for performance analysis but useless for energy attribution. This combination — rich performance counter availability alongside complete energy counter absence — defines the core challenge for software power modeling on the GB10. Performance-counterbased power models for ARM (e.g., the validated approach in Walker et al. [15]) require per-SoC calibration against ground-truth energy measurements. The Cortex-X925 and A725 in the GB10 big.LITTLE configuration, coupled via NVLink-C2C, represent a novel SoC profile for which no published calibration dataset exists. Without that calibration, the performance counters can characterize workload behavior precisely — IPC, cache pressure, memory bandwidth — but cannot be converted to energy estimates with bounded error. This is distinct from the scenario where external metering provides coarse board-level ground truth, which we address in Section 8.2.
6
Attribution Without On-Device Counters: Feasibility and Limits
The absence of hardware energy counters on the GB10 does not make energy attribution entirely impossible. Statistical disaggregation approaches — most notably FaasMeter [16] — demonstrate that per-process or per-function energy attribution can be achieved using only system-level power readings (e.g., from an external DC meter or coarse board-level sensor), combined with scheduling and utilization data, without per-domain hardware counters. FaasMeter uses Shapley-value-based energy allocation across concurrent functions, achieving meaningful attribution fidelity even with noisy, coarse-grained system-level power. On x86 systems, direct RAPLbased attribution has a reported attribution error of 10–23× under multi-tenant load; FaasMeter reduces this through disaggregation modeling. These results are relevant to the GB10 scenario: with an external DC meter providing total board power and NVML providing GPU power, the derived quantity 𝐸 cpu+sys = 𝐸 total − 𝐸 gpu yields a two-channel decomposition that could serve as input to a disaggregation model. We discuss this configuration in Section 8.2. However, disaggregation approaches introduce limitations that are material for the research use cases that motivate this audit: Unbounded error without calibration. Software power models and disaggregation methods require a ground-truth energy source to calibrate against. On the GB10, the only available calibration sources are (a) total board power from an external meter, and (b) GPU power from NVML. CPU-domain energy is inferred by subtraction, inheriting the error of both measurements. Without per-domain CPU counters, the per-process estimate conflates CPU orchestration energy with system-level power (memory, NVLink, I/O), introducing a systematic overestimation bias whose magnitude depends on workload characteristics. Multi-process attribution. In shared-device or concurrent-workload scenarios — the norm in agentic systems where orchestrator, tool processes, and inference workers co-exist — CPU-fraction scaling becomes an approximation whose error grows with workload heterogeneity. RAPL-based attribution on x86 avoids this by providing actual energy consumed in each sampling window; disaggregation models estimate it. Reproducibility. Research-grade energy accounting — the kind required to replicate OOI measurements across hardware platforms — requires that the measurement be hardware-grounded, deterministic, and overhead-free. External meter calibration bridges provide a useful operational approximation but cannot deliver the submillisecond sampling, per-domain resolution, and process-level attributability that RAPL provides on x86. Overhead. External DC meter integration requires physical hardware modification (inline at the DC barrel jack), constraining portability and preventing automated, unattended measurement in production or cloud edge settings. In summary: attribution is possible on the GB10 using external metering and disaggregation, but with bounded uncertainty, coarser resolution, and higher operational overhead than hardware
The Energy Blind Spot: NVIDIA’s Flagship Edge AI Hardware Cannot Support Process-Level Energy Attribution
counter-based methods. This distinction matters for reproducibilityoriented research and for regulatory compliance frameworks that require auditable, methodology-transparent energy reporting. The hardware requirement specification in Section 8.1 is therefore motivated by the quality and reproducibility of attribution, not its binary possibility.
7
Table 3: Energy attribution capability across AI-capable hardware. The GB10—NVIDIA’s flagship edge AI chip—grades LIMITED despite SCMI firmware and hidden SPBM energy accumulators.
Consequences for Energy-Aware AI
On an x86 platform with RAPL, we attribute energy to a specific agentic goal attempt via three layers [1]: (1) Raw RAPL: 𝐸 pkg (𝑡 0 → 𝑡 1 ) from RAPL counters (2) Baseline-subtracted: 𝐸 task = 𝐸 pkg − 𝐸 idle · Δ𝑡 (3) CPU-fraction-scaled: 𝐸 pid = 𝑓cpu × 𝐸 task , where 𝑓cpu = pid_cpu_time total_cpu_time
On the GX10, Layer 1 does not exist for the CPU. Without it, Layers 2 and 3 cannot be computed. The /proc/{pid}/stat scheduler accounting works on ARM—𝑓cpu is available—but there is no energy denominator to multiply it against. Without Layer 1, a developer on the GB10 cannot directly compare using per-domain hardware counters, cannot measure OOI on edge hardware, cannot normalize energy by successful goals, and cannot even detect whether a code change made orchestration more expensive. None of this is theoretical. Rajat et al. [14] show that CPU-side tool processing accounts for up to 90.6% of total latency and 44% of total dynamic energy in agentic workloads. The GB10 is not a single product but the foundation of an emerging hardware class—seven OEMs now ship systems on this SoC, including NVIDIA DGX Spark, Dell Pro Max, ASUS Ascent GX10, HP ZGX Nano, MSI EdgeXpert, Acer, and Gigabyte [13]. As agentic AI scales to edge devices—phones, vehicles, workstations, robots—every deployment is an energy black box for the CPU-bound orchestration that our prior work shows dominates total cost.
7.1
The Jevons Paradox at the Edge
The energy observability gap compounds a known economic dynamic. Inference cost reductions drive adoption of more complex agentic architectures—multi-agent orchestration, speculative execution, retry-heavy tool use—each multiplying the orchestration overhead our prior work quantifies [1]. On x86 with RAPL, this overhead is visible and optimizable: developers can measure OOI, identify retry-dominated goal attempts, and restructure orchestration to reduce energy. On the GB10, the same developer has no signal—optimization is impossible and the Jevons rebound proceeds unchecked.
8 Proposed Solutions 8.1 Hardware Requirement Specification We propose that to support process-level energy attribution for agentic AI, a hardware platform must expose: (1) Per-power-domain cumulative energy counters readable from userspace at < 1 ms read latency with resolution ≤ 1 mJ (2) Sufficient domain granularity to separate CPU, GPU, DRAM, and I/O (3) Monotonically increasing counters with defined overflow semantics
Platform
CPU
GPU
Sys
Grade
Intel x86 + RAPL NVIDIA Jetson Orin (ARM + INA3221) NVIDIA GB10 (ARM + SCMI, no powercap) Apple M-series (ARM, no public API) Qualcomm Snapdragon (ARM, no public API)
✓ ✓
— ✓
✓ ✓
MEASURED MEASURED
×
✓∗
×
LIMITED
×
×
×
LIMITED
×
×
×
LIMITED
✓ = hardware energy counter available
× = absent
— = N/A
∗ NVML instantaneous power only; no cumulative energy counter
Table 3 evaluates current platforms against this specification.
8.2
Interim Calibration Bridge
Before firmware updates expose SCMI energy counters, we propose a three-layer measurement methodology: (1) Native counters: NVML for GPU power (available now) (2) External DC metering: A precision power monitor (e.g., Monsoon HV, Qoitech Otii) inline at the DC barrel jack, providing total board power at ≥ 1 kHz sampling (3) Derived attribution: 𝐸 cpu+sys = 𝐸 total − 𝐸 gpu This provides a two-channel decomposition (GPU vs. everythingelse) that, while coarser than RAPL’s per-domain granularity, enables the first empirical measurements of orchestration-vs-inference energy on ARM edge AI hardware under controlled single-workload conditions. The external meter also serves as calibration ground truth for a future performance-counter-based software power model.
8.3
Standards-Track Solution: SCMI Energy Extension
The long-term solution requires the GB10’s SCP firmware to expose the SCMI Powercap protocol with measurement capability. The kernel infrastructure is being actively developed: Radford’s MAI patches [5] and the SCMIv4.0 powercap extensions [6] add the Linux-side plumbing. What is needed is a firmware decision by NVIDIA and MediaTek to enable it on the GB10. We propose that NVIDIA publish a firmware update for the GB10 exposing (i) SCMI Powercap domains for CPU cluster, GPU, DRAM, and SoC-total, (ii) cumulative energy readout in microjoules with configurable measurement averaging intervals, and (iii) power limit read/write for energy-aware scheduling. This would move the GB10 from LIMITED to MEASURED in our grading framework and make it the first ARM desktop AI platform with research-grade energy attribution—a competitive advantage for the scientific community NVIDIA is targeting with DGX Spark.
Deepak Panigrahy and Aakash Tyagi
9
Discussion
A systemic, not product-specific, gap. While we audit the GB10, the energy observability gap spans the ARM ecosystem. Apple’s M-series SoCs contain per-core power monitors accessible only to macOS kernel extensions with no public userspace API. Qualcomm’s Snapdragon platforms expose some power rail data on select development boards but not on commercial devices. Ampere’s Altra server CPUs provide per-socket power via BMC/IPMI — a datacenter interface — but no per-domain breakdown accessible from userspace. The common pattern across ARM SoC vendors is that energy monitoring is implemented for internal firmware use (thermal management, DVFS) but is not exposed as a userspaceaccessible measurement interface. The GB10 is a case of this broader pattern made particularly visible by the contrast with NVIDIA’s own Jetson Orin platform, which includes INA3221 board monitors providing per-rail energy to userspace. The edge paradox. Edge AI is motivated partly by energy efficiency — reducing data-center load and network transfer energy by running inference locally. But the hardware enabling this shift simultaneously removes the measurement infrastructure needed to verify the energy savings. An organization migrating agentic workloads from cloud (where power is metered per rack, per server, per VM) to edge GB10 devices loses all direct energy visibility for the CPU-bound orchestration that dominates cost. Regulatory exposure. The EU AI Act’s [10] energy documentation requirements (Annex XI, Section 1(e)) currently apply to GPAI model providers — organizations placing general-purpose AI models into service — not directly to edge hardware manufacturers or organizations deploying pre-existing models on edge devices. The practical consequence, however, is clear: organizations subject to Annex XI who deploy GPAI-class models on edge hardware must be able to document energy consumption. Hardware that cannot produce per-system energy data from software-accessible interfaces creates a documentation methodology gap, even if it does not itself constitute regulatory non-compliance. As the EU Commission develops harmonized standards under Article 40 (with a first progress report due August 2, 2028 ), and as California’s SB 253 Scope 1–3 [9] reporting obligations mature, the pressure to instrument edge deployments for energy will increase. The gap we document is therefore a present barrier to a near-certain future requirement. Remediability. The central constructive finding of this paper is that this gap is fixable without hardware changes. Exposing the PMIC’s existing current-sensed data through SCMI powercap requires only a firmware update — no board redesign, no additional components. The community spark_hwmon driver demonstrates that the underlying data is accessible via undocumented ACPI, confirming the firmware infrastructure exists. The Linux kernel is being prepared to consume SCMI energy data. The remaining decision is a firmware enablement choice by NVIDIA and MediaTek. Further, it will be productive for energy benchmarks such as ML.ENERGY [7] and Zeus [8] to not silently fall back to TDP estimates when real counters are missing—they should flag the gap explicitly so the community can see the scale of the problem. We propose this change constructively and note that it would make
the GB10 the first ARM desktop AI platform with research-grade energy attribution — a competitive advantage for the scientific community NVIDIA is explicitly targeting with DGX Spark. Limitations. Our audit covers one GB10-based system (ASUS Ascent GX10, firmware GX10DGX.0104.2026.0326.1657, kernel 6.17.01018-nvidia). The DGX Spark, Dell ProMax, and HP ZGX Nano use the same SoC but different board designs; INA monitor population may differ, and our I2C scan result (zero devices) is board-specific. We did not have access to the NVIDIA DGX Spark for comparative audit. Our SCMI findings reflect the specific firmware version tested; future firmware updates could enable powercap support without hardware changes, in which case the platform would move from LIMITED to MEASURED in our grading framework. The community spark_hwmon demonstrates that per-rail energy data is accessible via ACPI reverse-engineering, but we did not independently validate the DSM call semantics, accumulator resolution, or update rate on our unit. The driver uses an undocumented interface with a placeholder UUID and is explicitly unsupported by NVIDIA; it cannot serve as a foundation for reproducible research infrastructure. Characterizing the SPBM interface through firstparty DSM invocation traces is identified as essential follow-on work. We did not conduct a validation experiment for the proposed interim calibration bridge. An empirical bound — comparing external DC meter readings against NVML-subtracted estimates across controlled workloads — is needed to establish the bridge’s practical utility and error characteristics. We commit to providing this as supplementary material if accepted, and recommend it as a standard validation step for any researcher implementing the bridge methodology. Finally, the cross-device generalizability of our audit results is limited to what can be inferred from the shared SoC. We encourage researchers with access to DGX Spark, Dell ProMax, or HP ZGX Nano units to replicate the described interface enumeration and report results, enabling a cross-OEM comparison of energy observability across the GB10 hardware family.
Acknowledgments This work builds on the A-LEMS framework and EpG/OOI metrics described in [1]. Hardware audit conducted on the ASUS Ascent GX10, May 2026.
References [1] D. Panigrahy and A. Tyagi. Energy per Successful Goal: Goal-Level Energy Accounting for Agentic AI Systems. arXiv preprint arXiv:2605.22883, May 2026. [2] NVIDIA. NVIDIA Puts Grace Blackwell on Every Desk and at Every AI Developer’s Fingertips. NVIDIA Newsroom, January 2025. https://nvidianews.nvidia.com/news/nvidia-puts-grace-blackwell-on-everydesk-and-at-every-ai-developers-fingertips [3] K. N. Khan, M. Hirki, T. Niemi, J. K. Nurminen, and Z. Ou. RAPL in Action: Experiences in Using RAPL for Power Measurements. ACM Transactions on Modeling and Performance Evaluation of Computing Systems, 3(2):1–26, 2018. [4] Arm Ltd. System Control and Management Interface (SCMI) Platform Design Document. https://developer.arm.com/Architectures/System%20Control% 20and%20Management%20Interface, 2024. [5] P. Radford. [PATCH v3 9/9] firmware: arm_scmi: add Powercap MAI get/set support. Linux Kernel Mailing List, February 2026. [6] P. Radford. [PATCH v4 03/11] firmware: arm_scmi: Add SCMIv4.0 Powercap basic support. Linux Kernel Mailing List, April 2026.
The Energy Blind Spot: NVIDIA’s Flagship Edge AI Hardware Cannot Support Process-Level Energy Attribution [7] J. Chung, T. Kim, and M. Jeon. ML.ENERGY: Holistic Energy Benchmarking for Machine Learning Systems. NeurIPS, 2025. [8] J. You, J.-W. Chung, and M. Jeon. Zeus: Understanding and Optimizing GPU Energy Consumption of DNN Training. NSDI, 2023. [9] Schneider Electric. AI and the Coming Electricity Demand Surge: A New Era for Energy Management. Schneider Electric Research Report, 2025. [10] European Parliament and Council of the European Union. Regulation (EU) 2024/1689 (AI Act). Official Journal of the European Union, August 2024. [11] NVIDIA Developer Forums. How to Enable Grace CPU Power Telemetry on DGX Spark (GB10)? https://forums.developer.nvidia.com/t/help-needed-how-toenable-grace-cpu-power-telemetry-on-dgx-spark-gb10/360631, February 2026.
[12] A. Kapenekakis. spark_hwmon: Linux hwmon Driver for NVIDIA DGX Spark (GB10 SoC) Power Telemetry. https://github.com/antheas/spark_hwmon, February 2026. [13] InsiderLLM. GB10 Boxes Compared: DGX Spark vs Dell vs ASUS vs MSI. https: //insiderllm.com/guides/gb10-boxes-compared/, February 2026. [14] R. Rajat, S. Singh, et al. A CPU-Centric Perspective on Agentic AI. arXiv preprint arXiv:2511.00739, November 2025. [15] M. Walker, S. Bischoff, S. Diestelhorst, G. Sherwood, and G. Riley. Hardware Validated CPU Performance and Energy Modelling on ARM. IEEE ISPASS, 2017. [16] A. Rehman, A. Fuerst, and P. Sharma. FaasMeter: Energy-First Serverless Computing. arXiv preprint arXiv:2408.06130, August 2024.