Architect report — q2kxl-agentic

capacity — VRAM in use across the whole telemetry window against the RTX 3090's 24,576 MiB physical ceiling, with headroom shaded. CONDITIONS: RTX 3090, board memory only (dmon 'fb'); Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log, -ngl 99, -c 32,768 with 1 slot (--parallel 1), read from the server log, --parallel 1, -fa on, KV q8_0 for both K and V; workload is the aider polyglot agentic benchmark. FINDING: the footprint is 13,417 MiB median (13.10 GiB) and varies by only 240 MiB across 285 minutes, which is 1.79% of that median footprint. Capacity is committed once at load and is never managed at run time, which is what makes a board ceiling a gate rather than a budget, and it is why a memory limit here is answered with a quantisation ladder rather than with a scheduler. 10.9 GiB of headroom is left at this window. The ladder argument is measured, not arithmetic: UD-IQ4_XS at the full native 262,144-token window reached 23,821 MiB - 755 MiB from the ceiling, inside the 1,796 MiB desktop reserve, with speculation off - while UD-Q2_K_XL at 2.912 bits per weight held the same window at 22,859 MiB with speculation on. NOT MEASURED: per-process VRAM attribution, because nvidia-smi pmon reports '-' for every process under Windows WDDM; the split between weights, KV cache, CUDA context, compute buffers and the drafter cannot be read off this trace, and the figure says so on its face. The 24,576 MiB ceiling is specification; every other number on the figure is measured on this rig.

capacity — Two deliberate null results, each plotted at the scale of what that path could carry so that the emptiness is the message and not an omission. PANEL 2, PCIe: rxpci and txpci from nvidia-smi dmon, plotted against the theoretical one-direction rate of PCIe Gen4 x16 (31,508 MB/s, SPECIFICATION) so that the emptiness is legible rather than autoscaled away. Over the plotted window, combined traffic is 297 MB/s median - 0.94% of the link - and 507 MB/s at the 95th percentile, with 97.8% of samples below 1,000 MB/s. DECISION: do not spend silicon area or power widening this interconnect for local inference; it is empty precisely because the weights fit in VRAM, which is figure 1's finding seen from the other side. THE TAIL IS DISCLOSED RATHER THAN SMOOTHED: 2.2% of samples burst above 1,000 MB/s, peaking at 22,394 MB/s (71% of the link); the bursts are brief and never sustained, and their cause was NOT MEASURED, because per-process PCIe attribution does not exist under Windows WDDM and a scoring container shared the machine. BAR1 was flat at 32,739 MiB on every sample and is deliberately not interpreted, since NVML does not separate aperture from occupancy on this part. PANEL 3, host storage: disk bytes/s and pages-in converted to bytes/s using the 4 KiB Windows page, on a log axis; these are machine-wide Windows performance counters, not per-process ones. THE NULL HOLDS FOR THE INFERENCE PATH, and it is measured directly rather than assumed: board VRAM drifted by only 240 MiB across the run and PCIe stayed near the floor, so no weight was evicted and re-read. Median host disk is 146 kB/s, 89.9% of samples sit below 1 MB/s, and 2.7% read exactly zero. THE NULL DOES NOT HOLD MACHINE-WIDE, and that is a correction to the expected result rather than a footnote: 70 GB crossed the disk in this window, of which 63% is host paging - pages-in x 4 KiB tracks disk bytes at r = 0.855 - while available host RAM fell to 87 MiB. NOT MEASURED: per-process disk attribution, so that traffic is reported as host memory pressure from the co-resident scoring container and is explicitly NOT charged to inference. DECISION: storage bandwidth is not a local-inference design input once the weights are resident, but host RAM sizing is - the co-tenant that scores the run can page the machine into the ground while the board itself is untouched. INSTRUMENT NOTE: Instrument note: the host collector logs local-time epoch while the GPU collector logs UTC; the host panel is aligned to GPU telemetry by -8.0 h (residual -2 s).

cost — Prompt-heavy calls cost measured 39.9x more GPU board energy per completion token. One point per aider polyglot exercise, coloured by source language. Part: NVIDIA RTX 3090 (GA102, 24 GB GDDR6X). Workload: aider polyglot exercises, Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log on llama.cpp, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log. Attribution: each exercise owns the interval since the previous exercise finished, integrated over GPU-busy samples (SM > 5%); aider's "duration" is deliberately not used as the window because the results-file timestamp is written after the unit tests, which would bill test-time idle to the model. 222 exercises attributed, 1 dropped for having no predecessor, 0 for falling outside the telemetry trace (the GPU collector started 0 minutes after the first exercise finished) and 0 for holding no GPU-busy sample. Run mean measured 6.66 J per completion token (derived 1.85 kWh per million completion tokens); range measured 4.33 (zebra-puzzle) to measured 172.63 (crypto-square), a spread of 39.9x, correlating with the prompt:completion ratio at Pearson r = 0.14 (Spearman rho = 0.82, n = 222). NOT measured: system or wall power (this is GPU board power from NVML only, so no PSU loss, CPU, RAM or fans); per-process GPU power (nvidia-smi pmon reports "-" for every process under Windows WDDM, so board draw cannot be split between the server and anything else on the card); memory junction temperature (not exposed by NVML on this part).

cost — Joules per token is throughput restated, not an independent measurement: the board draws a measured constant 339 W and the one-parameter model fits at r2 = 0.999. Left: energy per completion token against GPU-busy seconds per completion token, one point per exercise. Mean board power per exercise varies by only measured 1.6% (coefficient of variation), so energy per token is time per token multiplied by a fixed number. Right: distribution of board power over 15360 GPU-busy telemetry samples (SM > 5%), mean measured 341 W at 4.8% coefficient of variation, with the NVML clock-limit reason over non-idle samples (SW power cap 92.8%, SW thermal 6.9%, Unconstrained 0.2%). An architect should treat energy-per-token differences on this part as throughput differences, and expect the two to decouple only on a part not pinned to its power limit. Part: NVIDIA RTX 3090 (GA102, 24 GB GDDR6X). Workload: aider polyglot exercises, Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log on llama.cpp, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log. NOT measured: system or wall power (this is GPU board power from NVML only, so no PSU loss, CPU, RAM or fans); per-process GPU power (nvidia-smi pmon reports "-" for every process under Windows WDDM, so board draw cannot be split between the server and anything else on the card); memory junction temperature (not exposed by NVML on this part).

coupling — A host at 11.1% mean CPU busy (median 11.0%) is issuing 111,153 system calls and 40,447 context switches per second, and 52% of the busy time is kernel (privileged) time. The utilisation figure and the syscall figure describe two different machines, and only the second one is a platform requirement. Stacked left axis: kernel and user time as a percentage of total logical-CPU capacity, smoothed over 27 s, with the raw 3 s total drawn over it; right axis: system-call and context-switch rates. Conditions: NVIDIA RTX 3090 (board), single card; workload is the aider polyglot agentic coding benchmark, scored in a Docker container on this same host; Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log, 9.154 GiB on disk (recorded in campaign.md at that precision); 9.8290 decimal GB (derived: 9.154 GiB × 1.073741824) — the recorded figure is the GiB value; the decimal-GB form is derived from it, and the gap between the two units is about 7 percent, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log. Host counters are machine-wide: they include llama-server, the scoring container and the WSL2 boundary together. Per-process CPU attribution was not recorded, and neither was the per-core distribution, the logical-core count, nor interrupt affinity. System and wall power were not measured anywhere in this campaign - GPU board power only. Clock domains differ: the host collector stamps local time, the GPU collectors stamp Unix epoch, so the raw series do not intersect at all. The host series is shifted by -8.00 h (-28800 s) - the half-hour offset that maximises span overlap, giving 17126 s of overlap against 15328 s for the next-best offset. No sub-hour fitting was applied.

coupling — Host system-call rate tracks GPU decode rate (Pearson r = -0.207, p < 1e-12; Spearman rho = -0.523; fit -0.5 tokens/s per extra 10,000 system calls per second), while aggregate CPU busy does not (Pearson r = +0.072, p = 1.7e-05). The utilisation number an architect would reach for carries no usable signal about the GPU. Each point is one host counter interval (about 3 s) in which every /slots sample was in the decode phase; y is the mean GPU decode rate over that interval, from n_decoded differences, so a slow request and a loaded host land on the same axis. The system-call rate was selected because its ranked correlation is the stronger of the two named candidates (3588 windows); the interrupt rate, not a candidate, was stronger still at rho -0.524. This is an association over one uncontrolled run - the controlled 5.4% decode cost of host load was measured separately in this campaign, and the GPU clock rose while it happened. Conditions: NVIDIA RTX 3090 (board), single card; aider polyglot agentic coding benchmark, scored in a Docker container on this same host; Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log, 9.154 GiB on disk (recorded in campaign.md at that precision); 9.8290 decimal GB (derived: 9.154 GiB × 1.073741824) — the recorded figure is the GiB value; the decimal-GB form is derived from it, and the gap between the two units is about 7 percent, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log. Host counters are machine-wide: they include llama-server, the scoring container and the WSL2 boundary together. Per-process CPU attribution was not recorded, and neither was the per-core distribution, the logical-core count, nor interrupt affinity. System and wall power were not measured anywhere in this campaign - GPU board power only. Clock domains differ: the host collector stamps local time, the GPU collectors stamp Unix epoch, so the raw series do not intersect at all. The host series is shifted by -8.00 h (-28800 s) - the half-hour offset that maximises span overlap, giving 17126 s of overlap against 15328 s for the next-best offset. No sub-hour fitting was applied.

dvfs — The board power cap binds almost continuously and the SM clock pays the entire cost: measured 345 W median against a 350 W limit, with NVML reporting the cap actively reducing clocks on measured 69% of the sample period. 12143 decode samples (n_decoded advancing) plus 3224 further busy samples, at a 1.07 s cadence. Upper panel plots SM clock against GPU board power, colour is SM utilisation, marker is workload phase; grey points are samples outside the /slots trace whose phase is unknown rather than idle, and the inset magnifies the corner the workload occupies. The SM clock sits measured 435 MHz (20%) below the 2130 MHz maximum SM P-state. Inside that capped regime r(board power, SM clock) is -0.15, not positive: watts are not buying clock. Lower panel, same power axis: the memory clock holds measured 9501 MHz on 100.0% of decode samples while its controller is busy only measured 47% of the time, and the lower memory P-states this part uses when idle are never selected under load. THE PHASE-AWARE CLOCK TRADE THIS SUGGESTS IS AN OPPORTUNITY, NOT A RESULT: nothing in this run varied the memory clock, and with no per-rail power on this part the watts at stake are unmeasured. Part: NVIDIA RTX 3090 (GA102, 24 GB GDDR6X, 350 W enforced board limit). Workload: aider polyglot exercises, Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log on llama.cpp, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log. Both utilisation figures here are NVML duty cycles, not bandwidth or occupancy fractions: SM utilisation is the percentage of the sample period with at least one kernel resident, and memory-controller busy is the percentage of the sample period with a device-memory transaction in flight. Neither is a fraction of peak bandwidth, and neither says how much of the SM array or of the memory bus was in use while it was busy. NOT measured: system or wall power (this is GPU board power from NVML only - no PSU loss, CPU, RAM, fans or display); per-rail power (NVML gives one board number on this part, so the watts held by the memory clock cannot be separated out); memory junction temperature (not exposed by NVML on this part, the field is NULL in every sample); and the memory-for-SM clock trade itself, which nothing in this run varied.

dvfs — The two clock domains run on completely different policies under one shared power cap. Over measured 16476 s of busy samples (SM > 5%), each sample weighted by its own 1.07 s interval: the SM clock is spread over 29 distinct frequencies on a 15 MHz grid and never reaches the 2130 MHz maximum P-state, spending measured 94% of busy time inside a 120 MHz band around measured 1695 MHz. The memory clock is a single bar, measured 9501 MHz for 99.9% of busy time, while the traffic it serves over that same interval (inset, same axis of time) is a broad distribution centred on measured 47% of the sample period (5th-95th pct 42-53%). The lower memory P-states at the left of that panel are real and this part uses them when idle, so the granularity exists in silicon and is simply never selected under load. NOTHING HERE MEASURES WHAT A DIFFERENT POLICY WOULD COST OR SAVE: no clock was locked, offset or varied in this campaign, and NVML on this part gives one board-power number with no per-rail split. Part: NVIDIA RTX 3090 (GA102, 24 GB GDDR6X, 350 W enforced board limit). Workload: aider polyglot exercises, Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log on llama.cpp, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log. Both utilisation figures here are NVML duty cycles, not bandwidth or occupancy fractions: SM utilisation is the percentage of the sample period with at least one kernel resident, and memory-controller busy is the percentage of the sample period with a device-memory transaction in flight. Neither is a fraction of peak bandwidth, and neither says how much of the SM array or of the memory bus was in use while it was busy. NOT measured: system or wall power (this is GPU board power from NVML only - no PSU loss, CPU, RAM, fans or display); per-rail power (NVML gives one board number on this part, so the watts held by the memory clock cannot be separated out); memory junction temperature (not exposed by NVML on this part, the field is NULL in every sample); and the memory-for-SM clock trade itself, which nothing in this run varied.

limits — Board power tracks the enforced limit for essentially the entire run, dropping only where the server goes idle between requests. The band is the severity-collapsed NVML clock-event label, so exactly one limit holds each sample and the stack is 100%% at every instant; limits other than the power cap also get fixed-width tick marks above the band, because one sample is roughly one pixel wide at this aspect ratio and would otherwise be invisible. NVIDIA GeForce RTX 3090 (single board, GPU 0). Workload: aider polyglot agentic coding benchmark against a local llama-server, Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log, 9.154 GiB on disk (recorded in campaign.md at that precision); 9.8290 decimal GB (derived: 9.154 GiB × 1.073741824) — the recorded figure is the GiB value; the decimal-GB form is derived from it, and the gap between the two units is about 7 percent, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log; run 2026-08-26-18-41-54--q2kxl-agentic, tag q2kxl-agentic. Window: 285 minutes of telemetry, 3194 clock-event samples, 3096 of them busy. Board power is the NVML GPU board domain only, so PSU, CPU and wall power were not measured, and per-process power attribution is unavailable under Windows WDDM.

limits — Power is the limit on 92.8% of busy samples, temperature on 6.9%, and the part is unconstrained on 0.2%. Idle is excluded and the figure states how many idle samples were dropped: idle is a state, not a limit, and including it would dilute every bar. Filled bars are the exclusive severity-collapsed label; open diamonds are how often each reason bit was set at all, since reasons co-occur. Limits that never fired are drawn at zero and labelled as measured rather than omitted, so a reader can tell 'never happened' from 'never sampled'. NVIDIA GeForce RTX 3090 (single board, GPU 0). Workload: aider polyglot agentic coding benchmark against a local llama-server, Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log, 9.154 GiB on disk (recorded in campaign.md at that precision); 9.8290 decimal GB (derived: 9.154 GiB × 1.073741824) — the recorded figure is the GiB value; the decimal-GB form is derived from it, and the gap between the two units is about 7 percent, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log; run 2026-08-26-18-41-54--q2kxl-agentic, tag q2kxl-agentic. Window: 285 minutes of telemetry, 3194 clock-event samples, 3096 of them busy. Board power is the NVML GPU board domain only, so PSU, CPU and wall power were not measured, and per-process power attribution is unavailable under Windows WDDM.

pareto — Part: RTX 3090, 350 W stock board limit, fan pinned at 100%. Model: Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log. Workload: the live agentic coding benchmark, tag q2kxl-agentic, run 2026-08-26-18-41-54--q2kxl-agentic - real multi-turn edit-and-test traffic on one slot, median context depth 2,077 tokens. Each point is one poll-to-poll decode interval of about 1 s whose BOTH endpoints are decode samples of the same task (n=11813; the first interval of every decode run is discarded because it starts inside prompt processing, and gaps over 4 s are discarded as stalls). Board power is the NVML sample nearest in time, within 1.0 s. The shaded field and its labelled rays are lines of constant energy per decoded token. FINDING: board power holds a coefficient of variation of 1.0% while throughput holds 23.0%, so the measured cloud is a near-vertical stripe standing on the power limit. At this operating point there is no power-side lever to pull - energy per token is decided almost entirely by decode speed, which is to say by speculative-decoding acceptance. Run aggregate: 4.43 J per decoded token, 927,954 tokens over 11923 s of decode, 345 W mean. Not measured: wall or system power - this is the GPU board rail read in-band by NVML, so power supply loss, CPU, RAM, drives and fans are all excluded; per-process power attribution (NVML pmon reports "-" for every process under Windows WDDM); memory-junction temperature (NULL on this part, so memory thermal headroom is unknown).

pareto — Part: RTX 3090, 350 W stock board limit. Model: Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log. LEFT: the published power-cap sweep as an arm-level curve, drawn on the same throughput-against-board-power plane as the operating cloud, with each arm placed at the power it ACTUALLY drew rather than at the limit it was set to (dotted verticals mark the limits). Source results/qwen38-27b-blind/data/register/power-cap-arms-saturating.json, measured 2026-08-28 02:04 on NVIDIA GeForce RTX 3090, 3 probes per arm, 32768-token context. RIGHT: what each cap step changed against the 350 W stock arm - the 300 W limit costs 4.1% throughput for 13.1% less board power and 9.4% less energy per token; the 250 W limit costs 14.6% throughput for 27.1% less board power and 14.7% less energy per token. Capping improved energy per token at both steps, which puts the stock 350 W limit past the efficiency knee FOR THAT WORKLOAD. CAVEAT, carried on the figure: the sweep ran on synthetic decode drawing 337 W against a 350 W limit, so it never reaches its cap, while the agentic workload in this run sits on the cap (96.1% of busy samples carry the software power-cap bit) and averages 345 W in steady decode. The two power distributions barely overlap, so the published curve describes a regime the agentic workload is not in and must not be assumed to transfer. Not measured: wall or system power - this is the GPU board rail read in-band by NVML, so power supply loss, CPU, RAM, drives and fans are all excluded; per-process power attribution (NVML pmon reports "-" for every process under Windows WDDM); memory-junction temperature (NULL on this part, so memory thermal headroom is unknown).

phases — Phase timeline with board power. RTX 3090 (board power via NVML; system and wall power not measured), Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log, aider polyglot agentic workload, run 2026-08-26-18-41-54--q2kxl-agentic, tag q2kxl-agentic. Phase accounting is scoped to the 285-minute /slots trace; GPU work outside that window is not counted. Decode holds 76.0% of wall-clock seconds, prompt processing 20.6% and idle 3.5%, alternating in 2225 runs across 1084 requests (median run 3.0 s). Mean board power is 343 W in decode and 334 W in prompt processing - only 9 W apart, so the phase cannot be read off the power trace; the idle floor is 80 W with 13.1 GiB still resident in VRAM. The lower panel is the 150 s window whose phase-change count is the median over every window of that width, so it is representative rather than chosen for appearance. Memory junction temperature and per-process power are not exposed on this part: absent, not zero.

phases — Time, energy and tokens split between phases. RTX 3090 (board power via NVML; system and wall power not measured), Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log, aider polyglot agentic workload, run 2026-08-26-18-41-54--q2kxl-agentic, tag q2kxl-agentic. Phase accounting is scoped to the 285-minute /slots trace; GPU work outside that window is not counted. Decode takes 76.0% of the seconds but only 22.3% of the tokens: 3.49 prompt tokens are recomputed per token generated, because prompt processing runs batched at 958 tok/s against decode's 74 tok/s aggregate. Board energy splits 78.5% decode / 20.7% prompt processing / 0.8% idle of 5680 kJ, computed by integrating A.energy() over each contiguous phase run with busy_only=False and summing by phase. Decoded-token counts are a FLOOR - n_decoded is sampled between polls and the server clears it when a slot is released - so decode's token share is a lower bound and its per-token cost an upper bound. A further 878 k prompt tokens hit KV cache and are excluded, since they cost no prefill compute. The 74 tok/s decode figure is a phase aggregate over every decode second in the run, so it sits below steady-state decode: instantaneous rate in the same trace is median 73 tok/s, p90 103 tok/s.

roofline — Roofline for single-stream decode on RTX 3090 (GA102, 24 GB GDDR6X, 350 W board-power cap). Axes: achieved useful tokens per second against useful tokens per GB of weight traffic, both log; the roof is y = min(936 GB/s x intensity, the measured compute ceiling of 2047 tok/s), so a point lying ON the sloped roof is bandwidth-bound. Workload: Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log (9.83 GB resident) on an agentic coding benchmark, -c 32,768 with 1 slot (--parallel 1), read from the server log, flash attention on, KV cache q8_0, MTP speculative decoding ON, read from the server log; mean accepted length — which is how many tokens of the draft head's guess the full model accepted per attempt, so a value of 1 would mean speculation bought nothing — is 3.84, the mean over 1082 draft-acceptance lines in this run's own log. The finding: plain decode moves the whole 9.83 GB of weights per token, so the bandwidth ceiling is 95.2 tok/s; drafter-off measures 45.2 tok/s, 47% of it, which is bandwidth-bound. Drafter-on measures 99.16 tok/s at mean accepted length 3.55, and that EXCEEDS the one-weight-pass-per-token ceiling, so that model cannot explain it: real traffic is 275 GB/s, 29% of the roof. The remaining 3.4x is taken by the 350 W board-power cap, which is active on 93% of non-idle samples and pulls the core clock to 1680 of 2130 MHz while the memory clock holds at 9501 of 9751 MHz - the cap lowers the compute roof and leaves the bandwidth roof exactly where it was. Decode measurements measured on UD-IQ4_XS, not this run. NOT measured: FLOPs (which is why the axes are in tokens, not FLOP/s), KV-cache and draft-head memory traffic, the prompt-processing micro-batch size (its intensity bar spans n_ubatch 512 to n_batch 2048, and only its throughput is measured), per-request accepted length (the live agentic spread is placed at the run-mean intensity, so only its vertical extent is measured), memory junction temperature (NVML exposes none on this part), and any power other than board power.

roofline — The same roofline swept over hypothetical mean accepted lengths L = 1 to 6 on RTX 3090 (GA102, 24 GB GDDR6X, 350 W board-power cap), so an architect can read off what a better draft head buys before it stops helping. Filled markers are the two MEASURED points (measured on UD-IQ4_XS, not this run): L = 1 at 45.2 tok/s and L = 3.55 at 99.16 tok/s, on Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log (9.83 GB resident), -c 32,768 with 1 slot (--parallel 1), read from the server log, KV cache q8_0, agentic coding workload, 350 W board-power cap. Open markers are a two-parameter cost model, throughput = L / (T0 + T1 x L), fitted through those two points and nothing else: T0 = 16.8 ms is the pass over the weights, paid once per verification cycle however many tokens ride on it, and T1 = 5.36 ms is the marginal cost of each speculated token (the draft head's own serial pass, the wider verification GEMM, the extra sampling). Two points and two parameters leave zero degrees of freedom, so there is no residual and no error bar: the open markers are an interpolation with a physical shape, not measurements. Reading: today's L = 3.55 already returns 53% of the 1/T1 = 186 tok/s asymptote, so lifting acceptance to the server's configured --spec-draft-n-max = 4 is worth +6%, reaching L = 6 is worth +24%, and a perfect draft head that accepted every token it drafted would be worth +88%. Measured acceptance is already 89% of the configured cap, so the cap is the lever, not the draft head's quality - and the cap itself is worth only +24%. NOT measured: any accepted length other than 1 and 3.55; whether raising n-max would itself change acceptance; the draft head's own weight traffic, power and FLOPs; KV-cache traffic. Board power only - system and wall power were NOT measured.

tornado — Ranked sensitivity of every lever this campaign measured, on one RTX 3090 24 GB (stock 350 W cap) with an i5-13600KF host, Windows 11, llama.cpp build 10502, Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log at -ngl 99. LEFT PANEL is throughput: percent change in decode tokens per second, right is faster. MIDDLE PANEL is efficiency: percent change in joules per token, left is more efficient. The two panels are NOT on a shared axis - they carry different units and opposite polarity, and a bar in one says nothing about the other. The grey vertical bands are the rig's own measured noise: 1.1 percent total range for one fixed arm reloaded 16 times on throughput, and a 2.9 percent triplicate floor on joules per token. A bar that stays inside its band was not resolved by this instrument and is drawn neutral grey rather than as a win or a loss - the --load-mode row is the only one of those. Six of the nine levers were never paired for energy and carry an explicit 'not measured' mark rather than a zero-length bar. The ngram-mod row is drawn as a measured range (1.10x to 1.48x across six content types) because no single point estimate exists for it. Speculation's two bars come from different arms - throughput from the UD-IQ4_XS 45.2 to 99.16 t/s pair, energy from the power matrix at 8.104 to 3.210 joules per decode token - which is why 2.19x and 2.52x do not match exactly; decode-phase board power is flat across that pair (344.6 to 341.0 W), so the energy saving is the throughput gain restated. Both power-cap rows were measured on synthetic decode whose 305.4 W mean never reached the 350 W cap, while agentic coding sits at the cap on about 97 percent of busy samples, so those two rows are not shown to transfer to this workload. NOT MEASURED ANYWHERE ON THIS FIGURE: wall or system power (board power only - there is no meter on this rig), memory junction temperature (NVML returns N/A for mtemp on this part), per-process GPU attribution (nvidia-smi pmon reports '-' for every process under Windows WDDM), and any interaction between levers - each row is its own arm with its own file, flags and prompt, and the rows are not a factorial sweep.

workload — Per-request demand over 1084 requests of the aider polyglot agentic coding loop, on one RTX 3090 running Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log. Left: prompt depth (processed + cache-supplied tokens), median 2516 and p95 11994 tokens, with the peak KV footprint (prompt + generated) as the dashed curve; the p99 footprint of 24660 tokens is 75% of the 32768-token window the server was started with, so this workload runs close to the configured wall. Right: generated tokens, median at least 326 and p95 at least 3485. Prompt tokens outnumber generated tokens 4.4 to 1. Generated counts are a floor - the 1 Hz /slots poll loses the last partial second of every request. Single slot (--parallel 1), so no concurrency appears in this distribution. Board telemetry only; no system or wall power is implied. KV bytes per token were not computed: layer and head geometry is not measured by this harness.

workload — KV cache reuse per request, 1082 requests of the aider polyglot agentic coding loop on one RTX 3090 running Qwen3.8-27B UD-Q2_K_XL at 2.912 bits per weight (cited, campaign.md), read from this run's own server log with a single slot (--parallel 1) and q8_0-quantised K and V. Each point is one request: prompt depth against the share of that prompt the server reported as cache-supplied. Across the run the cache supplied 20.6% of all 4254843 prompt tokens, but 55.4% of requests reused nothing at all and the median request reused only 0.0%, so a per-request average would badly understate the hardware benefit - the green markers give token-weighted reuse inside each depth band. Reuse does not increase with depth: it rises, collapses in the 4k-8k band and rises again, so depth alone does not predict a cache hit. Cache evictions and the byte size of a cached token were not measured. Board telemetry only; no system or wall power is implied.