Choose the unit of useful work
Start with the output the application needs: a processed image, a completed request or a period of monitored operation. Fix the relevant quality and response requirements before comparing energy. A run that stops early or produces unusable output is not equivalent to one that completes the job. Keep failed requests visible in the result instead of allowing them to make the device appear economical.
Draw the measurement boundary
State whether the reading covers the board input, an entire mains supply or a larger assembly with storage and peripherals. NVIDIA’s platform documentation describes device power and operating telemetry, but a software power reading and a meter around the complete system answer different questions. Pick the boundary that matches the decision, then use it consistently across the configurations being compared.
Account for time
Power describes a rate; energy accumulates over a period. Record when the task begins and ends and integrate power over that interval using the measurement equipment’s capabilities. A lower instantaneous reading can accompany a longer run. Keep the complete power trace where possible so a reviewer can distinguish startup, sustained work and the return to idle rather than trusting an unexplained average.
Declare the idle policy
An always-on camera and an assistant used occasionally have different duty cycles. Report task energy separately from the time the system waits for work, then state how a deployment estimate combines them. Do not subtract idle consumption silently. If an alternative can sleep between jobs, include the cost and delay of waking it under a comparable service requirement. The workload schedule belongs with the estimate.
Compare within the service requirement
Repeat the same task with the same input and retain completion times, errors and energy observations. A more restrictive power mode may be suitable if it still meets the response target, while a faster mode may reduce active time. Neither outcome should be assumed from a mode label. The result should explain which configuration meets the application’s requirement at the measured boundary and under the stated arrival pattern.
Sources & publication notes
Retrospective period: January 2026. Written and published November 2, 2026. Product announcements establish release timing; support pages are linked as current references.