clm-0041

The KV dequant patch cuts energy 42% at 200k context — 146.1 Wh unpatched against 85.3 Wh patched for the same throughput benchmark — and patched q8_0 (85.3 Wh) beats f16 (89.6 Wh). That INVERTS clm-0040's agentic finding, and both are correct: on fixed-token throughput work quantised KV wins once patched, while on agentic work it loses because it spends extra TURNS. The workload decides, not the flag.

Wall energy from `sensor.hardware_ai_hydra_energy`, a cumulative kWh counter at ~10s resolution, differenced across each benchmark invocation's window. Units Wh / pence. ## The 200k-context comparison Four invocations of the same deep-context benchmark, Aug 8, differing only in build and KV type: | build + KV | wall time | **Wh** | mean W | pence | |---|---|---|---|---| | stock q8_0 | 51 min | **146.08** | 171.7 | 4.43 p | | **kvfix q8_0** | 29 min | **85.25** | 178.5 | 2.58 p | | stock f16 | 30 min | 89.55 | 177.7 | 2.71 p | | kvfix f16 | 31 min | 90.43 | 177.7 | 2.74 p | Note the mechanism: power draw is essentially identical across all four (172-179 W). The energy difference is **entirely wall time**. The patch does not make the machine sip less; it makes it finish sooner. That is `clm-0022`'s +70.3% decode recovery, expressed in the unit that appears on a bill. **Patched q8_0 is now the cheapest option at depth** — 85.3 Wh against f16's 89.6 Wh — so once the patch is applied, quantised KV saves both memory and electricity on this workload. ## ⚑ This inverts clm-0040, and both results stand `clm-0040` found q8_0 costs **48% MORE** energy per correct answer on τ² agentic tasks. This claim finds it costs **42% LESS** on a throughput benchmark. Not a contradiction — they measure different workloads: · **Throughput work** processes a FIXED token count. Faster decode means less wall time means less energy. Quantised KV wins once the dequant path is fixed. · **Agentic work** has a VARIABLE turn count. `clm-0038` measured q8_0 taking +39% more turns on paired tasks, so it does more total work — and the extra work outweighs any per-token saving. So the correct statement is not "q8_0 is efficient" or "q8_0 is wasteful", it is: **q8_0 is efficient per token and can be wasteful per task, and which dominates depends on whether the workload's length is fixed or emergent.** A benchmark that only measured tok/s would have reported the first half and missed the second entirely. ⚠ The agentic measurement (clm-0040) was on the STOCK build. Whether patched q8_0 also recovers the agentic energy penalty is untested — the turn inflation may or may not be a consequence of the same broken dequant path. That is the obvious next run. ## Method and provenance Windows are **RECONSTRUCTED, not recorded**: each llama-bench invocation wrote a JSON whose mtime is that invocation's end, so the window is [previous end, this end]. Run records only ever stored a `date`, never timestamps — the gap this exercise exposed. · Windows include model load time, which is part of the cost but not part of inference. · Where invocations are separated by more than an hour, a 5-minute lead-in is assumed rather than attributing hours of idle to a run. · One artefact is visible and left in deliberately: `deepkv200-080145/stock-q8_0` reads 0.84 Wh at 10.1 W — exactly the idle floor, i.e. an aborted run. Reconstruction that surfaces its own failures is worth more than one that hides them. · Peak draw is remarkably consistent across every benchmark on this box: 205-215 W.

Note — the record's own working

Cited by — computed at build time, never stored