You see two claims about an AI service: one gives watts, another gives joules per request. They may both describe something useful, but they do not answer the same question. Watts describe how quickly energy is being used. Joules describe an amount of energy. Dividing that amount by a count of requests adds a third choice: what work was counted.

We will follow an invented thirty-second run through those choices. Its complete IT equipment boundary uses 4,000 joules while completing four requests. Acceptance here means that all three requested fields are present; three results are assigned that outcome. The run is stipulated to produce 200 output tokens. These are teaching inputs, not inspected outputs or measurements from a model or a service. We have not run an AI workload, installed an energy tracker or measured a computer for this article.

The goal is to make an energy claim readable. A useful account explains the equipment boundary, time interval, counting unit and any estimates added afterwards. The Software Carbon Intensity specification organizes its own calculation around a defined system boundary and functional unit. [1] We will use those distinctions without presenting our small electricity example as a complete software carbon assessment.

Separate power P, energy E and normalized energy E/R. Power has dimensions of energy per time; integrating it over a defined interval yields energy. Dividing by a functional count R then produces a rate per unit of work. A watt figure, a joule figure and a joule-per-request figure cannot be ranked as though they were measurements of one quantity.

Our original construction stipulates a complete IT boundary, a thirty-second interval, four completed requests, three accepted results and 200 generated output tokens. Acceptance means that all three requested fields are present, without asserting their correctness. A piecewise-constant power trace will yield E=4,000 J. Acceptance labels and token counts are assumed, not obtained from output inspection, model evaluation or tokenization. All calculations are exact arithmetic over invented inputs; no model, provider, hardware meter or energy-tracking library was executed.

The reporting problem is to preserve the definitions through each transformation. The inspected SCI specification, version 1.1.0, separates boundary selection, quantification method and functional unit [1]. We borrow that accounting discipline while keeping our scope narrower. The construction will produce energy and an illustrative operational-emissions calculation; it will not establish the complete boundary or embodied-emissions term required for a full SCI result.

Start by drawing the boundary around the equipment being counted. A reading from a graphics board is not automatically the energy used by the entire computer. The processor, memory, storage, fans and power supply may sit partly or wholly outside that reading. Adding a cooling estimate later also does not repair an unexplained gap in the original equipment count.

CodeCarbon's accuracy documentation describes its CPU, GPU and RAM measurements or estimates and identifies components that it does not separately cover. It also distinguishes those figures from a whole-machine wall reading. [3] As a separate historical example, MLCommons' published Inference v2.0 power rules define system-level measurement at the wall and include components affected by the workload. [5] That document illustrates a boundary choice; this article is not a current benchmark submission guide or an MLPerf result.

For our arithmetic, the 4,000 joules are stipulated to cover the complete IT equipment boundary for the run, before facility overhead. They are not a GPU counter value relabelled as a complete computer. If a real report only has a board measurement, retain that narrower label. A smaller measured boundary can produce a smaller number even when nothing became more efficient.

Define the measured or estimated set of components before comparing totals. Board telemetry, processor-package counters, a server's AC input and an allocated facility total describe different boundaries. Their values may overlap or omit components; summing them without a component map can therefore double-count energy or leave a gap. The location of a sensor is part of the result's meaning.

The inspected CodeCarbon accuracy page scopes its reporting to CPU, GPU and RAM that it can measure or estimate, and distinguishes this from a full wall-socket validation [3]. The retained MLCommons document explicitly labels itself Inference v2.0 and specifies wall-level system power, including workload-affected components [5]. We use it as a documented historical example of a broader boundary, not as evidence of current submission requirements or certification of our construction.

Here E_IT=4,000 J is an assumption about the entire defined IT equipment boundary over the same thirty seconds. It is not inferred from component telemetry. A later PUE calculation will extend that stipulated boundary to facility energy under another explicit assumption. In a real comparison, a GPU-only number and an AC-input number need boundary reconciliation before their difference can support an efficiency claim.

Imagine that power stays at 100 watts for the first ten seconds, 180 watts for the next ten and 120 watts for the final ten. These are complete constant-power intervals in our invented trace, not three isolated readings whose behavior in between is unknown. Multiplying each power by its ten-second duration gives 1,000, 1,800 and 1,200 joules.

The total is 4,000 joules. Across thirty seconds, that corresponds to an average power of about 133.3 watts. The same energy is 4,000 divided by 3,600, or about 1.111 watt-hours. In kilowatt-hours it is exactly 1/900, approximately 0.001111. Writing the unit at every stage helps prevent a thousandfold mistake when moving between watts and kilowatts.

Now compare two shortcuts. Extending only the middle 180-watt reading across the whole run gives 5,400 joules. Extending only the last 120-watt reading gives 3,600 joules. Both differ from the defined trace because they replace its changing power with a different assumption. This does not tell us the error of a particular commercial meter. It shows why an energy claim needs to explain how power readings represent the full time interval.

For a piecewise-constant trace, E=Σ P_i Δt_i. Choose three adjacent ten-second intervals with powers (100,180,120) W. The interval energies are (1,000,1,800,1,200) J, so E=4,000 J and the time-weighted mean is E/30 s=400/3 W. The constant-within-interval assumption is essential: three instantaneous samples alone would not uniquely specify this integral.

Using 1 Wh=3,600 J and 1 kWh=3,600,000 J gives E=10/9 Wh=1/900 kWh. We retain the exact fractions until display rounding. Power integration is also the conceptual calculation described in the tracking methodology [2], but the numbers here are independently constructed and do not reproduce a tracker output or imply its sampling accuracy.

Two deliberately substituted traces demonstrate the consequence of extrapolation. Holding 180 W for all thirty seconds gives 5,400 J; holding 120 W gives 3,600 J. These are exact energies of different assumed traces, not confidence limits around the original 4,000 J. Real integration needs documented sample semantics, timestamps and treatment of the interval boundaries. A printed mean or final reading is insufficient unless its averaging interval and relation to the measured workload are known.

An energy counter that accumulates between reads can preserve activity that happened between those reads. A few snapshots of power or processor load tell a different story: they need a rule for estimating what happened during the gaps. CodeCarbon's accuracy discussion explicitly separates its energy-counter paths from sampled estimation paths, especially for short or uneven work. [3]

That distinction changes how to read a number with many decimal places. It might come from a device counter, a model based on processor activity, or a configured constant. The methodology and output documentation describe these different origins. [2][4] Extra digits in the displayed result do not turn an estimated input into a direct measurement, and agreement with another program reading the same counter is not an independent wall-meter check.

For a real report, keep the measurement method beside the result: which component was observed, whether the value accumulated energy or sampled power, how long the run lasted, and what was estimated. If one backend is unavailable and the software uses another, record that change. Our invented trace avoids those instrument questions by declaring every interval, but it cannot tell you how accurately any device or fallback would capture a real workload.

Distinguish cumulative energy differences from numerical integration of instantaneous samples or modeled power. A valid cumulative counter can include energy consumed between polls; a sparse sampled load series may fail to represent short transients. The inspected accuracy discussion makes this distinction [3]. Neither mechanism removes the need to establish component scope, valid intervals and the instrument's own uncertainty.

CodeCarbon's documentation differentiates hardware-counter backends from load-based and constant estimates [2][4]. Its reported agreement with a second reader of the same CPU counters is not an external calibration of those counters against wall energy; the accuracy page explicitly leaves that broader validation unresolved [3]. We do not transfer one backend's observations to every processor, GPU, operating system or workload.

The proposed record therefore includes backend identity, raw quantity, integration interval, estimated components and known validation limits. A backend transition changes the evidential basis even if the output column keeps the same name and unit. Our arithmetic has no instrument uncertainty because the inputs are stipulated, not because real measurement is exact. The example validates dimensional bookkeeping and the consequences of assumptions; it supplies no empirical error bound for a tracking package.

Suppose we also choose an 80-watt baseline for the same thirty seconds and the same IT equipment boundary. That baseline corresponds to 2,400 joules. Subtracting it from the run's 4,000 joules leaves 1,600 joules, or about 0.444 watt-hours. Both numbers can be useful when their labels stay attached.

The 4,000-joule figure describes all energy inside our stated run boundary. The 1,600-joule figure describes the difference from the chosen baseline. It does not prove that cancelling one request would save that amount, or that a real computer would otherwise have spent the interval at exactly 80 watts. Those are different questions about what would happen without the workload, and our assumed baseline does not answer them.

The SCI specification includes energy associated with reserved or provisioned hardware and identifies idle infrastructure within its boundary considerations. [1] Consequently, we should not quietly replace total energy with our baseline-subtracted figure and call the result a complete SCI calculation. Publish both when the comparison needs them, state how the baseline was obtained, and compare like definitions. A report that changes its subtraction rule can appear to improve without changing the actual run.

Define a hypothetical baseline P_b=80 W over the identical thirty-second interval and equipment boundary. Then E_b=P_b T=2,400 J and ΔE=E_run−E_b=1,600 J=4/9 Wh. This is a defined arithmetic difference between two stipulated quantities. It is not an empirical estimate of the causal energy avoided by removing a request or shutting down a service.

The distinction matters for resource allocation. Reserved infrastructure may remain powered independently of one request, and a proposed alternative schedule may change duration or shared activity. Our construction models none of those counterfactuals. Calling ΔE an incremental figure must therefore include the baseline definition; it cannot silently imply that the entire difference is an observed, individually attributable saving.

SCI version 1.1.0 includes energy consumed by hardware reserved or provisioned and calls for significant supporting infrastructure within the software boundary [1]. Our baseline subtraction is a separate diagnostic calculation, not a substitute for those accounting requirements. For a before-and-after comparison, preserve the methodology and functional unit as well as the boundary. Report E_run, E_b and ΔE separately so another reader can distinguish a changed workload from a changed baseline convention.

Keep the same 4,000-joule total and divide it by four completed requests. The average is 1,000 joules per completed request. If the reporting question instead concerns the three results meeting our invented acceptance rule, the average is 4,000 divided by three, or about 1,333.3 joules per accepted result. No electricity changed between those calculations; the denominator changed.

Our stipulated 200 output tokens produce another figure: 20 joules per output token. That number is not interchangeable with either request average. State whether a token count covers generated output, supplied input or both, and which counting convention was used. Likewise, define whether requests include unsuccessful attempts, retries or work that started but did not finish. Otherwise, two identically labelled averages can count different work.

Using the chosen baseline difference instead gives 1,600 divided by four, or 400 joules per completed request above that baseline. The extra words in the label are essential. None of these averages proves that every individual request used the same energy. We know the aggregate interval and the stipulated counts, not each request's separate contribution. A quality-related denominator also needs an explicit acceptance rule, not merely the word “successful”.

Using E=4,000 J with the stipulated counts gives E/R_completed=1,000 J/request, E/R_accepted=4,000/3 J/accepted result and E/R_output=20 J/output token. These rates use one numerator with three distinct denominators. The accepted count of three is an assigned outcome under a hypothetical rule, not a measured task-quality result or a claim that token throughput measures utility.

Changing the numerator to ΔE=1,600 J yields 400 J/completed request relative to the specified baseline. The denominator alone is therefore insufficient to interpret a normalized figure. Both numerator boundary and work-count definition must accompany it. SCI likewise requires a consistent functional unit when combining component rates [1]; a request rate cannot simply be added to a token rate without an explicit conversion relating them.

For a workload report, define admission, completion, acceptance and retry handling, plus the input/output token convention and time window. Include the energy associated with the chosen window consistently rather than silently excluding failed attempts from one side of the ratio. Aggregate division allocates a mean; it does not establish a per-request energy trace or causal attribution. Shared work and unequal request sizes would need additional evidence before individual costs could be inferred.

Consider a second invented run that uses a constant 100 watts but lasts fifty seconds. Assume it completes the same four requests with the same three accepted outcomes. Its energy is 100 multiplied by fifty: 5,000 joules. That is 25 percent more than the first run, even though its average power is lower than the first run's roughly 133.3 watts.

Its average energy per completed request is 1,250 joules, compared with 1,000 in the first run. This example does not show that a particular power limit, processor or model is inefficient. We have changed the stipulated power and duration, not tested an optimization. The lesson is that a lower watt figure alone cannot establish lower energy for a completed workload.

To compare real alternatives, preserve the task and its acceptance criteria while recording the actual duration and energy boundary. Differences in input length, generated output, retries, batching or included startup work can change what was accomplished. The historical MLCommons rules also require power and performance figures from the same benchmark run, rather than combining favorable values from separate runs. [5] That is a useful reporting distinction even when your work is not a benchmark submission.

Define a second hypothetical run with P_2=100 W, T_2=50 s and the same completed and accepted counts. Then E_2=5,000 J, E_2/E_1=1.25 and E_2/R_completed=1,250 J/request. Its mean power is less than 400/3 W, but its energy is greater because the lower power persists for longer. This follows from the specified traces, not an empirical performance-power relationship.

No inference about a particular optimization follows. A hardware change could alter duration, quality, utilization and boundary conditions together. To identify an improvement, define equivalent work and compare the resulting integrated energy under disclosed conditions. Holding only the model name constant does not hold prompt lengths, output lengths, accepted outcomes or surrounding service work constant.

The inspected historical MLCommons power rules couple energy-related measurement and performance to the same run and measurement interval [5]. They provide a concrete example of why mixing the fastest duration from one run with the lowest power from another is not a measured operating point. Our pair of traces is deliberately labeled as two constructed cases. A real report should preserve paired observations and state whether initialization, waiting, retries and shared infrastructure fall inside the measured interval.

A data center also uses energy beyond its IT equipment. To illustrate the accounting, choose a power usage effectiveness value of 1.2 for our defined interval. Applied to the stipulated 4,000 joules of complete IT energy, it gives 4,800 joules of facility energy: 4,000 for IT and 800 for the associated overhead. This is an invented allocation, not a measured data-center value.

If someone then multiplies the already adjusted 4,800 joules by 1.2 again, the result becomes 5,760 joules. The second multiplication adds 960 joules that do not belong in our stated calculation. It overstates the correctly adjusted total by 20 percent. The arithmetic is straightforward; the practical difficulty is knowing whether an exported number already includes the multiplier.

CodeCarbon's inspected documentation says its energy columns already include a configured PUE. Its output page separately notes a change to reported power columns from version 3.3.1. [2][4] Check the version and column meaning before applying another adjustment. Also keep the original boundary in view: multiplying a partial GPU reading by a facility factor does not, by itself, provide the missing energy of the rest of the IT equipment.

For a compatible boundary and interval, stipulate PUE=E_facility/E_IT=1.2. With complete IT energy E_IT=4,000 J, the modeled facility allocation is E_facility=4,800 J and overhead is 800 J. The ratio is an input to this construction, not a measured value, universal constant or assertion that one facility-wide average applies unchanged to every request.

Reapplying the same factor to E_facility produces 5,760 J. Relative to the intended 4,800 J boundary, that is a 960 J excess, or 20 percent. This is double application of one adjustment, not evidence of additional cooling energy. A component-only numerator would present a separate problem: the multiplier cannot reconstruct unmeasured IT components without a justified allocation model.

The inspected CodeCarbon 3.3 documentation states that configured PUE is already included in component and total energy columns [2][4]. Its output reference specifically dates power-column scaling to version 3.3.1; we do not generalize that power behavior to earlier releases. Retain the software version, original component scope and adjustment provenance. SCI's boundary discussion includes data-center efficiency where relevant [1], but that does not authorize applying an unexplained multiplier to every quantity labeled energy.

Convert the adjusted 4,800 joules to kilowatt-hours: it is exactly 1/750 kWh. Now choose an illustrative electricity intensity of 300 grams of carbon-dioxide equivalent per kilowatt-hour. Multiplying gives 0.4 grams of electricity-related operational emissions. In kilograms, the same amount is 0.0004, not 0.4. Keep the unit conversion visible.

If the assumed intensity were 600 grams per kilowatt-hour instead, the estimated operational emissions would be 0.8 grams for the same energy. The computer did not become more energy hungry in that calculation. We changed the emissions factor attached to its electricity. Neither intensity is offered as the current value for a country, cloud region or electricity supplier.

Dividing the first operational estimate by four completed requests gives 0.1 grams per completed request for this chosen boundary. It remains an illustrative operational figure. A real calculation should identify the intensity source, location, time basis and whether it uses an average or another defined measure. The SCI specification makes electricity intensity a separate input [1]; an energy reading alone cannot supply that information or describe the emissions from manufacturing the hardware.

Use consistent units in O=E×I. Our modeled facility energy is E=4,800/3,600,000=1/750 kWh. With a stipulated constant I=300 gCO₂e/kWh, O=0.4 gCO₂e=0.0004 kgCO₂e. A kilogram output requires the grams-to-kilograms conversion; the dimensional calculation, rather than an ambiguous displayed label, determines the unit.

Changing only I to 600 gCO₂e/kWh gives O=0.8 gCO₂e while E remains unchanged. These factors are invented values for illustrating sensitivity, not regional observations. If intensity varies over a real interval, the calculation needs an appropriately matched treatment of energy and intensity rather than an unexplained arithmetic average. Record the temporal and geographic basis and the selected intensity methodology.

For the first factor, O/R_completed=0.1 gCO₂e/request. The operational quantity is narrower than a full software carbon-intensity result. SCI version 1.1.0 distinguishes electricity-related operational emissions from allocated embodied emissions and specifies the intensity unit [1]. Our calculation follows that dimensional distinction without claiming that the factor is measured, that all system components have been assessed, or that this per-request average predicts the marginal emissions caused by one additional request.

Computing equipment also has emissions associated with its creation and disposal. The SCI specification treats the allocated share of those embodied emissions separately from electricity-related emissions. [1] We have supplied no device lifecycle assessment, expected service life or resource-allocation record for our imaginary equipment, so that share is unknown here.

This matters when naming the result. The specification's structure combines operational emissions and allocated embodied emissions before expressing the result per functional unit. We can calculate our illustrative operational part, but we cannot fill the missing embodied term with zero just because the necessary information is absent. Doing so would change an incomplete assessment into a falsely complete-looking one.

The same care applies to the broader system boundary. A short inference interval does not automatically cover training, storage, networking, service support or end-user equipment. Decide which significant components belong in the stated assessment and explain the treatment of each. A clearly bounded operational example can teach useful arithmetic. It should keep that name rather than claim to be the total environmental footprint of an AI model or the complete consequence of a user's request.

The inspected SCI specification defines M as the embodied emissions allocated to the software, with time-share and resource-share contributing to that allocation [1]. It requires an estimate for hardware within the software boundary. Our construction provides neither device lifecycle emissions nor the lifetime and reservation data needed to determine that allocation, so M remains unknown.

The conceptual rate is (O+M)/R, with O=E×I. Because only the illustrative operational term is available, reporting O/R does not establish the complete rate. Setting M=0 would be an additional unsupported assumption, not a neutral representation of missing data. The output should identify the known term, the unresolved term and the boundary for which those statements apply.

Boundary completeness is independent of numerical precision. An exactly calculated thirty-second IT/facility example does not automatically include training, networking, storage, monitoring or end-user equipment relevant to a broader software assessment. SCI's boundary provisions address significant supporting systems [1]. We have not audited those components or made a lifecycle claim. A narrower operational calculation may still be useful, provided its label and limitations survive when the value is copied into a chart, comparison or per-request headline.

Imagine receiving only the number “400 joules per request”. In our example, that refers to a baseline-subtracted total divided by completed requests. The gross figure for the same run is 1,000 joules per completed request, while the gross figure per accepted result is about 1,333.3. Without the definitions, a reader could mistake changes in accounting for changes in the machine.

A useful comparison record therefore travels with the number. It describes the task and acceptance rule, the equipment included, the measurement or estimation method, the time window, energy units and work count. It then names the baseline, facility factor and electricity-intensity assumptions, stating which adjustments are already present. If hardware-related emissions or significant system components are unresolved, the record says so.

Finally, retain totals as well as averages. A lower energy-per-request value does not by itself establish a lower total if the amount of work changes. Our calculations answer a precise reading question: why two plausible-looking AI energy numbers can disagree. To decide whether a real change is better, first make the boundaries and work definitions comparable, then inspect the paired measurements and their limitations. A familiar model name and a smaller headline number cannot do that work for you.

The value 400 J/request is recoverable here only as ΔE/R_completed under the stated 80 W baseline. It is not E/R_completed and not E/R_accepted. Preserving numerator provenance and denominator semantics prevents an accounting change from masquerading as an improvement in the underlying workload. These are different metrics of one construction, not conflicting instrument readings.

For a reproducible comparison, retain workload identity and acceptance criteria; component boundary and shared-resource allocation; backend and integration method; interval definition; raw energy and units; completed, accepted and token counts; and each subsequent adjustment. Record the baseline separately and identify whether PUE is already included. Attach the electricity-factor basis and distinguish unknown embodied emissions from an assumed zero. The original specification's baseline comparison requires a consistent methodology [1]; our proposed record makes that consistency inspectable.

Report aggregate energy alongside normalized rates. A rate reduction does not determine a total reduction without the corresponding workload count and boundary. Our exact arithmetic establishes only the relationships among the chosen inputs. It does not measure a named model's efficiency, establish an instrument's accuracy or predict system-wide emissions changes. Those questions require matched evidence. The practical reading skill is to identify what each figure measures before asking which one is smaller.