frank-primary: shape G — force the arena to the flag ceiling, KV to 400,700 tokens

Two plan terms were still unspent: the CUDA-graph charge (shape F's own boot
reported a NEGATIVE capture delta, -0.06 GiB, so the 256 MiB base pool was
fiction -> charge 0 + 12 MiB/graph = 0.07 GiB) and the budget (util 0.982 -> 1.0,
the field's le=1 maximum). Together +0.82 GiB of expert cache: plan target
18.35 GiB / ~8,016 slots. KV_BYTES 3.15e9 -> 3.1665e9 = the 400,700-token ask at
the engine's measured 7,891.8 B/token. Cost of the force, recorded: driver
high-water ~30.4 GiB of 31.86, so ~1.5 GiB of real margin per card; rollback is
UTIL=0.982.

scripts/frank-primary.env

@@ -1,15 +1,17 @@
 # frank-primary.env — tcclaviger RDNA4 vLLM production config (dankserver :7770).
 #
-# 2026-10-03 shape F: MNBT 2048 and the CUDA-graph plan term pinned to the
-# measured capture cost. The expert arena is `budget - non-expert - KV reserve
-# - graphs - overhead`, and with UTIL capped (see FRANK_PRIMARY_UTIL) the graph
-# estimate is the only plan term this repo can reach: the fork charges an
-# analytic 0.55 GiB (256 MiB base + 52 MiB/graph) where the engine's own
-# post-capture line reports 0.31 GiB on the heavier rank. Pricing it honestly
-# returns 0.24 GiB to the arena. The rest of the idle free VRAM (~3.3 GiB/card)
-# stays unreachable from flags: it is locked inside the registry's overhead
-# (5.25 GiB) and KV-price (9,190 B/token vs the measured 7,892) terms, which
-# live in the image, not in our argv or env.
+# 2026-10-03 shape G: the arena forced to the flag ceiling. The expert arena is
+# `budget - non-expert - KV reserve - graphs - overhead` and the KV reserve is a
+# registry constant, so exactly two terms are reachable: the CUDA-graph estimate
+# (priced at the measured capture — the engine's own post-capture delta is
+# -0.06 GiB, i.e. free, so we charge 12 MiB/graph and nothing else) and the
+# budget, which is `device_total x gpu_memory_utilization` with the field pinned
+# to `le=1`. UTIL 1.00 + graph term 0.07 GiB is therefore the MAXIMUM arena this
+# repo can ask for without editing the image: 18.35 GiB / ~8,016 slots. Frank
+# approved forcing util to 1.00 for this; the measured cost is the free-VRAM
+# margin, which lands at ~1.5 GiB/card (see FRANK_PRIMARY_UTIL).
+# 2026-10-03 shape F (absorbed): MNBT 2048 + the graph term pinned. Measured on
+# the live deploy: arena 17.52 GiB / 7,653 slots, budget 31.29, graphs 0.32.
 # 2026-10-02 shape E: fp8 KV, MAXLEN 200704 x SEQS 3, pool 3.15e9/rank, and
 # --expert-precise-memory ON. The window shrink from the native 262144 and the
 # --max-num-seqs 3 lock both come from shape D (SEQS=2 CANNOT boot this model —
@@ -162,31 +164,44 @@ FRANK_PRIMARY_SEQS=3
 # 3.15e9 preserves the measured 1.99x while precise-memory grows the arena. A
 # 2.2e9 pool was probed in the same window (277,686 tokens / 1.38x) and rejected
 # as the shipped value; it remains the conservative arm if free VRAM ever binds.
-FRANK_PRIMARY_KV_BYTES=3150000000
+# KV forced to 400,700 tokens (Frank, 2026-10-03). The engine prices this pool
+# at 7,891.8 B/token at this shape and loses ~3.87 MB to block alignment, so
+# 3,166,500,000 B is the ask that lands at/above 400,700 (verify the reported
+# "GPU KV cache size" line on every deploy; it is not a constant ratio across
+# geometries — 7,701 B/token at 262144).
+FRANK_PRIMARY_KV_BYTES=3166500000
 FRANK_PRIMARY_KV_DTYPE=fp8
 FRANK_PRIMARY_MNBT=2048
 FRANK_PRIMARY_GATHER_CHUNKS=32
 FRANK_PRIMARY_GATHER_LANES=64
-# UTIL is Frank's cap: 0.982 maximum, never 1.00. It is an ARENA lever — the
-# fork plans `budget = device_total x util` — but a weak one here: 0.980 -> 0.982
-# moves the budget 31.22 -> 31.28 GiB, i.e. +28 slots. Raising it to 1.00 would
-# add 0.64 GiB and Frank vetoed it: this endpoint has twice died at the ceiling
-# (the 2x262144 bf16 boot at 0.13 GiB free, the 5x262144 boot at "0 bytes free"
-# on a real 995-token request), so the margin stays.
-FRANK_PRIMARY_UTIL=0.982
-# CUDA-graph plan term, pinned to the measured capture cost. expert_plan.py
-# charges estimate_cudagraph_memory() = BASE_MB + PER_GRAPH_MB x n_graphs with
-# defaults 256/52, and the estimator's own docstring says to tune these against
-# the post-capture line. MEASURED on shape E (model_runner.py:1094, same
-# 6-graph plan, same shape): "Graph capturing finished in 3 secs, took 0.31 GiB"
-# on the heavier rank (TP0) and 0.31/0.17 across ranks — vs the 0.55 GiB the
-# plan charged. 12 MiB/graph keeps ~10 MiB of margin over the fitted marginal
-# cost (~10 MiB/graph) and, unlike VLLM_CUDAGRAPH_MEM_ESTIMATE_MB (an explicit
-# TOTAL), scales correctly if a future MNBT or spec-decode change grows the
-# ladder. Verify every deploy against the "Estimated CUDA graph memory" and
-# "Graph capturing finished" lines; if capture exceeds the estimate, raise
-# FRANK_PRIMARY_CUDAGRAPH_PER_GRAPH_MB back toward 52.
-FRANK_PRIMARY_CUDAGRAPH_BASE_MB=256
+# UTIL is an ARENA lever: the fork plans `budget = device_total x util`, and at
+# 31.86 GiB/card every +0.01 is +0.32 GiB of expert cache (~+139 slots). Frank
+# held it at 0.982 and then approved FORCING it to 1.00 to buy the last gig of
+# arena — with the caveat written down, because this endpoint has twice died at
+# the ceiling (the 2x262144 bf16 boot at 0.13 GiB free; the 5x262144 boot at
+# "0 bytes free" on a real 995-token request). At util 1.00 the engine's budget
+# equals the whole card, so anything the registry under-prices shows up as a
+# RUNTIME allocation failure rather than a plan refusal. MEASURED cost of the
+# force: the driver high-water mark moves from 28.28 GiB (shape E) to ~30.4 GiB,
+# i.e. ~1.5 GiB of real free VRAM per card is the safety margin. If a request
+# ever dies with `Tried to allocate ... 0 bytes free`, the rollback is THIS
+# number back to 0.982 (-0.57 GiB of arena), not the window.
+FRANK_PRIMARY_UTIL=1.0
+# CUDA-graph plan term, priced at the measured capture. expert_plan.py charges
+# estimate_cudagraph_memory() = BASE_MB + PER_GRAPH_MB x n_graphs (defaults
+# 256/52 = 0.55 GiB for our 6-graph plan), and the estimator's own docstring
+# says to tune these against the post-capture line. MEASURED twice on this
+# shape: shape E reported "Graph capturing finished ... took 0.31 GiB" (TP0) and
+# 0.17 GiB (TP1); shape F, with the 0.32 GiB we then charged, reported
+# "took -0.06 GiB" — a NEGATIVE delta, i.e. capture fits inside memory the
+# profiler had already counted. So the base pool (256 MiB) is the over-charge:
+# charge 0 base + 12 MiB/graph = 0.07 GiB for the shipped no-spec 6-graph plan,
+# which returns 0.25 GiB more to the arena while still paying per graph, so a
+# future spec-decode shape (18 graphs) is charged 0.21 GiB rather than zero.
+# Verify every deploy against the "Estimated CUDA graph memory" vs "Graph
+# capturing finished ... took X GiB" lines; if capture ever goes positive and
+# exceeds the charge, raise FRANK_PRIMARY_CUDAGRAPH_PER_GRAPH_MB back toward 52.
+FRANK_PRIMARY_CUDAGRAPH_BASE_MB=0
 FRANK_PRIMARY_CUDAGRAPH_PER_GRAPH_MB=12
 
 # --- optional engine knobs (unset == the flag is absent) ---------------------