frank-secondary: record the deployed f16-K boot ledger, correct the k_eq_v billing law

Verbosity 4 paid for itself: the engine's own llama_kv_cache lines give the
exact accounting — the cache bills the K+V pair TWICE under attention_k_eq_v
(6.125 B/elem at f16 K + q8_0 V), reproducing 3,001.25 MiB (5 full layers at
n_head_kv 2) + 306.25 MiB (25 SWA rings at n_head_kv 8, window 1024) to the
byte. The earlier "bill K-only" note was wrong; full layers have 2 KV heads,
not 8.

Deployed boot: 21,868 used / 2,257 free — the f16-K raise (+2,161 MiB KV) is
funded by the ubatch 2048 -> 1024 cut (~616 MiB of compute buffer) plus
variance, so exact K came essentially free. Measured decode 139.9 t/s temp 0;
vision probe returns Red at prompt_tokens 151.

serverAppConfigs-docs/LLM/frank-secondary-llama-gemma4-q4km-200704.md

@@ -10,7 +10,7 @@ RCO-IQ3_XXS-mtp, 2×114,688, in-file MTP).
 
 |File|Path|Bytes|
 |---|---|---|
-|Main (Q4_K_M)|`/home/dank/models/Gemma4-26B-A4B/Gemma4-26B-A4B-QAT-Uncensored-HauhauCS-Balanced-Q4_K_M.gguf`|16,780,192,888|
+|Main (Q4_K_M)|`/home/dank/models/Gemma4-26B-A4B/Gemma4-26B-A4B-QAT-Uncensored-HauhauCS-Balanced-Q4_K_M.gguf`|16,796,015,520 on disk; the engine reports 16,780,192,888|
 |Vision (mmproj BF16)|`/home/dank/models/Gemma4-26B-A4B/mmproj-Gemma4-26B-A4B-QAT-Uncensored-HauhauCS-Balanced-BF16.gguf`|~1.195 GiB|
 |MTP assistant (on disk, NOT loaded)|`/home/dank/models/Gemma4-26B-A4B/mtp-gemma-4-26B-A4B-it.gguf`|~0.252 GiB|
 
@@ -38,28 +38,46 @@ morning): **21,890 MiB used / 2,235 MiB free** (`nvidia-smi`). With MTP ON
 context costs ~1.9 GiB because its KV is built against the target's full
 window ([[Llama Cpp Serving Sizing]]).
 
-Same evening (Frank): **K raised to f16, ubatch cut 2048 → 1024, verbosity
-4**. f16 K doubles the K side (20.5 KiB/token over the 5 full layers ≈ 4.1
-GiB at 200,704, +2.05 GiB over q8_0); the ubatch cut claws back part of it
-(the Swift-era 3090 measurement put the 2048 rung at ~746 MiB of compute
-buffers). Projected usage ~23 GiB — **the boot ledger is the referee, not
-this arithmetic**: on a 24,125 MiB card a failed graph capture is the failure
-mode. Decode is ubatch-invariant (Swift-era 3090 law; unmeasured on Gemma4 —
-inference).
+**Deployed shape (2026-10-07 evening, Frank): K = f16, ubatch 1024, verbosity
+4. Measured boot: 21,868 MiB used / 2,257 MiB free** — i.e. the f16-K raise
+(+2,161 MiB of KV, see the accounting below) was paid for by the ubatch cut
+(2048 → 1024 returns ~616 MiB of compute buffer) plus slot-geometry variance.
+Exact K came essentially free. The verbosity-4 ledger (journal, `llama_kv_cache`
+lines): model 16,002.91 MiB (CUDA0) + 577.50 MiB (CPU-mapped), **KV 3,001.25
+MiB (5 full layers) + 306.25 MiB (25 SWA rings)**, compute buffers 926.39 +
+150.63 MiB, output buffer 1.00 MiB.
+
+**Measured decode: 139.9 tok/s** (`/completion` timings, temp 0, 256 tokens,
+deployed shape) — the ~4 B-active MoE is at home on the 3090. The model
+thinks: a 256-token budget on a short prompt can be consumed entirely by
+`reasoning_content` with empty `content` and `finish_reason: length`, so
+harness requests must budget for thinking (same law as the uncensored Swift
+payload). Vision probe on this build: solid-red 512 px PNG via the OpenAI
+`image_url` part → `Red`, `prompt_tokens` 151 (the image reached the model).
+
+Decode is expected ubatch-invariant (Swift-era 3090 law; the 139.9 t/s above
+is at ubatch 1024 — one rung measured, not a ladder).
 
 ## Architecture facts
 
 Gemma4 MoE hybrid: 30 layers, 128 experts (8 active), n_embd 2816, 262,144
-native window, n_vocab 262,144. Hybrid attention: **25 sliding-window layers
-(window 1024) + 5 full-attention layers (5, 11, 17, 23, 29)** — the KV pool
-scales with the 5 full layers only (8 KV heads × 256 dim): q8_0 ≈ 10.6
-KiB/token, f16 ≈ 20.5 KiB/token. A 200,704 slot therefore costs ~2.05 GiB at
-q8_0 — far less than the Swift 16-layer shape (34 KiB/token).
-`attention_k_eq_v: True` — in `gemma4.cpp` the absent `wv` tensor makes
-`Vcur = Kcur` in the compute graph, and in this build (5fc4f3c) the KV cache
-**honours it: no V slots are allocated**. Measured: the q8_0 pool landed at
-~2.05 GiB, exactly the K-only figure. **Bill K-only.** The `--cache-type-v`
-flag is kept explicit for contract visibility; with `k_eq_v` it is inert.
+native window, n_vocab 262,144. Attention is hybrid per
+`gemma4.attention.sliding_window_pattern` (read from the file at load): **25
+sliding-window layers (window 1024, `n_head_kv = 8`) + 5 full-attention layers
+(indices 5, 11, 17, 23, 29, `n_head_kv = 2`)**, head_dim 256 for K and V in
+both classes. The KV pool is TWO caches: the full-context cache scales with
+the 5 layers at the full 200,704 window; the SWA cache is a fixed 1024-token
+ring per sliding layer.
+
+**The rate law (measured, exact):** bytes/token = `n_kv_heads × 256 × 6.125 B`
+per layer at f16 K + q8_0 V — `attention_k_eq_v` does **NOT** shrink the
+allocation: `Vcur = Kcur` is a compute-graph mapping, the cache reserves K and
+V slots and, with `k_eq_v`, reserves the pair **twice** (6.125 = 2 × (2 B f16 +
+1.0625 B q8_0)). Verified against the boot: 5 × 2 × 256 × 6.125 = 15,680
+B/token × 200,704 = **3,001.25 MiB** ✓ and 25 × 1024 × 8 × 256 × 6.125 =
+**306.25 MiB** ✓. At q8_0 K + q8_0 V the rate is 2.125 B/elem: the same shape
+costs 1,041 + 106 = **1,147 MiB**, so the f16-K raise is **+2,161 MiB**. The
+`--cache-type-v` flag is honoured, not inert.
 
 The llama.cpp master build at commit `5fc4f3c` supports the arch
 (`src/models/gemma4.cpp`, `LLM_ARCH_GEMMA4 = "gemma4"`). Note: `grep -c`