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

name, description

name	description
radiance-calib-tap-sizing	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.