frank-large: record the 32k outcome — the doubling is clamped away, docs resynced

Deployed HALOGEN_MAX_TOK=32768 by operator call (upstream default, full prefill
speed) and confirmed the prediction from the ledger:

  kv pool: 524288 positions need ~35.0 GiB ... LOWERING THE POOL TO 262144 (~27.8 GiB)
  memory: 68.0 weights + 7.2 KV pool + 21.1 working = 96.3 GiB in all

so the effective pool is 262144 again and the doubling this task set out to do
is not in force. Healthy, completion verified. Left the pool requesting 524288
deliberately: with KV_POOL_FIT on that is a grow-if-RAM-frees-up declaration,
not a mistake.

Two corrections to what I wrote earlier today:

1. The engine's sizing block, and its "WARNING even 262144 ... host RAM cannot
   spare it" line, print ONLY when the fit check had to clamp something. The
   09-11 baseline boot prints no kv pool: sizing lines at all. So the absence
   of a warning in old logs was never evidence of headroom.

2. The budget needs a vision term. Actual need is pool + arena + 1.97 GiB of
   vision tower, not pool + a 1.5 GiB nominal margin. That makes the ceiling
   for a doubled pool max_tok <= 18,130 rather than 19,115, and it means the
   32768/262144 corner this box has run in since 09-11 is ~0.3 GiB OVER its own
   stated budget -- and has been the whole time. It boots and serves with
   12-14 GiB genuinely free because the 24 GiB reserve is generous. A soft
   floor, not a wall.

The arena model also reproduces upstream's three published "on the device"
figures exactly (35 / 42 / 41 GiB), confirming they are pool+arena totals at
the default max_tok and not pool-only -- which is the misreading that made the
doubling look affordable in my first estimate.

dankclaw/frank-large/quadlet/frank-large.container

@@ -97,39 +97,39 @@ Environment=HALOGEN_DOWNLOAD=peonist-ai/halogen-qwen3.8-flash-next
 Environment=HALOGEN_MODEL_ID=frank-large
 # Native context of the model. Matches what both clients declare.
 Environment=HALOGEN_CTX=262144
-# Doubled 2026-09-12 from 262144 to upstream's own default (2 x HALOGEN_CTX):
-# two full-length conversations resident at once, or four at 131k, instead of
-# one. The old pool was the binding constraint on concurrency, not CTX — a
-# request reserves prompt + max_tokens against the pool, so four 65k chats
-# used to contend for one 262k pool.
+# Requested 2026-09-12 as double the 262144 this had run since 09-11, to get
+# two full-length conversations resident instead of one. NOTE THE ASYMMETRY
+# BELOW: with HALOGEN_MAX_TOK at 32768 (current) the fit check clamps this to
+# 262144 at every boot, so the EFFECTIVE pool is 262144 and only one
+# full-length conversation stays resident. It is left at 524288 deliberately:
+# it is a "grow if the RAM frees up" declaration, and HALOGEN_KV_POOL_FIT
+# raises nothing but honours it the moment the arena stops eating the budget.
+# Set HALOGEN_MAX_TOK=16384 to actually get the doubled pool today.
 Environment=HALOGEN_KV_POOL_POSITIONS=524288
 Environment=HALOGEN_KV_SLOTS=4
-# LOAD-BEARING. This line is what makes the doubling above real; do not
-# "clean it up". The device budget here is 121 GiB - 67.7 resident weights
-# - 24.0 reserved for the n-gram page cache and the OS = 29.5 GiB, and that
-# one budget carries BOTH the KV pool and the prefill arena.
+# The device budget is ONE budget, covering the KV pool, the prefill arena and
+# the vision tower:
 #
-# Measured across three restarts on 2026-09-12. The arena (the engine's
-# "everything but the pool" figure) is linear in this flag: 3.80 GiB of base
-# plus 8.40 GiB per 16384 tokens.
-#   16384 -> arena 12.2, 524288 needs 26.6 -> FITS
-#   32768 -> arena 20.6, 524288 needs 35.0 -> fit lowers the pool to 262144
-#   65536 -> arena 37.3, even 262144 needs 44.5 -> OOM, dmalloc FAILED at 39.97
-# So 16384 is not conservative, it is the ceiling: 29.5 budget - 1.5 margin -
-# 14.4 pool leaves 13.6 for the arena, i.e. max_tok <= 19,115, and 16384 is
-# the largest power of two under that. The reverse checks too — put max_tok
-# back to 32768 and only 7.4 GiB is left for the pool, about 269k positions,
-# which is exactly the 262144 config this replaced. Those two corners are the
-# only points of this box that have ever run here.
+#   budget = 121 host - 67.7 resident weights - 24.0 reserve = 29.5 GiB
+#   need   = KV(~28 KiB/position) + arena + vision(1.97 measured)
+#   arena  = 3.80 GiB + 8.40 GiB x (HALOGEN_MAX_TOK / 16384)
 #
-# Do NOT raise this flag past 16384 while the pool stays doubled: 65536 does
-# not shrink the pool, it stops the server booting at all — and the unit still
-# reads active with the container "Up (starting)", so the health check waits
-# out LLM_WAIT rather than failing fast.
-
-# EXPERIMENT 2026-09-12 (operator call): back to upstream's default 32768.
-# Model predicts 524288 needs 35.0 against a 29.5 budget, so HALOGEN_KV_POOL_FIT
-# should clamp the pool to 262144 (~27.8) at boot. Watch the ledger.
+# That arena term is linear in max_tok and was checked against five restarts
+# and against upstream's three published "on the device" figures, all to
+# 0.1 GiB. Measured on this host:
+#   max_tok 16384 -> arena 12.2, pool 524288 total 28.6 -> FITS, 0.9 spare
+#   max_tok 32768 -> arena 20.6, pool 524288 total 37.0 -> clamps to 262144
+#   max_tok 32768 -> pool floor 262144 total 29.8 -> 0.3 OVER budget, boots
+#   max_tok 65536 -> arena 37.3, even the floor needs 46.5 -> OOM, no boot
+# So 16384 is the ceiling for a doubled pool, not a conservative setting. The
+# 0.3 over-budget at the 32768/262144 corner is where this box has been ever
+# since it was deployed on 09-11; the 24 GiB reserve is generous, so it boots
+# and serves with 12-14 GiB genuinely left. It is a soft floor, not a wall.
+#
+# Do NOT raise max_tok past 16384 while asking for the doubled pool: 65536 did
+# not shrink the pool, it stopped the server booting — and the unit still reads
+# active with the container "Up (starting)", so the health check waits out
+# LLM_WAIT rather than failing fast.
 Environment=HALOGEN_MAX_TOK=32768
 # RAM left for the n-gram table the engine reads through the page cache.
 # Above the vendor's 20 because a dozen containers share this host; too low