frank-large: double the KV pool to 524288 positions

HALOGEN_KV_POOL_POSITIONS 262144 -> 524288, which is upstream's own
default (2 x HALOGEN_CTX). The old pool was the binding constraint on
concurrency, not context: a request reserves prompt + max_tokens against
the pool, so with pool == CTX four concurrent 65k chats were contending
for one full-length conversation's worth of positions. Two full-length
conversations, or four at 131k, now stay resident.

Cost is ~7.2 GiB more device RAM (measured 28 KiB/position), taken from
the page cache the 47.7 GiB n-gram lookup table reads through. Live
startup ledger for the prior config: 68.0 weights + 7.2 pool + 21.1
working = 96.3 GiB held, 12.1 GiB left on the host. The doubled pool
puts the remainder near 5 GiB against a ~4.3 GiB co-tenant working set,
and cache at ~69 GiB -- still above the lookup table, so the table can
stay hot. Compensating lever if long prompts start crawling:
HALOGEN_MAX_TOK=16384, which frees 8.3 GiB of prefill arena for ~8%
of prefill throughput.

Docs updated to match, including the admission-trap paragraph, which was
only true while pool == CTX.

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

@@ -34,12 +34,22 @@
 # that then takes the remainder can stall both for minutes at full CPU with no
 # disk activity and no output. That is documented behaviour, not a crash, and
 # the escape hatch is HALOGEN_FLASH_PIN_TRUNK=0 (at several times the decode
-# cost). Sizing chosen 2026-09-11 for a SHARED 121 GiB host: KV pool 262,144
-# positions (~7.2 GiB) + the baked 32,768-token prefill arena (16.7 GiB) sits
-# well inside the device budget once the ~68 GiB of weights and the ~5 GiB of
-# co-tenant containers are accounted for. HALOGEN_KV_POOL_FIT stays on as the
-# safety net: if the machine refuses, the engine lowers the pool itself and
-# prints what it chose.
+# cost). Sizing is chosen for a SHARED 121 GiB host, and HALOGEN_KV_POOL_FIT
+# stays on as the safety net: if the machine refuses the configured pool the
+# engine lowers it itself and prints what it settled on. Read that ledger on
+# every restart — it is the ground truth for sizing, not this comment.
+#
+# DOUBLED 2026-09-12: pool 524,288 positions (~14.4 GiB at the measured
+# 28 KiB/position). Measured startup ledger for the prior 262,144 config was
+# 68.0 weights + 7.2 pool + 21.1 working = 96.3 GiB held, 12.1 GiB left on
+# the host. The doubled pool puts that remainder at roughly 5 GiB against a
+# ~4.3 GiB co-tenant working set, and the extra 7.2 GiB comes out of the
+# page cache the 47.7 GiB n-gram lookup table reads through. The table still
+# fits the ~69 GiB of cache that remains, so this is a tighter-but-sane
+# position rather than an overcommit. If long prompts start crawling with the
+# disk busy, the compensating lever is HALOGEN_MAX_TOK=16384: it shrinks the
+# prefill arena 16.7 -> 8.4 GiB, which pays for the doubling outright at
+# about 8% of prefill throughput.
 #
 # WEIGHTS. HALOGEN_DOWNLOAD fetches the whole weights repo on FIRST START ONLY
 # (the entrypoint checks whether the checkpoint is absent) into the bind mount
@@ -86,10 +96,12 @@ 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
-# Conservative pool for a shared host: one full-length conversation, or four
-# at 65k. Raising it to 524288 doubles the resident conversations for ~7 GiB
-# more device memory — do that only after reading the startup ledger.
-Environment=HALOGEN_KV_POOL_POSITIONS=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.
+Environment=HALOGEN_KV_POOL_POSITIONS=524288
 Environment=HALOGEN_KV_SLOTS=4
 # 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