command-center/agent/managed-skills/radiance-w4-campaign/SKILL.md

name, description

name	description
radiance-w4-campaign	Run a radiance GPTQ-w4 quantization campaign on dankserver: calibration → protected experts → convert → KLD gate → deploy, with the engine-pin, tap-engagement and MNBT laws.

Pipeline for quantizing a BF16 Qwen3.8-Flash-Next checkpoint into a servable qwen4exp .rad on dankserver (frank-primary). Reference run: serverAppConfigs-docs/LLM/frank-primary-radiance-swift15-w4dn8.md; scripts in scripts/ (run-swift15-bf16.sh, calib-push.py, derive-protected-experts.py, apply-protected-cast.sh, convert-swift15-w4dn8.sh, kld-gate-swift15.sh, fleet-probes-swift15.sh).

Sequence:

1. Fetch checkpoint with per-shard LFS sha256 verification (-f, byte counts, no token on argv).
2. BF16 container: rad-convert no-recipe (pure copy) — serves as the KLD reference engine.
3. KLD reference: record logits on the SERVE pin (1.0.13) at MNBT 32768, --max-model-len 16384, corpus ≤16k prompts. Writes atomically at completion (rows: line = receipt). Never scp a running bash script (lazy-read law).
4. Calibration: the tap arms on the 1.2.0 pin — see the section below before any hour is spent.
5. Protected experts: derive from gram energy (share ≥3 % AND ≥3× routing share), splice between # PROTECTED-BEGIN/END markers of the recipe. Plugin law: ONE encoding per expert table; only whole bf16 experts legal beside it — no gate_up/down split.
6. Final convert on the SERVE pin (CPU GPTQ, hours; disk gate ≥146 GiB free first).
7. KLD gate on the serve pin: MNBT ≤ 2048 (w4 streams in place only there; 32768 → DID NOT FIT ... stored form is not the container's), pool 40960, fp8 KV matching the production KV dtype. Gate: mean KL ≤ 0.03, top-1 ≥ 95 %.
8. Deploy ./scripts/deploy.sh dankserver --service frank-archon; verify /v1/models id = served-model-name (alias independent of file — harness models.yml untouched), boot ledger, streamed ≥128-token decode probe, fleet probes (vision needs ≥256-token budget + reasoning_content fallback).

The calibration tap: pin, arming, engagement gate, output size

• Pin: 1.2.0 arms the tap, the production pin does not. RADIANCE_CALIB_DIR + RADIANCE_CALIB_TOKENS are the whole interface (there is no --calib* flag on any pin). Running a tap on the 1.8.1 serve image produced zero bytes over 17 h / 7.3 M prompt tokens at a healthy 118 tok/s — no error, no ledger line, no /stats counter. Swift15's runner pins PIN_120 for the calib mode only; a runner that uses FRANK_ARCHON_IMAGE for every mode silently calibrates into a void.
• Strings prove code, not arming. CalibExperts, RADGRAM2 and the seal line calibration wrote layer Hessians after %lld tokens exist in architectures/qwen4exp_fp8.so from 1.2.4 through 1.8.1, and the boot ledger lists RADIANCE_* env names (a dump, not support). Neither is evidence the tap is engaged.
• Engagement gate, before any long drain. Boot with a tiny floor (RADIANCE_CALIB_TOKENS=8192), push 2–3 corpus documents, and require the seal line plus bytes in the tap dir. The seal fires after ~10 k tokens regardless of prompt size, so the test costs minutes — the absence of this check cost 17 h.
• One seal writes ~40 GB (per-expert gram + Hessian set, sized by expert width and layer count, essentially independent of how few tokens triggered it). Point RADIANCE_CALIB_DIR at a volume with ≥60 GiB free (/mnt/entropy on dankserver) and gate on free space before boot; landing it on a 37 GiB root filled the filesystem, and every subsequent write came back was short / cannot write.
• The tap needs the bf16 container (calibrate the bf16 container), tp=2 with --placement expert_tiered --weights-disk-tier is fine (swift15 did it), and a sliced-expert layout is refused by name (calibration runs at one rank; this rank holds a slice of every expert's width). 1.2.0 lacks --flash-attn, --metrics, --expert-nl, --busy-prefill-chunk; it does have every measuring-shape flag (--kv-cache-dtype, --max-model-len, --ngram-placement, --num-speculative-tokens, --override-chat-template).
• Engine rates: prefill_tps in /stats is a rolling gauge, never a cumulative counter — derive throughput from total_requests × corpus mean tokens/doc, or from steps_prefill. A wide calib step (MNBT 8192) turns ~2.5 steps/doc into 1.0 and buys ~1.2× on a disk-tiered bf16 rig, not 4.5×.

Laws: stop frank-archon for every GPU phase (relinked unit: stop, mask fails; plain systemctl for a system unit is denied by polkit — use sudo systemctl); verify docs against podman inspect <name> --format {{join .Config.Cmd " "}} (rootless, as dank) before writing shapes; ff-pull fails on untracked files the merge tracks — trash first.