frank-primary: max-possible window (241664) + reasoning/tool contract

Night ladder result (Frank's subtract-16k method): 262144 and 245760 both OOM
at CUDA graph capture ('Tried to allocate 76.00 MiB ... 0 bytes free'), 237568
passed (KV 718,606 tokens), and the +4096 bonus step PASSED -> 241664 is max
possible and DEPLOYED at util 0.98 (KV 732,359 tokens / 3.03x concurrency at
241,664-token requests). Util stays 0.98: lowering it shrinks the engine's own
budget instead of buying slack.

Client contract restored (the GLM rollback d91379d dropped all three and the
qwen rollback inherited the gap): --reasoning-parser qwen3 fixes the malformed
thinking block (thinking was landing inline in content with a dangling
</think> and a null reasoning field), --enable-auto-tool-choice with
--tool-call-parser qwen3_xml makes tools work, and
--default-chat-template-kwargs enables enable_thinking + preserve_thinking.

Harness: contextWindow 241664 (compaction gap recomputed), preserve_thinking
moved into chat_template_kwargs.

serverAppConfigs-docs/LLM/dankserver-qwen38-fp8-expert-offload-tuning.md

@@ -244,13 +244,78 @@ scripts `arm_*.sh` / `sweep_*.sh` and the detached runner `/home/dank/job.sh`
 are `podman cp`'d into the container after every recreate (the serve script
 re-copies them; a recreate wipes container-local files).
 
+## 2026-10-01 — production cutovers (qwen FP8+MTP4, then bf16 no-spec)
+
+Two same-day cutovers moved this page's findings into production:
+
+1. **Qwen FP8 + MTP4 replaced the failed GLM/DFlash2 experiment** (the GLM
+   window is documented in [[frank-primary-glm53-flash-w4a16]]; git tag
+   `frank-primary-fp8-mtp-20261001` is the last commit of that shape). The
+   production trio took MAXLEN 200000 x 3, fp8 KV, MTP4, prefetch off —
+   measured 37.4-40.6 tok/s at ~54% acceptance.
+2. **The overnight redo campaign re-measured EVERY lever at matched
+   geometry** (prefetch OFF everywhere, MAXLEN 200000/SEQS 3/fp8 baseline)
+   and concluded the day: the incumbent cutover to **bf16 KV, no
+   speculative decode** (Frank's call).
+
+### What the redo campaign measured (all at shallow depth, 166/1087/4064)
+
+| lever | verdict |
+|---|---|
+| prefetch (re-confirmed) | the whole night's +40-51% lives in deleting it; the old 12.11 "no-spec baseline" was itself prefetch-taxed |
+| gather geometry | **R4D_LRU_GATHER_CHUNKS=32 / LANES=64 = +18.7%** (49.25 @4064), the win GROWS with depth (39.5@166 -> 54.1@1087); g8x16 mild, g64x128 past peak |
+| KV dtype | bf16 (`auto`) +4% decode on fp8-era numbers but halves attention-KV capacity (measured 14,047 vs 7,926 B/token; mamba states unaffected) |
+| spec family | no-spec fastest once the tax was gone (41.46/41.29/41.47); MTP4's drafter reserves ~2.6 GiB/rank beside the pool; untaxed MTP re-measures never completed |
+| MNBT | 512 doubles TTFT (2.46 s vs 1.36 s @4064); 1024-4096 interchangeable; 12288 -2.5% + arena; **locked 1024** |
+| UVA | 2048 POISON (-39%); 8192 ~parity |
+| arena | flat ±1.4% from ~6,830 down to ~5,500 slots; knee below |
+| six slots | every SEQS-6 KV sizing refused at engine init |
+
+Depth caveat: every number above is at a near-empty KV. Deep-context
+behavior (the gather win growing with depth, bf16's decode cost at depth)
+is only sampled at 3 depths; a 64k-192k-depth probe is the flagged gap.
+
+### The bf16 no-spec incumbent (production since 2026-10-01)
+
+```
+FRANK_PRIMARY_MAXLEN=241664    x SEQS 3 (724,992 tokens of contract)
+FRANK_PRIMARY_KV_BYTES=10184000000  PER RANK (bf16, pool scales with window)
+FRANK_PRIMARY_KV_DTYPE=auto   --kv-cache-dtype auto (bf16, unquantized)
+FRANK_PRIMARY_MNBT=1024       --max-num-batched-tokens 1024
+R4D_LRU_GATHER_CHUNKS=32 / R4D_LRU_GATHER_LANES=64  (container env)
+NO --speculative-config, NO --expert-prefetch
+```
+
+Boot-probed 2026-10-01 (transient systemd units, full-log capture): 262144
+and 245760 both died at graph capture (`Tried to allocate 76.00 MiB ...
+0 bytes free` — the pool+profile+graph budget exceeds by a hair at util
+0.98); 237568 passed (KV 718,606 tokens) and the +4096 bonus attempt
+**241664 PASSED and is production: KV 732,359 tokens / Maximum concurrency
+for 241,664 tokens per request: 3.03x** — all three full windows fit with
+a 7,367-token margin. Decode measured at the 262k-era shape before the
+ladder: 39.38/38.79/36.42 tok/s (166/1087/4064 ctx).
+The old "KV_BYTES is PER RANK, 9/16 GiB OOM" law was the MTP4 WORKSPACE
+reservation, not a VRAM wall — no-spec bf16 takes ~9.5-10.2 GB/rank and
+boots clean. The failed 11.3 GB attempt OOMed at the engine's free-memory
+check (`RuntimeError: Worker failed with error 'CUDA out of memory'`,
+captured from the journald json stream — the fork's giant ERROR lines are
+split by journald, so grep the `-o json` output, not `-o cat`).
+
+Rollback to the fp8+MTP4 shape: git tag `frank-primary-fp8-mtp-20261001`
+(env trio + seam re-pinned there). The bf16 trade is deliberate: ~14%
+decode cost at 4064 ctx vs the fp8+gather arm (49.25 -> 36.42) bought
+clean cache + the largest window this box boots. The model's native
+262,144 exceeds what graph capture grants at util 0.98 here: the ladder
+measured 262144/245760 OOM and 241,664 as max possible (Frank's
+subtract-16k method, then one +4k bonus step).
+
 ## See Also
 
 - [[dankserver-frontier-moe-feasibility]] — the sibling feasibility page
   (which frontier MoE fits this box; the same PCIe-expert-stream wall at
   V4.1 scale)
-- [[frank-primary-r9v-radiance-qwen38-q8]] — the ACTIVE frank-primary
-  (production is the R9V fork; this page's container is the ad hoc detour)
+- [[frank-primary-r9v-radiance-qwen38-q8]] — RETIRED 2026-09-30 (the R9V
+  fork era; production has been the tcclaviger fork since)
 - [[x4-pair-experiment]] — the same residency law measured on a narrower
   link: streaming over PCIe loses, computing in RAM does not care
 - [[Dual-R9700-Cooperation]] — the board swap that made TP=2 legal here