live: heartbeat sync 2026-10-30T16:20:49-07:00 (Refs #11)

agent/managed-skills/radiance-calib-tap-sizing/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: radiance-calib-tap-sizing
+description: "Decide whether a radiance calibration tap is needed, how large a token floor it wants, and which step/window shape makes it fast — before booking a multi-hour card window."
+---
+
+# Sizing a radiance calibration tap
+
+Read this before promising a tap run (hours to days of exclusive cards). It answers three questions:
+*what is the tap for*, *how many tokens*, and *which shape makes it fast*.
+
+## 1. The tap is for the Hessian, not the imatrix
+
+`tools/rad_convert.cpp` help: `--imatrix F` is *"the expert-popularity profile, the column
+importance"* — a diagonal summary. GPTQ's input is separate: the recipe names `gptq calib=<dir>`,
+and `<dir>` is the tap's gram set: **d × d fp32 second moments (`E[x xᵀ]`) per expert per layer**.
+
+- An external/published imatrix **cannot** substitute. It carries no second moments, it is keyed by
+  another model's tensor names, and radiance warns that *"a legacy-format imatrix cannot carry
+  [per-expert counts] at all — the planner will start cold."*
+- The imatrix you need is a free by-product: `scripts/grams-to-imatrix.py <tap dir> -o imatrix.gguf`.
+- Without a tap the experts can only take the recipe's non-GPTQ rule (`rtn`) — a visibly worse arm.
+  So "we only want an imatrix" is not a reason to skip it, and "just fetch one" is not a path.
+
+## 2. The shape decides the throughput — window and step are one decision
+
+The arch prices a step against the window: **QSA score plane ≈ rows × (window ÷ 4) × 4 bytes**.
+
+| window | step (rows) | plane | verdict |
+|---|---|---|---|
+| 200,000 | 16,384 | 3,125 MiB | refused at boot (`the QSA score plane would be … Lower either`) |
+| 32,768 | 16,384 | 512 MiB | fits |
+| 32,768 | 32,768 | 1 GiB | fits |
+
+Tap prefill is bound by **expert re-reads per step**, not by tokens as such, so the small window is the
+lever: calibration corpora are re-chunked to ≤7,168-token documents and need nowhere near a 200k
+window, yet copying the production window is the reflex that disqualifies a wide step and pins the run
+to 2,048-token steps (≈70 tok/s on 2× R9700 = ~48 h for 12 M tokens). A 8,192–16,384-token step at a
+32,768 window re-reads experts 4–8× less often per token.
+
+Always boot once and read the ledger (`activation arena`, `experts`, `kv cache`) before believing any
+speed estimate: a wider step grows the arena and steals from the experts.
+
+## 3. Before you spend the cards
+
+- **Arming proof**: the boot must print `recorded passes: off, the program accumulates calibration
+  Grams (gram_accum)`. A build that prints nothing writes nothing, however healthy `/health` and
+  `/stats` look (a 17-hour run on a shipped pin produced zero files).
+- **The rig must own the socket**: `ss -ltnp 'sport = :7770'` → pid, and that pid must appear in
+  `podman top <rig> pid`. After the runner stops production, the dying process answers `/health` for a
+  moment while the new container is still loading — "container running + health 200" is not the rig.
+- **Liveness is completions, not log mtime**: the engine logs one line per *completed* request, so a
+  4–8 minute prefill looks like silence while `kv_tokens_used` steps in 2,048-token chunks.
+- **Space**: one seal writes ~40 GiB in one burst; the preflight needs ≥60 GiB free in the tap dir.
+- **The floor is a campaign decision, not a vendor default**: the engine default is 65,536 tokens; a
+  12 M floor over a ~9.31 M-token corpus seals in round 1 plus part of round 2, and a round that seals
+  nothing is normal (the floor is pooled — never treat a flat round as a failure).
+- **Exit means success**: at the seal the engine exits by itself; a mid-flight client gets
+  `429 rate_limit_error: the server is shutting down`.