49W Average Hid a 338W Burst on Gemma 26B
Gemma 4 26B Q4_K_M averaged 49 W on a long RTX 5090 run and peaked at 338 W. Keep both watt numbers before you compute energy per token.
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.
| Workload | Input | Output | Output rate | Watts avg / max |
|---|---|---|---|---|
| short-gen-256 | 53 | 256 | 198.81 tok/s | 43 / 187 |
| long-context-summarize | 4,470 | 128 | 180.18 tok/s | 49 / 338 |
| agent-code-task-512 | 76 | 512 | 207.41 tok/s | 48 / 320 |
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:
- The sensor (
nvidia-smi power.draw, wall meter, or other). - The sample interval.
- 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:
Copy-ready prompt
Paste the exact block into your coding agent.
No article chrome, no footnotes, no formatting drift.
This prompt and every other one we publish live in the free prompt library.
Copy the block above.
Get the next measured local AI build note from The 5090 Reports.
Get the Local AI Field Kit
Four copy-ready tools now, then one evidence-backed Local AI Lab Note on Friday when there is something worth sharing.
Get the requested artifact now, then at most one evidence-backed Local AI Lab Note on Friday when there is something worth sharing. One-click unsubscribe. No sponsored placements. Privacy.
Patrick Hughes
Building BMD HODL — a one-person AI-operated holding company. Nashville, Tennessee. Twenty-Two agents.
More writing
- 5 min
How to Calculate Local LLM Energy per Token
My RTX 5090 test shows how watts and output rate become joules per token, and why the faster of two matched settings can waste energy.
- 4 min
Why a Failed Local LLM Benchmark Row Still Matters
A failed local LLM row marks the test boundary. My RTX 5090 report shows why quality, speed, and settings belong in one receipt.
- 5 min
My local LLM eval hid four token caps
My 5090-rig eval uses four output caps: 50, 180, 192, and 256 tokens. A score without the cap is not a model result. Record the cap on every row.
- 5 min
The 26B Model Hit the Cap. The 8B Finished.
Same code task, same 512-token cap. Ollama's done_reason showed one local model finished and one got cut off. Tokens per second hid it.
- 5 min
How I Benchmark Local LLMs Before I Trust Them
A local LLM benchmark should end with a decision. I record task quality, tokens per second, VRAM, power, and failure state before I add a model.