fix(frank-archon): raise the ttm pages cap in the serve path; reshape to 4 x 200,000 fp8 KV

The 2026-10-12 23:17 power failure reset /sys/module/ttm/parameters/pages_limit
from the manual 2026-10-05 raise (200 GiB) back to the kernel default (half of
RAM = 125,988 MiB), below the pinned-RAM ledger floor of 150,000 MiB. The serve
script's preflight named the refusal and exited 1; Restart=always re-ran it
6,919 times over ~20 hours and frank-archon served nobody.

scripts/ttm-preflight.sh (sourced by the serve script) now RAISES the knob
itself before refusing: the unit is root, the knob is a 0644 root module
parameter, and the cap is a runtime knob whose default is half of RAM — so a
manual sysfs write is not a repair procedure, it is a countdown to the next
reboot. FRANK_ARCHON_TTM_TARGET_MIB=204800 records the host ceiling; the gate
re-reads the cap after writing and only then refuses, so a knob the kernel
will not move is still a named failure.

Shape change (Frank's call): FOUR decode slots x 200,000 tokens with fp8
(quantized) KV. The pool must back seqs x max-model-len, so fp8 is what funds
the fourth slot: at bf16 the four slots cost 11,679 MiB of pool and would cut
the resident expert slab to 17,441 MiB (-33 %); at fp8 they cost 6,601 MiB, so
the pool stays 6,912 MiB (predicts 843,566 tokens), the VRAM pair stays at the
measured 29,120 MiB/card ceiling, the weights slab and the 44 GiB host pool are
untouched, and the fused TP all-reduce rides 4 x (1+2) = 12 rows, inside the
25-row bound where the wht6 wire is bit-exact.

scripts/frank-archon.env

@@ -3,10 +3,13 @@
 # built by scripts/convert-swift15-w4dn8.sh) on BOTH R9700s (TP=2),
 # dankserver :7770.
 #
-# SHAPE (2026-10-11): 2 decode slots x 200,000 tokens with an UNQUANTIZED
-# (bf16) KV cache — the pool is sized for the pair, and the weights slab pays
-# for it (see the KV block). The fp8-native payload this file was written for
-# is the rollback target and keeps its own trio under the fp8-native runbook.
+# SHAPE (2026-10-13): FOUR decode slots x 200,000 tokens with an fp8
+# (quantized) KV cache. fp8 is what makes four slots affordable: the pool must
+# back seqs x max-model-len, and at bf16 that costs 11,679 MiB (weights would
+# fall to 17,441 MiB, -33 %), at fp8 only 6,601 MiB — so the slab stays at its
+# 2026-10-11 size. See the KV block for the arithmetic and the measured dtype
+# law. The fp8-native payload this file was written for is the rollback target
+# and keeps its own trio under the fp8-native runbook.
 #
 # 2026-10-05 cutover from FreeToken (PR #587 ROCm, one card, experts in
 # pinned host RAM; git tag frank-archon-freetoken-pr587-20261005 is the
@@ -113,18 +116,21 @@ FRANK_ARCHON_TP=2
 # +5.6-6.3% prefill, ~-1.3% 8-stream decode at TP2). min-kb stays the
 # engine default.
 FRANK_ARCHON_TP_WIRE=wht6
-# Decode slots: TWO, so the served window is a CAPACITY CONTRACT — two
+# Decode slots: FOUR, so the served window is a CAPACITY CONTRACT — four
 # concurrent conversations of --max-model-len fit the KV pool (see the KV
 # block below). The "seqs 2 cannot boot" law is NOT radiance's: it was the
 # tcclaviger vLLM fork's torch.compile shape specialization on
 # query_start_loc (ConstraintViolationError, measured 2026-10-02, retired
 # with that runtime). Radiance booted seqs 2 at the fp8-native first boot,
 # and the 2026-10-06 decode sweep measured seqs 2 and 3 statistically tied
-# (30.9-33.1 t/s, inside the +-3% noise floor). Side benefit: the fused TP
-# all-reduce is declared over seqs x (1 + spec) = 6 rows, under the 25-row
-# bound at which the wht6 wire stays EXACT (single-sequence decode and any
-# step of <= 25 rows is bit-exact; only busier steps are lossy).
-FRANK_ARCHON_MAX_SEQS=2
+# (30.9-33.1 t/s, inside the +-3% noise floor) — slot count buys concurrency,
+# not speed, so the price of the fourth slot is KV, not decode.
+# Cost of each extra slot: 110 MiB of per-slot recurrent state inside the KV
+# pool, and the fused TP all-reduce is declared over seqs x (1 + spec) rows —
+# 4 x 3 = 12 here, still under the 25-row bound at which the wht6 wire stays
+# EXACT (single-sequence decode and any step of <= 25 rows is bit-exact; only
+# busier steps are lossy).
+FRANK_ARCHON_MAX_SEQS=4
 # Served window. Native is 262,144; 200,000 is the publisher's production
 # value (compose) and what models.yml's contextWindow must quote — a longer
 # prompt is refused by the engine, never truncated. The engine treats
@@ -156,14 +162,16 @@ FRANK_ARCHON_GPU_HEADROOM_MIB=96
 # so a bigger KV pool steals weight residency from the slab AND from the
 # lendable cache. Priors on this card/model: stealing 2.14 GiB of weights for
 # a bigger pool (MAX_MODEL_LEN 262144) cost 2.5% decode; the EVC ladder's
-# other direction (0.82 -> 0.84, +2.5 GiB weights) cost 8.9%. Expect -3..-8%
-# vs the fp8 control (136 t/s median at 44.5k depth, acceptance 0.7246,
-# ~190 t/s on a live 512-token probe); re-tune from a boot ledger + probe,
-# never from that estimate.
+# other direction (0.82 -> 0.84, +2.5 GiB weights) cost 8.9%. The 2026-10-11
+# exact-KV A/B measured the price of this exact slab size (22208): prefill
+# -29 %, TTFT at the full window +25 %, decode inside the noise band on 2 of 3
+# passes, draft acceptance UP 0.661 -> 0.740. Since 2026-10-13 the pool is fp8
+# (see the KV block), which is what funds the FOURTH slot at this slab size;
+# re-tune from a boot ledger + probe, never from that estimate.
 FRANK_ARCHON_VRAM_WEIGHTS_MIB=22208
 FRANK_ARCHON_VRAM_KV_MIB=6912
-# KV cache UNQUANTIZED (bf16). This engine's flag takes ONLY bf16|fp8 — there
-# is ONE kv_dtype for the whole cache, so "exact K, quantized V" (llama.cpp's
+# KV cache QUANTIZED (fp8). This engine's flag takes ONLY bf16|fp8 — there is
+# ONE kv_dtype for the whole cache, so "exact K, quantized V" (llama.cpp's
 # --cache-type-k/--cache-type-v pair, which is what frank-zealot runs) is
 # UNSERVABLE here: the rung below bf16 is fp8 on both halves.
 # Measured per-rank cost, read out of the boot ledger's group table (fp8 boot
@@ -177,30 +185,33 @@ FRANK_ARCHON_VRAM_KV_MIB=6912
 # The dtype-INDEPENDENT terms also live in the pool: kv_gdn_state 54 MiB x 2
 # copies per sequence (+ conv/tail/ple ~= 110 MiB a sequence) and the prefix
 # checkpoint region 8 x 55.99 = 448 MiB. So:
-#   pool_mib >= tokens x 13.8125 KiB + 110 x seqs + 448
-#   6912 -> (6912 - 220 - 448) x 1024 / 13.8125 = 462,946 tokens; the engine
-#   reported 462,752 (0.04% page rounding) — 2 x 200,000 with 62k of slack,
-#   and the ledger says it outright: "backs 2 sequences all at 200000 tokens
-#   at once, which is the worst case".
-# (the fp8 pool of 3543 gave 386,904 — it never held 2 x 200k, it held 1.93
-# sessions, and a third long conversation preempted to the host/disk tiers).
-# Secondary cost: the prefix-cache entry grows with the attention plane
-# (one entry 58.50 KiB at fp8 -> 110.50 KiB at bf16, measured on the two boot
-# ledgers' `kv tier transfer` lines), so the host tier below doubles to keep
-# the same number of parked conversations, out of RAM the host has
-# (104 GiB available with the service loaded).
-FRANK_ARCHON_KV_DTYPE=bf16
+#   pool_mib >= tokens x 7.3125 KiB + 110 x seqs + 448
+#   4 x 200,000 at fp8 needs 5,713 + 440 + 448 = 6,601 MiB; the pool is 6,912,
+#   and it predicts (6912 - 440 - 448) x 1024 / 7.3125 = 843,566 tokens, i.e.
+#   FOUR full-height conversations with 5.4 % slack. The ledger line is the
+#   referee ("backs N sequences all at 200000 tokens at once").
+#   At bf16 the same four slots cost 10,791 + 888 = 11,679 MiB, which would
+#   cut the resident slab to 17,441 MiB (-33 % vs the fp8-era 26,071) — that
+#   is why fp8 is not a preference here, it is the only dtype that funds four
+#   slots at this window. The 2026-10-11 bf16 shape (6,912 / seqs 2) backed
+#   462,752 tokens = 2 x 200,000; the historical fp8 pool of 3,543 gave 386,904
+#   (1.93 sessions).
+# Secondary saving: the prefix-cache entry shrinks with the attention plane
+# (one entry 110.50 KiB at bf16 -> 58.50 KiB at fp8, measured on the two boot
+# ledgers' `kv tier transfer` lines), so the host tier below parks twice as
+# many conversations as it did at bf16 — no re-size needed to park four slots.
+FRANK_ARCHON_KV_DTYPE=fp8
 # Spec decode: the checkpoint's own MTP head at the publisher's depth-3
 # operating point (probe() returns 3 when mtp_num_hidden_layers > 0; the
 # flag states it so the ledger records the intent).
 FRANK_ARCHON_SPEC_TOKENS=2
 FRANK_ARCHON_MAX_BATCHED_TOKENS=2048
-# Prefix cache tiers (publisher pattern; disk tier sized for 2 slots).
-# The host tier is sized in ENTRIES, and one entry doubles with the cache
-# dtype (58.50 KiB at fp8 -> 117 KiB at bf16, per the ledger's `kv tier
-# transfer` line): 4096 MiB at bf16 parks ~1.4 sessions of 200k where it
-# parked ~2.9 at fp8. Doubled to keep the capacity, at RAM the host has
-# (104 GiB available with the service loaded).
+# Prefix cache tiers (publisher pattern). The host tier is sized in ENTRIES,
+# and one entry tracks the cache dtype (58.50 KiB at fp8, 117 KiB at bf16, per
+# the ledger's `kv tier transfer` line): at fp8, 8192 MiB parks ~5.8 sessions
+# of 200k (at bf16 the same tier parked ~2.9), so four live slots plus a full
+# parked set fits with the tier as it stands — at RAM the host has (104 GiB
+# available with the service loaded).
 FRANK_ARCHON_PREFIX_HOST_MIB=8192
 FRANK_ARCHON_PREFIX_DISK_MIB=65536
 # Frank's pin law: the PLE n-gram table (47.7 GiB) serves from pinned host
@@ -211,11 +222,17 @@ FRANK_ARCHON_NGRAM_PLACEMENT=ram
 # prefix host = ~147 GiB) rides TTM's shared pages, capped by ttm's
 # pages_limit (the current kernel exposes NO pages_max; the cap function
 # takes the min over the knobs that exist). Below the plan the load dies
-# mid-pin with an allocator error instead of this named refusal — raise the
-# knob first (runtime sysfs write; kernel cmdline fallback + one reboot only
-# if the file is read-only), see the runbook. Cap raised 2026-10-05 to
-# 52,428,800 pages = 200 GiB, which still clears this floor.
+# mid-pin with an allocator error instead of this named refusal.
+# THE CAP IS A RUNTIME KNOB — the kernel default is half of RAM, so every
+# raise dies with a reboot. Measured the hard way: the 2026-10-05 manual raise
+# to 52,428,800 pages (200 GiB) was gone after the 2026-10-12 23:17 POWER
+# FAILURE, the cap fell back to 125,988 MiB, and the preflight refused the
+# start 6,919 times in ~20 h while Restart=always re-ran it. The gate in
+# scripts/ttm-preflight.sh now RAISES the knob itself before refusing (the
+# root unit is privileged; the knob is a 0644 root module parameter), so the
+# recovery is a boot, not a visit to the machine.
 FRANK_ARCHON_TTM_MIN_MIB=150000
+FRANK_ARCHON_TTM_TARGET_MIB=204800
 # Escape hatch for boot-ladder experiments. Unset -> no extra argv. Keep
 # multi-flag values as one string; the serve script expands it unquoted on
 # purpose.