frank-archon shape: MAX_SEQS 2 → 4, HOST_POOL_MIB 44,928 → 49,152, TTM_MIN_MIB 150,000 → 162,000. Same image pin, same payload, same window, same BUSY_PREFILL_CHUNK=auto / PREFILL_INTERLEAVE=1 from #57.
The order
Four slots over a ≥ 700,000-token KV pool, rounding up if the resolver cannot land it exactly.
Why these numbers
The cache's demand is kv_cap = --max-num-seqs × --max-model-len and the card funds kv = min(kv_cap, elastic − experts), where the experts take expert_vram_floor = plane + 2·unit_max − host_room (core/place/planner.cpp:100-104, core/engine_bringup.cpp:1415-1422,1443-1449). So the two knobs are one lever, not two:
4 × 200,000 = 800,000 tokens of demand ≈ 5.85 GiB of paged cache + 0.43 GiB of per-sequence state (the live carve prices that at 7.48 kB/token and 110 MiB/sequence a card).
The live ledger pins the expert plane at 67.60 GiB a rank (a 23.73 GiB floor at 43.875 GiB of host room), so HOST_POOL_MIB=49,152 puts the floor at 19.61 GiB and leaves the cache ~6.9 GiB — enough to fund the whole 800k target, with the leftover returned to the experts. At the old 44,928 the cache could only ever get 2.76 GiB = 365,204 tokens, so 4 slots alone would have bought admission without backing.
TTM_MIN_MIB follows the pin ledger: the pool is pinned once per rank, so 96.0 GiB of host pool + 47.7 GiB PLE + 8 GiB prefix + 2 GiB arena/static + the auto checkpoint store, now 40 slots × 112 MiB = 161,848 MiB. The bats ledger guard now counts the checkpoint store because it grows with the slot count, and the two env-value assertions in that seam are bumped with the values they guard.
Costs, stated before the boot
Pinned host RAM 87.75 → 96.0 GiB for the pool (total pin ~159 GiB against the 200 GiB TTM target the preflight raises the knob to; host has 246 GiB).
~3.2 GiB a card of expert residency, which now lives in host RAM and is read over the x8 Gen5 ceiling when the router picks it. Decode-only steps were 15.5 ms at 90 % residency; that is the number this pays, and the §9 census is where it shows.
Four slots at 200k = 800k of demand against a pool that will back ~730–800k. Still an over-commit at full height; preemption (vllm:num_preemptions_total) remains the observable.
Verification plan
./tests/run.sh green before merge (archon seam: 20/20 locally).
Post-boot, the ledger is the referee: vram_kv / kv: the cache can grow to … tokens must read ≥ 700,000; --checkpoint-slots must come back 40; queue_cap 32.
scripts/probe-frank-archon-kv.py (the capacity leg), then one chat turn, one tool call, one vision probe.
If vram_kv comes back under 700,000 tokens: HOST_POOL_MIB goes up 1,024 and this redeploys — written into the env comment so the next agent does not re-derive it.
## What changes
`frank-archon` shape: `MAX_SEQS 2 → 4`, `HOST_POOL_MIB 44,928 → 49,152`, `TTM_MIN_MIB 150,000 → 162,000`. Same image pin, same payload, same window, same `BUSY_PREFILL_CHUNK=auto` / `PREFILL_INTERLEAVE=1` from #57.
## The order
Four slots over a **≥ 700,000-token** KV pool, rounding **up** if the resolver cannot land it exactly.
## Why these numbers
The cache's demand is `kv_cap = --max-num-seqs × --max-model-len` and the card funds `kv = min(kv_cap, elastic − experts)`, where the experts take `expert_vram_floor = plane + 2·unit_max − host_room` (`core/place/planner.cpp:100-104`, `core/engine_bringup.cpp:1415-1422,1443-1449`). So the two knobs are one lever, not two:
- 4 × 200,000 = **800,000 tokens of demand** ≈ 5.85 GiB of paged cache + 0.43 GiB of per-sequence state (the live carve prices that at 7.48 kB/token and 110 MiB/sequence a card).
- The live ledger pins the expert plane at **67.60 GiB a rank** (a 23.73 GiB floor at 43.875 GiB of host room), so `HOST_POOL_MIB=49,152` puts the floor at **19.61 GiB** and leaves the cache **~6.9 GiB** — enough to fund the whole 800k target, with the leftover returned to the experts. At the old 44,928 the cache could only ever get 2.76 GiB = 365,204 tokens, so 4 slots alone would have bought admission without backing.
- `TTM_MIN_MIB` follows the pin ledger: the pool is **pinned once per rank**, so 96.0 GiB of host pool + 47.7 GiB PLE + 8 GiB prefix + 2 GiB arena/static + the auto checkpoint store, now 40 slots × 112 MiB = **161,848 MiB**. The bats ledger guard now counts the checkpoint store because it grows with the slot count, and the two env-value assertions in that seam are bumped with the values they guard.
## Costs, stated before the boot
1. **Pinned host RAM 87.75 → 96.0 GiB** for the pool (total pin ~159 GiB against the 200 GiB TTM target the preflight raises the knob to; host has 246 GiB).
2. **~3.2 GiB a card of expert residency**, which now lives in host RAM and is read over the x8 Gen5 ceiling when the router picks it. Decode-only steps were 15.5 ms at 90 % residency; that is the number this pays, and the §9 census is where it shows.
3. Four slots at 200k = 800k of demand against a pool that will back ~730–800k. Still an over-commit at full height; preemption (`vllm:num_preemptions_total`) remains the observable.
## Verification plan
- `./tests/run.sh` green before merge (archon seam: 20/20 locally).
- Post-boot, the ledger is the referee: `vram_kv` / `kv: the cache can grow to … tokens` must read **≥ 700,000**; `--checkpoint-slots` must come back 40; `queue_cap` 32.
- `scripts/probe-frank-archon-kv.py` (the capacity leg), then one chat turn, one tool call, one vision probe.
- **If `vram_kv` comes back under 700,000 tokens: `HOST_POOL_MIB` goes up 1,024 and this redeploys** — written into the env comment so the next agent does not re-derive it.
## Rollback
`MAX_SEQS=2`, `HOST_POOL_MIB=44928`, `TTM_MIN_MIB=150000` — one commit revert (`1bb6399`), redeploy `--service frank-archon`.
---
cwd: /home/blank/.omp/wt/wt-20261020-213526-6d1fc1f · session: 01a15cbe-157e-7527-b4b5-22f3d2feea00
Frank's order: 4 slots, a 700k pool, round UP if the resolver cannot land it
exactly. The cache target is MAX_SEQS x MAX_MODEL_LEN, so the demand is
800,000 fp8 tokens; the resolver funds ~91-93 % of demand (three boots of
evidence on the endpoint page), which clears 700k, and the VRAM has to come
from the expert plane -- which has to go somewhere, so HOST_POOL_MIB moves with
it. expert_vram_floor (core/place/planner.cpp:100-104) is exactly
plane + 2 units - host_room, and the live boot ledger pins that plane at 67.60
GiB a rank (23.73 GiB floor at 44,928 of room), so 49,152 drops the floor to
19.61 GiB and leaves the cache ~6.9 GiB: enough for the whole target, with the
leftover returned to the experts.
Costs, both real: pinned host RAM 87.75 -> 96.0 GiB (the pool is pinned once per
rank) and ~3.2 GiB a card of expert residency, read over the x8 Gen5 link when
the router picks a host-resident expert. The boot ledger's vram_kv line is the
referee; if it comes back under 700,000 tokens HOST_POOL_MIB goes up 1024 and
this redeploys.
TTM_MIN_MIB 150,000 -> 162,000 for the new pin ledger (2 x pool + PLE 48,824 +
prefix 8,192 + MNBT 2,048 + the auto checkpoint store, now 40 slots of 112 MiB =
161,848 MiB), and the bats ledger guard now counts the checkpoint store because
it grows with the slot count. The two env-value assertions in that seam are
bumped with the values they guard.
Frank's order: 4 slots, a 700k pool, round UP if the resolver cannot land it
exactly. The cache target is MAX_SEQS x MAX_MODEL_LEN, so the demand is
800,000 fp8 tokens; the resolver funds ~91-93 % of demand (three boots of
evidence on the endpoint page), which clears 700k, and the VRAM has to come
from the expert plane -- which has to go somewhere, so HOST_POOL_MIB moves with
it. expert_vram_floor (core/place/planner.cpp:100-104) is exactly
plane + 2 units - host_room, and the live boot ledger pins that plane at 67.60
GiB a rank (23.73 GiB floor at 44,928 of room), so 49,152 drops the floor to
19.61 GiB and leaves the cache ~6.9 GiB: enough for the whole target, with the
leftover returned to the experts.
Costs, both real: pinned host RAM 87.75 -> 96.0 GiB (the pool is pinned once per
rank) and ~3.2 GiB a card of expert residency, read over the x8 Gen5 link when
the router picks a host-resident expert. The boot ledger's vram_kv line is the
referee; if it comes back under 700,000 tokens HOST_POOL_MIB goes up 1024 and
this redeploys.
TTM_MIN_MIB 150,000 -> 162,000 for the new pin ledger (2 x pool + PLE 48,824 +
prefix 8,192 + MNBT 2,048 + the auto checkpoint store, now 40 slots of 112 MiB =
161,848 MiB), and the bats ledger guard now counts the checkpoint store because
it grows with the slot count. The two env-value assertions in that seam are
bumped with the values they guard.
dank
merged commit 7993a336bf into main2026-10-20 23:14:35 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What changes
frank-archonshape:MAX_SEQS 2 → 4,HOST_POOL_MIB 44,928 → 49,152,TTM_MIN_MIB 150,000 → 162,000. Same image pin, same payload, same window, sameBUSY_PREFILL_CHUNK=auto/PREFILL_INTERLEAVE=1from #57.The order
Four slots over a ≥ 700,000-token KV pool, rounding up if the resolver cannot land it exactly.
Why these numbers
The cache's demand is
kv_cap = --max-num-seqs × --max-model-lenand the card fundskv = min(kv_cap, elastic − experts), where the experts takeexpert_vram_floor = plane + 2·unit_max − host_room(core/place/planner.cpp:100-104,core/engine_bringup.cpp:1415-1422,1443-1449). So the two knobs are one lever, not two:HOST_POOL_MIB=49,152puts the floor at 19.61 GiB and leaves the cache ~6.9 GiB — enough to fund the whole 800k target, with the leftover returned to the experts. At the old 44,928 the cache could only ever get 2.76 GiB = 365,204 tokens, so 4 slots alone would have bought admission without backing.TTM_MIN_MIBfollows the pin ledger: the pool is pinned once per rank, so 96.0 GiB of host pool + 47.7 GiB PLE + 8 GiB prefix + 2 GiB arena/static + the auto checkpoint store, now 40 slots × 112 MiB = 161,848 MiB. The bats ledger guard now counts the checkpoint store because it grows with the slot count, and the two env-value assertions in that seam are bumped with the values they guard.Costs, stated before the boot
vllm:num_preemptions_total) remains the observable.Verification plan
./tests/run.shgreen before merge (archon seam: 20/20 locally).vram_kv/kv: the cache can grow to … tokensmust read ≥ 700,000;--checkpoint-slotsmust come back 40;queue_cap32.scripts/probe-frank-archon-kv.py(the capacity leg), then one chat turn, one tool call, one vision probe.vram_kvcomes back under 700,000 tokens:HOST_POOL_MIBgoes up 1,024 and this redeploys — written into the env comment so the next agent does not re-derive it.Rollback
MAX_SEQS=2,HOST_POOL_MIB=44928,TTM_MIN_MIB=150000— one commit revert (1bb6399), redeploy--service frank-archon.cwd: /home/blank/.omp/wt/wt-20261020-213526-6d1fc1f · session: 01a15cbe-157e-7527-b4b5-22f3d2feea00