docs(vault): fleet-wide fact re-verification pass (67 pages)

The docs-fact census wave re-read the live hosts and re-keyed every page it could: runtime/payload identities, ports, sizes, ledger figures, unit state, and the retirement banners that drifted as the fleet moved. The wave was interrupted mid-run, so this commit carries only what passed the integrity gates: every touched page parses (front matter or H1+status convention intact, balanced fences, no truncated tables, trailing newline), the docs_completeness and link-integrity seams are green, and bats is 384/384. Numbers that this session proved on live hosts are keyed to the measured value, not the page's earlier claim.
2026-10-18 13:15:43 -07:00
1 parent 466fd477d8
commit e7f0d93c86
@@ -16,9 +16,19 @@ priority and the exact action.
 Dates: researched 2026-08. Hardware is verified on the live machine unless
 marked "verify first". Re-verified 2026-08-15/16; corrections marked below.

+**Live today (2026-10-18).** The era described below — llama.cpp on the 8060S
+iGPU behind :7770 — is retired. Dankclaw now serves
+[[frank-dragoon-flash-server-v2-native]] (halogen-flash-server 0.16.2, port
+7770) and [[frank-zealot-llama-prism-bonsai2-pq20]] (llama.cpp PrismML fork on
+the RTX 3090, port 7771 — drift today: that unit is `failed` since 2026-10-18
+03:40 and a hand-run 9B-MTP process answers the port), and boots `iommu=pt` since 2026-10-18
+([[dankclaw-iommu-translation-off]]). The numbers below are the measurements of
+the era they were taken in; the `ttm` ceiling and the NVMe scheduler rows were
+re-checked 2026-10-18 and still hold.
+
 ## Corrections (re-verified 2026-08-15/16)

- **Backend**: production is **Vulkan0**, not ROCm. Measured on this box
+- **Backend**: that era's production was **Vulkan0**, not ROCm. Measured on this box
  (b10433): Vulkan 25.13 t/s vs ROCm 24.33 t/s decode at 16k; at 262k ctx
  Vulkan decodes 48% faster (5.68 vs 3.83 t/s). ROCm wins prefill (410 vs
  302 t/s @64k). The "HIP out-performs Vulkan for decode" claim did not
@@ -26,9 +36,12 @@ marked "verify first". Re-verified 2026-08-15/16; corrections marked below.
 - **Power profile**: the `/sys/class/drm/card0/device/power_profile` file
  does not exist on this machine (checked 2026-08-15). GPU DPM is already
  `performance`, forced level `auto`. This item is N/A.
- **KV cache**: production runs `q8_0` K **and** `q8_0` V (both quantized).
- **Spec**: DFlash/DSpark are retired. Production is `--spec-default`
-  (ngram-mod) with draft-mtp first. See [[qwen3.8-spec-matrix]].
+- **KV cache**: production ran `q8_0` K **and** `q8_0` V (both quantized). The law
+  still holds on `frank-zealot` (`CACHE_TYPE_K=q8_0`, `CACHE_TYPE_V=q8_0` —
+  `scripts/frank-zealot.env:55-56`).
+- **Spec**: DFlash/DSpark are retired. That era's production was `--spec-default`
+  (ngram-mod) with draft-mtp first. See [[qwen3.8-spec-matrix]]. Today `frank-zealot`
+  is configured with speculation **off** (`SPEC_TYPE=none` — `scripts/frank-zealot.env:67`).
 - **TTM**: raised to 114 GiB on 2026-08-25, set live (no reboot) and
  persisted in `/etc/modprobe.d/ttm.conf`. The effective VRAM ceiling that
  once held the service at ~15 GiB is gone.
@@ -39,21 +52,31 @@ marked "verify first". Re-verified 2026-08-15/16; corrections marked below.
 | ------ | ----- | ------ |
 | OS physical RAM | 30.5 GiB | `/proc/meminfo` |
 | TTM pages_limit | 114 GiB (29,883,536 x 4KiB) — raised 2026-08-25 | `/sys/module/ttm/parameters/pages_limit` |
-| ROCm VRAM total | 96.0 GiB | `rocm-smi --showmeminfo vram` |
+| ROCm VRAM total | 96.0 GiB | `rocm-smi --showmeminfo vram` under the then firmware VGM carve |
 | ROCm VRAM used | 76.2 GiB | `rocm-smi` while serving 3x200700 |

-The OS accounts only ~30.5 GiB physical RAM. The TTM GPU-addressable pool
-was capped at ~15.24 GiB (the real pre-2026-08-25 ceiling); that cap is now
-lifted to 114 GiB. ROCm/SMI still reports a 96 GiB VRAM carve-out (VGM) — a
-different, driver-reported figure that has always been larger than the kernel
-cap.
+That 2026-08 reading is the firmware-VGM era: the BIOS carved ~96 GiB as
+"dedicated" iGPU VRAM, so the kernel saw only ~30 GiB (the same split is
+recorded in [[ling-3.0-flash-trial]] §Why Vulkan + GTT). The OS now accounts
+**121 GiB** (`MemTotal 127108080 kB`, 2026-10-18) and `rocm-smi
+--showmeminfo vram` reports **2.0 GiB** (2,147,483,648 B) of dedicated VRAM —
+the carve is gone and the GPU budget is the GTT aperture, not the SMI figure
+([[Dankclaw System Specs]]).
+The TTM row above is still live: `pages_limit = 29883536` (114 GiB) and
+`/etc/modprobe.d/ttm.conf` still carries the `options ttm` line (both read
+2026-10-18).
+
 This split is the Strix Halo GTT/VGM design. It drives the batch/ubatch memory
 limits documented in [[frank-dragoon-benchmark]].

 ## 1. Self-Hosted Agentic Tools

-All of these connect to the local llama.cpp OpenAI-compatible endpoint
-(`http://localhost:7770/v1`). None need NVIDIA.
+All of these connect to the local OpenAI-compatible endpoint
+(`http://127.0.0.1:7770/v1`). Today that port is **halogen-flash-server**, not a
+llama.cpp server, and the address must be the IPv4 literal: `curl
+http://localhost:7770/v1/models` returns nothing while
+`http://127.0.0.1:7770/v1/models` answers 200 (checked 2026-10-18 — the rootless
+podman publish is IPv4-only). None need NVIDIA.

 | Tool | Use | Endpoint config | Priority |
 | ---- | --- | --------------- | -------- |
@@ -67,7 +90,8 @@ All of these connect to the local llama.cpp OpenAI-compatible endpoint
 | Qdrant | Vector store for RAG | Standalone, CPU-native | Low |

 The pragmatic first installs are Open WebUI, Cline, and Aider. They all work
-with the current llama.cpp server and need no extra GPU.
+with the endpoint on 7770 and need no extra GPU. The 7770 endpoint today is
+halogen-flash-server, not llama.cpp.

 ## 2. Inference Runtime Tuning (llama.cpp on gfx1151)

@@ -90,8 +114,8 @@ All require root and a reboot for the modprobe change.
 | Setting | Action | Effect | Priority |
 | ------- | ------ | ------ | -------- |
 | TTM GPU pool | `/etc/modprobe.d/ttm.conf` → `options ttm pages_limit=29883536 page_pool_size=29883536` (applied 2026-08-25, set live then persisted) | Lifts the 15 GiB cap to 114 GiB; the full 262k KV + Q8 AGENT payload fit in one slot | Done |
-| Power profile | **N/A on this machine** (2026-08-15): no `power_profile` sysfs; GPU DPM already `performance` | none | ~~Medium~~ |
-| NVMe scheduler | Already `none` (`[none]` confirmed) | No change | Done |
+| Power profile | **N/A on this machine** (2026-08-15; re-checked 2026-10-18: no `power_profile` under `/sys/class/drm/card0/device/` or `card1/device/`); GPU DPM already `performance` | none | ~~Medium~~ |
+| NVMe scheduler | Already `none` (`[none] mq-deadline` in `/sys/block/nvme0n1/queue/scheduler`, re-read 2026-10-18) | No change | Done |
 | BIOS VGM | Set Variable Graphics Memory / UMA to "High" in the EVO-X2 BIOS | Max dedicated VRAM for the GPU carve-out; verify in the live BIOS | Verify |
 | Firmware/EC | Check GMKtec for a newer EC/fan-curve firmware | Better sustained thermal behavior | Verify |

@@ -99,8 +123,8 @@ All require root and a reboot for the modprobe change.

 - Test `--spec-draft-n-max 5` and re-benchmark acceptance; if throughput rises,
  change the env tunable.
- Consider switching the disabled `vllm-thinkingcap.service` unit off or
-  removing it to avoid confusion (it is loaded in a failed state).
+- The `vllm-thinkingcap.service` unit this item told you to clean up is gone:
+  `systemctl is-enabled vllm-thinkingcap.service` → `not-found` (2026-10-18).
 - Profile generation under 3-slot concurrent load before touching boot
  settings, so any tuning is measured against the real workload.

@@ -10,7 +10,7 @@ timestamp: 2026-09-03

 ## Server Overview

-Dankclaw is an AMD APU server for CIRU ROCmFPX llama.cpp inference. The host runs Ubuntu 26.04 with an AMD Ryzen AI MAX+ 395 Strix Halo APU. The APU uses unified memory — CPU and GPU share the same physical RAM pool.
+Dankclaw is an AMD APU + RTX 3090 inference host. It ran CIRU ROCmFPX llama.cpp inference through 2026-08-22 ([[ciru-activefpx-promptforge]], retired). The host runs Ubuntu 26.04 with an AMD Ryzen AI MAX+ 395 Strix Halo APU. The APU uses unified memory — CPU and GPU share the same physical RAM pool. Today it serves [[frank-dragoon-flash-server-v2-native]] (halogen-flash-server 0.16.2 on the iGPU, port 7770) and [[frank-zealot-llama-prism-bonsai2-pq20]] (llama.cpp PrismML fork on the RTX 3090, port 7771).
 ## Hardware Specifications

 ### CPU
@@ -22,7 +22,7 @@ Dankclaw is an AMD APU server for CIRU ROCmFPX llama.cpp inference. The host run
 | Cores | 16 (1 socket, 1 thread per core) |
 | Max MHz | 5187.50 |
 | Min MHz | 625.00 |
-| NUMA Nodes | 1 (node 0, 31213 MB) |
+| NUMA Nodes | 1 (node 0, 124129 MB — `Node 0 MemTotal: 127108080 kB`, read 2026-10-18) |

 ### GPU (Integrated)

@@ -31,8 +31,8 @@ Dankclaw is an AMD APU server for CIRU ROCmFPX llama.cpp inference. The host run
 | Model | AMD Radeon 8060S (Strix Halo) |
 | Device ID | 0x1586 |
 | Architecture | gfx1151 (Strix Halo) |
-| GPU-Visible Memory | ~114 GiB GTT aperture (the budget; `gtt_total`; rocm-smi's smaller SVM carve-out is not the budget) |
-| Physical RAM | 64 GiB (61 GiB visible; upgraded from 32 GB, corrected 2026-08-17) |
+| GPU-Visible Memory | ~114 GiB GTT aperture (the budget; `mem_info_gtt_total` = 122,402,963,456 B read 2026-10-18; rocm-smi's smaller SVM carve-out is not the budget) |
+| Physical RAM | 121 GiB visible to the OS (`free -g` total 121, read 2026-10-18) on a 128 GB part — 8 × 16 GB LPDDR5 ([[ling-3.0-flash-trial]] §hardware). The 64 GiB this page recorded as "corrected 2026-08-17" (from 32 GB) is stale |

 ### NPU

@@ -41,12 +41,12 @@ Dankclaw is an AMD APU server for CIRU ROCmFPX llama.cpp inference. The host run
 | Model | AMD XDNA2 (Ryzen AI) |
 | Rating | 50 TOPS |
 | Device | /dev/accel/accel0 |
-| Driver | amdxdna 0.7 (in-tree, kernel 7.0.0-29-generic) |
-| Firmware | 1.1.2.65 |
-| Runtime | FastFlowLM 0.9.45 + XRT (installed 2026-08-16; **retired 2026-09-11** with the `amd_iommu=off` decision) |
-| Status | Not in service. Research only. See [[FastFlowLM NPU Inference]] |
+| Driver | amdxdna 0.7.0, in-tree — bound since 2026-10-18 (`lspci -k -s c6:00.1` → `Kernel driver in use: amdxdna`; journal 2026-10-18 01:25:14 `Initialized amdxdna_accel_driver 0.7.0 for 0000:c6:00.1 on minor 0`) |
+| Firmware | 1.1.2.65 (`/usr/lib/firmware/amdnpu/17f0_11/npu_7.sbin` → `npu.sbin.1.1.2.65.zst`, loaded at boot 2026-10-18 01:25:13) |
+| Runtime | None installed. FastFlowLM 0.9.45 + XRT (installed 2026-08-16) was **retired 2026-09-11** with the `amd_iommu=off` decision — see [[dankclaw-iommu-translation-off]]; the package remains at `/home/dank/GitPackages/fastflowlm_0.9.45_ubuntu26.04_amd64.deb` |
+| Status | Not in service — no NPU endpoint is deployed. The device itself is usable since the 2026-10-18 `iommu=pt` boot (`/dev/accel/accel0` present, `crw-rw---- root:render 261,0`); Gitea issue #3 tracks enablement. See [[FastFlowLM NPU Inference]] |

-The NPU is retired (2026-09-11). The `frank-zealot` name now serves Gemma4-12B QAT on the RTX 3090 via llama.cpp (see [[frank-zealot-gemma4-12b]]).
+The NPU endpoint is retired (2026-09-11; [[frank-npu]]). The `frank-zealot` name now serves **Ternary-Bonsai-2-27B-PQ2_0** on the RTX 3090 via the llama.cpp PrismML fork (see [[frank-zealot-llama-prism-bonsai2-pq20]]); the Gemma4-12B QAT rung it once pointed at is retired history ([[frank-zealot-gemma4-12b]], 2026-09-17 → 10-01).

 ### ROCm

@@ -54,7 +54,7 @@ The NPU is retired (2026-09-11). The `frank-zealot` name now serves Gemma4-12B Q
 |----------|-------|
 | ROCk Module | Loaded |
 | Runtime Version | 1.18 |
-| ROCm Version | 7.2.4 system (/opt/rocm) + TheRock 7.15 SDK in the CIRU venv (used for the runtime) |
+| ROCm Version | 7.2.4 system (`/opt/rocm/.info/version` = 7.2.4, read 2026-10-18). The TheRock 7.15 SDK that lived in the CIRU venv left the serving path when CIRU was retired 2026-08-22 |
 | Agent Name | AMD RYZEN AI MAX+ 395 w/ Radeon 8060S |
 | GPU Arch | gfx1151 (Strix Halo) |
 | GPU Global Memory | ~114 GiB GTT aperture (the budget) |
@@ -63,22 +63,22 @@ The NPU is retired (2026-09-11). The `frank-zealot` name now serves Gemma4-12B Q

 | Property | Value |
 |----------|-------|
-| System RAM | 64 GiB (shared CPU + GPU; 61 GiB visible) |
-| GPU-Visible (ROCm) | ~114 GiB GTT aperture (the budget) |
-| Swap | 8.0 GiB |
-| /dev/shm | ~15 GiB (half of RAM) |
+| System RAM | 121 GiB (shared CPU + GPU; `free -g` total 121, `MemTotal 127108080 kB`, 2026-10-18) |
+| GPU-Visible (ROCm) | ~114 GiB GTT aperture (`mem_info_gtt_total` 122,402,963,456 B — the budget) |
+| Swap | 64 GB `/swap.img` (`swapon`, 2026-10-18; `free` reports 63 GiB) |
+| /dev/shm | 61 GiB tmpfs (half of RAM, `df /dev/shm`, 2026-10-18) |

 ### Storage

 | Filesystem | Size | Used | Avail | Use% |
 |------------|------|------|-------|------|
-| / (nvme0n1p2) | 1.9T | 1.3T | 545G | 70% |
+| / (nvme0n1p2) | 1.9T | 1.4T | 424G | 77% |

 ### Network

 | Interface | Type | Speed | IP | Notes |
 |-----------|------|-------|----|-------|
-| eno1 | onboard | 2500 Mb/s (2.5 GbE) | 192.168.0.143 (DHCP) | Carries the RPC path to Dankserver since 2026-08-17. Default route via 192.168.0.1. |
+| eno1 | onboard | 2500 Mb/s (2.5 GbE) | 192.168.0.143 (DHCP) | Carried the RPC path to Dankserver during the 2026-08-17 pipeline-parallelism trial; no RPC listener runs today (`ss -ltn` shows no :50052, 2026-10-18). Default route via 192.168.0.1. |
 | enx00e04cc2e1e5 | USB-C to Ethernet adapter | 1000 Mb/s | 192.168.0.116 | UNPLUGGED 2026-08-17. While present, the route to 192.168.0.235 went through this adapter (lower route metric), so all RPC traffic was capped at 1 GbE. See [[Pipeline Parallelism/Ethernet Bandwidth Math]] section 0. |
 | docker0 | bridge | - | 172.17.0.1 | Usually down. |

@@ -92,19 +92,20 @@ cable between claw and server is required for 10G.
 | Property | Value |
 |----------|-------|
 | OS | Ubuntu 26.04 LTS (Resolute Raccoon) |
-| Kernel | 7.0.0-29-generic |
-| Python | 3.14.4 (system), 3.12.13 (CIRU venv) |
-| CIRU runtime | ciru-ai/ROCmFPX v2.3 (llama-server, ROCm 7.15 SDK) |
-| uv | 0.12.2 |
+| Kernel | 7.0.0-38-generic (`uname -r`, 2026-10-18) |
+| Boot line | `iommu=pt` since 2026-10-18 (`/proc/cmdline`, no `amd_iommu` token); eras before: `amd_iommu=off` 2026-09-11 → 10-18, IOMMU default-on before that — [[dankclaw-iommu-translation-off]] |
+| Python | 3.14.4 (system, `python3 --version`, 2026-10-18). The 3.12.13 CIRU venv left with that runtime (retired 2026-08-22) |
+| CIRU runtime | ciru-ai/ROCmFPX — **retired 2026-08-22** ([[ciru-activefpx-promptforge]]); not the serving runtime |
+| uv | 0.12.8 (`~/.local/bin/uv --version`, 2026-10-18) |

 ## Runtime Relevance

 - Unified memory eliminates separate VRAM limits. The GPU uses system RAM.
- The GPU budget is the GTT aperture: ~114 GiB (`gtt_total` in `/sys/class/drm/card1/device/`; `llama-server --list-devices` reports 116,732 MiB). rocm-smi's smaller SVM/dedicated carve-out is **not** the budget — the 2026-08 "64 GiB rocm-smi" lesson is stale. Do not use `free` or `dmidecode` for the GPU budget.
- The active service is `frank-dragoon` on port 7770: **gufo** (gufo-org/gufo) v0.1.1, the Strix Halo inference engine, built from source at `/home/dank/GitPackages/gufo-v0.1.1/`, serving unsloth/Qwen3.8-27B-GGUF:UD-Q8_K_XL (27B dense, DFlash2 drafter). See [[frank-dragoon-gufo-qwen38-27b]].
- The active runtime **links against the host ROCm** (`/opt/rocm` → `/etc/alternatives/rocm` → 7.2.4) through its RPATH, so it needs the host HIP stack rather than a bundled one — the opposite of the retired llama.cpp prebuilt, which carried its own. Building it needs the ROCm dev packages that are installed, and two workarounds recorded in the runbook (drop `librocwmma-dev`; pin `--gcc-install-dir` to GCC 15). The retired CIRU venv's TheRock 7.15 SDK (`LD_LIBRARY_PATH`) is not in the serving path.
+- The GPU budget is the GTT aperture: ~114 GiB (`mem_info_gtt_total` in `/sys/class/drm/card1/device/` = 122,402,963,456 B; `card1` is the amdgpu iGPU, `PCI_ID=1002:1586`; `llama-server --list-devices` reports 116,732 MiB). rocm-smi's smaller SVM/dedicated carve-out is **not** the budget — the 2026-08 "64 GiB rocm-smi" lesson is stale. Do not use `free` or `dmidecode` for the GPU budget.
+- The active services are `frank-dragoon` on 7770 — **halogen-flash-server 0.16.2** serving the native v2 abliterated `.hgn` in a rootless podman container ([[frank-dragoon-flash-server-v2-native]]) — and `frank-zealot` on 7771 ([[frank-zealot-llama-prism-bonsai2-pq20]]). The gufo v0.1.1 / UD-Q8_K_XL runtime this page once described is retired (2026-09-28 → 10-01, [[frank-dragoon-gufo-qwen38-27b]]); the gufo build tree is still on disk at `/home/dank/GitPackages/gufo-v0.1.1/`.
+- The gufo-era note that the active runtime links against the host ROCm (`/opt/rocm` → `/etc/alternatives/rocm` → 7.2.4) through its RPATH belongs to that retired source build. The serving runtimes do not depend on the host ROCm that way: halogen runs inside its digest-pinned image, and `frank-zealot` is a CUDA build on the 3090. The retired CIRU venv's TheRock 7.15 SDK (`LD_LIBRARY_PATH`) was never in the serving path either.
 - The retired vLLM venvs (`/home/dank/vllm-venv`, `/home/dank/vllm-vk-venv`) were moved to `/home/dank/.AGENTTRASH/` on 2026-08-18.
- 1.1 TB free disk space is ample for model storage.
+- 424 GB free on `/` (`df -h`, 2026-10-18) is ample for model storage.

 ## See Also

@@ -15,10 +15,13 @@ timestamp: 2026-09-20

 ## Server Overview

-Dankserver is a media/library server and the `frank-medium` LLM host. The
-host runs Ubuntu 26.04 (Resolute Raccoon). The RTX 3090 that served the
-FreeToken/CUDA `frank-zealot` era was removed on 2026-09-15 and replaced with
-two AMD Radeon AI PRO R9700 cards.
+Dankserver is a media/library server and the `frank-archon` LLM host (radiance
+1.0.13, 2×R9700 tensor-parallel — [[frank-archon-radiance-qwen38-iq4r]]; the
+`frank-medium` name this page carried was retired 2026-09-20, see §Active
+Services). The host runs Ubuntu 26.04 (Resolute Raccoon). The RTX 3090 that
+served the FreeToken/CUDA `frank-zealot` era was removed on 2026-09-15 and
+replaced with two AMD Radeon AI PRO R9700 cards (`lspci | grep -ci nvidia` → 0,
+read 2026-10-18).

 ## Hardware Specifications

@@ -28,11 +31,11 @@ two AMD Radeon AI PRO R9700 cards.
 |----------|-------|
 | Board | **ASUS ProArt B850-Creator WiFi NEO** (Rev 1.xx) — swapped in 2026-09-20 |
 | Previous | ASUS TUF GAMING B650-E WIFI (card #2 was behind the chipset there; see [[Dual-R9700-Cooperation]]) |
-| GPU lanes | CPU GPP ports bifurcated **x8/x8** at Gen5: `PCIEX16(G5)_1` → `00:01.1`, `PCIEX16(G5)_2` → `00:01.3`; ~31.5 GB/s per card |
-| Atomic routing | `AtomicOpsCap: Routing+` on every bridge in both GPU chains, `AtomicOpsCtl: ReqEn+` on both endpoints — the condition that ruled out TP=2 for the previous board |
+| GPU lanes | CPU GPP ports bifurcated **x8/x8** at Gen5: `PCIEX16(G5)_1` → `00:01.1`, `PCIEX16(G5)_2` → `00:01.3` (both bridges: `current_link_width=8`, `current_link_speed=32.0 GT/s`, read 2026-10-18); ~31.5 GB/s per card. Each card sits behind an on-board PCIe switch (`01:00.0`/`02:00.0`, `05:00.0`/`06:00.0` — "Navi 10 XL Upstream/Downstream Port of PCI Express Switch"), so the GPU endpoint itself trains **x16** Gen5 while the CPU-facing leg stays x8 |
+| Atomic routing | `AtomicOpsCap: Routing+` on every bridge in both GPU chains, `AtomicOpsCtl: ReqEn+` on both endpoints — the condition that ruled out TP=2 for the previous board (2026-09-20 census; not re-readable today — `lspci -vv` needs root) *(unverified 2026-10-18)* |
 | Free | `PCIEX16(G4)` (chipset, x4), M.2_2, M.2_3 |
-| Occupied M.2 | M.2_1 — boot NVMe (Samsung PM9C1a, DRAM-less), trained **x2** at Gen5 (63 Gb/s ≈ 7.9 GB/s) |
-| Onboard | 2x Realtek RTL8126 5GbE, RTL8922AE WiFi 7, PROM21 SATA controller |
+| Occupied M.2 | M.2_1 — boot NVMe (Samsung PM9C1a, DRAM-less, `04:00.0`), trained **x2** at Gen5 (`current_link_width=2`, `current_link_speed=32.0 GT/s`, `max_link_width=4`, read 2026-10-18; 63 Gb/s ≈ 7.9 GB/s) |
+| Onboard | 2× Realtek RTL8126 5GbE (`0b:00.0`, `0d:00.0`), RTL8922AE WiFi 7 (`0e:00.0`), ASMedia ASM1064 SATA (`0c:00.0`) + AMD 600-series SATA (`10:00.0`); the board's "PROM21 SATA" label is not what `lspci` reports *(unverified 2026-10-18)* |

 ### CPU

@@ -41,7 +44,7 @@ two AMD Radeon AI PRO R9700 cards.
 | Architecture | x86_64 |
 | Vendor | AuthenticAMD |
 | Model | AMD Ryzen 7 7700X |
-| Cores | 8 cores / 16 threads (1 socket) — SMT is **on**; the BIOS defaults reset with the board swap. `llama.cpp` still runs `--threads 8 --threads-batch 8`, so this is headroom, not a change in the serving shape |
+| Cores | 8 cores / **8 threads** today — SMT is **off** (`lscpu`: `CPU(s): 8`, `Thread(s) per core: 1`, `Core(s) per socket: 8`, read 2026-10-18; max observed 5575.87 MHz). The board-swap era recorded 16 threads with SMT on; BIOS defaults reset with the board swap. The `--threads 8 --threads-batch 8` llama.cpp note belongs to the retired llama.cpp serving era |
 | NUMA Nodes | 1 (node 0) |

 ### GPUs
@@ -51,10 +54,10 @@ two AMD Radeon AI PRO R9700 cards.
 | Model | 2x AMD Radeon AI PRO R9700 (Navi 48, DID 0x7551, rev c0) |
 | Architecture | gfx1201 (RDNA4) |
 | VRAM | 32,624 MiB each (`rocm-smi` reports 34,208,743,424 B per card) |
-| Link | PCIe 5.0 **x8** each (CPU GPP `00:01.1` / `00:01.3`), no XGMI; separate IOMMU groups (15 and 20), ACS `ReqRedir+` on both root ports, so P2P hairpins at the root complex |
-| Atomic ops | `Routing+` on all four bridges per chain; `ReqEn+` on both endpoints (`CAP_EXP+28.w = 0x1440`) |
+| Link | PCIe 5.0, endpoint-trained **x16** each behind the on-board switch; the CPU-facing leg is x8 (`00:01.1` / `00:01.3`, both `current_link_width=8` at 32.0 GT/s, read 2026-10-18). No XGMI. Separate IOMMU groups — `03:00.0` → group **15**, `07:00.0` → group **20** (`/sys/bus/pci/devices/.../iommu_group`, read 2026-10-18) |
+| P2P | **Live and in use.** The running engine prints "I device: the 2 cards reach each other's memory directly (peer to peer)" (`podman logs frank-archon`, 2026-10-15 boot). The 2026-09-20 census had predicted the opposite — ACS `ReqRedir+` on both root ports, so traffic hairpinning at the root complex — and that prediction is superseded; see [[Dual-R9700-Cooperation]] |
 | PCI | 03:00.0 and **07:00.0** (were `03:00.0` / `0b:00.0` on the B650-E) |
-| iGPU | Raphael (gfx1036) at **11:00.0** — enumerates as ROCm device 2, hidden from HIP |
+| iGPU | Raphael (gfx1036) at **11:00.0** — enumerates as ROCm device 2 (rocm-smi GPU[2], 512 MiB). The retired llama.cpp trios hid it with `HIP_VISIBLE_DEVICES=0,1`; the live radiance engine instead enumerates all three AQL devices and ignores it ("3 devices [0:gfx1201 1:gfx1201 2:gfx1036], using 2 of 3, ignoring gfx1036") |

 The RTX 3090 is gone; stale `nvidia-smi` binaries and the disabled NVIDIA
 apt lists remain on disk but no NVIDIA PCI device exists.
@@ -63,29 +66,31 @@ apt lists remain on disk but no NVIDIA PCI device exists.

 | Property | Value |
 |----------|-------|
-| System RAM | **246 GiB** (upgraded for the Lucebox DeepSeek deployment of 2026-09-26; this page said 60 GiB until 2026-09-28 — a stale figure that survived the board swap) |
-| Swap | 63 GiB (`/swapfile`) |
-| /dev/shm | 32 GiB |
+| System RAM | **246 GiB** (`free -g` total 246, read 2026-10-18; upgraded for the Lucebox DeepSeek deployment of 2026-09-26; this page said 60 GiB until 2026-09-28 — a stale figure that survived the board swap) |
+| Swap | 63 GiB (`/swapfile`, `swapon` → 64 GB file, read 2026-10-18) |
+| /dev/shm | 124 GiB tmpfs (`df /dev/shm`, read 2026-10-18) |

 ### Storage

 | Filesystem | Size | Used | Avail | Use% |
 |------------|------|------|-------|------|
-| / (nvme0n1p2) | 1.8T | 927G | ~822G | ~54% |
-| /mnt/entropy (dm-0) | 91T | 87T | **244G** | **100%** — full; do not plan model payload here |
+| / (nvme0n1p2) | 1.8T | 985G | 764G | 57% |
+| /mnt/entropy (dm-0) | 91T | 87T | **67G** | **100%** — full; do not plan model payload here |

-Models live under `/home/dank/models`; the serving build tree under
-`/home/dank/GitPackages/llama.cpp-dflash2` (the older `charlie-ROCmFPX` tree is
-still on disk), both sharing the self-contained ROCm 7.14 nightly toolchain
-under `~/.local/share/rocm-7.14.0a20260624` — which also carries `librccl.so.1`
-and `hipcc`, so an RCCL-backed rebuild needs no new host packages.
+Models live under `/home/dank/models`; the serving stack is a digest-pinned
+container image, not a host build tree — the llama.cpp trees on disk
+(`/home/dank/GitPackages/llama.cpp-dflash2`, the older `charlie-ROCmFPX`, both
+still present 2026-10-18) are retired-era builds. They share the self-contained
+ROCm 7.14 nightly toolchain under `~/.local/share/rocm-7.14.0a20260624` (also
+present 2026-10-18), which carries `librccl.so.1` and `hipcc`, so an
+RCCL-backed rebuild needs no new host packages.

 ### Network

 | Interface | Type | Speed | IP | Notes |
 |-----------|------|-------|----|-------|
 | eno1 | onboard RTL8126 5GbE | 2500 Mb/s (negotiated) | 192.168.0.235, **static** | LLM endpoint (port 7770). The address `models.yml`, Prometheus and Pi-hole all point at — preserved across the swap. |
-| eno2 | onboard RTL8126 5GbE, second port | 2500 Mb/s | 192.168.0.247, DHCP | **New since the swap**: cabled, and it took the lower-metric default route (101, against eno1's 102). Two live addresses and two default routes for one host — either declare it or bring the link down. |
+| eno2 | onboard RTL8126 5GbE, second port | 2500 Mb/s | 192.168.0.247, DHCP | **New since the swap**: cabled, both ports up at 2500 Mb/s. The old lower-metric default route was resolved — `ip route` today shows eno1 `proto static metric 100` and eno2 `proto dhcp metric 200`, so eno1 wins. Two live addresses and two default routes remain for one host |
 | wlp14s0 | WiFi 7 (RTL8922AE) | - | - | Renamed with the board (was `wlp8s0`); unused. |

 ### OS and Software
@@ -93,10 +98,10 @@ and `hipcc`, so an RCCL-backed rebuild needs no new host packages.
 | Property | Value |
 |----------|-------|
 | OS | Ubuntu 26.04 LTS (Resolute Raccoon) |
-| Kernel | 7.0.0-31-generic (`iommu=pt`) |
+| Kernel | 7.0.0-38-generic, `iommu=pt` (`uname -r`, `/proc/cmdline`, read 2026-10-18) |
 | Python | 3.14.4 |
 | ROCm userspace | Ubuntu 7.1 packages in /usr (hipcc 7.1.1, rocminfo, rocm-smi 7.1.1) |
-| Serving stack | mainline llama.cpp `fb27a525` at `~/GitPackages/llama.cpp-dflash2/build-rdna4-rocm714`, RPATH-bundled with the ROCm 7.14 nightly runtime |
+| Serving stack | radiance 1.0.13 container (`stilldeadcode/radiance@sha256:4c3f484564…`), TP=2 across both R9700s — [[frank-archon-radiance-qwen38-iq4r]]. The llama.cpp `fb27a525` build at `~/GitPackages/llama.cpp-dflash2/build-rdna4-rocm714` is the retired frank-medium artifact |

 The stale AMD-repo ROCm 6.3.3 packages (167, `~24.04`-suffixed) that used to
 hijack `libhsa-runtime64` were purged on 2026-09-15 — see
@@ -104,28 +109,44 @@ hijack `libhsa-runtime64` were purged on 2026-09-15 — see

 ### Active Services

-The active inference service is `frank-medium.service`: mainline llama-server on
-port 7770, layer-split 32:33 across both R9700s with the DFlash2 drafter pinned to
-ROCm1. See [[frank-medium-llamacpp-dflash2]]. The former
-`frank-zealot.service` (FreeToken/CUDA) was retired with the 2026-09-15 GPU swap;
-its unit is archived in `~/.AGENTTRASH/20260915-frank-zealot-retire/host-units/`,
-and the vllm-radiance replica trio in `~/.AGENTTRASH/20260916-vllm-radiance-retire/`.
-See [[deployment]].
+The active inference service is `frank-archon.service` (`systemctl is-active` →
+`active`, `is-enabled` → `enabled`, read 2026-10-18): radiance 1.0.13 in a
+host-network podman container answering `curl 127.0.0.1:7770/health` →
+`{"status":"ok","model":"frank-archon",…}`. See
+[[frank-archon-radiance-qwen38-iq4r]].
+
+The services this page once called active are gone: `frank-medium.service`
+(llama-server, 32:33 layer split + DFlash2 drafter) is `not-found` — that rung
+ran 2026-09-16 → 09-20 and is documented in [[frank-medium-llamacpp-dflash2]];
+`frank-zealot.service` (FreeToken/CUDA) was retired with the 2026-09-15 GPU
+swap. Its archived unit was moved to `~/.AGENTTRASH/20260915-frank-zealot-retire/host-units/`
+and the vllm-radiance replica trio to `~/.AGENTTRASH/20260916-vllm-radiance-retire/`
+— neither path exists today (checked 2026-10-18), so the archive location is
+unverified. See [[deployment]].

 ## Hardware Relevance

- 2x 32 GB VRAM: the 27.0 GiB Q8_0 checkpoint plus the 1.06 GiB DFlash2 drafter
-  and the f16 KV pool for 327,680 tokens fit with the split at 32:33; live
-  headroom is ~6.3 GiB on ROCm0 and ~5.2 GiB on ROCm1, which is why a batch or
+- 2× 32 GB VRAM: the live budget is stated per card, not by checkpoint size —
+  `--vram-weights-mib 25600` / `--vram-kv-mib 5120`
+  (`scripts/frank-archon.env:230-231`), against a card total of 31.86 GiB with
+  96 MiB publisher headroom (`scripts/frank-archon.env:186`). The retired
+  frank-medium fit (27.0 GiB Q8_0 + 1.06 GiB drafter + f16 KV for 327,680
+  tokens at 32:33, ~6.3/~5.2 GiB headroom) is history. Either way a batch or
  context change needs a re-fit and not a guess.
- 60 GB system RAM is mostly headroom; nothing in the serving path is
-  CPU-resident.
- The iGPU is deliberately unused: `HIP_VISIBLE_DEVICES=0,1` keeps work off
-  the shared-memory Raphael device.
+- 246 GiB system RAM is **not** headroom: the live shape pins a 43.88 GiB host
+  pool per rank (`FRANK_ARCHON_HOST_POOL_MIB=44928`,
+  `scripts/frank-archon.env:184`) plus the 47.68 GiB n-gram/PLE table in RAM,
+  and `free -g` showed **90 GiB available** with the engine loaded (read
+  2026-10-18). The frank-medium claim that "nothing in the serving path is
+  CPU-resident" is retired with that runtime.
+- The iGPU stays out of the serving path by engine choice, not by an env
+  var: radiance enumerates all three devices and uses 2 of 3, ignoring
+  gfx1036. No `HIP_VISIBLE_DEVICES` is set in the container today (`podman
+  inspect frank-archon`, read 2026-10-18).

 ## See Also

- [[frank-medium-llamacpp-dflash2]] — the active serving runbook
+- [[frank-archon-radiance-qwen38-iq4r]] — the active serving runbook
 - [[Dual-R9700-Cooperation]] — why the PCIe path matters, and what the swap changed
 - [[deployment]] — the deploy flow
 - [[Shared Memory Architecture Dankclaw]] — for contrast, Dankclaw's unified memory
@@ -14,11 +14,15 @@ timestamp: 2026-09-16

 # Dual R9700 Cooperation

-Dankserver's two R9700s serve `frank-medium` as **one vLLM-radiance process at
-tensor_parallel_size 2** ([[frank-medium-radiance-mxfp4]]). This page records why
+Dankserver's two R9700s run **one tensor-parallel engine across both cards** —
+today that is `frank-archon` under radiance 1.0.13, TP=2
+([[frank-archon-radiance-qwen38-iq4r]]). When this page was written the endpoint
+was `frank-medium`: first llama.cpp's layer split
+([[frank-medium-llamacpp-dflash2]], 2026-09-16 → 09-20), then from 2026-09-20
+one vLLM-radiance process at `tensor_parallel_size 2`
+([[frank-medium-radiance-mxfp4]], 2026-09-20 → 09-26). This page records why
 true tensor parallelism was impossible on the previous board (TUF GAMING B650-E
-WIFI), and what the 2026-09-20 board swap changed. The llama.cpp layer split that
-served the endpoint until that swap is [[frank-medium-llamacpp-dflash2]].
+WIFI), and what the 2026-09-20 board swap changed.

 ## The short answer

@@ -43,9 +47,11 @@ What that bought:
  and served (its R4D allreduce needs no RCCL collective at all), and llama.cpp
  `--split-mode tensor` booted and served against an RCCL-backed build — so a
  collective HAS been dispatched on this host since the swap.
- **One of them is production.** TP=2 wins on every axis measured, by 2.1x on
-  decode and 3.6x at 4-way concurrency, so it replaced the layer split on the day
-  of measurement. See [[frank-medium-radiance-mxfp4]] for the deployed shape.
+- **TP=2 is the production shape.** It wins on every axis measured, by 2.1x on
+  decode and 3.6x at 4-way concurrency, and it replaced the layer split on the day
+  of measurement. The payload has moved since: the MXFP4 `frank-medium` shape is
+  retired 2026-09-26, and what runs today is the iq4r publisher under radiance
+  1.0.13 ([[frank-archon-radiance-qwen38-iq4r]]).
 - **The drafter, not the collective, is what llama.cpp lost.** Its tensor mode
  could not carry the DFlash2 drafter, which is the honest caveat on the
  comparison below.
@@ -137,20 +143,30 @@ LAN/SATA/WiFi:
 - `dmesg` agrees on bandwidth: `252.056 Gb/s available PCIe bandwidth, limited
  by 32.0 GT/s PCIe x8 link at 0000:00:01.1` (and `.13`) — ~31.5 GB/s per
  card. DMI confirms the bifurcation: `PCIEX16(G5)_2`, "8x or x8".
- `rocm-smi --showtopo` still reports `PCIE` between the cards (Navi 48 has no
-  XGMI), they are still in separate IOMMU groups (15 and 20), and both root
-  ports have ACS `ReqRedir+`, so P2P hairpins at the root complex. Plain P2P
-  traffic measured 45.27 GB/s bidirectional on the *old* board — DMA was never
-  the gate, atomics were.
- Kernel 7.0.0-31-generic with `iommu=pt`. Both were ruled out as causes
-  ([above](#ruled-out-empirically-do-not-re-derive)) and both are unchanged.
+- `rocm-smi --showtopo` reported `PCIE` between the cards (Navi 48 has no XGMI),
+  they were in separate IOMMU groups (15 and 20 — re-read 2026-10-18: still 15
+  and 20), and both root ports had ACS `ReqRedir+`, so this page inferred P2P
+  would hairpin at the root complex. **That inference is superseded:** the live
+  engine says the opposite about the same pair — "I device: the 2 cards reach
+  each other's memory directly (peer to peer)" (`podman logs frank-archon`,
+  2026-10-15 boot). Plain P2P traffic measured 45.27 GB/s bidirectional on the
+  *old* board — DMA was never the gate, atomics were.
+- Kernel 7.0.0-31-generic with `iommu=pt` then; this host runs 7.0.0-38-generic
+  with `iommu=pt` today (`/proc/cmdline`, read 2026-10-18). Both were ruled out
+  as causes ([above](#ruled-out-empirically-do-not-re-derive)) and this host's
+  IOMMU posture is unchanged.

-**Still unproven.** The gate that matters is ROCclr's `checkAtomicSupport()`
-reading the `kLinkAtomicSupport` link attribute; the ReqEn bit is the same cause
-seen from the kernel side, but no RCCL kernel has been launched since the swap.
-Until the 2-rank probe runs — or a `--split-mode row` boot that does *not* log
-`internal AllReduce init failed ... falling back to meta-backend butterfly` —
-"collectives work here" is a strong expectation, not a measurement.
+**Still unproven (as of 2026-09-20).** The gate that matters is ROCclr's
+`checkAtomicSupport()` reading the `kLinkAtomicSupport` link attribute; the ReqEn
+bit is the same cause seen from the kernel side, but no RCCL kernel had been
+launched since the swap. Until the 2-rank probe runs — or a `--split-mode row`
+boot that does *not* log `internal AllReduce init failed ... falling back to
+meta-backend butterfly` — "collectives work here" was a strong expectation, not a
+measurement. **RCCL never got that measurement**; what settled the operational
+question instead is production traffic: radiance's TP=2 wire moves cross-rank
+all-reduces over the direct P2P path and reports its own precision — "tp wire:
+LOSSY (--tp-wire wht6) at 128 KiB a message and above … Steps of at most 25 rows
+are exact" (`podman logs frank-archon`, 2026-10-15 boot).

 ## Measured matrix

@@ -249,9 +265,13 @@ RCCL 2.27 does carry gfx1201 kernels, and that is what row 3 linked against.

 **Rule for any future multi-GPU collective experiment: stop and mask the
 production service first**, per the benchmarking policy, or run it on a host that
-is not serving users. Since 2026-09-20 `frank-medium` is a rootless quadlet, so
-that is `systemctl --user stop frank-medium && systemctl --user mask frank-medium`
-on Dankserver.
+is not serving users. The production service is `frank-archon`, a **root** unit,
+so on Dankserver that is `sudo systemctl stop frank-archon && sudo systemctl
+mask frank-archon` (`scripts/frank-archon.service`; never `disable` — that
+deletes the unit file, and `mask` is what the bench policy prescribes). The
+2026-09-20 wording below — `systemctl --user stop frank-medium && systemctl
+--user mask frank-medium`, frank-medium being a rootless quadlet — is retired
+with that service, which today reports `not-found` (read 2026-10-18).

 This is not theoretical: on 2026-09-16 a bare RCCL P2P probe was run against the live
 service; the host went hard down ~20 minutes later (no ARP, no ICMP, required a
@@ -260,7 +280,7 @@ GPU driver is a plausible cause and this host has precedent for going
 unreachable until a power cycle.


-## The third path, and the one in production: llama.cpp's layer split
+## The third path (production in the layer-split era): llama.cpp's layer split

 Everything above is about *collectives*, and vLLM cannot proceed without them
 in any of its parallelisms — TP needs a per-layer allreduce, and PP's stage
@@ -270,8 +290,9 @@ layers are distributed across the cards and the boundary activation is a
 plain per-backend copy, once per forward pass. No RCCL kernel is ever launched
 on the second card, so the atomics gate never comes up.

-That is what `frank-medium` runs today ([[frank-medium-llamacpp-dflash2]]): one
-process, one model, both cards, 262144 context. Measured against tensor split
+That is what `frank-medium` ran from 2026-09-16 to 09-20
+([[frank-medium-llamacpp-dflash2]]): one process, one model, both cards,
+262144 context. Measured against tensor split
 on this host: 1991 t/s prefill / 18.8 tok/s decode layer-split, against 272 /
 26.3 tensor (butterfly fallback, no RCCL). **That tensor number is not a
 prediction for an RCCL-backed build** — it is what tensor split costs when the
@@ -282,9 +303,10 @@ The ranking therefore changed twice. On 2026-09-16: software already gets both
 cards onto one model, so the hardware fix stopped being a capability question
 and became a performance one — *tensor* parallelism, ~40 % decode, plus one
 pooled KV instead of two independent 122k-token pools. On 2026-09-20 the
-hardware half of that question was answered by the board swap; the measurement
-half has not run yet, and `GGML_HIP_RCCL` is still `OFF` in
-`scripts/build-llama-rdna4.sh` for exactly the reason this page documents.
+hardware half of that question was answered by the board swap; the llama.cpp
+measurement half never ran, and `GGML_HIP_RCCL` still defaults `OFF` in
+`scripts/build-llama-rdna4.sh:41` (re-read 2026-10-18) for exactly the reason
+this page documents — moot while no llama.cpp shape is deployed on this host.

 ## What would change the answer

@@ -15,10 +15,21 @@ timestamp: 2026-09-03
 > See [[frank-redo-2026-08-17]] and [[deployment]] for the active configuration.
 > The `frank-zealot` name and port 52625 then belonged to the vLLM
 > service on Dankclaw (nameistoken Quark W8A8); this page is archive.
+>
+> **The NPU endpoint is retired — 2026-09-11.** On Dankclaw today
+> `frank-npu.service` is `masked`/`inactive` and nothing listens on 52625
+> (`ss -ltn`, read 2026-10-18). The runtime is still installed
+> (`fastflowlm 1.0.1`, `libxrt2`/`libxrt-npu2`, `/opt/fastflowlm`,
+> `~/.config/flm`, `/usr/bin/flm` — all read 2026-10-18) and the device is
+> usable again since the 2026-10-18 `iommu=pt` boot (`amdxdna` bound,
+> `/dev/accel/accel0` present — [[dankclaw-iommu-translation-off]]), but no
+> service runs on it. `frank-zealot` today is the llama.cpp PrismML endpoint on
+> the RTX 3090 ([[frank-zealot-llama-prism-bonsai2-pq20]]). See [[frank-npu]]
+> for the retirement record. Everything below is the 2026-08 research record.

 # FastFlowLM NPU Inference

-FastFlowLM (FLM) runs LLMs entirely on the AMD Ryzen AI NPU. It targets XDNA2 chips: Strix, Strix Halo, Kraken, and Gorgon Point. The project describes itself as "Ollama, but deeply optimized for NPUs." As of 2026-08-16, FLM is installed on Dankclaw, the NPU validates, and `frank-zealot` (port 52625) serves in production. See Promotion.
+FastFlowLM (FLM) runs LLMs entirely on the AMD Ryzen AI NPU. It targets XDNA2 chips: Strix, Strix Halo, Kraken, and Gorgon Point. The project describes itself as "Ollama, but deeply optimized for NPUs." As of 2026-08-16, FLM was installed on Dankclaw, the NPU validated, and `frank-zealot` (port 52625) served in production — that arrangement ended with the 2026-09-11 retirement (see the banner above). See Promotion.

 ## Verdict (2026-08-16)

@@ -46,7 +57,7 @@ Key properties, per the project README and docs:

 ## NPU Hardware on Dankclaw

-Dankclaw runs an AMD Ryzen AI MAX+ 395 (Strix Halo). The chip integrates an XDNA2 NPU rated at 50 TOPS. It sits beside the Radeon 8060S iGPU and shares the same 30 GiB unified memory pool.
+Dankclaw runs an AMD Ryzen AI MAX+ 395 (Strix Halo). The chip integrates an XDNA2 NPU rated at 50 TOPS (vendor spec: "NPU TOPS — Up to 50 TOPS", [amd.com product page](https://www.amd.com/en/products/processors/laptop/ryzen/ai-300-series/amd-ryzen-ai-max-plus-395.html)). It sits beside the Radeon 8060S iGPU and shares the same unified memory pool — 30 GiB exposed to the OS in the 2026-08 reading below; the box presents **121 GiB** today (`free -g` total 121, read 2026-10-18).

 Live verification on Dankclaw, 2026-08-16:

@@ -60,9 +71,9 @@ $ flm validate
 [ERROR]  Memlock limit is too low (8MB). Please raise the limit or set to infinity.
 ```

- Kernel 7.0.0-29-generic ships the `amdxdna` driver in-tree. The driver is loaded.
+- Kernel 7.0.0-29-generic shipped the `amdxdna` driver in-tree, loaded. The host now runs 7.0.0-38-generic and the driver is still bound (`lspci -k -s c6:00.1` → `Kernel driver in use: amdxdna`, read 2026-10-18).
 - Firmware 1.1.2.65 meets the 1.1.0.0 minimum.
- The XRT runtime packages (`libxrt2`, `libxrt-npu2`) are installed.
+- The XRT runtime packages (`libxrt2`, `libxrt-npu2`) are installed — still installed on 2026-10-18 (`dpkg -l` → `libxrt2 1:2.21.75+dfsg-4`, `libxrt-npu2 1:2.21.75+dfsg-4`).
 - The only failure is the memlock ulimit (8 MB). FLM needs `unlimited`.
 - Ubuntu 26.04 is not on the FLM supported-distro list (24.04, 25.10, Arch, generic). Validation passes anyway. Treat 26.04 as "generic Linux, working".

@@ -78,6 +89,11 @@ Budget math for this fleet:
 | Dankserver (Ryzen 7 7700X) | 62 GB | no NPU |
 | FLM bench box (Kraken Point) | 32 or 96 GB | ~16 or ~48 GB |

+2026-10-18 re-read: Dankclaw's OS now reports **121 GiB** (`free -g`) and
+Dankserver **246 GiB** (`free -g`), so the half-of-RAM rule would price the NPU
+budget at ~60 GiB and the 7700X box still has no NPU. The 30 GiB / 62 GB rows
+are the 2026-08-16 state; the table is moot while no NPU endpoint is deployed.
+
 Weight sizes (approximate, Q4-class):

 | Model | Quant | Weights | Fits ~15 GiB budget? |
@@ -162,7 +178,7 @@ Proposed role: a small, always-on, low-power endpoint for triage, summarization,

 - `fastflowlm 1.0.1` installed (deb, upgraded from 0.9.45-12-ga6bd056 on 2026-08-17). `flm` at `/usr/bin/flm`. The 0.9.45 runtime refused the qwythos pack, which declares `flm_version` 1.0.0.
 - `libxrt2` / `libxrt-npu2` (Xilinx Runtime) installed.
- `/dev/accel/accel0` present. `flm validate` passes fully.
+- `/dev/accel/accel0` present. `flm validate` passed fully. (Re-read 2026-10-18: `/dev/accel/accel0` is still present and `fastflowlm 1.0.1` is still installed, but the endpoint is retired — `frank-npu.service` masked, no listener on 52625.)
 - Memlock fixed: `/etc/security/limits.d/99-flm-memlock.conf` sets soft and hard memlock to unlimited. A fresh sshd session picks it up via pam_limits. No reboot needed.
 - `gpt-oss:20b` pulled (4/4 files verified, 13.8 GB `model.q4nx` + tokenizer) into `~/.config/flm/models/GPT-OSS-20B-NPU2/`.
 - `qwythos:9b` (Huihui-Qwythos-9B-Claude-Mythos-5-1M-abliterated-NPU2) installed 2026-08-17 via `flm-add.py` (downloaded from the HF repo; stdlib-only, no pip needed). Tag registered in the user registry `~/.config/flm/model_list.json` (a copy of the v1.0.1 system registry + the custom entry); kernels symlinked `~/.config/flm/xclbins/Huihui-...-NPU2 -> /opt/fastflowlm/share/flm/xclbins/Qwen3.5-9B-NPU2`. The service env exports `FLM_CONFIG_PATH` and `FLM_XCLBIN_PATH` so the tag resolves (without them flm hits the unknown-tag fallback, see the incident below).
@@ -241,7 +257,14 @@ Consequence: the NPU endpoint is a single lane. It suits low-frequency backgroun

 ## Test Runbook

-Do not run large model loads while the production service holds most of the 30 GiB pool. Check free RAM first or stop the service. The NPU shares the unified pool with everything else on the box.
+This runbook targets a retired endpoint; keep it as the procedure if the NPU is
+ever revived. Do not run large model loads while the production service holds
+most of the unified pool — 30 GiB exposed to the OS in the 2026-08 reading,
+**121 GiB** today (`free -g`, read 2026-10-18). Check free RAM first, or stop
+the service the way the bench policy requires (`sudo systemctl stop
+frank-dragoon && sudo systemctl mask frank-dragoon` — self-healing would
+otherwise restart it). The NPU shares the unified pool with everything else on
+the box.

 ```mermaid
 graph TD
@@ -387,10 +410,18 @@ pi sessions failed against this endpoint with `Stream ended without finish_reaso

 - **Ubuntu 26.04 is unofficial.** The distro list stops at 25.10. Validation passes, but breakage would fall on the "generic Linux" path.
 - **The 30 GiB budget is untested at the very top.** gpt-oss-20b (15 GiB resident) works. 35B-A3B (~20 GB weights) is still an unknown. Vendor data covers 32 GB and 96 GB boxes only.
- **The FLM serve process is not under systemd.** A reboot of Dankclaw kills it. The PP head service is enabled and returns. The FLM process must be restarted by hand. A unit file is a natural next step.
+- **The FLM serve process was not under systemd** (2026-08-era risk). A reboot
+  of Dankclaw killed it. The fleet law today is the opposite: every deployed
+  container/service ships a boot-persistent, self-healing unit, and the retired
+  NPU unit is deliberately `masked` (`frank-npu.service`, read 2026-10-18) so it
+  cannot come back at boot.
 - **gpt-oss reasoning budget.** The model can spend its full token budget on `reasoning_content` and return empty content. Clients must handle or cap this.
 - **No llama.cpp GGUF path.** FLM uses its own pre-compiled kernels. Our UD-Q8_K_XL and HauhauCS builds are not importable. NPU work means FLM-specific model tags.
- **NPU production role (2026-08-16).** `frank-zealot` serves `qwen3.6-moe:35b-a3b` on port 52625 (swap churn and the unknown-tag incident are recorded above). The remaining NPU content (benchmarks, runbook steps) is still research until a step lands and is recorded.
+- **NPU production role (2026-08-16, retired 2026-09-11).** `frank-zealot` then
+  served `qwen3.6-moe:35b-a3b` on port 52625; the endpoint was retired with the
+  `amd_iommu=off` decision that day and the unit is masked today. The remaining
+  NPU content (benchmarks, runbook steps) is research on a device that is again
+  usable since 2026-10-18 but serves nothing.

 ## Citations

@@ -74,6 +74,11 @@ cat /sys/class/drm/card*/device/mem_info_gtt_total    # aperture onto SYSTEM RAM
 rocm-smi --showmeminfo all | grep -i gtt              # used == what the CPU also sees
 ```

+Read on Dankclaw 2026-10-18: `mem_info_vram_total` = 2147483648 (2 GiB of
+dedicated carve), `mem_info_gtt_total` = 122402963456 (114 GiB) — the aperture is
+the whole budget, the carve is noise, and the OS sees 121 GiB of it
+([[Dankclaw System Specs]]).
+
 A large GTT window means the "GPU memory" is the *same* LPDDR under one
 memory controller: adding a stage there adds a compute engine, not capacity
 or bandwidth. Only the discrete card's VRAM is additive. Fencing more
@@ -101,6 +106,13 @@ of bytes), so it is tempting. Before proposing it:
  gap. In llama.cpp the portable mechanism is `--spec-draft-device/-devd`
  (draft gets its own device list) plus `-ngld`/`-otd`/`-ctkd -ctvd`.

+The llama.cpp half of that bullet is checkable upstream: `--spec-draft-device`
+(`-devd` / `--device-draft`, line 4259), `--spec-draft-ngl` (`-ngld`, 4268),
+`--spec-draft-override-tensor` (`-otd`, 4137) and `--spec-draft-type-k/v`
+(`-ctkd`/`-ctvd`, 4111/4124) all exist in
+`common/arg.cpp` ([source](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/common/arg.cpp),
+read 2026-10-18).
+
 ## 6. Expressing a split (llama.cpp, the usual vehicle)

 ```bash
@@ -110,10 +122,12 @@ of bytes), so it is tempting. Before proposing it:

 - buffer types match by name at load (`ggml_backend_buft_name`), so device
  names work as `-ot` values;
- `-cmoe`/`-ncmoe` are **CPU-only**; device-side MoE placement is `-ot`;
+- `-cmoe`/`-ncmoe` are **CPU-only** (`--cpu-moe` / `--n-cpu-moe`,
+  `common/arg.cpp:2764,2771`); device-side MoE placement is `-ot`;
 - several backends in one binary is fine (CUDA + Vulkan is the practical
-  pair; HIP + CUDA do not coexist) — `GPU_BACKEND_A=OFF` in the existing
-  build's CMakeCache tells you what needs adding;
+  pair; HIP + CUDA do not coexist *(unverified 2026-10-18 — upstream build docs
+  do not settle the combination either way)*) — `GPU_BACKEND_A=OFF` in the
+  existing build's CMakeCache tells you what needs adding;
 - contiguous ranges are the WRONG split when KV bandwidth dominates: they
  drag half the attention layers (and their KV) back to the slow pool.

@@ -10,13 +10,13 @@ timestamp: 2026-08-28

 ## Overview

-Dankserver uses NVIDIA GPU with system RAM for hybrid processing. vLLM splits model weights onto GPU and moves KV cache between GPU VRAM and system RAM. This allows larger models to run on GPUs with limited VRAM.
+Dankserver has **no NVIDIA GPU**: the RTX 3090 left the box on 2026-09-15 and the host now runs two AMD Radeon AI PRO R9700s (`lspci | grep -ci nvidia` → 0, read 2026-10-18 — [[Dankserver System Specs]]). This page's vLLM-era hybrid guidance is reference material, not the serving path: the live service is radiance 1.0.13 as `frank-archon`, and its hybrid mechanism is a pinned host pool (43.88 GiB per rank, `scripts/frank-archon.env:184`) plus the CPU-resident 47.68 GiB n-gram/PLE table, not vLLM KV swapping ([[frank-archon-radiance-qwen38-iq4r]]).

 ## Architecture

 ### Model Weights

-Model weights stay on GPU. vLLM loads the entire model into GPU memory. You cannot offload model weights to CPU. The GPU must hold all model parameters.
+In the setup this page describes, model weights stay on GPU and the GPU must hold all parameters. As a statement about vLLM it is no longer true: current vLLM ships CPU weight offload as `cpu_offload_gb`, plus the grouped prefetch path (`offload_group_size`) — `vllm/config/offload.py:23,54` ([source](https://raw.githubusercontent.com/vllm-project/vllm/main/vllm/config/offload.py), read 2026-10-18). What remains true is the capacity arithmetic: offloaded weights cost PCIe traffic per token (see [[PCIe Link and Atomics]] §2).

 ### KV Cache

@@ -47,11 +47,16 @@ Set `--gpu-memory-utilization` based on your GPU:
 | 80 GB (A100 80GB) | 0.85-0.95 |
 | 80 GB (H100) | 0.9-0.95 |

+Dankserver has neither NVIDIA card today: it carries 2× 32 GB (32,624 MiB) R9700s.
+The live engine does not use this knob at all — it claims an explicit per-card
+pair instead (`--vram-weights-mib 25600` / `--vram-kv-mib 5120`,
+`scripts/frank-archon.env:230-231`).
+
 Lower values leave more GPU memory for KV cache. This reduces swap frequency.

 ### Swap Space / KV Offload

-Recent vLLM releases removed the `--swap-space` engine argument. Use `--kv-offloading-size` to move KV cache to CPU RAM. In Podman, mount the host cache read-write for KV offload writes. The table below shows historical `--swap-space` guidance as a sizing reference.
+Recent vLLM releases removed the `--swap-space` engine argument — `CacheConfig` on `main` has no `swap_space` field ([source](https://raw.githubusercontent.com/vllm-project/vllm/main/vllm/config/cache.py), read 2026-10-18). Use `--kv-offloading-size` (`kv_offloading_size`, same file) to move KV cache to CPU RAM. In Podman, mount the host cache read-write for KV offload writes. The table below shows historical `--swap-space` guidance as a sizing reference.

 | System RAM | Recommended Swap |
 |------------|------------------|
@@ -69,26 +74,24 @@ Use tensor parallelism for large models:
 ```
 vllm serve meta-llama/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 4 \
-    --gpu-memory-utilization 0.85 \
-    --swap-space 16
+    --gpu-memory-utilization 0.85
 ```

 ### KV Cache Data Type

-Use FP8 KV cache for Ampere and newer GPUs:
+Use FP8 KV cache for Ampere and newer NVIDIA GPUs. On this host's RDNA4 cards the live engine runs an fp8 KV cache too (`kv fp8` — `scripts/frank-archon.env:264`, which also records that this engine takes only bf16|fp8 for the whole cache).

 ```
 vllm serve Qwen/Qwen3.6-35B-A3B-FP8 \
    --kv-cache-dtype fp8 \
-    --gpu-memory-utilization 0.9 \
-    --swap-space 16
+    --gpu-memory-utilization 0.9
 ```

 FP8 KV cache reduces memory usage by 50% compared to BF16.

 ## NUMA Optimization

-Dankserver may have multiple NUMA nodes. Optimize with:
+Dankserver reports **one** NUMA node today (`lscpu` → `NUMA node(s): 1`, `NUMA node0 CPU(s): 0-7`, read 2026-10-18), so NUMA binding buys nothing on this host; these flags matter on multi-node topologies:

 ```
 vllm serve model \
@@ -117,10 +120,11 @@ VLLM needs CPU cores for:

 Minimum physical cores = 2 + N (where N is GPU count).

-For Dankserver with 1 GPU:
+For Dankserver, which has **2** GPUs (2× R9700) and 8 cores (`lscpu`, read
+2026-10-18):

- Minimum 3 physical CPU cores
- Recommended 8+ physical CPU cores
+- Minimum 4 physical CPU cores by the 2 + N rule
+- Recommended 8+ physical CPU cores — the host has exactly 8 (SMT off)

 ## Performance Tuning

@@ -169,7 +173,7 @@ vllm serve model \
 Check GPU memory:

 ```
-nvidia-smi
+rocm-smi
 ```

 Check for preemption warnings in VLLM logs.
@@ -187,7 +191,6 @@ htop
 ```
 vllm serve Qwen/Qwen3.6-35B-A3B \
    --gpu-memory-utilization 0.85 \
-    --swap-space 16 \
    --max-num-batched-tokens 4096 \
    --max-num-seqs 128
 ```
@@ -198,7 +201,6 @@ vllm serve Qwen/Qwen3.6-35B-A3B \
 vllm serve Qwen/Qwen3.6-35B-A3B-FP8 \
    --kv-cache-dtype fp8 \
    --gpu-memory-utilization 0.9 \
-    --swap-space 16 \
    --max-num-batched-tokens 8192
 ```

@@ -208,7 +210,6 @@ vllm serve Qwen/Qwen3.6-35B-A3B-FP8 \
 vllm serve meta-llama/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 4 \
    --gpu-memory-utilization 0.9 \
-    --swap-space 32 \
    --max-model-len 8192
 ```

@@ -18,6 +18,18 @@ interchangeable:
 | **Layer split** — layers 0..n on dev A, rest on dev B | `-sm layer -ts <a>/<b>` | **yes**, no collectives needed; works cross-vendor (CUDA + Vulkan measured 2026-09-16) |
 | **Per-tensor placement** — attention+KV on A, experts on B | `-ot <regex>=<dev>` | **NO.** `--override-tensor` sets `has_tensor_overrides()`, a REQUIRED term of the scheduler's `pipeline_parallel` flag (only read site: `llama-context.cpp`, in the `pipeline_parallel = …` expression). That flag sets `n_copies = parallel ? MAX : 1` in `ggml_backend_sched_new`; with `n_copies == 1` a pre-allocated weight on a non-primary device has no backend and the graph aborts at `ggml-backend.cpp:941` (`pre-allocated tensor (blk.0.ffn_down_exps.weight) in a buffer (Vulkan1) that cannot run the operation (NONE)` — `(NONE)` is the leaf's own op name). |

+Upstream anchors, re-read 2026-10-18 against `master`:
+`src/llama-context.cpp:517-526` computes `pipeline_parallel` with
+`!model.has_tensor_overrides()` as a required term;
+`ggml/src/ggml-backend.cpp:1089` carries the verbatim abort
+`pre-allocated tensor (%s) in a buffer (%s) that cannot run the operation (%s)`
+(the `:941` anchor above is where it sat in the `37b53fd` build this was
+measured on); and `common/arg.cpp` defines `-sm/--split-mode` (2821),
+`-fit/--fit` (2882), `--spec-type` (4295), `--spec-draft-device` (4259),
+`--spec-draft-n-max` (4161), `-fa/--flash-attn` (1758) — every flag in §4 is
+real upstream, not fork-only
+([source](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/common/arg.cpp)).
+
 Failure modes observed (mainline `37b53fd`): per-tensor `-ot exps=Vulkan1`
 with `-dev CUDA0,Vulkan1` → scheduler abort; layer-scoped `-ot` with a
 cross-backend pair → model load fails with only `failed to load model`;
@@ -147,7 +159,8 @@ not prevent a boundary-copy fault.
 ## 6. Drafter KV: sized from the TARGET, bounded by its window policy

 `common/speculative.cpp` builds the draft context with
-`cparams.n_ctx = llama_n_ctx(ctx_tgt)` — **no flag caps it.** So:
+`cparams.n_ctx = llama_n_ctx(ctx_tgt)` — `common/speculative.cpp:2663` on
+`master`, re-read 2026-10-18 — **no flag caps it.** So:

 ```
 draft KV = ctx_tgt × block_count × 2 (K,V) × kv_heads × key_length × dtype
@@ -55,7 +55,7 @@ First decide which kind of memory is in question:
 |---|---|---|
 | RTX 3090 (Dankclaw) | discrete GDDR6X | `nvidia-smi --query-gpu=memory.total,memory.used,memory.free` |
 | gfx1151 iGPU (Dankclaw) | **UMA** — "VRAM" is host RAM | `/sys/class/drm/card1/device/mem_info_gtt_{total,used}` (114 GiB) vs `mem_info_vram_*` (2 GiB carve-out) |
-| R9700s (Dankserver) | discrete | `rocm-smi` figure (64 GiB, SVM-backed) |
+| R9700s (Dankserver) | discrete | `rocm-smi --showmeminfo vram` → 34,208,743,424 B = 32,624 MiB (31.86 GiB) per card, read 2026-10-18 — **not** the 64 GiB "SVM-backed" figure this row once carried ([[Dankserver System Specs]]) |

 Per-process truth on NVIDIA:
 `nvidia-smi --query-compute-apps=pid,process_name,used_memory`. Never add the
@@ -66,8 +66,12 @@ co-tenants.
  contiguous blocks — the honest fragmentation signal: 240 blocks/12.3 GiB
  after reboot vs 475/14.7 GiB before means the model did not come back into
  the same hole), device budget, KV pool/working split, "left for everything
-  else". llama.cpp prints at `llama-model.cpp:1827` (per-backend model buffer)
-  and `llama-context.cpp:692` (compute buffer) — but **`llama-bench`
+  else". llama.cpp prints them at `llama-model.cpp:1827` (per-backend model buffer)
+  and `llama-context.cpp:692` (compute buffer) on the era's build; on today's
+  `master` the same `LLAMA_LOG_INFO` lines sit at `llama-model.cpp:2009`
+  ("model buffer size =") and `llama-context.cpp:842` ("compute buffer size =")
+  ([source](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/src/llama-context.cpp),
+  re-read 2026-10-18) — but **`llama-bench`
  suppresses loader INFO and a systemd unit did not put them in the journal**
  (verified `grep -c` = 0). Recipe: one launch through `llama-cli`/`llama-server`
  keeping the first ~200 lines.
@@ -80,7 +84,10 @@ co-tenants.
 - **Traps:** mmap'd PLE is reclaimable page cache; `-ot` makes it pinned —
  "move layers to the card" converts reclaimable cache into device memory and
  frees nothing for co-tenants. A served model's footprint ≠ weight size
-  (frank-zealot: 22.6 of 24.1 GiB for an 11.29 GiB model). Do the capacity
+(a retired frank-zealot shape: 22.6 of 24.1 GiB for an 11.29 GiB model; the card
+today reads 24,576 MiB = 24.0 GiB total, `nvidia-smi --query-gpu=memory.total`,
+2026-10-18, and the deployed payload is the PQ2_0 pair
+[[frank-zealot-llama-prism-bonsai2-pq20]]). Do the capacity
  subtraction before designing: 12 attn layers × 1.62 GiB + 200k f16 KV =
  28.6 GiB > 24.1 GiB usable → KV-in-VRAM on that pair only reaches ~64k.
 - **Context lengths: derive, never remember.** `llama-bench` computes
@@ -94,9 +101,13 @@ co-tenants.

 ## 3. Prompt cache and state sizing

-`--cache-ram` (MiB, default 8192) is HOST RAM for saved prompt states —
-unpinned, on demand, moves no VRAM. `--ctx-checkpoints` (default 32) is a
-different mechanism: per-slot KV snapshots; `0` disables them.
+`--cache-ram` (alias `-cram`, `common/arg.cpp:1719`) is HOST RAM for saved
+prompt states — unpinned, on demand, moves no VRAM. `--ctx-checkpoints` (alias
+`-ctxcp`/`--swa-checkpoints`, `common/arg.cpp:1701`) is a different mechanism:
+per-slot KV snapshots; `0` disables them. Both flags are current upstream; the
+two defaults quoted here (8192 MiB and 32) are the era's values and were not
+re-readable in the upstream sources checked *(unverified 2026-10-18)* — print
+them from the binary (`llama-server --help`) before sizing on them.

 **State law** (compute before trusting any cap): a state is the serialized KV
 of the whole sequence + constant recurrent state + the draft context's KV:
@@ -157,7 +168,7 @@ in the timings. Context cap for full-model residency on that shape stayed
 ## Related

 - [[GGUF Compatibility]] — what a payload is before it is priced
- [[frank-zealot-llama-mimo-q6k-2x200704]] — the current two-boot priced shape
+- [[frank-zealot-llama-mimo-q6k-2x200704]] — the two-boot priced shape of the retired MiMo era (live shape today: [[frank-zealot-llama-prism-bonsai2-pq20]])
 - [[frank-medium-llamacpp-dflash2]] — where the 68 KiB/token datum was measured
 - [[DFlash DSpark Speculative Decoding]] — the spec A/B protocol on llama.cpp
 - [[Dual-R9700-Cooperation]] / [[x4-pair-experiment]] — the multi-device side
@@ -251,17 +251,24 @@ step a redeploy deadlocks against its own gate.
 small/fast + image roles at the new endpoint; move the vision role WITH the
 vision tower (one owner per capability). `shared/homepage/services.json`: a
 card per endpoint, probed from the monitor's own host. Prometheus: only add
-a job if the runtime actually exposes Prometheus text (halogen publishes
-`/health`, `/cache`, `/v1/*` and nothing else — the job was REMOVED with the
-reason written down rather than left as a permanent red).
+a job if the runtime actually exposes Prometheus text — and re-measure rather
+than repeat, because that answer moves. This bullet once said halogen serves
+`/health`, `/cache`, `/v1/*` "and nothing else"; measured 2026-10-18 on
+Dankclaw, `curl -s http://127.0.0.1:7770/metrics` returns Prometheus text
+(`# HELP llamacpp:prompt_tokens_total …`, content-type
+`text/plain; version=0.0.4`) while an invented path 404s — so the surface has
+grown and a scrape target is expressible again.

 **4. Cutover, then verify by driving it.** `deploy.sh <target> --service
 <large> --service <small>` (order matters); per endpoint: `/health`,
 `/v1/models` reports the alias, a chat completion returns content AND
 `reasoning_content`, a `tools` request returns `tool_calls`, an image
 request is answered (or refused with a named reason), the runtime's own
-speculation counters move, and the unit is `enabled`/`generated` with linger
-on. Read the engine's boot ledger for a silent clamp. Finally spend one
+speculation counters move, and the unit is `enabled` and `active`. All three LLM
+endpoints are **root** units today (`User=dank` + `WantedBy=multi-user.target` —
+`scripts/frank-archon.service:30,71`, `scripts/frank-dragoon.service:8,31`,
+`scripts/frank-zealot.service:8,26`), so linger is not what gates them; linger
+matters for rootless quadlets. Read the engine's boot ledger for a silent clamp. Finally spend one
 real request through the harness per changed role — routing labels lie; the
 servers' own journals do not.

@@ -278,4 +285,4 @@ predecessor "stopped" (the port race above).
 - [[Llama Cpp Serving Sizing]] — pricing the shape once it loads
 - [[RDNA4 MoE Expert Offload VRAM Budget]] — vLLM-side fit arithmetic
 - [[LLM Bench Windows and Measurement]] — measuring the new deployment
- [[dankserver-qwen38-fp8-expert-offload-tuning]] — the current endpoint
+- [[dankserver-qwen38-fp8-expert-offload-tuning]] — the retired tcclaviger vLLM endpoint (2026-09-29 → 10-05); the live Dankserver endpoint is [[frank-archon-radiance-qwen38-iq4r]]
@@ -59,9 +59,11 @@ Gen4 usable payload after 128b/130b: **x4 7.877 GB/s, x8 15.75, x16 31.5**.
 **Ceiling arithmetic:** `link time/token = active expert bytes / measured
 H2D rate`; `ceiling = 1 / link_time × resident-fraction saved (LRU hits)`.
 Compare against the compute-in-RAM path at host RAM bandwidth (256 GB/s
-LPDDR5X on the Strix Halo). **If the link is >10x slower than the memory
-behind it (x4 is 31x here), streaming loses by construction and no tuning
-rescues it; doubling the link only doubles a losing number.**
+LPDDR5X on the Strix Halo — 128 GB LPDDR5x-8000 on a 256-bit bus,
+[amd.com spec page](https://www.amd.com/en/products/processors/laptop/ryzen/ai-300-series/amd-ryzen-ai-max-plus-395.html)).
+**If the link is >10x slower than the memory behind it (x4 is 31x here),
+streaming loses by construction and no tuning rescues it; doubling the link
+only doubles a losing number.**

 Worked example (Dankclaw 2026-09-16): Gen4 x4 measured H2D **6.72 / D2H 6.60
 GB/s** (85 % of spec) — pinned H2D ≈ async, pageable within 1 %, i.e.
@@ -215,15 +217,25 @@ reporting an outage (`gitea` vs `gitea-server`).
   complex; x4 suffices for TP.
 2. Board whose CPU x16 bifurcates x8/x8 (done 2026-09-20 on dankserver — both
   R9700s on root ports `00:01.1`/`00:01.3`, every bridge `Routing+`, both
-   endpoints `ReqEn+`).
+   endpoints `ReqEn+`). Re-checked 2026-10-18 without root: both root ports
+   report `current_link_width=8` at `32.0 GT/s`
+   (`/sys/bus/pci/devices/0000:00:01.{1,3}/current_link_width`), and the live
+   engine states direct P2P between the cards
+   ([[Dual-R9700-Cooperation]]).
 3. llama.cpp `--split-mode layer` — no collectives at all ([[Llama Cpp Multi-Device Splits]]); costs the GGUF conversion plus paged attention /
   continuous batching / spec decode.
 4. Independent TP=1 replicas + routing proxy — cards never share one model.

 **Closed software routes (do not re-litigate):** vLLM's IPC custom allreduce
 is gated by a CUDA-sm-keyed table (`{9.0, 10.0, 10.3, 10.7}`; ROCm reports
-12.0 → off on RDNA4 by code limit) — and patching it is insufficient because
-TP init's `broadcast`/`barrier`/logits `all_gather` have no non-RCCL path. A
+12.0 → off on RDNA4 by code limit) — the table is
+`CUSTOM_ALL_REDUCE_MAX_SIZES` in
+`vllm/distributed/device_communicators/all_reduce_utils.py`, whose keys on
+today's `main` are exactly `"9.0"`, `"10.0"`, `"10.3"`, `"10.7"`
+([source](https://raw.githubusercontent.com/vllm-project/vllm/main/vllm/distributed/device_communicators/all_reduce_utils.py),
+read 2026-10-18); nothing keys on a ROCm-reported `12.0`. — and patching it is
+insufficient because TP init's `broadcast`/`barrier`/logits `all_gather` have
+no non-RCCL path. A
 fork wrapping `.all_reduce` (e.g. radiance `RADIANCE_USE_R4D_AR` one-shot
 P2P, gloo for IPC-handle exchange) does not intercept
 `PyNcclCommunicator.__init__`'s warmup allreduce. NCCL symmetric memory needs
@@ -241,4 +253,4 @@ kernel's declared args (`roc-obj-extract` + `llvm-readelf --notes`), look for

 - [[Llama Cpp Multi-Device Splits]] — the layer-split path around the wall
 - [[Dual-R9700-Cooperation]] / [[x4-pair-experiment]] — measured history
- [[dankserver-qwen38-fp8-expert-offload-tuning]] — the live gather economics
+- [[dankserver-qwen38-fp8-expert-offload-tuning]] — the gather economics of the retired tcclaviger vLLM era (2026-09-29 → 10-05)
@@ -10,6 +10,14 @@ timestamp: 2026-09-03
 > **SUPERSEDED 2026-08-17.** The Frank redo retired this topology.
 > See [frank-redo-2026-08-17.md](../frank-redo-2026-08-17.md) and
 > [deployment.md](../deployment.md) for the active configuration.
+>
+> **2026-10-18: nothing pipeline-parallel runs on the fleet.** No RPC listener
+> exists on either host (`ss -ltn` shows no :50052), every artifact named below
+> is gone (§Files), and the worker hardware left the box: the RTX 3090 was
+> removed from Dankserver on 2026-09-15 (it now sits in Dankclaw) and the server
+> runs 2× R9700. The live multi-GPU scheme on Dankserver is tensor parallelism
+> inside one process ([[Dual-R9700-Cooperation]],
+> [[frank-archon-radiance-qwen38-iq4r]]).

 # Qwen3.8-27B Pipeline-Parallel Deployment (Dankclaw + Dankserver)

@@ -54,7 +62,10 @@ helper `frank-restart-small.sh` is obsolete (it restarts the removed
 `frank-zealot` unit); restart the worker with
 `sudo systemctl restart frank-pp-worker`. The Dankclaw helper
 `frank-restart-large.sh` (sync + cache drop + restart) is correct for the
-head. `deploy.sh dankserver` is broken until retargeted. See
+head. The "deploy.sh dankserver is broken until retargeted" note is long fixed:
+`./scripts/deploy.sh dankserver --service frank-archon` is the documented
+invocation today (`scripts/deploy.sh:38`, dispatch case
+`dankserver:frank-archon` at `scripts/deploy.sh:149`). See
 [[deployment]] for the full boot-policy table.

 ## FA-all-quants rebuild (2026-08-17)
@@ -133,10 +144,13 @@ content, degenerate logits). Root cause chain:
   A clean cache and a healthy disk produced correct output immediately
   (acceptance 0.89 on the first smoke test).

-Guard: `scripts/prune-rpc-cache.sh` on Dankserver (cron, 40 GiB cap).
-Never let the cache directory grow unchecked; a full disk silently
-corrupts it. Signature to recognize: healthy load + degenerate repeated-
-token output.
+Guard was `scripts/prune-rpc-cache.sh` on Dankserver (cron, 40 GiB cap). That
+script is gone from the repo and from the host, yet the crontab line still
+runs every 10 minutes against it
+(`*/10 * * * * /home/dank/vLLM/scripts/prune-rpc-cache.sh`, `crontab -l`, read
+2026-10-18 — the target does not exist, so it fails silently). Never let the
+cache directory grow unchecked; a full disk silently corrupts it. Signature to
+recognize: healthy load + degenerate repeated-token output.

 ## Topology

@@ -163,9 +177,9 @@ llama-server b10433                      ggml-rpc-server b10433
 - **Why the head is on Dankclaw:** the model file is already there; the
  worker streams its tensor share at load (no 31.5 GB copy to the server).
 - **Both sides must run the identical build** (b10433 / 9b05354ec). The
-  worker build lives in a worktree `/home/dank/llama-cpp-rpc` on Dankserver
-  so the production b10121 build stays untouched. A version skew hangs the
-  RPC handshake with no error.
+worker build lived in a worktree `/home/dank/llama-cpp-rpc` on Dankserver so the
+production b10121 build stayed untouched (that path no longer exists, read
+2026-10-18). A version skew hangs the RPC handshake with no error.

 ## Files

@@ -179,6 +193,14 @@ llama-server b10433                      ggml-rpc-server b10433
 | `scripts/pp-test.sh` | any box with ssh to both | test orchestrator (preflight/start/verify/bench/stop-pp/restore) |
 | `scripts/pp-bench.py` | claw | API driver; reports server-side `print_timing` |

+
+**Every PP file in that table except `scripts/frank-dragoon.env` no longer
+exists** (checkout read 2026-10-18: `frank-pp-worker.env`,
+`serve-pp-worker.sh`, `serve-pp-head.sh`, `frank-pp-worker.service`,
+`pp-test.sh`, `pp-bench.py` and `prune-rpc-cache.sh` are all absent), and
+`scripts/frank-dragoon.env` is today the halogen-flash-server env, not a PP
+head env ([[frank-dragoon-flash-server-v2-native]]).
+
 ## Gotchas (all verified in b10433 source / live tests, 2026-08-15)

 1. **No `--device` on the head.** Setting `params.devices` makes
@@ -188,9 +210,9 @@ llama-server b10433                      ggml-rpc-server b10433
 2. **The iGPU side is ROCm by default.** Backends register in fixed order
   (HIP before Vulkan); the iGPU dedup rule keeps the first backend's view.
   Live check showed `[RPC0, ROCm0]`. For a Vulkan side, use the second
-   head build `/home/dank/llama.cpp/build-vulkan-rpc` (HIP off) — set
-   `HEAD_BIN` in the env. Trade: ROCm side = faster prefill, ~3% slower
-   decode (measured on this box).
+   head build `/home/dank/llama.cpp/build-vulkan-rpc` (HIP off; removed — the
+   path is gone on 2026-10-18) — set `HEAD_BIN` in the env. Trade: ROCm side =
+   faster prefill, ~3% slower decode (measured on this box).
 3. **Pin `--tensor-split 1,1`.** The default split is proportional to
   *reported free memory*: the Strix reports up to 96 GiB (GTT) vs the
   3090's 24 GB, so the default lands ~20/80 on the slow device (verified
@@ -207,7 +229,9 @@ llama-server b10433                      ggml-rpc-server b10433
 ## Runbook (morning of 2026-08-16)

 Run from any box with ssh access to both (repo path on claw:
-`/home/dank/vllmScripts`, on server: `/home/dank/vLLM`).
+`/home/dank/vllmScripts`, on server: `/home/dank/vLLM` — both still exist as
+stale checkouts; the deployment checkout today is `/home/dank/serverAppConfigs`
+on both hosts).

 ```
 # 0. one-time: pull the kit on both boxes
@@ -243,8 +267,9 @@ Verification checklist after each `start`:
 1. `verify` shows `using device RPC0 ... using device ROCm0|Vulkan0`.
 2. Layer assignment lines (`-lv 10`): worker gets the first ~32 layers at a
   1,1 split.
-3. `nvidia-smi` on the server shows ~15–16 GB used by the worker
-   (production small service + worker share).
+3. `nvidia-smi` on the server showed ~15–16 GB used by the worker
+   (production small service + worker share). No NVIDIA card is in that host
+   today — the equivalent check is `rocm-smi --showmeminfo vram`.
 4. Head GTT usage (rocm-smi) well under 96 GiB; model fully on devices
   (`--gpu-layers all` offloads everything; CPU holds embeddings/lm_head glue).

@@ -36,7 +36,7 @@ In unified memory:

 ### ROCm Version

-vLLM supports AMD GPUs with ROCm 6.3 or above. Dankclaw has ROCm 7.2.4 from AMD repos.
+vLLM supports AMD GPUs with ROCm 6.3 or above *(unverified 2026-10-18)*. Dankclaw has ROCm 7.2.4 from AMD repos (`/etc/apt/sources.list.d/rocm.list` → `deb https://repo.radeon.com/rocm/apt/7.2.4 noble main`; `rocm-core 7.2.4.70204-93~24.04`, read 2026-10-18). No vLLM endpoint runs on this host today — 7770 is halogen-flash-server and 7771 is llama.cpp ([[Dankclaw System Specs]]) — so this page is reference material, not the serving path.

 Check ROCm version:

@@ -83,6 +83,12 @@ Available backends for ROCm:
 | ROCM_AITER_MLA | AITER MLA | DeepSeek models |
 | ROCM_AITER_TRITON_MLA | Combined MLA | DeepSeek models |

+All seven names exist on current vLLM `main` (`AttentionBackendEnum` in
+`vllm/v1/attention/backends/registry.py` —
+[source](https://raw.githubusercontent.com/vllm-project/vllm/main/vllm/v1/attention/backends/registry.py),
+read 2026-10-18), and `--attention-backend`, `--numa-bind`, `--numa-bind-nodes`
+are real `vllm serve` flags (`vllm/engine/arg_utils.py:1098,1171-1176`).
+
 ## Special Flags for APU

 ### Memory Configuration
@@ -97,7 +103,7 @@ vllm serve model \

 - `gpu_memory_utilization`: Set lower (0.8-0.85) to leave room for CPU operations
 - `max_model_len`: Match actual context needs
- The old `--swap-space` argument was removed from current vLLM. Use `--kv-offloading-size` for CPU KV offload
+- The old `--swap-space` argument was removed from current vLLM — `CacheConfig` on `main` carries no `swap_space` field ([source](https://raw.githubusercontent.com/vllm-project/vllm/main/vllm/config/cache.py), read 2026-10-18). Use `--kv-offloading-size` (`kv_offloading_size`, same file) for CPU KV offload

 ### NUMA Binding

@@ -126,15 +132,25 @@ export HSA_ENABLE_SDMA=1
 export HSA_FORCE_FINE_GRAIN_PCIE=1
 ```

-### GPU Memory Limits
+These three variables came out of the September research pass and were not
+re-checked against current ROCm documentation *(unverified 2026-10-18)*.

-Strix Halo APU shares memory between CPU and GPU. Set GPU memory limit:
+### GPU "memory limits" and the gfx override
+
+There is no memory-limit knob for the APU here. What the GPU may address is the
+GTT aperture (`mem_info_gtt_total`, see §ROCm Overcommit); the firmware VGM/UMA
+setting in BIOS is what sizes the *dedicated* carve-out.
+
+`HSA_OVERRIDE_GFX_VERSION` is not a memory setting — it makes the runtime report
+a different ISA version:

 ```
 export HSA_OVERRIDE_GFX_VERSION=11.5.1
 ```

-This may be needed for Strix Halo compatibility.
+Do not set it on this host: the stack already reports `gfx1151` natively
+(`rocm-smi --showproductname` → `GFX Version: gfx1151`, read 2026-10-18). The
+override exists for GPUs whose ISA the installed runtime does not know.

 ## Performance Considerations

@@ -144,13 +160,13 @@ Unified memory has lower bandwidth than dedicated VRAM:

 | Memory Type | Bandwidth |
 |-------------|-----------|
-| HBM3 (A100) | 2 TB/s |
+| HBM2e (A100 80 GB) | 2 TB/s |
 | GDDR6 (RTX 4090) | 1 TB/s |
-| LPDDR5x (Strix Halo) | ~170 GB/s |
+| LPDDR5x-8000, 256-bit (Strix Halo) | 256 GB/s ([amd.com spec page](https://www.amd.com/en/products/processors/laptop/ryzen/ai-300-series/amd-ryzen-ai-max-plus-395.html)) |

 ### ROCm Overcommit

-ROCm reports ~114 GiB of GPU memory on Strix Halo APU (the GTT aperture, `gtt_total=122402963456` bytes = 114 GiB; `llama-server --list-devices` shows 116,732 MiB — the 2026-08-17 "96 GiB" figure was stale). Physical RAM is 64 GiB (61 GiB visible; the box was upgraded from 32 GB). The GPU can address more than physical RAM exists because the GTT aperture maps over the shared LPDDR. vLLM will see ~114 GiB and try to allocate accordingly. Set `--gpu-memory-utilization` to 0.80 or lower to prevent OOM.
+ROCm reports ~114 GiB of GPU memory on Strix Halo APU (the GTT aperture: `mem_info_gtt_total` = 122402963456 bytes = 114 GiB, read 2026-10-18 under `/sys/class/drm/card1/device/`; `llama-server --list-devices` shows 116,732 MiB — the 2026-08-17 "96 GiB" figure was stale). Physical RAM visible to the OS is **121 GiB** today (`free -g` total 121, read 2026-10-18; 64 GiB in the earlier reading on this page, upgraded from 32 GB). The GPU can address more than physical RAM exists because the GTT aperture maps over the shared LPDDR. vLLM will see ~114 GiB and try to allocate accordingly. Set `--gpu-memory-utilization` to 0.80 or lower to prevent OOM.

 Lower bandwidth means slower inference. Plan for lower throughput.

@@ -195,6 +211,10 @@ Unified memory limits concurrent requests:
 | Prefix Caching | Yes |
 | Chunked Prefill | Yes |

+The two "No" rows (Async Output, Multi-step Decoding) were transcribed from a
+vLLM feature-support snapshot and not re-checked against current upstream
+*(unverified 2026-10-18)*.
+
 ### Context Length

 Some models on ROCm have context length limited to 4096 tokens. Check model documentation.
@@ -205,9 +225,16 @@ FP8 quantization depends on GPU architecture:

 - MI300 series supports native FP8
 - Radeon RX 7900 supports FP8 via software emulation
- Strix Halo (gfx1151) uses **software emulation** for FP8 (no native FP8 tensor cores); expect memory savings, not full compute speedup
+- Strix Halo (gfx1151) uses **software emulation** for FP8 matmuls — RDNA 3.5 has
+  no FP8 tensor instructions ([FP8-ROCM](https://github.com/wabibito/FP8-ROCM));
+  expect memory savings, not full compute speedup. (Conflicting vendor-side
+  evidence exists for an FP8/INT8 WMMA path used by FSR4 on RDNA 3.5, so treat
+  the matmul claim as the settled half.)

-For FP4 on Dankclaw, the ROCmFPX llama.cpp fork (`Q2_0_ROCMFP4`) provides native ROCm FP4 kernels.
+For FP4 on Dankclaw the ROCmFPX llama.cpp fork (`Q2_0_ROCMFP4`) provided native
+ROCm FP4 kernels; that runtime line is **retired** (CIRU/Kairic eras,
+[[ciru-activefpx-promptforge]], [[frank-dragoon-kairic-edge-qwen38-27b]]) and no
+ROCmFPX build serves this host today.

 ## Example Commands

@@ -217,7 +244,6 @@ For FP4 on Dankclaw, the ROCmFPX llama.cpp fork (`Q2_0_ROCMFP4`) provides native
 vllm serve Qwen/Qwen3.6-35B-A3B \
    --attention-backend ROCM_AITER_UNIFIED_ATTN \
    --gpu-memory-utilization 0.85 \
-    --swap-space 8 \
    --max-num-batched-tokens 4096 \
    --max-num-seqs 64
 ```
@@ -228,8 +254,7 @@ vllm serve Qwen/Qwen3.6-35B-A3B \
 vllm serve Qwen/Qwen3.6-35B-A3B-FP8 \
    --attention-backend ROCM_AITER_UNIFIED_ATTN \
    --gpu-memory-utilization 0.85 \
-    --kv-cache-dtype fp8 \
-    --swap-space 8
+    --kv-cache-dtype fp8
 ```

 ### With Long Context
@@ -238,7 +263,6 @@ vllm serve Qwen/Qwen3.6-35B-A3B-FP8 \
 vllm serve Qwen/Qwen3.6-35B-A3B \
    --attention-backend ROCM_AITER_UNIFIED_ATTN \
    --gpu-memory-utilization 0.8 \
-    --swap-space 16 \
    --max-model-len 16384 \
    --rope-scaling '{"rope_type":"yarn","factor":2.0,"original_max_position_embeddings":32768}'
 ```
@@ -14,7 +14,7 @@ tags:
 timestamp: 2026-09-11
 ---

-# Dankclaw IOMMU translation off — decision record
+# Dankclaw IOMMU boot line — decision record (amd_iommu=off 2026-09-11 → iommu=pt 2026-10-18)

 **Current state (since 2026-10-18 01:24): Dankclaw boots `iommu=pt`** — identity
 DMA, IOMMU armed, XDNA2 NPU bound and usable. Everything below is the record of
@@ -201,8 +201,11 @@ and PerfOpt is now a bonus nobody is waiting for rather than the reason to flip.
 boot ledger is unchanged to the MiB — 62.9 GiB weights (0.8 of them vision) + 5.5
 GiB KV + 5.7 GiB working = 74.1 GiB, two slots over ONE 200,704-position pool, MTP
 depth 2, prompt cache ON, no clamp line — and Gitea, the Caddy edge and Grafana all
-answered 200. (Later the same day the pool was doubled to 401,408 positions for
-slot parity — that reservation is ~10.8 GiB and the engine-side total ~79.4 GiB;
+answered 200. (Later the same day the pool DOUBLING to 401,408 positions for
+slot parity was COMMITTED — `2b12716` — but as of 2026-10-18 NOT yet
+redeployed: the live boot still reserves ONE 200,704-position pool (5.5 GiB),
+host `frank-dragoon.env` included. When it lands, the reservation is ~10.8
+GiB and the engine-side total ~79.4 GiB;
 see [[frank-dragoon-flash-server-v2-native]].)

 **The NPU came back with the flip.** `amdxdna` bound to `0000:c6:00.1` (Strix/
@@ -1,7 +1,7 @@
 ---
 type: guide
 title: LLM Deployment
-description: Scoped deployment and update process for the two inference services.
+description: Scoped deployment and update process for the three inference services (frank-archon, frank-dragoon, frank-zealot).
 tags:
  - llm
  - deployment
@@ -19,7 +19,7 @@ SearXNG, Caddy, or another container service does **not** restart inference.

 | Target | Host | Service | Port |
 |---|---|---|---:|
-| Dankserver | `dank@dankserver` | `frank-medium` | 7770 |
+| Dankserver | `dank@dankserver` | `frank-archon` | 7770 |
 | Dankclaw | `dank@dankclaw` | `frank-dragoon` | 7770 |
 | Dankclaw | `dank@dankclaw` | `frank-zealot` | 7771 |

@@ -39,7 +39,7 @@ graph LR
 Run the unified deployer from the repository root:

 ```bash
-./scripts/deploy.sh dankserver --service frank-medium
+./scripts/deploy.sh dankserver --service frank-archon
 ./scripts/deploy.sh dankclaw --service frank-dragoon
 ./scripts/deploy.sh dankclaw --dry-run
 ```
@@ -47,10 +47,14 @@ Run the unified deployer from the repository root:
 Without `--service`, `scripts/deploy-plan.py` maps changed files to the service
 on the selected host. The following files select the corresponding service:

- Any file under `dankserver/frank-medium/` (the Quadlet unit, its
-  entrypoint and its healthcheck) selects `frank-medium` on Dankserver —
-  the container mounts the entrypoint and healthcheck straight out of the
-  checkout, so any file there changes deployed state.
+- `scripts/frank-archon.env`, `frank-archon.service`, and
+  `serve-frank-archon.sh` select `frank-archon` on Dankserver
+  (`scripts/deploy-plan.py:422-428`). The quadlet-era directory
+  `dankserver/frank-medium/` left the tree on 2026-09-26 and plans nothing
+  (`scripts/deploy-plan.py:374-377`).
+- `scripts/qwen-sharp-v22.4.0.jinja` selects `frank-dragoon` — a planner rule
+  left from the llama.cpp era when dragoon loaded it via
+  `--chat-template-file` (`scripts/deploy-plan.py:415-421`).
 - `scripts/frank-dragoon.env`, `frank-dragoon.service`, and
  `serve-frank-dragoon.sh` select `frank-dragoon` on Dankclaw.
 - `scripts/frank-zealot.env`, `frank-zealot.service`, and
@@ -59,27 +63,33 @@ on the selected host. The following files select the corresponding service:
  do not select any inference service.

 The target-side `scripts/deploy-remote.sh` installs the selected service.
-`frank-dragoon` and `frank-zealot` are **root units**: the handler relinks the
-repo file into `/etc/systemd/system/` (`relink_unit`), reloads systemd,
-enables it and restarts it. `frank-medium` is a **rootless Quadlet**: the
-handler retires its predecessors (the replica Quadlets and the retired llama
-root unit), stops the service's own unit, waits for the published port to
-clear, installs the `.container` and restarts the generated unit. Each
+All three LLM services are **root units** whose repo unit file is relinked
+into `/etc/systemd/system/` (`relink_unit`), daemon-reloaded, enabled and
+restarted (`deploy-remote.sh:1158` `deploy_llm_dragoon`, `:1254`
+`deploy_llm_zealot`, `:1315` `deploy_llm_archon`). The dragoon and archon
+handlers wait for port 7770 to be released before the replacement starts
+(`wait_port_free`; the 2026-09-16/26 cutover lessons). The archon handler
+additionally hard-gates on the env file, the digest-pinned image ref, and the
+payload before touching the unit (refuse rather than restart-loop). Each
 handler then waits on that service's health endpoint —
-`http://127.0.0.1:7770/health` for frank-dragoon and frank-medium,
-`http://127.0.0.1:7771/health` for frank-zealot. The wait budget is 20 minutes
-because cold model loads are slow. A failed handler does not advance its
-per-service state.
+`http://127.0.0.1:7770/health` for frank-dragoon (budget 1200 s) and
+frank-archon (1800 s), `http://127.0.0.1:7771/health` for frank-zealot
+(900 s) — and refuses a false green: the deploy is only green when the unit
+itself reports a live MainPID behind the health answer
+(`deploy-remote.sh:1395-1403`, `:1285`). A failed handler does not advance
+its per-service state.

 ## Unit and artifact paths

 The root units point into the stable target checkout:
 ```text
+/home/dank/serverAppConfigs/scripts/frank-archon.service
 /home/dank/serverAppConfigs/scripts/frank-dragoon.service
 /home/dank/serverAppConfigs/scripts/frank-zealot.service
 ```
-`frank-medium` is a Quadlet under `dankserver/frank-medium/quadlet/`
-(`frank-medium.container`) rather than a unit in `scripts/`.
+All three services keep their unit, env and serve script as this flat trio
+under `scripts/` — there is no LLM Quadlet left (the `frank-medium`
+quadlet-era directory left the tree 2026-09-26).

 The unit files and serve scripts validate their model/runtime artifacts before
 starting. Keep `REMOTE_DIR` stable; moving the checkout requires updating both
@@ -110,15 +120,16 @@ change in that service's inputs.

 If the LLM handler fails after the target pull:

-1. Inspect `journalctl -u frank-dragoon -n 200` or `journalctl -u frank-zealot
-   -n 200` (root units), or `journalctl --user -u frank-medium -n 200`
-   (rootless Quadlet).
-2. Confirm the model files, the runtime binary and (for frank-medium) the
-   container image are present and readable by `dank`.
+1. Inspect `journalctl -u frank-dragoon -n 200`, `journalctl -u frank-zealot
+   -n 200` or `journalctl -u frank-archon -n 200` (all three are root units);
+   frank-dragoon's engine boot ledger is in `/home/dank/logs/frank_dragoon.log`,
+   frank-archon's in `podman logs frank-archon` — not in the journal.
+2. Confirm the model files, the runtime binary and (for frank-archon) the
+   digest-pinned container image are present and readable by `dank`.
 3. Retry only the affected service:

   ```bash
-   ./scripts/deploy.sh dankserver --service frank-medium
+   ./scripts/deploy.sh dankserver --service frank-archon
   ./scripts/deploy.sh dankclaw --service frank-dragoon
   ./scripts/deploy.sh dankclaw --service frank-zealot
   ```
@@ -1,18 +1,22 @@
 # frank-archon — FreeToken PR #587 ROCm (Qwen3.8-Flash-Next-Uncensored-FP8, 1× R9700)

 **Status: RETIRED 2026-10-05 → (superseded the same day by the radiance
-cutover — see [[frank-archon-radiance-qwen38-native-fp8]]; kept as the
-rollback runbook: the image + orcarouter payload stay on disk until the
-window closes)** · **Host:** Dankserver (192.168.0.235) · **Port:** 7770 ·
+cutover — see [[frank-archon-radiance-qwen38-native-fp8]], itself retired
+2026-10-08; the payload live today (2026-10-18) is the publisher iq4r container,
+[[frank-archon-radiance-qwen38-iq4r]]). Kept as the rollback runbook: the image
+is still in dank's rootless storage, the orcarouter payload is not on disk any
+more)** · **Host:** Dankserver (192.168.0.235) · **Port:** 7770 ·
 **GPU:** 1× Radeon AI PRO R9700 (gfx1201) — the second R9700 sits idle

 The tcclaviger RDNA4 vLLM fork was replaced by **FreeToken at PR #587 head
 `77a7201f98f00d93f618c6cf8b81ffe8360e0899`** (branch `rocm714_torch214`), built
-on the host into the local image
-`localhost/frank-archon-freetoken:pr587-77a7201` by
-`scripts/docker/frank-archon-freetoken.Dockerfile`. Same port, same served
-alias (`frank-archon`), same 131-shard payload
-(`/home/dank/models/Qwen3.8-Flash-Next-Uncensored-FP8`). Rollback:
+on the host into the local image `localhost/frank-primary-freetoken:pr587-77a7201`
+(that is the tag podman reports today — the 2026-10-10 rename never retagged it)
+by `scripts/docker/frank-primary-freetoken.Dockerfile`, which survives only in
+the rollback tag: `scripts/docker/` is not in the tree today. Same port, same
+served alias (the wire id was `frank-primary` until the 2026-10-09 rename), same
+131-shard payload (`/home/dank/models/Qwen3.8-Flash-Next-Uncensored-FP8`, since
+deleted from the host). Rollback:
 git tag `frank-archon-vllm-shapeG-20261003` (the vLLM trio + its env lore),
 runbook [[dankserver-qwen38-fp8-expert-offload-tuning]].

@@ -30,11 +34,17 @@ deterministic pass — no per-boot estimator to fight.
 ## The build (on dankserver, rootless podman as dank)

 ```bash
+git checkout frank-archon-freetoken-pr587-20261005   # scripts/docker/ exists only in the tag
 cd /home/dank/serverAppConfigs
-podman build -t frank-archon-freetoken:pr587-77a7201 \
-  -f scripts/docker/frank-archon-freetoken.Dockerfile scripts/docker/
+podman build -t frank-primary-freetoken:pr587-77a7201 \
+  -f scripts/docker/frank-primary-freetoken.Dockerfile scripts/docker/
 ```

+(The names above are the ones the tag actually carries —
+`scripts/docker/frank-primary-freetoken.Dockerfile`, per
+`git ls-tree frank-archon-freetoken-pr587-20261005`. The 2026-10-10 rename
+swept the docs, not the tag or the image in storage.)
+
 Laws baked into the Dockerfile (each one cost a failure):

 - **Base digest-pinned**: `rocm/pytorch:rocm7.14_ubuntu24.04_py3.12_pytorch_release_2.11.0@sha256:a223aee1…` —
@@ -18,20 +18,26 @@ timestamp: 2026-09-30

 # frank-archon — GLM-5.3-Flash W4A16 int4 (tcclaviger, 2x R9700)

-> **RETIRED 2026-10-01.** Cutover reversed to Qwen3.8-Flash-Next-Uncensored-FP8
-> + MTP4 (commit `2339fae` trio). The DFlash2 drafter experiment is a
-> **failure**: after five patches the drafter served and drafted (12.8 tok/s
-> proposed, 65,536 ctx, both TP ranks capturing FULL dflash2 cuda graphs) but
-> **acceptance pinned at 1.00-1.38 on every text class including verbatim
-> repetition** — the signature of a mis-wired aux-hidden-state capture, not a
-> weak drafter. At ~1.2 acceptance the 8-token verification tax makes decode
-> 5x SLOWER than the 9.9-10.0 no-draft baseline (1.6-1.8 tok/s measured). The
-> untested alternative capture semantics: post-layer output state
-> (DeepSeek's `hidden_states + residual`) or the mHC `comb` stream. Payload
-> (170 GiB) + drafter (2.2 GiB) staged to
-> `/home/dank/.AGENTTRASH/20261001-glm-purge/` pending purge approval.
-> KV-cache work that survives: patches 02/03/04 in `scripts/patches/` are
-> generic unifier/tailpin/grouping fixes, apply-verified against the image.
+> **RETIRED 2026-10-01** (era 2026-09-30 → 10-01, matching the AGENTS.md Runbook
+> Index). Cutover reversed to Qwen3.8-Flash-Next-Uncensored-FP8 + MTP4 — the
+> trio as of commit `2339fae`, restored by `d91379c` (2026-09-30). frank-archon
+> runs [[frank-archon-radiance-qwen38-iq4r]] (radiance) today, 2026-10-18. The
+> DFlash2 drafter experiment is a **failure**: after five patches the drafter
+> served and drafted (12.8 tok/s proposed, 65,536 ctx, both TP ranks capturing
+> FULL dflash2 cuda graphs) but **acceptance pinned at 1.00-1.38 on every text
+> class including verbatim repetition** — the signature of a mis-wired
+> aux-hidden-state capture, not a weak drafter. At ~1.2 acceptance the 8-token
+> verification tax makes decode 5x SLOWER than the 9.9-10.0 no-draft baseline
+> (1.6-1.8 tok/s measured). The untested alternative capture semantics: post-layer
+> output state (DeepSeek's `hidden_states + residual`) or the mHC `comb` stream.
+> Payload (170 GiB) + drafter (2.2 GiB) were staged to
+> `/home/dank/.AGENTTRASH/20261001-glm-purge/` and purged since — on 2026-10-18
+> Dankserver has no GLM tree under `/home/dank/models/` and `~/.AGENTTRASH` is
+> empty. KV-cache work that survives: `glm53-dflash-04-kv-groups-draft.patch` and
+> `glm53-dflash-04b-kv-registry-dflash.patch` are still in `scripts/patches/`;
+> patch 03 (tailpin) was deleted at the rollback (`d91379c`) and patch 02 was
+> never committed. None of these apply byte-exact today — the 2026-10-10 rename
+> (`55f87fc`) rewrote the retired service names inside their context lines.


 > **Question this page answers.** Can the fleet serve the 320B-class
@@ -695,12 +701,16 @@ newest GLM dialect the fork ships (`glm45`/`glm47` exist for both).
 ## Operations

 ```bash
-# rollback to the pre-cutover qwen FP8 + MTP4 shape (payload and R9V state
-# dirs are untouched on disk):
+# rollback to the pre-cutover qwen FP8 + MTP4 shape. The trio is in git; the
+# qwen FP8 payload is NOT on disk any more, so re-fetch it first. The R9V state
+# dirs are still on the host (/home/dank/r9v-state/):
 git show 2339fae -- scripts/ | git apply   # or: git checkout 2339fae -- scripts/
 ./scripts/deploy.sh dankserver --service frank-archon

-# payload inventory (34 shards + 2 extras, weight-map index):
+# payload inventory (34 shards + 2 extras, weight-map index) — in the GLM era
+# this was scripts/download-frank-primary.sh (REPO=Intel/GLM-5.3-Flash-W4A16-AutoRound,
+# EXPECTED_SHARDS=34, git show f2bcf84). The same-named script today fetches
+# Qwen/Qwen3.8-Flash-Next-FP8 (scripts/download-frank-archon.sh:21):
 bash scripts/download-frank-archon.sh --verify-only

 # live telemetry (needs the profiler window; with_stack=false is mandatory —
@@ -794,5 +804,5 @@ toggling on the mini itself).

 | state | where |
 | --- | --- |
-| qwen FP8 + MTP4 (2026-09-29 → 09-30) | commit `2339fae`, payload `/home/dank/models/Qwen3.8-Flash-Next-Uncensored-FP8` |
+| qwen FP8 + MTP4 (2026-09-29 → 09-30) | commit `2339fae`; payload `/home/dank/models/Qwen3.8-Flash-Next-Uncensored-FP8` was deleted from the host (2026-10-18: `/home/dank/models/` has `StillDeadcode`, `rad`, `tpl.jinja`) — rollback = re-fetch |
 | R9V radiance Qwen3.8-Flash-Next Q8_0 | [[frank-archon-r9v-radiance-qwen38-q8]], state dirs `/home/dank/r9v-state/{q8xl,uncensored}` |
@@ -1,7 +1,7 @@
 ---
 type: configuration
 title: frank-archon llama.cpp Qwen3.8-Flash-Next Q8_0 Runbook
-description: ACTIVE frank-archon runbook — unsloth llama.cpp (the b11030-mix prebuilt, ROCm gfx120X, bundled runtime, root systemd unit) serving unsloth/Qwen3.8-Flash-Next-GGUF at Q8_0 (175.3 GiB across six split parts) on Dankserver's two Radeon AI PRO R9700s (gfx1201), with the shared Q8_0 MTP drafter (depth 2) chained behind ngram-mod, BF16 vision, and the routed experts + 51B-param n-gram embedding table computed in host RAM. Port 7770, one stream, full 262,144 ctx. Cutover 2026-09-26, replacing the same-day Lucebox DS4.1 deployment.
+description: RETIRED 2026-09-26 → 09-27 frank-archon runbook — unsloth llama.cpp (the b11030-mix prebuilt, ROCm gfx120X, bundled runtime, root systemd unit) serving unsloth/Qwen3.8-Flash-Next-GGUF at Q8_0 (175.3 GiB across six split parts) on Dankserver's two Radeon AI PRO R9700s (gfx1201), with the shared Q8_0 MTP drafter (depth 2) chained behind ngram-mod, BF16 vision, and the routed experts + 51B-param n-gram embedding table computed in host RAM. Port 7770, one stream, full 262,144 ctx. Cutover 2026-09-26, replacing the same-day Lucebox DS4.1 deployment; superseded 2026-09-27, and frank-archon runs [[frank-archon-radiance-qwen38-iq4r]] today (2026-10-18).
 tags:
  - frank-archon
  - dankserver
@@ -21,7 +21,9 @@ timestamp: 2026-09-26

 # frank-archon llama.cpp Qwen3.8-Flash-Next Q8_0 Runbook

-The ACTIVE dankserver LLM endpoint (:7770, alias **frank-archon**):
+The dankserver LLM endpoint (:7770, alias **frank-archon**) as it stood from
+2026-09-26 to 2026-09-27 (retired; the port today serves
+[[frank-archon-radiance-qwen38-iq4r]]):
 unsloth llama.cpp serving `unsloth/Qwen3.8-Flash-Next-GGUF` at **Q_8**
 (the 6-part `Q8_0/` main, 175.30 GiB) on **both** Radeon AI PRO R9700s,
 with the **shared Q_8 MTP drafter** (`draft-mtp`, depth 2) layered with
@@ -240,22 +242,29 @@ traffic mix with `frank-archon-expert-activity.py <pid>` (or

 ## Rollback

-The lucebox DS4.1 material is fully retained on the host: image
-`localhost/lucebox-rocm:gfx1201`, the 378 GiB payload, and the quadlet-era
-repo files in `dankserver/.AGENTTRASH/20260926-llamacpp-cutover/` (see
-[[frank-archon-lucebox-ds4]]). Restore = move the `.container` back,
-uninstall the root unit (`systemctl disable --now frank-archon` — the
-link, not the file; never `systemctl disable` a unit whose file must
-survive), `daemon-reload`, start the user quadlet. The Qwen payload
-(~179 GiB) stays fetched, so a forward re-swap is a redeploy, not a
-refetch.
+The lucebox DS4.1 image `localhost/lucebox-rocm:gfx1201` is still in dank's
+rootless storage; the 378 GiB payload is not (Dankserver's `/home/dank/models/`
+holds only `StillDeadcode`, `rad` and `tpl.jinja` as of 2026-10-18), and the
+quadlet-era repo files were deleted by `8500600` rather than trashed — there is
+no `dankserver/.AGENTTRASH/20260926-llamacpp-cutover/` (see
+[[frank-archon-lucebox-ds4]]). Restore = recover the `.container` from
+`git show 8500600^`, stop the root unit (`systemctl stop frank-archon`; the
+fleet law forbids `systemctl disable` on these hosts — it removes the unit
+entry, which here is the symlink into the checkout), `daemon-reload`, start the
+user quadlet. The Qwen payload (~179 GiB) is no longer on disk either, so a
+forward re-swap is a re-fetch plus a redeploy.

 ## Fleet context

- [[frank-dragoon-unsloth-qwen38-27b-q8xl]] — Dankclaw :7770, the same
-  b11030-mix binary family on gfx1151.
- [[frank-zealot-gemma4-12b]] — Dankclaw :7771, mainline llama.cpp on the
-  3090; the only audio-capable endpoint.
- The harness contract lives in `/home/blank/.omp/agent/models.yml`
-  (`llamacpp (dankserver)` provider, `contextWindow 262144`,
-  `maxTokens 65536`, `input: [text, image]`).
+- [[frank-dragoon-unsloth-qwen38-27b-q8xl]] — the era's Dankclaw :7770, the same
+  b11030-mix binary family on gfx1151 (retired 2026-09-28; frank-dragoon runs
+  [[frank-dragoon-flash-server-v2-native]] today).
+- [[frank-zealot-gemma4-12b]] — the era's Dankclaw :7771, mainline llama.cpp on
+  the 3090, and then the fleet's only audio-capable endpoint. Both are history:
+  frank-zealot serves [[frank-zealot-llama-prism-bonsai2-pq20]] today and no
+  fleet endpoint takes audio (the audio path left with Gemma4 on 2026-10-01).
+- The harness contract lives in `/home/blank/.omp/agent/models.yml`. The era's
+  `llamacpp (dankserver)` numbers (`contextWindow 262144`, `maxTokens 65536`,
+  `input: [text, image]`) are long gone — that provider reads
+  `contextWindow: 200000`, `maxTokens: 16384`, `input: [text, image]` as of
+  2026-10-18.
@@ -1,7 +1,7 @@
 ---
 type: configuration
 title: frank-archon Lucebox DeepSeek V4 Runbook
-description: RETIRED 2026-09-26 frank-archon runbook (active for hours on 2026-09-26) — the Lucebox runtime (github.com/Luce-Org/lucebox, local image localhost/lucebox-rocm:gfx1201) serving DeepSeek-V4.1-Flash-ROCMFP23 (377.2 GiB GGUF, 43-layer MoE, 256 routed experts, top-6) on Dankserver's R9700 with the routed experts computed on CPU from the mmapped page cache. Replaced the same day by [[frank-archon-llamacpp-qwen38-flash-next-q8]] (llama.cpp Qwen3.8-Flash-Next Q8_0); payload and image retained on the host as the rollback target.
+description: RETIRED 2026-09-26 frank-archon runbook (active for hours on 2026-09-26) — the Lucebox runtime (github.com/Luce-Org/lucebox, local image localhost/lucebox-rocm:gfx1201) serving DeepSeek-V4.1-Flash-ROCMFP23 (377.2 GiB GGUF, 43-layer MoE, 256 routed experts, top-6) on Dankserver's R9700 with the routed experts computed on CPU from the mmapped page cache. Replaced the same day by [[frank-archon-llamacpp-qwen38-flash-next-q8]] (llama.cpp Qwen3.8-Flash-Next Q8_0); the image is still in rootless storage but the payload is gone from the host, and frank-archon runs [[frank-archon-radiance-qwen38-iq4r]] today (2026-10-18).
 tags:
  - frank-archon
  - dankserver
@@ -21,9 +21,12 @@ timestamp: 2026-09-26
 > [!warning] RETIRED 2026-09-26 (same day it went live)
 > Replaced by [[frank-archon-llamacpp-qwen38-flash-next-q8]] — unsloth
 > llama.cpp serving Qwen3.8-Flash-Next Q8_0 on both R9700s. This runtime
-> served for hours; the rollback material (image `localhost/lucebox-rocm:
-> gfx1201` and the 378 GiB payload) is retained on the host, and the
-> quadlet-era files live in `dankserver/.AGENTTRASH/20260926-llamacpp-cutover/`.
+> served for hours; the image `localhost/lucebox-rocm:gfx1201` is still in
+> dank's rootless storage, but the 378 GiB payload was deleted from the host
+> (`ls /home/dank/models/` on Dankserver, 2026-10-18: `StillDeadcode`, `rad`,
+> `tpl.jinja` only), and the quadlet-era repo files were deleted by `8500600`
+> (2026-09-26) — they survive only in git history, not in a `.AGENTTRASH`
+> directory (`dankserver/.AGENTTRASH/` holds only `20260916-vllm-radiance`).

 The dankserver LLM endpoint (:7770, alias **frank-archon**) as it stood on
 2026-09-26: the
@@ -61,8 +64,8 @@ mode here, not an error.
 ```
 git clone --recurse-submodules https://github.com/Luce-Org/lucebox.git
 cd lucebox
-# Three local modifications (repo-tracked at
-# dankserver/frank-archon/lucebox-gfx1201.patch):
+# Three local modifications (tracked at the time as
+# dankserver/frank-primary/lucebox-gfx1201.patch, deleted by 8500600):
 #   1. Dockerfile.rocm drops the ROCm *-dev apt packages (the 7.14.1-full
 #      base already ships them in /opt/rocm; the apt repo does not serve
 #      them) and the three runtime math libs.
@@ -98,7 +101,8 @@ fetched with `huggingface_hub` (the xet-native path — plain `curl` full GETs

 ## Deployed flags (2026-09-26)

-From `dankserver/frank-archon/frank-archon-entrypoint.sh` (the unit
+From `dankserver/frank-primary/frank-primary-entrypoint.sh` (deleted by `8500600`;
+recover it with `git show 8500600^:dankserver/frank-primary/frank-primary-entrypoint.sh`) — the unit
 bypasses the image's entrypoint, which only forwards a fixed Qwen/DFlash
 flag set and cannot express the DS4 flags):

@@ -126,20 +130,23 @@ metadata — the fleet contract is unchanged from frank-medium.
 1. Image built and model fetched (gates in `deploy_llm_archon`).
 2. `deploy.sh` → `deploy_llm_archon`: stops and **masks** the radiance
   unit (`frank-medium`), waits for :7770 to free, installs
-   `dankserver/frank-archon/quadlet/frank-archon.container`, starts
+   `dankserver/frank-primary/quadlet/frank-primary.container` (also deleted by
+   `8500600`; recover it from `git show 8500600^`), starts
   `frank-archon.service`, waits for health (1800 s start period — first
   start page-ins the dense weights and builds the graphs).
 3. Verify: `/health` 200 is not enough — a real chat completion, a tool
   call, and an Open WebUI completion.
 4. Retire the radiance unit to the home trash (never `rm`); the MXFP6
-   checkpoint payload stays on disk.
+   checkpoint payload did not stay — it is gone from the host (see Rollback).

 ## Rollback

 Unmask and start the radiance unit (`systemctl --user unmask frank-medium &&
 systemctl --user start frank-medium`) and stop/mask frank-archon. The
-`localhost/radiance-vllm:0.13.0-e060895` image and the
-`/models/Qwen3.8-27B-PARO-MXFP6` checkpoint remain on disk.
+`localhost/radiance-vllm:0.13.0-e060895` image is still in dank's rootless
+storage; the `/models/Qwen3.8-27B-PARO-MXFP6` checkpoint is not — Dankserver's
+`/home/dank/models/` holds only `StillDeadcode`, `rad` and `tpl.jinja` as of
+2026-10-18, so this rollback needs a re-fetch of the payload.

 ## Verification (2026-09-26)

@@ -3,26 +3,32 @@ title: frank-archon — R9V radiance-vLLM Qwen3.8-Flash-Next Q8_0
 service: frank-archon
 host: dankserver
 port: 7770
-status: active
+status: retired
 deployed: 2026-09-27
 supersedes: "[[frank-archon-r9v-radiance-qwen38-uncensored]]"
 tags: [llm, frank-archon, r9v, vllm, radiance, gfx1201, q8]
 ---

-# frank-archon — R9V radiance-vLLM Q8_0 (dankserver, ACTIVE)
+# frank-archon — R9V radiance-vLLM Q8_0 (dankserver, RETIRED 2026-09-27 → 09-30)

-The Dankserver LLM endpoint is the **R9V radiance-vLLM fork**
+The Dankserver LLM endpoint **was** the **R9V radiance-vLLM fork** (retired
+2026-09-30, when [[frank-archon-glm53-flash-w4a16]] took the port; the engine
+live today, 2026-10-18, is radiance with
+[[frank-archon-radiance-qwen38-iq4r]])
 (`drwolfen/radiance-vllm-qwen4exp`, docker-pinned prebuilt image bundle
 `2dac17a2`) serving the **unsloth Qwen3.8-Flash-Next-GGUF Q8_0** payload
 (175.30 GiB, 6 GGUF shards, sha256-verified per part) with the blockfp8
 MTP4 head and the mmproj, on **both R9700s** (gfx1201, BDFs `0000:03:00.0`
-/ `0000:07:00.0`) as `frank-archon` on **:7770**.
+/ `0000:07:00.0`) as `frank-primary` on **:7770** (the `frank-archon` wire alias
+arrived with the 2026-10-09 rename).

 Cut over from the uncensored IQ4_XS payload on 2026-09-27 at Frank's
-direction. Rollback target: [[frank-archon-r9v-radiance-qwen38-uncensored]]
-— the uncensored state dir (`/home/dank/r9v-state/uncensored/`, `ready:
-true`), its frozen config (`restore-config-20260927.env`) and payload stay
-on disk; a rollback is an env-file `R9V_STATE_FILE` flip plus a redeploy.
+direction. Rollback target at the time:
+[[frank-archon-r9v-radiance-qwen38-uncensored]] — its state dir
+(`/home/dank/r9v-state/uncensored/`, with `setup.json` and
+`restore-config-20260927.env`) is still on the host as of 2026-10-18, but the
+IQ4_XS payload itself is not (`/home/dank/models/` holds only `StillDeadcode`,
+`rad`, `tpl.jinja`), so that flip now needs a re-fetch.

 ## Why the swap

@@ -269,9 +275,11 @@ quoting through ssh+zsh layers.
  `scripts/frank-archon.env` `R9V_STATE_FILE` back at
  `/home/dank/r9v-state/uncensored/setup.json`, drop the two q8-only keys
  (adapter, FULL_MUTABLE_CACHE) and the template keys, redeploy — the
-  uncensored state dir and payload are intact on disk.
- **Models on the wire**: served alias `frank-archon`; thinking channel
-  is `reasoning` (vLLM); tool parser `qwen3_coder`.
+  uncensored state dir is intact on disk; the IQ4_XS payload is not (it was
+  deleted in the 2026-10-17 cleanup), so this rollback re-fetches first.
+- **Models on the wire**: served alias `frank-primary` (the StarCraft wire
+  names arrived 2026-10-09, `7c77326`); thinking channel is `reasoning` (vLLM);
+  tool parser `qwen3_coder`.

 ## Known costs (accepted at cutover)

@@ -13,23 +13,29 @@ tags: [llm, frank-archon, r9v, vllm, radiance, gfx1201, retired]
 # frank-archon — R9V radiance-vLLM (dankserver, RETIRED)

 > **RETIRED 2026-09-27** — superseded the same day by the Q8_0 cutover,
-> [[frank-archon-r9v-radiance-qwen38-q8]]. Kept as the rollback runbook:
-> the uncensored state dir, frozen config and payload are intact on disk;
-> the rollback procedure lives in that page's Ops section.
+> [[frank-archon-r9v-radiance-qwen38-q8]] (itself retired 2026-09-30; the live
+> frank-archon runbook today, 2026-10-18, is
+> [[frank-archon-radiance-qwen38-iq4r]]). The uncensored state dir and frozen
+> config are still on disk (`/home/dank/r9v-state/uncensored/` — `setup.json`,
+> `restore-config-20260927.env`); the IQ4_XS **payload is not** — it was deleted
+> in the 2026-10-17 cleanup. The rollback procedure lives in the Q8_0 page's Ops
+> section, with a re-fetch as step one.

-The Dankserver LLM endpoint is the **R9V radiance-vLLM fork**
+The Dankserver LLM endpoint **was** the **R9V radiance-vLLM fork**
 (`drwolfen/radiance-vllm-qwen4exp`, docker-pinned prebuilt) serving
 `Dyluhn/Qwen3.8-Flash-Next-Uncensored-R9V-IQ4_XS` — the abliterated
 Qwen3.8-Flash-Next at IQ4_XS (92.39 GiB, 3 GGUF shards) with the blockfp8
 MTP4 head and the F16 mmproj — on **both R9700s** (gfx1201, BDFs
-`0000:03:00.0` / `0000:07:00.0`) as `frank-archon` on **:7770**.
+`0000:03:00.0` / `0000:07:00.0`) as `frank-primary` on **:7770** (the
+`frank-archon` wire alias arrived 2026-10-09).

 Replaced llama.cpp b11030 (Qwen3.8-Flash-Next Q_8) on 2026-09-27 at Frank's
 direction; downtime window ~1 h 20 min (killed 02:47, healthy 04:11 PDT).
 Rollback target: [[frank-archon-llamacpp-qwen38-flash-next-q8]] — the
 llama.cpp trio (unit/env/serve) is at commit `4992e5a`+ (the repo-side
-wiring; host unit was the relinked one) and the GGUF payload stays on disk,
-so a rollback is a redeploy.
+wiring; host unit was the relinked one); the GGUF payload is no longer on
+disk (Dankserver's `/home/dank/models/` holds only `StillDeadcode`, `rad`,
+`tpl.jinja` as of 2026-10-18), so that rollback is a re-fetch plus a redeploy.

 ## Production shape (repo-tracked)

@@ -38,7 +44,7 @@ The repo carries a **thin** wiring; the engine shape lives on-host:
 | Piece | File | Law |
 |---|---|---|
 | Unit | `scripts/frank-archon.service` | Root unit, `User=dank`, `LimitMEMLOCK=infinity`, `ExecStop=podman stop -t 120 frank-archon-r9v`, `Restart=on-failure` |
-| Env | `scripts/frank-archon.env` | Production overrides ONLY: bind 0.0.0.0, :7770, alias `frank-archon`, container `frank-archon-r9v`, GPU BDFs |
+| Env | `scripts/frank-archon.env` | Production overrides ONLY: bind 0.0.0.0, :7770, alias `frank-primary` (the wire id became `frank-archon` on 2026-10-09), container `frank-archon-r9v`, GPU BDFs |
 | Serve | `scripts/serve-frank-archon.sh` | Layers setup state under repo env → execs the fork's own `scripts/launch.sh` via the docker→podman shim → `docker wait` |
 | Deployer | `scripts/deploy-remote.sh` `deploy_llm_archon` | Gates on setup state ready, image digest, PLE bytes, shard files; MainPID false-green check |

@@ -1,6 +1,10 @@
 # frank-archon — Radiance (StillDeadcode), Qwen3.8-Flash-Next-FP8 NATIVE, 2× R9700 TP=2

-**Status: ACTIVE 2026-10-05 →** · **Host:** Dankserver (192.168.0.235) · **Port:** 7770 · **GPU:** 2× Radeon AI PRO R9700 (gfx1201), TP=2
+**Status: RETIRED 2026-10-05 → 2026-10-08** — replaced by the Swift1.5 w4dn8
+conversion ([[frank-archon-radiance-swift15-w4dn8]]), itself retired 2026-10-15;
+the payload live today (2026-10-18) is the publisher iq4r container,
+[[frank-archon-radiance-qwen38-iq4r]] (`scripts/frank-archon.env:110-111`). ·
+**Host:** Dankserver (192.168.0.235) · **Port:** 7770 · **GPU:** 2× Radeon AI PRO R9700 (gfx1201), TP=2

 The FreeToken PR #587 endpoint was replaced by the **radiance engine** (C++/HIP,
 libr4d kernels for gfx1201, no Python in the serving path) driving the
@@ -10,9 +14,14 @@ digest-pinned image `stilldeadcode/radiance@sha256:4c3f484564bb2872784e4…`
 (`frank-archon.service`, `User=dank`, `LimitMEMLOCK=infinity`). Same port,
 same served alias (`frank-archon`), same container identity
 (`frank-archon` = the unit name). Rollback: git tag
-`frank-archon-freetoken-pr587-20261005` (FreeToken trio + Dockerfile), image
-`localhost/frank-archon-freetoken:pr587-77a7201`, payload
-`/home/dank/models/Qwen3.8-Flash-Next-Uncensored-FP8`.
+`frank-archon-freetoken-pr587-20261005` (FreeToken trio + Dockerfile; the
+Dockerfile lives in the tag as `scripts/docker/frank-primary-freetoken.Dockerfile`
+— `scripts/docker/` is not in the tree today), image
+`localhost/frank-primary-freetoken:pr587-77a7201` (that is the tag on the host —
+the 2026-10-10 rename never retagged it), payload
+`/home/dank/models/Qwen3.8-Flash-Next-Uncensored-FP8`, which is **no longer on
+disk** (`ls /home/dank/models/` on Dankserver 2026-10-18: `StillDeadcode`, `rad`,
+`tpl.jinja` only).

 ## Why radiance

@@ -126,9 +135,10 @@ serve script's TTM preflight (`FRANK_ARCHON_TTM_MIN_MIB=140000`) refuses to
 start until it is raised. DONE 2026-10-05 pre-cutover: sysfs write of
 **52,428,800 pages = 200 GiB** (`/sys/module/ttm/parameters/pages_limit`;
 verified read-back; raising at runtime is harmless and allocates nothing).
-PERSISTENCE: the sysfs write does not survive reboot — add
-`ttm.pages_limit=52428800` to the kernel cmdline at the next scheduled
-reboot.
+PERSISTENCE: the sysfs write does not survive reboot, and the kernel-cmdline
+`ttm.pages_limit=52428800` was never added — the unit now raises the knob at
+every boot instead (`scripts/frank-archon.service:44`,
+`ExecStartPre=+…/scripts/ttm-preflight.sh --raise`).

 **Per-rank VRAM** at TP2: expert slice 56.4 GiB total across VRAM + host
 pool; trunk ~3.75 GiB/rank; token embedding vocab-parallel (~1.18 GiB/rank
@@ -280,12 +290,13 @@ Post-cutover checklist (each is observable, not assumed):

 | Layer | Path |
 |---|---|
-| FreeToken (one card, native FP8 safetensors) | `git checkout frank-archon-freetoken-pr587-20261005 -- scripts/frank-archon.env scripts/frank-archon.service scripts/serve-frank-archon.sh scripts/docker/ tests/frank_archon_unit.bats` + redeploy; image `localhost/frank-archon-freetoken:pr587-77a7201` and payload `/home/dank/models/Qwen3.8-Flash-Next-Uncensored-FP8` stay on disk until the window closes |
+| FreeToken (one card, native FP8 safetensors) | `git checkout frank-archon-freetoken-pr587-20261005 -- scripts/frank-archon.env scripts/frank-archon.service scripts/serve-frank-archon.sh scripts/docker/ tests/frank_archon_unit.bats` + redeploy; the image in storage is `localhost/frank-primary-freetoken:pr587-77a7201`, and the payload `/home/dank/models/Qwen3.8-Flash-Next-Uncensored-FP8` must be re-fetched — it is gone from the host |
 | tcclaviger vLLM fork (TP=2, shape G) | git tag `frank-archon-vllm-shapeG-20261003` (trio + env lore; image still in dank's rootless storage) |
-| 4-bit StillDeadcode publisher shape | `qwen3.8-next-flash-fp8-iq4r-moe.rad` + `--host-pool-mib 12288` — the documented fallback if the native container ever proves unbootable |
+| 4-bit StillDeadcode publisher shape | `qwen3.8-next-flash-fp8-iq4r-moe.rad` — **this became the live payload on 2026-10-15** ([[frank-archon-radiance-qwen38-iq4r]]), deployed with `--host-pool-mib 44928` (`scripts/frank-archon.env:184`), not the 12,288 MiB first sketched here |

-Retire the FreeToken-era orcarouter payload to `~/.AGENTTRASH/` only after
-the rollback window closes (trash policy, never `rm`).
+The FreeToken-era orcarouter payload has since been deleted from the host
+(`ls /home/dank/models/` on Dankserver, 2026-10-18) — there is nothing left to
+trash, and the FreeToken rollback needs a re-fetch.

 ## Links

@@ -547,14 +547,16 @@ full-height conversations at once, and answer each one exactly. It does.

 ### Wire rename + the bench drop-in trap (2026-10-09)

-`FRANK_ARCHON_SERVED_NAME` moved `frank-archon` → **frank-archon**; the
-service, unit, scripts and env file keep the old name. Radiance is the only
+`FRANK_ARCHON_SERVED_NAME` moved the served id `frank-primary` →
+**frank-archon** (commit `7c77326`, 2026-10-09); the service, unit, scripts and
+env file kept `frank-primary` until the 2026-10-10 rename (`55f87fc`) brought
+them to `frank-archon` too. Radiance is the only
 fleet engine whose `/v1/models` listing reflects the flag, and it echoes the
 **requested** model name in chat responses — so a chat probe that returns 200
 proves nothing about the served id. Always read `/v1/models`.

 The first deploy after the edit came up green and `/v1/models` still said
-`frank-archon`. Cause: a campaign leftover drop-in
+`frank-primary`. Cause: a campaign leftover drop-in
 `/etc/systemd/system/frank-archon.service.d/bench.conf` (2026-10-08 04:09)
 overrode BOTH `Environment=FRANK_ARCHON_ENV_FILE` and `ExecStart` to the
 staging worktree `/home/dank/serverAppConfigs-swift15`. Every
@@ -563,7 +565,8 @@ staging tree: green health gate, old configuration, silently. Verified before
 removing: the staging `serve-frank-archon.sh` and `frank-archon.service`
 are byte-identical to the checkout, its `frank-archon.env` differed only by
 the alias line, and its HEAD (`8375567`) is an ancestor of `main`. The
-drop-in is staged in `/home/dank/.AGENTTRASH/20261009-frank-archon-bench-dropin/`.
+drop-in was staged in `/home/dank/.AGENTTRASH/20261009-frank-archon-bench-dropin/`
+(that dated dir is gone — the trash dir is empty on Dankserver as of 2026-10-18).
 After `daemon-reload` + restart, `/v1/models` reports `frank-archon` (boot
 healthy in 102 s, shape unchanged: fp8 KV, spec depth 2, seqs 3, vram pair
 26071/3543).
@@ -94,6 +94,9 @@ the pool: **two long conversations can no longer share the endpoint** (two of
 ≤100k can). That is acceptable here because frank-dragoon carries the `slow`
 (medium-thinking) role and the `security-reviewer` subagent, not the
 interactive workhorse (that is frank-archon).
+Frank lifted exactly that concurrency limit on 2026-10-18 — see *Pool
+doubled for slot parity* below; that lift is COMMITTED but not yet deployed,
+so the sentences above remain the live truth until the next redeploy.

 **Memory ledger** (121.2 GiB unified), from the boot ledgers. The 22:20 boot
 printed `pinned 62.11 GiB in 1 range(s) in 1.6 s (41.0 GB/s)` trunk,
@@ -112,6 +115,43 @@ that long prompts read.
 `HALOGEN_FLASH_PIN_TRUNK=0` is **rejected by the v2 loader** — the trunk
 stays pinned. Disk-backing the weights is not a lever on this format.

+## Pool doubled for slot parity — committed 2026-10-18, awaiting redeploy
+
+`HALOGEN_KV_POOL_POSITIONS` **200,704 → 401,408** (commit `2b12716`), Frank's
+call: frank-dragoon's total in-flight context was **half** frank-zealot's —
+the llama.cpp endpoint runs one 401,408-position pool split into two 200,704
+conversations, while dragoon ran one 200,704-position pool behind its two
+slots, so one maximum-length request filled it and any second long
+conversation had to stay under ~100k (commit message;
+`scripts/frank-dragoon.env:26-27`, `:183-186`).
+
+- **The per-request ceiling does NOT move.** `HALOGEN_CTX` stays 200,704, the
+  native wall stays 262,144 (`HALOGEN_ROPE_YARN` law), and `models.yml`
+  `contextWindow` stays **155,648** — the pool is the shared budget behind the
+  slots, not the window. The serve seam enforces `HALOGEN_CTX ≤
+  HALOGEN_KV_POOL_POSITIONS ≤ HALOGEN_KV_SLOTS × HALOGEN_CTX`
+  (`scripts/serve-frank-dragoon.sh:85-95`); 401,408 is `slots × ctx`, the top
+  of the legal band, and exactly frank-zealot's pool number — parity, not
+  approximation.
+- Expected reservation **~10.8 GiB** at ~28 KiB/position (preflight formula,
+  `scripts/frank-dragoon.env:70-72`); the measured points beside it are 5.5
+  GiB at 200,704 (boot ledger 2026-10-18), 7.2 GiB reserved / 7.4 GiB billed
+  at 262,144, and 14.6 GiB at the 2026-10-06 shape's 524,288
+  (`scripts/frank-dragoon.env:49-52`, `:74-76`).
+- That RAM comes out of the n-gram table's page cache — FLAGS.md law: RAM the
+  pool takes is RAM that table loses.
+
+**Deploy state as of 2026-10-18: NOT yet deployed.** The live container
+(booted 2026-10-18 01:25) still runs `HALOGEN_KV_POOL_POSITIONS=200704` —
+verified in its `flash_serve` `/proc/<pid>/environ` and in the host-deployed
+`frank-dragoon.env` — and the 2026-10-18 boot ledger reserves `the KV pool,
+200704 positions (about 5.5 GiB)` with `74.1 GiB in all`
+(`/home/dank/logs/frank_dragoon.log`). Until the next
+`./scripts/deploy.sh dankclaw --service frank-dragoon`, the boot ledger keeps
+printing `2 slots over ONE 200704-position KV pool`; the first boot at the
+new pool must show `ONE 401408-position KV pool` and the ~10.8 GiB
+reservation — read that line before quoting 401,408 as live anywhere.
+
 ## Measured A/B — same battery, both boots (2026-10-17)

 Behavior probes ran against the live service (tagged `swift15` / `v2abl`);
@@ -267,6 +307,9 @@ restart; `webui.db.bak-20261017b` holds the pre-cutover row).
 **What the cut cost:** with pool == ctx one maximum-length request fills the
 pool, so two 200k conversations never coexist (two of ≤100 k do), and the
 harness window is now 155,648 — the 180 k compaction target of the 262,144 era
-is unreachable because the window itself is smaller. **What it bought:** 1.7
+is unreachable because the window itself is smaller. (The pool == ctx
+concurrency limit is superseded — on redeploy only — by *Pool doubled for slot
+parity* above; the window math stands, the pool never moves the ceiling.)
+**What it bought:** 1.7
 GiB back as page cache for the 47.68 GiB n-gram table (9.1 GiB against the
 2026-10-06 shape's 524,288 pool), and a smaller prompt-cache entry.
@@ -15,11 +15,17 @@ timestamp: 2026-09-11

 # frank-npu — the retired FLM NPU endpoint

-> **RETIRED 2026-09-11.** The endpoint is gone by operator decision, together
-> with the IOMMU configuration it required — see
-> [[dankclaw-iommu-translation-off]]. The service unit, env file and serve
-> script are staged in `serverAppConfigs/.AGENTTRASH/` (suffixed `.flm-npu`),
-> and the host unit is stopped and masked.
+> **RETIRED 2026-09-11 by operator decision** — and still retired: there is no
+> NPU endpoint service on Dankclaw today. The IOMMU configuration it required
+> has since been reversed twice — see
+> [[dankclaw-iommu-translation-off]]: the live 2026-10-18 posture is
+> `cat /proc/cmdline` → `… ro quiet splash iommu=pt …` (no `amd_iommu` token),
+> `amdxdna` is bound and `/dev/accel/accel0` exists, so the hardware is
+> reachable again — revival is tracked as Gitea issue #3. The service unit, env
+> file and serve script are staged in `serverAppConfigs/.AGENTTRASH/`
+> (suffixed `.flm-npu`), and the host unit is still masked
+> (`systemctl is-enabled frank-npu` → `masked`, read 2026-10-18). Port 7771
+> belongs to [[frank-zealot-llama-prism-bonsai2-pq20]] today.

 The third inference endpoint on Dankclaw: a FastFlowLM (FLM) v1.0.1 server
 (`/usr/bin/flm`, dpkg `fastflowlm`) on the **XDNA2 NPU** (50 TOPS), serving the
@@ -56,9 +62,16 @@ upstream project on this exact silicon. That single flag is the whole decision:
  NPU sits in IOMMU group 26 `identity` with PASID width 10, `/dev/accel/accel0`
  is `crw-rw---- root:render 261,0` and `dank` is in `render` — so a revival
  quadlet needs `AddDevice=/dev/accel/accel0` + `GroupAdd=keep-groups`, the
-  ComfyUI `/dev/kfd` pattern. Kernel versions to avoid: **6.18–6.18.7** disables
-  SVA outright. Full census in [[dankclaw-iommu-translation-off]]
-  § *2026-10-18 execution*.
+  ComfyUI `/dev/kfd` pattern. Re-read live 2026-10-18: `lspci -k -s c6:00.1` →
+  `Kernel driver in use: amdxdna`; `journalctl -k -b` → `Initialized
+  amdxdna_accel_driver 0.7.0 for 0000:c6:00.1` and `Load firmware
+  amdnpu/17f0_11/npu_7.sbin`; `/sys/kernel/iommu_groups/26/type` → `identity`;
+  `ls -l /dev/accel/accel0` → `crw-rw---- 1 root render 261, 0` (created
+  2026-10-18 01:25); `id -nG dank` contains `render`. Kernel versions to avoid:
+  **6.18–6.18.7** disables SVA outright *(unverified 2026-10-18 — upstream
+  reports place the amdxdna/Strix-Halo breakage at 6.18.4+ and fixed by 6.19.2,
+  not at a clean 6.18–6.18.7 window)*. Full census in
+  [[dankclaw-iommu-translation-off]] § *2026-10-18 execution*.
 - The operator took the vendor's prefill figure on the September evidence, so the
  NPU endpoint went — and it stays retired because nobody has asked for a model
  on it, not because the hardware is unreachable.
@@ -71,11 +84,11 @@ image path is halogen's vision tower on `frank-dragoon`.

 | consumer | setting | now |
 |---|---|---|
-| Hermes | `auxiliary.vision` | `dankclaw-large` / `frank-dragoon` (halogen vision tower) |
-| Hermes | `auxiliary.title_generation` | `dankserver-small` / `frank-zealot` |
-| harness (`~/.omp/agent/models.yml`) | `modelRoles.vision` | `llamacpp (dankclaw)` / `frank-dragoon` |
-| harness | `modelRoles.tiny` | `llamacpp (dankserver)` / `frank-zealot` |
-| harness | `modelRoles.task` | `llamacpp (dankclaw)` / `frank-dragoon:medium` |
+| Hermes | `auxiliary.vision` | `dankclaw-large` / `frank-dragoon` (halogen vision tower) *(unverified 2026-10-18: `/opt/hermes` is gone from Dankclaw, so the live `config.yaml` could not be read)* |
+| Hermes | `auxiliary.title_generation` | `dankserver-small` / `frank-zealot` *(unverified 2026-10-18: same)* |
+| harness (`~/.omp/agent/config.yml`) | `modelRoles.vision` | moved again: `llamacpp (dankclaw-3090)/frank-zealot:xhigh` (`config.yml:6`) |
+| harness | `modelRoles.tiny` | `llamacpp (dankclaw-3090)/frank-zealot:off` (`config.yml:10`) |
+| harness | `modelRoles.task` | `llamacpp (dankclaw-3090)/frank-zealot:off` (`config.yml:11`) |

 The `flm (dankclaw-npu)` provider block was removed from the harness model
 config, and the `dankclaw-npu` provider from Hermes's live `config.yaml`.
@@ -84,10 +97,10 @@ config, and the `dankclaw-npu` provider from Hermes's live `config.yaml`.

 | Field | Value |
 |---|---|
-| Runtime | FLM v1.0.1 (`/usr/bin/flm`, dpkg `fastflowlm`) on the XDNA2 NPU |
+| Runtime | FLM v1.0.1 (`/usr/bin/flm`, dpkg `fastflowlm`; `dpkg -l fastflowlm` on 2026-10-18 still reports `fastflowlm 1.0.1`) on the XDNA2 NPU |
 | Service | `frank-npu.service` (systemd **system** unit, `User=dank`, `Restart=on-failure`, `RestartSec=10`, `LimitMEMLOCK=infinity`) |
 | Files (archived) | `scripts/frank-npu.env`, `scripts/serve-frank-npu.sh`, `scripts/frank-npu.service` |
-| Port | `7771` on `0.0.0.0` |
+| Port | `7771` on `0.0.0.0` (that port is frank-zealot's today) |
 | Power mode | `FLM_PMODE=turbo` — nothing else used the NPU, so the top power mode cost no neighbour anything |
 | Context | `FLM_CTX_LEN=131072` (128K, the verified maximum on this box) |
 | Vision/audio | `FLM_ASR=0`; the E4B pack answers images through its own vision tower, and `FLM_ASR=1` would have added Whisper-V3-Turbo-NPU2 (+0.62 GB) and `/v1/audio/transcriptions` |
@@ -132,8 +145,9 @@ The same root cause explained the older
 consequence of IOMMU-off, not a GPU fault.

 **The standing rule this produced — "never set `iommu=off` on this host again" —
-has been superseded**: the NPU it protected is retired by decision, and
-`amd_iommu=off` is now intentional. See
+was superseded twice**: `amd_iommu=off` was the intentional posture from
+2026-10-16 to 2026-10-18, and the host has since flipped back to `iommu=pt`
+(live `cat /proc/cmdline`, 2026-10-18: `… ro quiet splash iommu=pt …`). See
 [[dankclaw-iommu-translation-off]] for the current posture and how to revert it.

 ## Client wiring (historical)
@@ -13,6 +13,16 @@ This page records the full redo of the inference fleet on 2026-08-17.
 The pipeline-parallel split and the FastFlowLM NPU endpoint were retired.
 The old scripts moved to `old/scripts/` in this repository.

+> **HISTORY — the topology below is two fleet generations dead.** Today the
+> fleet is three endpoints: [[frank-archon-radiance-qwen38-iq4r]]
+> (`192.168.0.235:7770`, radiance 1.0.13, 2×R9700 TP=2),
+> [[frank-dragoon-flash-server-v2-native]] (`192.168.0.143:7770`, halogen
+> flash-server 0.16.2 on the iGPU) and
+> [[frank-zealot-llama-prism-bonsai2-pq20]] (`192.168.0.143:7771`, llama.cpp
+> PrismML fork build 10754 on the RTX 3090 — the card that sat in Dankserver
+> until 2026-09-15). No vLLM and no ROCm endpoint serves anything; there is no
+> pipeline parallelism and no NPU endpoint.
+
 ## New Topology

 | Service | Host | Runtime | Model | Port |
@@ -20,6 +30,12 @@ The old scripts moved to `old/scripts/` in this repository.
 | frank-dragoon | Dankserver | llama.cpp (patched FastMTP) | HauhauCS Qwen3.8-27B-Uncensored-Aggressive IQ4_XS | 7770 |
 | frank-zealot | Dankclaw | vLLM ROCm | nameistoken Qwen3.6-35B-A3B Quark W8A8 INT8 | 52625 |

+Names as the 2026-08-17 commit wrote them: `frank-default-large` on Dankserver
+(`git show d9af7f1:scripts/frank-default-large.env:20,22` → `ALIAS=frank-default-large`,
+`LISTEN_PORT=7770`) and `frank-default-small` on Dankclaw
+(`git show d9af7f1:scripts/frank-default-small.env:16,18` → `ALIAS=frank-default-small`,
+`LISTEN_PORT=52625`); the Protoss ids date from 2026-10-06 → 10-10.
+
 The RTX 3090 runs the whole 27B model standalone. No RPC worker, no
 tensor split, no NPU.

@@ -58,7 +74,8 @@ tensor split, no NPU.
 ## Context Math (frank-dragoon, RTX 3090)

 KV per token: 16 attention layers x 4 KV heads x 256 dim.
-K q8_0 = 1088 B/token, V f16 = 2048 B/token, total 50176 B/token.
+K q8_0 = 1088 B per layer (4 KV heads × 256 dim × 1.0625 B), V f16 = 2048 B per
+layer, ×16 layers = 50176 B/token total.

 Budget (MiB): 24576 total - 14982 weights - 861 draft - 1024 fixed
 (CUDA context, compute graph, scratch, draft KV) - headroom.
@@ -150,7 +167,8 @@ on gfx1151; newer vLLM releases may already include it.

 - `models.json` (pi): two providers — `llamacpp (dankserver)` at
  http://192.168.0.235:7770/v1 and `vllm (dankclaw)` at
-  http://192.168.0.143:52625/v1.
+  http://192.168.0.143:52625/v1. (The harness config today has three providers
+  and no vLLM: `~/.omp/agent/models.yml:14,94,173`.)
 - HF token: `~/.cache/huggingface/token` on both machines (mode 600).
 - OpenWebUI (sibling repo): retarget `OPENAI_API_BASE_URL` to the
  Dankserver endpoint.
@@ -13,9 +13,20 @@ tags:

 # frank-zealot Benchmark — ncmoe and Batch/Ubatch Tuning

+> **HISTORY (runs 2026-08-13 and 2026-08-25, Dankserver's RTX 3090).** That
+> card was pulled from Dankserver on 2026-09-15 (`lspci | grep -ci nvidia` → 0
+> there on 2026-10-18 — [[Dankserver System Specs]]) and today drives
+> frank-zealot on **Dankclaw**: [[frank-zealot-llama-prism-bonsai2-pq20]]
+> (`Ternary-Bonsai-2-27B-PQ2_0.gguf`, 2 × 200,704 q8_0 KV, MTP off, no
+> `--n-cpu-moe` — the model fits the card outright). What survived the payloads:
+> decode is ubatch-invariant, CUDA prefill climbs monotonically to ubatch 2048,
+> and the logical `--batch-size` is neutral — the live env still ships
+> 4096/2048 (`scripts/frank-zealot.env:44-45`).
+
 This page records a llama-bench sweep on Dankserver (RTX 3090, 24 GiB) for
 the HauhauCS Qwen3.6-35B-A3B Q6_K_P model. The sweep decided the final
-`--n-cpu-moe` and `--ubatch-size` values for `frank-zealot`.
+`--n-cpu-moe` and `--ubatch-size` values for the llama.cpp rung then served on
+that card (the `frank-zealot` name dates from 2026-10-06/10-09).

 Run date: 2026-08-13. Build: llama.cpp `555881ebc` (10121). CUDA, 7 threads,
 `--cache-type-k q8_0 --cache-type-v f16`, `--fit-target 0` (KV auto-sized to
@@ -1,7 +1,7 @@
 ---
 type: reference
 title: "frank-zealot on Dankclaw — llama.cpp, Gemma4-12B QAT Q4_K_M"
-description: "The active frank-zealot runbook — mainline llama.cpp on Dankclaw's RTX 3090 serving HauhauCS Gemma4-12B-QAT-Uncensored-HauhauCS-Balanced at Q4_K_M with a separate MTP assistant sidecar chained behind ngram-mod, q8_0 KV, and --fit sizing the full 262k window: identity, payload, KV arithmetic, the spec-decode chain, deployed flags, the client contract, and what to check when it misbehaves."
+description: "The RETIRED frank-zealot runbook (2026-09-17 → 10-01) — mainline llama.cpp on Dankclaw's RTX 3090 serving HauhauCS Gemma4-12B-QAT-Uncensored-HauhauCS-Balanced at Q4_K_M with a separate MTP assistant sidecar chained behind ngram-mod, q8_0 KV, and --fit sizing the full 262k window: identity, payload, KV arithmetic, the spec-decode chain, deployed flags, the client contract, and what to check when it misbehaves."
 tags:
  - llm
  - frank-zealot
@@ -16,20 +16,26 @@ timestamp: 2026-09-17

 # frank-zealot — llama.cpp Gemma4-12B QAT Q4_K_M (MTP + ngram-mod)

-> **ACTIVE since 2026-09-17.** Replaces [[frank-zealot-qwen38-gsq-rco]]
-> (ISTA-DASLab Qwen3.8-27B-GSQ-RCO IQ3_S, now the rollback target) and
-> [[frank-zealot-vllm-gemma4]] (the same-day vLLM experiment, also the
-> rollback target). Same port (7771), same alias (`frank-zealot`), same
-> client contract surface.
+> **RETIRED 2026-09-17 → 2026-10-01** (AGENTS.md Runbook Index). It replaced
+> [[frank-zealot-qwen38-gsq-rco]] (ISTA-DASLab Qwen3.8-27B-GSQ-RCO IQ3_S) and
+> [[frank-zealot-vllm-gemma4]] (the same-day vLLM experiment).
+> Same port (7771), same alias (`frank-small` — this endpoint only carried the
+> `frank-zealot` name from 2026-10-06/10-09), same client contract surface.
+> :7771 today runs [[frank-zealot-llama-prism-bonsai2-pq20]] (llama.cpp PrismML
+> fork build 10754, `Ternary-Bonsai-2-27B-PQ2_0.gguf`, 2 × 200,704 q8_0 KV, MTP
+> off); the audio input this page documents left the fleet with this payload.

 ## Identity

- **Endpoint:** `frank-zealot` at `192.168.0.143:7771` (Dankclaw).
+- **Endpoint:** `frank-small` at `192.168.0.143:7771` (Dankclaw) —
+  `git show e23df8b:scripts/frank-small.env` → `ALIAS=frank-small`.
 - **Runtime:** mainline llama.cpp master `37b53fd`, CUDA build for sm_86 with
  `-DGGML_CUDA_FA_ALL_QUANTS=ON`
  (`/home/dank/GitPackages/llama.cpp-mainline/build-cuda/bin/llama-server`).
  The FA_ALL_QUANTS flag is required: without it, q8_0 KV + flash attention
-  collapses prefill ~12x on CUDA.
+  collapses prefill ~12x on CUDA. Host check 2026-10-18: that binary reports
+  `0.4.1-dev (build 1, commit 37b53fd)` and its `CMakeCache.txt` reads
+  `GGML_CUDA_FA_ALL_QUANTS:BOOL=ON`.
 - **Service shape:** root systemd unit `scripts/frank-zealot.service`
  (`User=dank`), launched by `scripts/serve-frank-zealot.sh` with tunables from
  `scripts/frank-zealot.env`.
@@ -78,25 +84,29 @@ the >12.8 GiB floor does not apply.
 (`mmproj-Gemma4-12B-QAT-Uncensored-HauhauCS-Balanced-BF16.gguf`, 11 tensors,
 52M params), which also carries an audio encoder. The fleet's image path
 lives here. Audio works: `input_audio` content parts transcribe verbatim
-(verified 2026-09-17 with a 16k mono WAV).
+(verified 2026-09-17 with a 16k mono WAV). Fleet-wide audio ended with this
+payload: no fleet endpoint takes audio input today.

 ## Payload

-The main GGUF, the BF16 mmproj, and the MTP sidecar live under
-`/home/dank/models/Gemma4-12B-QAT`. The serve script refuses to start if any
+The main GGUF, the BF16 mmproj, and the MTP sidecar lived under
+`/home/dank/models/Gemma4-12B-QAT`; they were staged to
+`.AGENTTRASH/20261002-retired-llm-payloads/Gemma4-12B-QAT/` on 2026-10-02 and
+that stage dir is gone as of 2026-10-18, so the payload needs a re-fetch. The serve script refuses to start if any
 is missing (a missing file is an unfinished download, and the unit's restart
 policy would otherwise turn it into a crash loop that reads like a runtime
 fault).

 ## Client contract

- **Alias:** `frank-zealot` (the `id` at `/v1/models`).
+- **Alias:** `frank-small` (the `id` at `/v1/models`).
 - **Reasoning:** extracted to `reasoning_content` (`--reasoning-format
  deepseek`, unlimited budget).
 - **Tools:** supported (`--jinja` is pinned even though this build defaults
  it on, so a future build that flips the default cannot silently take tools
  away).
- **Vision + audio:** supported.
+- **Vision + audio:** both supported in this era; audio is gone fleet-wide
+  today (`input: [text, image]` — `~/.omp/agent/models.yml:214`).
 - **Sampling:** greedy by default (fleet contract); a client that sends a
  temperature gets its own, and the harness applies per-model overrides from
  `models.yml`.
@@ -110,8 +120,12 @@ pp ~965 t/s, tg 257–302 t/s, idle 23,300 MiB of 24,576. Larger ubatches
 ## Rollback

 Payload and runtime for [[frank-zealot-qwen38-gsq-rco]] (ISTA-DASLab
-Qwen3.8-27B-GSQ-RCO IQ3_S) remain intact on disk. [[frank-zealot-vllm-gemma4]]
-is the same-day vLLM experiment (also a rollback target).
+Qwen3.8-27B-GSQ-RCO IQ3_S) are **not on disk any more** (the 2026-10-18 census
+of `/home/dank/models/` has no GSQ-RCO directory and the era fetch script is
+not in the tree) — that rollback re-downloads from ISTA-DASLab.
+[[frank-zealot-vllm-gemma4]] is the same-day vLLM experiment; its weights are
+gone too, though its derived image is still in rootless storage
+(`localhost/vllm/vllm-openai:frank-small`, id `8dad46d79c46`).

 # Citations

@@ -1,9 +1,13 @@
 # frank-zealot — llama.cpp CUDA, Gemma4-26B-A4B Q4_K_M, 1×200,704 (Dankclaw)

-**RETIRED 2026-10-07** — same day it went live. Superseded by
+**RETIRED 2026-10-07** — same day it went live (AGENTS.md Runbook Index).
+Superseded by
 [[frank-zealot-llama-qwen35-9b-q6k-2x200704]] (Qwen3.5-9B Q6_K at
-2 × 200,704 with exact KV); the payload stays at
-`/home/dank/models/Gemma4-26B-A4B/` as the rollback. This page keeps the
+2 × 200,704 with exact KV); :7771 today runs
+[[frank-zealot-llama-prism-bonsai2-pq20]] (llama.cpp PrismML fork build 10754,
+`Ternary-Bonsai-2-27B-PQ2_0.gguf`, 2 × 200,704 q8_0 KV, MTP off). The payload
+stays at `/home/dank/models/Gemma4-26B-A4B/` as the rollback (all three files
+present in the 2026-10-18 host census). This page keeps the
 Gemma4 KV-billing law (the `attention_k_eq_v` pair-billing measurement) and
 the drafter-cost boots, both of which outlive the model.

@@ -12,8 +16,8 @@ the drafter-cost boots, both of which outlive the model.
 |File|Path|Bytes|
 |---|---|---|
 |Main (Q4_K_M)|`/home/dank/models/Gemma4-26B-A4B/Gemma4-26B-A4B-QAT-Uncensored-HauhauCS-Balanced-Q4_K_M.gguf`|16,796,015,520 on disk; the engine reports 16,780,192,888|
-|Vision (mmproj BF16)|`/home/dank/models/Gemma4-26B-A4B/mmproj-Gemma4-26B-A4B-QAT-Uncensored-HauhauCS-Balanced-BF16.gguf`|~1.195 GiB|
-|MTP assistant (on disk, NOT loaded)|`/home/dank/models/Gemma4-26B-A4B/mtp-gemma-4-26B-A4B-it.gguf`|~0.252 GiB|
+|Vision (mmproj BF16)|`/home/dank/models/Gemma4-26B-A4B/mmproj-Gemma4-26B-A4B-QAT-Uncensored-HauhauCS-Balanced-BF16.gguf`|1,194,827,776 B on disk (2026-10-18) = 1.11 GiB|
+|MTP assistant (on disk, NOT loaded)|`/home/dank/models/Gemma4-26B-A4B/mtp-gemma-4-26B-A4B-it.gguf`|251,937,728 B on disk (2026-10-18) = 0.23 GiB|

 Repo: `HauhauCS/Gemma4-26B-A4B-QAT-Uncensored-HauhauCS-Balanced-MTP`
 (base `google/gemma-4-26B-A4B-it`). Downloaded 2026-10-07 by plain
@@ -81,7 +85,8 @@ costs 1,041 + 106 = **1,147 MiB**, so the f16-K raise is **+2,161 MiB**. The
 `--cache-type-v` flag is honoured, not inert.

 The llama.cpp master build at commit `5fc4f3c` supports the arch
-(`src/models/gemma4.cpp`, `LLM_ARCH_GEMMA4 = "gemma4"`). Note: `grep -c`
+(`src/models/gemma4.cpp` and `LLM_ARCH_GEMMA4 = "gemma4"` — both present in
+`/home/dank/GitPackages/llama-master` as read on 2026-10-18, `src/llama-arch.cpp:59`). Note: `grep -c`
 arch names on the packed binary returns 0 for EVERY arch (including the
 `qwen3_5` it serves) — check the source tree, not the binary.

@@ -16,13 +16,19 @@ timestamp: 2026-10-03

 # frank-zealot — llama.cpp MiMo-V2.6 Q5_K_M (RTX 3090, retired)

-> **RETIRED 2026-10-03** — superseded by
+> **RETIRED 2026-10-02 → 2026-10-03** — superseded by
 > [[frank-zealot-llama-mimo-q6k-2x200704]]: the ~3.5 GiB this shape left free
 > bought the **Q6_K quant rung** (same runtime, same 2 × 200,704 pool, same
 > f16 KV), which measures 2,849 MiB free and 94.44 tok/s — 10 % slower
 > decode is the measured price of the higher rung on this bandwidth-bound
 > card. This file remains the rollback reference and the owner of the
-> measured boot-pair table.
+> measured boot-pair table. :7771 today runs
+> the PrismML 27B era of [[frank-zealot-llama-prism-bonsai2-pq20]] (build 10754,
+> 2 × 200,704 q8_0 KV, MTP off) — retired 2026-10-17 → 10-18 as a rollback
+> target; the active row today is build **10777** on
+> `Ternary-Bonsai-2-9B-PQ2_0-MTP-Q8_0.gguf` at 3 × 262,144 q8_0 KV, MTP off by
+> measurement (AGENTS.md Runbook Index). The Q5_K_M
+> payload is still on disk (`stat -c %s` 2026-10-18 → 6876124704).

 > Its own history: one quant step down from [[frank-zealot-llama-mimo-q6k]]
 > (2026-10-01), resized twice on 2026-10-02 (three contexts with vision, then
@@ -36,7 +42,7 @@ timestamp: 2026-10-03

 |Field|Value|
 |---|---|
-|Endpoint|`192.168.0.143:7771`, served alias `frank-zealot`|
+|Endpoint|`192.168.0.143:7771`, served alias `frank-small` in this era (`git show e5893dc:scripts/frank-small.env` → `ALIAS=frank-small`; `frank-zealot` only from 2026-10-06/10-09)|
 |Runtime|llama.cpp **master** (qwen35 model support), CUDA build `sm_86`, at `/home/dank/GitPackages/llama-master/build-cuda/bin/llama-server` — unchanged across the quant swap|
 |Payload|`bartowski/MiMo-V2.6-Distill-Qwen-9B-GGUF` **Q5_K_M**, 6,876,124,704 B (6.40 GiB), sha256 `04cf46f2b5584ef922697d6c063f94879434fb86c467f1a09e52daf0cddaf35f` + the repo's `mmproj-MiMo-V2.6-Distill-Qwen-9B-f16.gguf`, 918,166,048 B, sha256 `ff348f3180a63188aa7285db85f550fe38acb61dd013c599eb8bad08d2cc2576` — both at `/home/dank/models/MiMo-Q5KM/`, fetched and byte- and sha256-verified by `scripts/download-frank-zealot.sh`|
 |Unit|root `frank-zealot.service` (repo `scripts/frank-zealot.service`, `User=dank`, relinked), env `scripts/frank-zealot.env`, serve `scripts/serve-frank-zealot.sh`|
@@ -102,9 +108,11 @@ The per-slot window is the whole price, in both directions:
  it reaches the ceiling instead of discovering it.
 - **frank-dragoon's tallest pre-compaction prompt now fits here.** Compaction
  for frank-dragoon sessions runs on this endpoint (`compactionModel` in
-  `models.yml`); frank-dragoon compacts at 70 % of 262,144 = 183,501 tokens,
+  `models.yml`, still true 2026-10-18 at `~/.omp/agent/models.yml:107`); frank-dragoon compacts at 70 % of 262,144 = 183,501 tokens,
  which did **not** fit the old 180,224 slot and fits 200,704 with 17,163
-  tokens to spare. The 2026-10-02 window trim had restored the fit for
+  tokens to spare (2026-10-18: frank-dragoon's `contextWindow` is 155,648 —
+  `~/.omp/agent/models.yml:131` — so its compaction input is smaller still).
+  The 2026-10-02 window trim had restored the fit for
  frank-archon's smaller 140,492-token trigger; the 2026-10-03 reslice widens
  the fit to frank-dragoon itself. Nothing routes compaction automatically —
  the point is the ceiling no longer forbids it.
@@ -137,7 +145,8 @@ The per-slot window is the whole price, in both directions:

 The GGUF has no MTP tensors (the same fact that made SGLang's NEXTN a 0.00
 ghost), and the cross-model DFlash draft
-(`/home/dank/models/DFlash-Qwen35/qwen3.5-9b-dflash-Q8_0.gguf`) is an
+(`/home/dank/models/DFlash-Qwen35/qwen3.5-9b-dflash-Q8_0.gguf` — no longer on
+disk: the 2026-10-18 census of `/home/dank/models/` has no `DFlash-Qwen35/`) is an
 optimization candidate, not a default — acceptance has to be measured on this
 traffic first. The bats seam fails if a draft flag ships unannounced.

@@ -146,10 +155,10 @@ traffic first. The bats seam fails if a draft flag ships unannounced.
 |Target|How|
 |---|---|
 |Previous shape: 3 × 180,224 + q8_0 V (2026-10-02)|`scripts/frank-zealot.env` `CTX_SIZE=540672 PARALLEL=3 CACHE_TYPE_V=q8_0` (measured 21,684 MiB used, 2,441 free) and `contextWindow: 180224` in `models.yml` — choose it when three simultaneous conversations matter more than per-slot window or exact V|
-|Q6_K, same runtime|`scripts/frank-zealot.env` `MODEL_FILE=/home/dank/models/MiMo-Q6K/MiMo-V2.6-Distill-Qwen-9B-Q6_K.gguf` + `MMPROJ_FILE` in that dir — **this is the deployed rung since 2026-10-03** ([[frank-zealot-llama-mimo-q6k-2x200704]]): at 2 × 200,704 it fits with 2,849 MiB free, no pool cut needed (the older "+1.4 GiB, drop 49,152 tokens" estimate held only for the 3-slot shapes)|
+|Q6_K, same runtime|`scripts/frank-zealot.env` `MODEL_FILE=/home/dank/models/MiMo-Q6K/MiMo-V2.6-Distill-Qwen-9B-Q6_K.gguf` + `MMPROJ_FILE` in that dir — the deployed rung **2026-10-03 → 10-05** ([[frank-zealot-llama-mimo-q6k-2x200704]]): at 2 × 200,704 it fits with 2,849 MiB free, no pool cut needed (the older "+1.4 GiB, drop 49,152 tokens" estimate held only for the 3-slot shapes)|
 |Two 262,144 windows|`CTX_SIZE=524288 PARALLEL=2 CACHE_TYPE_V=q8_0` (measured 20,190 MiB used, 4,386 free **with q8_0 V** — with f16 V the same shape is 16,384 MiB of KV + ~7,986 non-KV and does not fit) and `contextWindow: 262144` in `models.yml` — choose it when a single conversation needs the native window|
 |Vision off|`MMPROJ_FILE=` in the env file; the deployer gate then has to be satisfied too, so point `LLM_ZEALOT_MMPROJ` at any real projector file or drop the gate in the same commit|
-|SGLang + INT8|[[frank-zealot-sglang-mimo-v26]] — venv and old unit/env/serve trio still in place; the INT8 payload was staged to `/home/dank/.AGENTTRASH/20261002-retired-llm-payloads/` on 2026-10-02, so restore it there or re-fetch with `old/download-frank-zealot-sglang-int8.sh`|
+|SGLang + INT8|[[frank-zealot-sglang-mimo-v26]] — venv and old unit/env/serve trio still in place; the INT8 payload was staged to `/home/dank/.AGENTTRASH/20261002-retired-llm-payloads/` on 2026-10-02 and **that stage dir no longer exists** (`ls /home/dank/.AGENTTRASH/`, 2026-10-18), so re-fetch with `old/download-frank-zealot-sglang-int8.sh`|

 ## When it misbehaves

@@ -16,21 +16,24 @@ timestamp: 2026-10-03

 > **RETIRED 2026-10-05 (evening).** Superseded by
 > [[frank-zealot-llama-swift15-unc-iq3xxs-mtp-114688]] — the Swift-1.5-27B
-> RCO-IQ3_XXS-mtp swap (uncensored, MTP drafted). Two facts for the trail:
+> RCO-IQ3_XXS-mtp swap (uncensored, MTP drafted). :7771 today runs
+> [[frank-zealot-llama-prism-bonsai2-pq20]] (llama.cpp PrismML fork build 10754,
+> `Ternary-Bonsai-2-27B-PQ2_0.gguf`, 2 × 200,704 q8_0 KV, MTP off). Two facts for the trail:
 > committed earlier the same day (77decb5..380aafa) was **never deployed** —
 > THIS MiMo shape was the live payload when Swift cut over; (2) the KV
 > contract Frank set here (f16 K + f16 V, "no further quantization on this
 > endpoint") was superseded the same evening by the Swift swap's explicit
 > q8_0/q8_0 order. This page stays as the rollback and the measured
-> boot-pair record. Payload on disk: `/home/dank/models/MiMo-Q6K/`.
+> boot-pair record. Payload on disk (`stat -c %s`, 2026-10-18: 7793710624):
+> `/home/dank/models/MiMo-Q6K/`.

 ## Identity

 | | |
 |---|---|
 | Host / device | Dankclaw (192.168.0.143), RTX 3090, 24,576 MiB |
-| Endpoint | `http://192.168.0.143:7771` — alias `frank-zealot`, `/v1` OpenAI surface |
-| Runtime | llama.cpp master, CUDA sm_86 build `…/llama-master/build-cuda/bin/llama-server` (`GGML_CUDA_FA_ALL_QUANTS=ON`) |
+| Endpoint | `http://192.168.0.143:7771` — alias `frank-small` on the wire in this era (`git show e5893dc:scripts/frank-small.env` → `ALIAS=frank-small`; the id became `frank-secondary` 2026-10-06 and `frank-zealot` 2026-10-09), `/v1` OpenAI surface |
+| Runtime | llama.cpp master, CUDA sm_86 build `…/llama-master/build-cuda/bin/llama-server` (f16 KV needs no flash-attn option; the disk build's `CMakeCache.txt` reads `GGML_CUDA_FA_ALL_QUANTS:BOOL=OFF` and that tree has no CUDA-side guard for the option — `ggml/src/ggml-cuda/fattn.cu:438-449`) |
 | Unit | root systemd `frank-zealot.service` ([`scripts/frank-zealot.service`](../../scripts/frank-zealot.service)), `User=dank`, `Restart=on-failure`, `LimitMEMLOCK=infinity` |
 | Serve script | [`scripts/serve-frank-zealot.sh`](../../scripts/serve-frank-zealot.sh), tunables [`scripts/frank-zealot.env`](../../scripts/frank-zealot.env) |
 | Weights | `/home/dank/models/MiMo-Q6K/MiMo-V2.6-Distill-Qwen-9B-Q6_K.gguf` — bartowski/MiMo-V2.6-Distill-Qwen-9B-GGUF **Q6_K**, 7,793,710,624 B, sha256 `ef96d05a…` (qwen3_5 hybrid: 32 layers, 8 full-attention + 24 Gated DeltaNet, native 262,144, no MTP tensors) |
@@ -149,7 +152,7 @@ so the harness compacts before llama.cpp answers a longer prompt with a 400.
 |---|---|
 |Q5_K_M at the same shape|`scripts/frank-zealot.env` `MODEL_FILE=/home/dank/models/MiMo-Q5KM/MiMo-V2.6-Distill-Qwen-9B-Q5_K_M.gguf` (+ `MMPROJ_FILE` in that dir) and the deployer default — buys back 875 MiB (3,571 free measured) **and the 10 % decode rate** (104.84 tok/s measured). Payload sha-verified on disk|
 |3 × 180,224 + q8_0 V|`CTX_SIZE=540672 PARALLEL=3 CACHE_TYPE_V=q8_0` (measured 21,684 used / 2,441 free **with Q5_K_M** — Q6_K does NOT fit that shape inside the floor; pair them explicitly)|
-|SGLang + INT8|[[frank-zealot-sglang-mimo-v26]] — payload staged to `/home/dank/.AGENTTRASH/20261002-retired-llm-payloads/`|
+|SGLang + INT8|[[frank-zealot-sglang-mimo-v26]] — the 2026-10-02 staging dir `/home/dank/.AGENTTRASH/20261002-retired-llm-payloads/` is **gone** (`ls /home/dank/.AGENTTRASH/` on 2026-10-18 lists only the 20261005/06/07/10/17 batches), so this arm needs `old/download-frank-zealot-sglang-int8.sh`; the `sglang-cu128` venv is still on disk|

 ## When it misbehaves

@@ -19,17 +19,20 @@ timestamp: 2026-10-01
 > **RETIRED 2026-10-01 → 10-02** (one night): superseded by
 > [[frank-zealot-llama-mimo-q5km]], the same runtime and shape one quant rung
 > down. The Q6_K file stays at `/home/dank/models/MiMo-Q6K/` as the rollback
-> target.
+> target (on disk 2026-10-18, `stat -c %s` → 7793710624). :7771 today runs
+> [[frank-zealot-llama-prism-bonsai2-pq20]] (llama.cpp PrismML fork build 10754,
+> `Ternary-Bonsai-2-27B-PQ2_0.gguf`, 2 × 200,704, q8_0 K + q8_0 V, MTP off).
 >
 > Original order (Frank, 2026-10-01 night): move this endpoint to the GGUF
 > path for **asymmetric KV** — unquantized K + q8_0 V — which only llama.cpp
-> exposes per-tensor. That contract is what the current deployment kept.
+> exposes per-tensor. The per-tensor lever stayed; this pairing did not — the
+> live endpoint bills q8_0 K + q8_0 V (`scripts/frank-zealot.env:55-56`).

 ## Identity

 |Field|Value|
 |---|---|
-|Endpoint|`192.168.0.143:7771`, served alias `frank-zealot`|
+|Endpoint|`192.168.0.143:7771`, served alias `frank-small` in this era (`ALIAS` reached `frank-secondary` 2026-10-06 and `frank-zealot` 2026-10-09, commit `7c77326`)|
 |Runtime|llama.cpp **master** (qwen35 model support), CUDA build `sm_86`, at `/home/dank/GitPackages/llama-master/build-cuda/bin/llama-server`|
 |Payload|`bartowski/MiMo-V2.6-Distill-Qwen-9B-GGUF` **Q6_K**, 7,793,710,624 B, sha256 `ef96d05a2ddf2cbb450d1af1ac3860ec769d3575bafa70692ee5609bda3fad7d`, at `/home/dank/models/MiMo-Q6K/`|
 |Unit|root `frank-zealot.service` (repo `scripts/frank-zealot.service`, `User=dank`, relinked), env `scripts/frank-zealot.env`, serve `scripts/serve-frank-zealot.sh`|
@@ -68,15 +71,17 @@ Frank's KV contract: **K unquantized (f16), V `q8_0`** —
  (measured — this is not a fault).
 - Tools: `--jinja` + server-side tool parsing, verified
  `tool_calls` round-trip 2026-10-01 23:0x.
- **Text-only now.** The GGUF carries no vision projector; the
-  in-checkpoint tower existed only in the SGLang safetensors. `models.yml`
-  `input: [text]`.
+- **Text-only in this era.** The GGUF carries no vision projector; the
+  in-checkpoint tower existed only in the SGLang safetensors, so `models.yml`
+  carried `input: [text]`. Vision returned with the next payloads: the endpoint
+  is `input: [text, image]` today (`~/.omp/agent/models.yml:214`).

 ## No spec decode (yet)

 The GGUF has no MTP tensors (same fact that killed SGLang NEXTN), and the
 cross-model DFlash draft (`/home/dank/models/DFlash-Qwen35/qwen3.5-9b-dflash-Q8_0.gguf`,
-Q8_0) is an optimization-loop candidate, not a default — `--spec-type
+Q8_0 — that path is no longer on disk; the 2026-10-18 census of
+`/home/dank/models/` has no `DFlash-Qwen35/`) is an optimization-loop candidate, not a default — `--spec-type
 draft-dflash` needs acceptance measured on this traffic first. The bats
 seam fails if a draft flag ships unannounced.

@@ -92,9 +97,11 @@ cmake -B build-cuda -S . -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON \
 cmake --build build-cuda -j 16 --target llama-server
 ```

-The SGLang venv (`/home/dank/GitPackages/sglang-cu128`) and the INT8
-AutoRound payload (`/home/dank/models/MiMo-V2.6-Distill-Qwen-9B-INT8-W8A16-AutoRound`)
-stay on disk as the rollback: repoint the unit's serve script and env from
+The SGLang venv (`/home/dank/GitPackages/sglang-cu128`) is still on disk; the
+INT8 AutoRound payload (`/home/dank/models/MiMo-V2.6-Distill-Qwen-9B-INT8-W8A16-AutoRound`)
+is not — it was staged to `/home/dank/.AGENTTRASH/20261002-retired-llm-payloads/`
+on 2026-10-02 and that stage dir is gone as of 2026-10-18, so this rollback
+re-fetches with `old/download-frank-zealot-sglang-int8.sh`: repoint the unit's serve script and env from
 git history (`git show frank-dragoon-gufo-q4kxl-20261001` era is BEFORE this;
 use the parent of the 2026-10-01 night swap commit).

@@ -1,7 +1,7 @@
 ---
 type: reference
-title: "frank-zealot on Dankclaw — llama.cpp, Qwen3.5-9B Q6_K, 2 x 200704, f16 KV (ACTIVE)"
-description: "The ACTIVE frank-zealot runbook (since 2026-10-07) — llama.cpp master (CUDA sm_86) serving HauhauCS/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive at Q6_K on the RTX 3090: two conversations of 200,704 tokens with exact f16 KV, vision through the publisher's BF16 projector, MTP impossible (no tensors in the file), and the measured geometry that priced the shape."
+title: "frank-zealot on Dankclaw — llama.cpp, Qwen3.5-9B Q6_K, 2 x 200704, f16 KV (RETIRED, rollback target)"
+description: "The frank-zealot runbook of 2026-10-07 → 2026-10-17 (RETIRED — rollback target) — llama.cpp master (CUDA sm_86) serving HauhauCS/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive at Q6_K on the RTX 3090: two conversations of 200,704 tokens with exact f16 KV, vision through the publisher's BF16 projector, MTP impossible (no tensors in the file), and the measured geometry that priced the shape."
 tags:
  - llm
  - frank-zealot
@@ -14,7 +14,22 @@ timestamp: 2026-10-07

 # frank-zealot — llama.cpp Qwen3.5-9B Q6_K, 2 × 200,704, f16 KV

-Live since 2026-10-07, replacing the
+**RETIRED 2026-10-07 → 2026-10-17** (AGENTS.md Runbook Index), superseded by
+[[frank-zealot-llama-prism-bonsai2-pq20]] (27B PQ2_0, 2 × 200,704 q8_0 KV, build
+10754), itself retired 2026-10-17 → 10-18 and now the rollback target: :7771
+today is llama.cpp PrismML build **10777** on
+`Ternary-Bonsai-2-9B-PQ2_0-MTP-Q8_0.gguf`, 3 × 262,144 q8_0 KV, MTP off by
+measurement (AGENTS.md Runbook Index active row; `scripts/frank-zealot.env`).
+Transient 2026-10-18: :7771 is inside a bench window — the unit is `failed`
+since 03:14 and a hand-booted process answers the port; restore with
+`./scripts/deploy.sh dankclaw --service frank-zealot`.
+This era is the rollback target: the payload is still on disk
+(`stat -c %s /home/dank/models/Qwen35-9B-HauhauCS-Q6K/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive-Q6_K.gguf`
+→ 7359259008, read 2026-10-18) with its master CUDA build. Same census: the
+10754 rollback payload `Bonsai2-PQ2_0/Ternary-Bonsai-2-27B-PQ2_0.gguf` is
+present at 7206168928 with its Q8_0 mmproj at 629246976, and
+`Bonsai2-9B-MTP/Ternary-Bonsai-2-9B-PQ2_0-MTP-Q8_0.gguf` at 2675410720 —
+nothing this era or its successors need has been purged. It replaced the
 [[frank-zealot-llama-gemma4-q4km-200704]] era (Q4_K_M on ONE 200,704
 slot). The swap is a capacity trade: the 9B dense-hybrid rung costs ~7 GiB of
 weights where the 26B MoE cost ~16.6 GiB, and the freed room buys the second
@@ -26,7 +41,7 @@ conversation slot and unquantized KV back.
 |---|---|
 | Host / device | Dankclaw (192.168.0.143), RTX 3090, 24,576 MiB |
 | Endpoint | `http://192.168.0.143:7771` — served model id **`frank-zealot`** (`ALIAS` in the env; the SERVICE keeps the `frank-zealot` name), `/v1` OpenAI surface |
-| Runtime | llama.cpp master (0.5.0-dev, commit `5fc4f3c`), CUDA sm_86 build `…/llama-master/build-cuda/bin/llama-server` (`GGML_CUDA_FA_ALL_QUANTS=ON`); `qwen35` is registered in the build's own `src/llama-arch.cpp` and `src/models/qwen35.cpp` exists at that commit |
+| Runtime | llama.cpp master (0.5.0-dev, commit `5fc4f3c`), CUDA sm_86 build `…/llama-master/build-cuda/bin/llama-server` — `--version` on the disk build reads `0.5.0-dev (build 1, commit 5fc4f3c)` (built 2026-10-01); its `CMakeCache.txt` says `GGML_CUDA_FA_ALL_QUANTS:BOOL=OFF` and that tree carries no CUDA-side guard for the option (`ggml/src/ggml-cuda/fattn.cu:438-449` dispatches Q4/Q5 KV unconditionally), so quantized KV never required it; `qwen35` is registered in the build's own `src/llama-arch.cpp` and `src/models/qwen35.cpp` exists at that commit |
 | Unit | root systemd `frank-zealot.service` ([`scripts/frank-zealot.service`](../../scripts/frank-zealot.service)), `User=dank`, `Restart=on-failure`, `LimitMEMLOCK=infinity` |
 | Serve script | [`scripts/serve-frank-zealot.sh`](../../scripts/serve-frank-zealot.sh), tunables [`scripts/frank-zealot.env`](../../scripts/frank-zealot.env) |
 | Weights | `/home/dank/models/Qwen35-9B-HauhauCS-Q6K/Qwen3.5-9B-Uncensored-HauhauCS-Aggressive-Q6_K.gguf` — HauhauCS **Q6_K**, 7,359,259,008 B, sha256 `c0ba7beb68fd3fe47891bd549486d38dcf62d00817296ea314ad37017f5a4986` |
@@ -98,7 +113,9 @@ safe; the Gemma4 era's warning was the opposite case, a drafter running 53 %
 **past** its window). Weights load in ~6 s from page cache; `/health` answers
 `{"status":"ok"}` and `/v1/models` serves the alias `frank-zealot`.

-**Wire rename (2026-10-09):** `ALIAS` moved `frank-zealot` → `frank-zealot`,
+**Wire rename (2026-10-09):** `ALIAS` moved `frank-secondary` → `frank-zealot`
+(commit `7c77326`; the service-file rename to the `frank-zealot.*` names
+followed 2026-10-10, commit `55f87fc`),
 so the served id matches the harness model id and the family-facing name.
 Consumers re-keyed in the same change: OpenWebUI (`model` row, `access_grant`
 row, `openai.api_configs` index-2 `model_ids`) and `models.yml` (already
@@ -120,7 +137,7 @@ The publisher's recipe ships in `models.yml` `extraBody`: thinking mode
 thinking" is satisfied by the 200,704 slot.

 **Compaction hub**: `models.yml` routes `compactionModel` for all three
-endpoints here. With `--parallel 2` a compaction request no longer serializes
+endpoints here — still true 2026-10-18 (`~/.omp/agent/models.yml:25,107,185` all name `llamacpp (dankclaw-3090)/frank-zealot`). With `--parallel 2` a compaction request no longer serializes
 behind a live generation (the Gemma4 era's `--parallel 1` law), and the
 200,704 slot still fits the worst-case compaction input (~133k tokens).

@@ -1,7 +1,7 @@
 ---
 type: reference
 title: "frank-zealot on Dankclaw — llama.cpp, Swift-1.5-27B Uncensored RCO IQ3_XXS-mtp, 2 x 114688, draft-mtp, q8_0 KV"
-description: "The active frank-zealot runbook (live since 2026-10-05 evening; renamed from frank-small 2026-10-06, per-slot lowered to 112k and ubatch raised to 1024 the same evening) — llama.cpp master (CUDA sm_86) serving ajgazin's Swift-1.5-Qwen3.8-27B Uncensored RCO-IQ3_XXS (MTP head in the file, drafted) on the RTX 3090: TWO 114,688-token conversations at Frank's 112k cap, q8_0 K + q8_0 V (llama.cpp's FP8 class), vision through the publisher's own BF16 projector, and the full two-slot + drafter arithmetic."
+description: "The frank-zealot runbook of 2026-10-05 → 2026-10-07 (RETIRED — rollback target; live from 2026-10-05 evening, renamed from frank-small 2026-10-06, per-slot lowered to 112k and ubatch raised to 1024 the same evening) — llama.cpp master (CUDA sm_86) serving ajgazin's Swift-1.5-Qwen3.8-27B Uncensored RCO-IQ3_XXS (MTP head in the file, drafted) on the RTX 3090: TWO 114,688-token conversations at Frank's 112k cap, q8_0 K + q8_0 V (llama.cpp's FP8 class), vision through the publisher's own BF16 projector, and the full two-slot + drafter arithmetic."
 tags:
  - llm
  - frank-zealot
@@ -17,8 +17,21 @@ timestamp: 2026-10-06

 # frank-zealot — llama.cpp Swift-1.5-27B Uncensored RCO IQ3_XXS-mtp, 2 × 114,688, draft-mtp, q8_0 KV

-> **ACTIVE since 2026-10-05 (evening); reshaped three times on
-> 2026-10-06, renamed from frank-small the same night.** A 27B replaces
+> **RETIRED 2026-10-06 → 2026-10-07** (AGENTS.md Runbook Index; cut over
+> 2026-10-05 ~23:26, reshaped three times on 2026-10-06, renamed from
+> frank-small the same night). Superseded by
+> [[frank-zealot-llama-qwen35-9b-q6k-2x200704]]; the production shape on :7771
+> today is llama.cpp PrismML build **10777** on
+> `Ternary-Bonsai-2-9B-PQ2_0-MTP-Q8_0.gguf`, 3 × 262,144 q8_0 KV, MTP off by
+> measurement (AGENTS.md Runbook Index active row); the 27B PQ2_0 / 2 × 200,704
+> shape of [[frank-zealot-llama-prism-bonsai2-pq20]] is that era's rollback
+> target. Transient 2026-10-18 bench window on :7771 — the unit is `failed`
+> since 03:14 and a hand-booted process answers the port; restore with
+> `./scripts/deploy.sh dankclaw --service frank-zealot`).
+> **Rollback target**: the payload is still on disk —
+> `stat -c %s` on 2026-10-18 gives 10442827392 for
+> `/home/dank/models/Swift15-UncIQ3XXS/Swift-1.5-Qwen3.8-27B-Uncensored-Dynamic-MTP-RCO-IQ3_XXS.gguf`
+> and 931145888 for its `mmproj-BF16.gguf`. A 27B replaces
 > the 9B on the same 24 GiB card: KV at FP8 class, vision on. The
 > morning order (drop MTP, ubatch 512, TWO 128k contexts) bought the
 > second slot — 1,397 MiB free. The evening order swapped to the
@@ -41,8 +54,8 @@ timestamp: 2026-10-06
 | | |
 |---|---|
 | Host / device | Dankclaw (192.168.0.143), RTX 3090, 24,576 MiB |
-| Endpoint | `http://192.168.0.143:7771` — alias `frank-zealot`, `/v1` OpenAI surface |
-| Runtime | llama.cpp master (0.5.0-dev, commit 5fc4f3c), CUDA sm_86 build `…/llama-master/build-cuda/bin/llama-server` (`GGML_CUDA_FA_ALL_QUANTS=ON` — required for quantized V) |
+| Endpoint | `http://192.168.0.143:7771` — alias `frank-secondary` on the wire until the 2026-10-09 rename to `frank-zealot` (commit `7c77326`), `/v1` OpenAI surface |
+| Runtime | llama.cpp master (0.5.0-dev, commit 5fc4f3c), CUDA sm_86 build `…/llama-master/build-cuda/bin/llama-server` (quantized V needs `--flash-attn on`; it does NOT need `GGML_CUDA_FA_ALL_QUANTS` — see the KV section) |
 | Unit | root systemd `frank-zealot.service` ([`scripts/frank-zealot.service`](../../scripts/frank-zealot.service)), `User=dank`, `Restart=on-failure`, `LimitMEMLOCK=infinity` |
 | Serve script | [`scripts/serve-frank-zealot.sh`](../../scripts/serve-frank-zealot.sh), tunables [`scripts/frank-zealot.env`](../../scripts/frank-zealot.env) |
 | Weights | `/home/dank/models/Swift15-UncIQ3XXS/Swift-1.5-Qwen3.8-27B-Uncensored-Dynamic-MTP-RCO-IQ3_XXS.gguf` — ajgazin/Swift-1.5-Qwen3.8-27B-Uncensored-Dynamic-MTP-GGUF **RCO-IQ3_XXS -mtp**, 10,442,827,392 B, sha256 `e13d3e74…` (qwen35 hybrid: 64 real layers, 16 full-attention + 48 Gated DeltaNet, native 262,144; **MTP head in the file**: blk.64.nextn.*, `nextn_predict_layers=1`, and DRAFTED with it) |
@@ -78,9 +91,11 @@ The order supersedes the same-day f16/f16 rule, which was written for the
 Ornith 9B fit — at 64 KiB/token f16 the single 131,072 slot alone would
 cost 8.0 GiB of KV. At q8_0 the rate is **34 KiB/token** (16 attn layers ×
 4 KV heads × 256 dim × 1.0625 B, K and again V). `--flash-attn on` is
-pinned: quantized V requires it, and the build's
-`GGML_CUDA_FA_ALL_QUANTS=ON` (2026-09-17) makes the path real rather than
-a silent f16 fallback.
+pinned: quantized V requires it. The era note claiming the build carried
+`GGML_CUDA_FA_ALL_QUANTS=ON` does not describe the binary on disk: its
+`CMakeCache.txt` reads `GGML_CUDA_FA_ALL_QUANTS:BOOL=OFF` (binary built
+2026-10-01 22:35) and the option is vestigial in that tree — `ggml/src/ggml-cuda/fattn.cu:438-449`
+dispatches the Q4/Q5 KV cases unconditionally.

 **Two slots + drafter, by arithmetic and by order (2026-10-06 morning /
 evening, the 2 × 131,072 era).** The morning order bought the second slot
@@ -320,7 +335,7 @@ recipes:
  second 131,072 slot: 489 MiB free, vision `Red` at a 128-token budget,
  decode 63.3 t/s recipe / 72.9 temp 0 (48.0 no-spec).
 - 2026-10-06 (late, Frank): the endpoint renamed frank-small →
-  **frank-zealot** (87721ab — scripts, unit, seam, runbooks,
+  **frank-secondary** (87721ab — "rename frank-small → frank-secondary", scripts, unit, seam, runbooks,
  identifiers; historical references to the OLD FreeToken/CUDA
  frank-small, and to the Dankserver service that became frank-medium,
  stay frank-small) and the per-slot window cut 131,072 → 114,688 to
@@ -1,7 +1,7 @@
 ---
 type: reference
 title: "frank-zealot on Dankclaw — llama.cpp, Qwen3.8-27B GSQ-RCO IQ3_S"
-description: "The RETIRED frank-zealot runbook (2026-09-16 → 09-17, rollback target) — mainline llama.cpp on Dankclaw's RTX 3090 serving ISTA-DASLab Qwen3.8-27B-GSQ-RCO at IQ3_S with the model's own in-file MTP head and the BF16 vision projector: identity, KV arithmetic, deployed flags, the MTP contract, the client contract, and what to check when it misbehaves."
+description: "The RETIRED frank-zealot runbook (2026-09-16 → 09-17) — mainline llama.cpp on Dankclaw's RTX 3090 serving ISTA-DASLab Qwen3.8-27B-GSQ-RCO at IQ3_S with the model's own in-file MTP head and the BF16 vision projector: identity, KV arithmetic, deployed flags, the MTP contract, the client contract, and what to check when it misbehaves."
 tags:
  - llm
  - frank-zealot
@@ -13,3 +13,10 @@ tags:
  - vision
 timestamp: 2026-09-16
 ---
+
+**RETIRED 2026-09-16 → 2026-09-17** (AGENTS.md Runbook Index); superseded by
+[[frank-zealot-gemma4-12b]], and :7771 today runs
+[[frank-zealot-llama-prism-bonsai2-pq20]] (llama.cpp PrismML fork build 10754,
+`Ternary-Bonsai-2-27B-PQ2_0.gguf`). The payload is **not** a rollback target any
+more: the 2026-10-18 census of `/home/dank/models/` has no GSQ-RCO directory, so
+restoring this shape means re-downloading from ISTA-DASLab.
@@ -17,18 +17,22 @@ timestamp: 2026-10-01

 # frank-zealot — SGLang MiMo-V2.6-Distill-Qwen-9B INT8 W8A16 (NEXTN MTP)

-> **RETIRED 2026-10-01, hours after cutover.** Replaced by
+> **RETIRED 2026-10-01, hours after cutover** (AGENTS.md Runbook Index). Replaced by
 > [[frank-zealot-llama-mimo-q6k]] — llama.cpp CUDA on the MiMo Q6_K GGUF,
-> chosen for the asymmetric KV (f16 K + q8_0 V) SGLang cannot express.
-> The venv (`/home/dank/GitPackages/sglang-cu128/`) stays in place; the INT8
+> chosen for the asymmetric KV (f16 K + q8_0 V) SGLang cannot express. :7771
+> today runs [[frank-zealot-llama-prism-bonsai2-pq20]] (llama.cpp PrismML fork
+> build 10754, `Ternary-Bonsai-2-27B-PQ2_0.gguf`, 2 × 200,704 q8_0 KV, MTP off).
+> The venv (`/home/dank/GitPackages/sglang-cu128/`) is still on disk; the INT8
 > payload was staged to
-> `/home/dank/.AGENTTRASH/20261002-retired-llm-payloads/` on 2026-10-02 when
-> the llama.cpp endpoint was two runtimes deep — recoverable until the trash
-> is purged.
+> `/home/dank/.AGENTTRASH/20261002-retired-llm-payloads/` on 2026-10-02 and
+> **that stage batch is gone** (`ls /home/dank/.AGENTTRASH/`, 2026-10-18 —
+> only the 20261005/06/07/10/17 batches remain), so this runtime needs
+> `old/download-frank-zealot-sglang-int8.sh` to re-stage.

 ## Identity

- **Endpoint:** `frank-zealot` at `192.168.0.143:7771` (Dankclaw).
+- **Endpoint:** `frank-small` at `192.168.0.143:7771` (Dankclaw) — the id
+  became `frank-secondary` on 2026-10-06 and `frank-zealot` on 2026-10-09.
 - **Runtime:** SGLang (latest) in a self-contained python3.12 venv at
  `/home/dank/GitPackages/sglang-cu128/` (torch 2.13.0+cu130,
  transformers 5.12.1, flashinfer 0.6.18, sgl-kernel). No container — a root
@@ -53,9 +57,10 @@ timestamp: 2026-10-01
  one request. A single request may grow to the whole pool — a
  170,019-token prompt was verified at the 4-slot shape — the grid is
  the two-way concurrency contract. **That compaction arithmetic is
-  specific to a 262,144-token slot**: the ACTIVE shape runs three slots of
-  180,224, which 183,501 tokens already exceeds — see *What three slots
-  cost* in [[frank-zealot-llama-mimo-q5km]].
+  specific to a 262,144-token slot**: the shape that followed on 2026-10-02
+  ran three slots of 180,224, which 183,501 tokens already exceeds — see *What
+  three slots cost* in [[frank-zealot-llama-mimo-q5km]]; :7771 runs two 200,704
+  slots today.
 - **KV:** `fp8_e4m3` — 16 KiB/token (8 attn layers x 2 x 4 heads x 256
  dim x 1 B), pool 9.31 GiB.
 - **The memory shape (the 4.5 GiB the naive math misses):** the DeltaNet
@@ -125,7 +130,8 @@ change lands.
 ## Payload

 Eight safetensors shards (12,891,718,440 B total) + tokenizer and config
-files under `/home/dank/models/MiMo-V2.6-Distill-Qwen-9B-INT8-W8A16-AutoRound/`,
+files lived under `/home/dank/models/MiMo-V2.6-Distill-Qwen-9B-INT8-W8A16-AutoRound/`
+(absent from the 2026-10-18 census — see the banner),
 all LFS sha256-verified by `old/download-frank-zealot-sglang-int8.sh`
 (`--verify-only` re-checks) — the script moved to `old/` when the endpoint
 cut over to llama.cpp + GGUF on 2026-10-01 night, and
@@ -134,7 +140,7 @@ serve script refuses to start with a missing shard.

 ## Client contract

- **Alias:** `frank-zealot` (the `id` at `/v1/models`).
+- **Alias:** `frank-small` (the `id` at `/v1/models`).
 - **Reasoning:** extracted to **`reasoning_content`** (live-verified
  2026-10-01 — this SGLang build's qwen3 parser uses the same field name
  as llama.cpp; models.yml sets `reasoningContentField:
@@ -166,10 +172,10 @@ serve script refuses to start with a missing shard.

 ## Rollback

-[[frank-zealot-llama-mimo-q5km]] is the live shape two steps forward; the
-practical rollback today is [[frank-zealot-llama-mimo-q6k]] (payload at
-`/home/dank/models/MiMo-Q6K/`). This era's own rollback, the llama.cpp
-Gemma4-12B QAT payload, was staged to
+[[frank-zealot-llama-mimo-q5km]] was the live shape two steps forward; the
+practical rollback at the time was [[frank-zealot-llama-mimo-q6k]] (payload at
+`/home/dank/models/MiMo-Q6K/`, still on disk 2026-10-18).
+This era's own rollback, the llama.cpp Gemma4-12B QAT payload, was staged to
 `/home/dank/.AGENTTRASH/20261002-retired-llm-payloads/Gemma4-12B-QAT/` on
 2026-10-02; its unit/env/serve trio remains in `old/`.

@@ -17,10 +17,13 @@ timestamp: 2026-09-19

 # frank-zealot — vLLM on the RTX 3090 (Gemma4-12B QAT w4a16)

-> **RETIRED 2026-09-19 (same-day revert).** This vLLM deployment was cut
-> back to [[frank-zealot-gemma4-12b]] (llama.cpp, now the ACTIVE runbook)
-> the same day it landed — this page is the rollback target. Same port
-> (7771), same alias (`frank-zealot`), same client contract surface — the
+> **RETIRED 2026-09-19 (same-day revert) — rollback target only in git.**
+> This vLLM deployment was cut
+> back to [[frank-zealot-gemma4-12b]] (llama.cpp — itself retired
+> 2026-10-01; :7771 today runs [[frank-zealot-llama-prism-bonsai2-pq20]])
+> the same day it landed. Same port
+> (7771), same alias (`frank-small` — the name `frank-zealot` dates from
+> 2026-10-06/10-09), same client contract surface — the
 > runtime, the model payload, the drafter and the service shape (root
 > systemd unit → rootless Quadlet) all changed.

@@ -28,12 +31,12 @@ timestamp: 2026-09-19

 | what | value |
 |---|---|
-| runtime | vLLM `vllm/vllm-openai` dev build `gemma-x86_64-cu129` (base `sha256:e24d3d8e…001e`), audio extra pip-installed into `localhost/vllm/vllm-openai:frank-zealot` (`8dad46d7…`) |
-| unit | **rootless Quadlet** `dankclaw/frank-zealot/quadlet/frank-zealot.container` (root systemd unit retired 2026-09-19) |
+| runtime | vLLM `vllm/vllm-openai` dev build `gemma-x86_64-cu129` (base `sha256:e24d3d8e…001e`), audio extra pip-installed into `localhost/vllm/vllm-openai:frank-small` (`8dad46d79c46` — still in rootless storage on the 2026-10-18 `podman images` census; the tag carries the era name) |
+| unit | **rootless Quadlet** `dankclaw/frank-small/quadlet/frank-small.container` (era path; deleted by the revert commit `374041c` — root systemd unit retired 2026-09-19) |
 | model | `google/gemma-4-12B-it-qat-w4a16-ct` — compressed-tensors w4a16 (int4 Marlin weights, 10,264,229,896 B) |
-| model dir | `/home/dank/models/gemma4-12b-qat-w4a16-ct/` |
-| drafter | `google/gemma-4-12B-it-assistant` **bf16** (845,719,296 B) at `/home/dank/models/gemma4-12b-assistant-bf16/` |
-| port | 7771 → 8000 (alias `frank-zealot`; `frank-dragoon` keeps 7770) |
+| model dir | `/home/dank/models/gemma4-12b-qat-w4a16-ct/` (absent from the 2026-10-18 census of `/home/dank/models/` — re-fetch to use this rollback) |
+| drafter | `google/gemma-4-12B-it-assistant` **bf16** (845,719,296 B) at `/home/dank/models/gemma4-12b-assistant-bf16/` (absent from the same census) |
+| port | 7771 → 8000 (alias `frank-small` in this era; `frank-dragoon` keeps 7770) |
 | window | 262,144; KV pool **289,647 tokens** bf16; **2 concurrent full-context sessions** |
 | multimodal | native: text + image + **audio** (derived image carries `av`/`scipy`/`soundfile`/`mistral_common[audio]`) |

@@ -113,7 +116,8 @@ trade for the native w4a16 format + audio + CUDA graphs.)

 ## The image

-`dankclaw/frank-zealot/Dockerfile` (repo) — 16 comment lines + `FROM
+`dankclaw/frank-small/Dockerfile` (era path, deleted by the revert commit
+`374041c`; recover with `git show 374041c^:dankclaw/frank-small/Dockerfile`) — 16 comment lines + `FROM
 localhost/vllm/vllm-openai:gemma4-unified` + `RUN pip install
 --no-cache-dir av scipy soundfile "mistral_common[audio]"`. **No COPY
 lines** — the earlier `triton-sm89-sitecustomize.py` hack is gone:
@@ -144,9 +148,9 @@ not a hardware mystery.

 ## Deployed config

-Repo truth: `scripts/frank-zealot.env` + `scripts/serve-frank-zealot.sh`
+Repo truth **for this era** (the files carry llama.cpp knobs today): `scripts/frank-zealot.env` + `scripts/serve-frank-zealot.sh`
 (mounted into the container at `/scripts/`, which is the entrypoint) +
-`dankclaw/frank-zealot/quadlet/frank-zealot.container`. Key values:
+`dankclaw/frank-small/quadlet/frank-small.container` (era path, deleted at `374041c`). Key values:
 `KV_CACHE_DTYPE=auto` (resolves to bf16 — fp8_e5m2 is refused by
 compressed-tensors checkpoints and fp8 is hardware-dead on sm_86),
 `ENFORCE_EAGER=0` (CUDA graphs on), `max_model_len=262144`, MTP via
@@ -169,7 +173,9 @@ assistant, or the vllm binary are missing.
 - Audio → 200, a 440 Hz WAV tone described correctly (native audio
  encoder; verified in the derived image).
 - Harness: `contextWindow: 262144`, `maxTokens: 32768`,
-  `input: [text, image, audio]`.
+  `input: [text, image, audio]` — era values; the endpoint reads 200,704 /
+  16,384 / `[text, image]` today (`~/.omp/agent/models.yml:206,212,214`), and
+  audio left the fleet with this payload on 2026-10-01.

 ## Boot ledger

@@ -186,27 +192,35 @@ container while it loads.
 - **`sm_89` in an error** — stale arch override; `TRITON_OVERRIDE_ARCH`
  must be absent. 8.6 is correct.
 - **Audio 400/500** — the container is running the *base* image, not the
-  derived `:frank-zealot` (missing `av`). Check the deployed image digest
-  is `8dad46d7…`.
+  derived `:frank-small` (missing `av`). In this era, check the deployed image
+  id is `8dad46d7…` (`podman images`, 2026-10-18: it still exists, unused —
+  nothing on :7771 runs in podman today).
 - **CUDA not visible in container** — a `Device=` line or a lib mount
  dropped out of the unit after an edit; the unit is the source of truth,
  the host-side generated unit is not.
- Logs: `journalctl --user -u frank-zealot` (rootless Quadlet; `podman
-  logs` covers only the current `--replace --rm` instance).
+- Logs: `journalctl --user -u frank-zealot` (rootless Quadlet in this era;
+  `podman logs` covers only the current `--replace --rm` instance). The unit is
+  a ROOT unit today: `journalctl -u frank-zealot`.

 ## Rollback

 [[frank-zealot-gemma4-12b]] — the llama.cpp deployment. Its weights,
-mmproj and MTP sidecar are still on the host under
-`/home/dank/models/Gemma4-12B-QAT/`, and the retired root unit is at
-`scripts/.AGENTTRASH/frank-zealot.service.llama.cpp`. Restoring it means
-reinstalling that unit and stopping the Quadlet (one owner per port).
+mmproj and MTP sidecar are **no longer on the host** under
+`/home/dank/models/Gemma4-12B-QAT/` (2026-10-18 census: the directory is
+gone — it was staged to `.AGENTTRASH/20261002-retired-llm-payloads/` and that
+stage dir is gone too), so this rollback re-fetches
+`HauhauCS/Gemma4-12B-QAT-Uncensored-HauhauCS-Balanced` and restores the era
+trio from git (`git show 374041c:scripts/frank-small.service`,
+`…:scripts/frank-small.env`, `…:scripts/serve-frank-small.sh`); the era quadlet
+lived at `dankclaw/frank-small/quadlet/frank-small.container`. One owner per
+port: the llama.cpp unit is root, so stop the container unit before starting it.

 ## References

- `scripts/serve-frank-zealot.sh` — the actual exec line
- `dankclaw/frank-zealot/Dockerfile` — the audio-derived image
- `dankclaw/frank-zealot/quadlet/frank-zealot.container` — the unit
+- `scripts/serve-frank-zealot.sh` — the actual exec line (today: llama.cpp; the
+  vLLM exec line is in `git show 374041c^:scripts/serve-frank-small.sh`)
+- `dankclaw/frank-small/Dockerfile` — the audio-derived image (era path, deleted at `374041c`)
+- `dankclaw/frank-small/quadlet/frank-small.container` — the unit (era path, deleted at `374041c`)
 - [[frank-zealot-gemma4-12b]] — RETIRED predecessor (rollback)
 - [[halogen-flash-server]] — the sibling endpoint on the iGPU
 - [[VLLM Overview]] / [[VLLM Index]] — runtime background