docs(llm): record a measured NEGATIVE tuning result for frank-large

Asked for iterative decode/prefill improvement at a 32k working point
without touching the model or the quantization. There isn't one: gufo's
served settings are already at this engine's tuned point, so no config
change was made and none is proposed.

Measured on the repo's own prose and shell sources at 32,762 prompt
tokens, salted per run against a warm prefix cache, 3-5 repetitions:

* --prefill-chunk 512 -> 8192 moves prefill 410.7-412.4 t/s. A 16x change
  in chunk size, 0.4% out. The lever is dead at this depth.
* --draft-tokens 5 -> 10 gives 13.79-15.86 t/s decode, all inside the
  run-to-run noise. The 5-rep confirmation REVERSED the 3-rep leaders:
  dt9+chunk4096 looked best and came last (12.86), the deployed config
  came first (14.71).
* --draft-policy fixed vs adaptive: no effect. --min-draft-tokens:
  rejected by the engine ("DFlash2 requires ... 1"). MTP: unsupported for
  Q8 targets (token_embd.weight is Q8_0).
* --context 262144 -> 40960, tested as a diagnostic: no gain, and it
  would break models.yml's declared contextWindow. Not shipped.

What does move the number is speculation itself — 6.65 t/s off vs ~15 t/s
on, 5.3x — and it is already enabled.

The two traps that cost most of the wall time are now in AGENTS.md's
benchmarking policy, because both produced FALSE results:

1. gufo bench cannot rank speculative settings and inverted the ranking.
   Its corpus reports acceptance=0.933 +/- 0.000 with an identical trace
   sha256 across draft widths — the same highly-predictable text every
   run. It reported 29-37 t/s where real traffic gives ~15, and made
   dt16 look 6% faster than dt7 when real text made it 14% slower.
2. A live A/B needs >=128 generated tokens. At 8, inter_token is
   first-token noise; the first pass produced a nonsense ordering that
   the 128-token pass reversed.

Plus the Server-Timing header is `ttft;dur=402.485` — the unit rides in
the NAME half, so splitting on "=" keys the dict "ttft;dur" and every
lookup silently returns nothing. Four configs reported "no Server-Timing"
while the header was present on all of them.

AGENTS.md

@@ -208,13 +208,27 @@ archive.
 
 **STOP the production service BEFORE benchmarking** — these servers serve
 real users, and a bench beside a live service starves the GPU and corrupts
-results. Use the runtime's own harness: `llama-bench` for every llama.cpp
-endpoint (all three are llama.cpp now). Rolling your own bench
+results. Use the runtime's own harness: `llama-bench` for the llama.cpp
+endpoints, `gufo bench` for frank-large. Rolling your own bench
 requires asking first.
 Scratch ports are not used on LLM hosts — a
 test process cannot share the single GPU anyway; validate against the service
 itself.
 
+**`gufo bench` cannot rank speculative-decode settings, and will invert the
+ranking.** Measured 2026-09-28 on frank-large at depth 32768: its corpus
+reports `acceptance=0.933 ± 0.000` with an **identical trace sha256** across
+draft widths, i.e. the same highly-predictable text every run, and 93 % of
+every proposal accepted. It reported 29–37 t/s decode where real traffic
+gives ~15 t/s, and it made `--draft-tokens 16` look 6 % faster than 7 when
+real text made it 14 % *slower*. Use it for shape, not for A/B. For an A/B,
+replay **real** text through the live server and read the `Server-Timing`
+header — but note the unit rides in the **name** half (`ttft;dur=402.485`),
+so splitting on `=` alone keys the dict `ttft;dur` and every lookup silently
+returns nothing. Generate **at least 128 tokens** for the measurement: at 8
+tokens, `inter_token` is first-token noise and the run-to-run spread swamps
+every real difference.
+
 This covers **any GPU experiment, not just benchmarks** — including a bare
 2-rank RCCL/`torch.distributed` probe. On 2026-09-16 one such probe was run
 against the live service "because it only needs 200 MB of VRAM"; the host went