# The bench record, in short

The workshop's own working records for this run are two long internal documents.
They are not in this kit: they name machines, addresses and directories that do
not belong on a public page, and rewriting them line by line would have produced
a document nobody wrote. This file is the measurement record instead — every
number the exhibit rests on, with the directory in this kit it comes out of, and
nothing else.

**One card. One day: 2026-08-25. Two power limits: the card's 600 W default, and
450 W.** Twelve rungs, all in `rungs/`. Everything was measured through one
harness against one frozen prompt (`p512`, sha256 `90eedd0c…`), temperature 0,
fixed seed. **4,044 scored requests, 0 failed** — sum `requests_ok` and
`requests_failed` across the twelve `summary.json` files, or count the lines of
the twelve `raw.jsonl` files.

---

## 1. What was varied, and what was not

The card's board power limit was moved between 600 W (its default — nothing
changed) and 450 W. **Nothing else changed**: same prompt, same seed, same
models, same daemon, same card, same day. Two serving stacks were measured:

| lane | what it is | rungs |
|---|---|---|
| **dense** | a 24B dense model at Q4, one request at a time (the daemon's parallel-request setting is 1; its context window 32768) — the seat that reads what people write | `ollama-q4-mistral-{600W,450W}-p512-c{1,16}` |
| **sparse** | a 26B mixture-of-experts model at FP8, served with real batching — the seat that answers a walker's question | `vllm-fp8-gemma-*` |

The sparse lane's sustained probe was **interleaved** — 600, 450, 600, 450 — so
the same cell at the same limit was measured twice and the pair could be
published as an explicit noise floor (`noise-floor.md`). The dense lane was
measured **once** at each limit; it has no same-cap repeat, and its verdict
therefore borrows the sparse lane's floor.

## 2. The measurements

Busy-window means: only the `power.csv` samples where the card reported
**≥ 50 % utilisation**, windowed to each rung's own `started_utc`/`ended_utc`.

| | 600 W | 450 W | change |
|---|---|---|---|
| dense, tokens/s per stream (c=16, p50) | 94.64 | 92.74 | **−2.0 %** |
| dense, busy-mean draw | 586.53 W (n=266) | 448.44 W (n=271) | **−138.09 W** |
| dense, peak temperature | 83 °C | 72 °C | **−11 °C** |
| dense, tokens/s per watt | 0.1614 | 0.2068 | **+28.1 %** |
| dense, time-to-first-token (c=1, p50) | 20.6 ms | 22.2 ms | +7.8 % |
| dense, time-to-first-token (c=16, p50) | 21.7 s | 22.1 s | queueing behind the daemon's parallel-request setting of 1, not the cap |
| sparse, tokens/s per stream (sustained, mean of both repeats) | 170.24 | 170.09 | **−0.09 % — inside the floor** |
| sparse, aggregate tokens/s | — | — | −1.5 %, inside the 1.0–1.8 % repeat band: **not a result** |

The dense lane gave up **18.7 % of its clock** (busy-window mean 2763.6 MHz at
600 W; 2137–2400 MHz while the limit was actually biting) to lose **2.0 %** of
its speed. Q4 decoding spends most of each token waiting on memory, so a slower
clock costs little.

## 3. The instrument finding, with the count corrected

The card exposes two ways to answer "was this run power-limited?" — a live
**flag** and a cumulative **counter**. On this driver generation they disagreed,
and only one of them was telling the truth.

**The flag worked.** Windowing every rung's `throttle.csv` to that rung's own
`started_utc`/`ended_utc`:

| rung | flag Active / in-window samples |
|---|---|
| `ollama-q4-mistral-450W-p512-c16` | **119 / 275 (43.3 %)** — the one clamped rung |
| `ollama-q4-mistral-450W-p512-c1` | **1 / 24** — the same lane brushing the ceiling |
| `ollama-q4-mistral-600W-p512-c1` | 0 / 25 |
| `ollama-q4-mistral-600W-p512-c16` | 0 / 269 |
| the eight sparse rungs (4 burst + 4 sustained) | 0 / 12, 0 / 17, 0 / 13, 0 / 16, 0 / 210, 0 / 213, 0 / 205, 0 / 209 |

**Ten rungs read zero, one read once in twenty-four, one read 119 in 275.** The
flag discriminated correctly in both directions. Two corrections are folded into
that table and stated here rather than left in a working file: the `1 / 24` was
dropped from an earlier draft of the exhibit, which claimed zero on all eleven
un-clamped rungs; and the working record called the sparse rungs "six" when there
are **eight** (four burst, four sustained).

**The counter failed.** `clocks_event_reasons_counters.sw_power_cap` did not
advance one microsecond through roughly sixty seconds of flagged clamping —
**12 rungs of 12, delta 0 µs**, frozen at 6,584,407 µs (`throttle-delta.json` in
every rung directory records the same pre and post). It is not permanently dead:
the streams in this kit run well past the bench, and the counter resumes at
**2026-08-25T20:05:03.992Z**, reaching 230,454,492 µs by 21:35Z. That resume is
in the `throttle.csv` files themselves, so it can be checked rather than taken on
trust.

The practical rule the run produced: **a zero flag is evidence; a zero counter is
not.**

## 4. Two things not to do with these numbers

**Do not diff the `reference/` power columns against the `rungs/` power columns.**
The morning serving bench sampled power over a whole arm × prompt invocation
covering its entire c = 1, 4, 8, 16 ladder, so its `W mean`, `W busy`, `W peak`
and `T peak` repeat across its four rungs. Arm P gives every rung its own window.
The throughput and latency columns are directly comparable; the power columns are
the same quantity measured over a different window. Only the 600 W vs 450 W
comparison inside `rungs/`, where both legs use identical windows, is a
like-for-like watt comparison.

**Do not read the burst rungs as power results.** Seven to nine seconds of card
time is too short to resolve a power effect. Their own c=16 pair differs by 9.1 %
with *identical* SM clocks at both limits and neither leg reaching 450 W.

## 5. What was not pristine, and is named

**The machine driving the requests was not a clean room, and was not made into
one.** Through most of the window another session's **CPU** inference bench was
running on that same machine, holding roughly 379 % of its 24 cores; between the
two dense legs a browser spike briefly took its load average to 13.3. Neither
touched the card under test — that work never used a GPU at all — but both
competed for the threads the harness used to *send* requests and read replies.

So: **client-measured latency carries that caveat; the card's clocks, watts and
temperatures do not.** Time-to-first-token is measured on the sending side and is
the number to distrust. Every wattage, clock and temperature in `power.csv` and
`throttle.csv` is read from the card itself and is unaffected.

It was left running rather than killed. Ending another lane's evidence run to
tidy up this one's error bars is not a trade that gets made quietly.

The same client-side scheduling is the best explanation for the burst rungs' 9.1 %
spread: the 450 W burst leg logged two busy samples at 51 % and 81 % utilisation
against the 600 W leg's one at 93 %. Gaps like that stretch wall-clock time and
depress an aggregate without any clock moving.

## 6. What this kit cannot tell you

The dense lane has no same-cap repeat. The sparse lane was never at the ceiling,
so its "no measurable change" is a statement about a lane with headroom, not a
claim that caps are free. One card, one day, one prompt, two limits. The
24 GB-class sibling arm is not measured here.