49W Average Hid a 338W Burst on Gemma 26B

A 49-watt average on my RTX 5090 looked cheap. The same Gemma 4 26B Q4_K_M run peaked at 338 watts.

The short answer: Keep GPU watts average and GPU watts max on the same row. I only divide watts by output tokens per second after I name the sample window. Naive math on this long-context run gives 0.272 joules per output token from the average and 1.876 from the max. Those are not two valid answers. They are one missing window.

Canonical URL: https://bmdpat.com/blog/local-llm-gpu-watt-avg-vs-max-2026

What did the RTX 5090 receipt record?

The August 20, 2026 5090 Report lists three gemma4:26b Q4_K_M rows from Ollama 0.31.1. Each note stores watts avg/max during the run.

The long-context row is the loud one. Average power was 49 W. Max power was 338 W. That is a 6.9x gap on one run of one Q4_K_M file.

nvidia-smi reports power.draw as a sampled GPU power reading, not as wall power for the whole PC. I treat it that way. The receipt does not name the sample interval. It also does not say whether idle samples sat in the average.

Why is the average a weak energy input?

On August 24, 2026 I showed how to turn a generation-phase average into joules per output token. Divide watts by output tokens per second. On a different workshop row, num_batch=256 used 187.6 W at 215.7 tok/s, or about 0.870 J per output token. That write-up is How to Calculate Local LLM Energy per Token.

The formula still needs a named window. If I plug the long-context average into the same formula, 49 / 180.18 = 0.272. If I plug the max into it, 338 / 180.18 = 1.876. I round those to three decimal places only for the table. I do not keep either number as the energy result for that row.

The 0.272 figure is 3.2x lower than the workshop 0.870 figure. The 1.876 figure is 2.2x higher. Same GPU. Same 26B class. Different watt windows. A ranking built from those mixed averages would pick a winner for the wrong reason.

How should I use the max reading?

Max power is a burst flag. It is not a substitute average.

338 W on a 575 W card is a real spike. It is not a 49 W workload. I keep the max so a later reader can see that the GPU left the low-power band. I still need a generation-phase average before I compute joules per output token.

The short-gen row shows the same split at a smaller scale: 43 W average, 187 W max, 198.81 tok/s. The agent-code row recorded 48 W average and 320 W max at 207.41 tok/s. Across these three Q4_K_M rows, the average stayed in a 43-49 W band while the max moved from 187 W to 338 W.

I do not know the cause from this receipt. Prompt work, decode work, and idle samples can share one "during run" average. The input and output benchmark split already treats those phases as separate clocks. Power needs the same split.

What belongs in the next power receipt?

Keep the raw pair. Save watts average and watts max. Save the model, quant, runtime, GPU, workload, context, input tokens, output tokens, and output rate. Then name three more fields:

1. The sensor (nvidia-smi power.draw, wall meter, or other).
2. The sample interval.
3. The phase covered (full request, prompt eval only, or generation only).

If any of those three is missing, I can still compare speed and VRAM. I cannot compare energy per token with a row that named the window.

My earlier power-data note argued that speed without watts hides operating cost. This row adds the next trap: watts without a window hides the burst.

For this long-context Gemma run, I keep 49 W and 338 W together. I do not publish a joules-per-token winner from them. The next useful experiment is a generation-only average on the same prompt, with the sample interval written on the row.

Accompanying prompt

What the prompt does: It checks whether a local LLM power row has a named watt window before anyone computes energy per token.

Copy/paste this prompt:

Role:
You are a local LLM power-receipt reviewer.

Context:
I will give you benchmark rows with model, quant, runtime, GPU,
workload, token counts, output rate, watts average, watts max,
and any sample-window notes.

Task:
1. Keep rows that include both watts average and watts max.
2. Mark energy-per-token math as blocked when the sample interval
   or phase (full request, prompt, generation) is missing.
3. If the window is named, compute joules per output token as
   generation-phase average watts divided by output tok/s.
4. Report the avg-to-max ratio as a burst flag, not as energy.

Output:
- A table with raw watt fields and the window status.
- One line that says compute, block, or rerun.
- The missing fields needed for a valid energy figure.

Constraints:
- Do not treat GPU watts as wall power.
- Do not use watts max as the energy input.
- Do not compare energy across rows with unnamed windows.
- Keep full precision for the calculation and round only the shown result.

Copy the block above.

Get the next measured local AI build note from The 5090 Reports.

Get the local AI lab notes (benchmark rows, VRAM fit, quant choices, what runs on consumer GPUs), M-F only when there is something worth sending: https://bmdpat.com/newsletter?utm_source=blog_md&utm_medium=aeo&utm_campaign=local-llm-gpu-watt-avg-vs-max-2026

Originally published on bmdpat.com. I run a one-person AI agent company and write about what actually works.

Want these in your inbox? Subscribe to the newsletter - no spam, unsubscribe anytime.