command-center/agent/managed-skills/radiance-requant-source-audit/SKILL.md

name, description

name	description
radiance-requant-source-audit	Answer "can we re-quantize a radiance model from what's on disk / what must we re-fetch" before planning a heavier-or-different quant campaign: irreversibility law, live asset census, base-bound reuse rules, and the expert-mass pool-fit ceiling.

Radiance re-quant source audit (dank-fleet)

Decide whether a new/heavier radiance .rad quant is buildable from local state, and what must be re-fetched. Run this BEFORE costing any campaign.

Irreversibility law (never re-litigate)

• Quantization is one-way: a .rad payload on disk is a lossy ENDPOINT. Re-encoding it upward only re-wraps its own KL error.
• rad-convert takes a RAW HF checkpoint directory (safetensors) — never a .rad. No dequant→requant path exists in the engine (see scripts/convert-swift15-w4dn8.sh mount line).
• Therefore any genuine rung change needs the high-precision checkpoint on disk. Even "more bf16-protected experts instead of wider codes" needs the bf16 tensors at convert time.

Census (live, on the engine host — do not trust docs)

ssh <host> 'df -h /home/dank | tail -1; du -sh /home/dank/models/* ; \
  du -sh /home/dank/corpora/calib /home/dank/corpora/kld-ref /home/dank/corpora/out; \
  cat /sys/module/ttm/parameters/pages_limit; \
  podman image exists "stilldeadcode/radiance@sha256:<serve-pin>" && echo PIN-PRESENT'

• BF16 Swift1.5 source + fp8-native .rad were DELETED 2026-10-15; only the serving iq4r + w4dn8 rollback .rads remain under /home/dank/models/rad/.
• Survivors (verified 2026-10-17): grams /home/dank/corpora/calib (41 GiB), KLD ref /home/dank/corpora/kld-ref (24 GiB), corpora JSONL /home/dank/corpora/out, HF staging receipts, engine pin image local, free disk ~544 GiB.

Reuse rules (what each survivor is bound to)

Asset	Reusable for
Calibration grams (RADGRAM2, down-input Hessians)	ONLY the checkpoint they were recorded from (Swift1.5) — tiers-independent, so valid for ANY new recipe tier on that same base
KLD reference log-probs	ONLY same-base candidates
Corpora JSONL	any base (recalibrate if base changes)
Derived protected-expert list	same base only (routing is finetune-specific)
Reusing grams+KLD ref skips ~8 h of GPU-serve windows (calibration + KLD record).

Heavier-rung pool-fit ceiling

Expert tables for Qwen3.8-Flash-Next bill ~56 GiB (w4) → ~75 (w5/w6 class) → ~112 GiB (int8/fp8) across both ranks (from the recipe's own mass lines: gate_up 150 + down 75 GiB bf16). The one-table-one-encoding law moves the whole expert set together. Pinned host pool 43,928 MiB/rank ⇒ only w5/w6-class rungs keep the no-streaming shape; int8/fp8 experts overflow it and re-open the NVMe 3.5 GB/s streaming era. FP8-official-checkpoint rebuild (172.8 GB, ungated, no-recipe copy) is the cheap half-download "heavier" but carries those streaming economics.

Known scored comparisons (don't re-pay for them)

Upstream w5dn64-vs-iq4r on the official checkpoint: mean KL 0.0789→0.0717, top-1 93.34 %, decode +4 %, prefill −19 %. A custom heavier official rung reproduces this; a custom heavier Swift1.5 rung reuses the fleet's own grams/KLD assets instead.

Fetch scripts (dankserver)

• Swift1.5 BF16 335.3 GiB: scripts/download-frank-archon-swift15.sh
• Official FP8 172.8 GB: scripts/download-frank-archon.sh (NOT bf16 — a bf16-official fetch needs a fork of it)
• iq4r container: scripts/download-frank-archon-iq4r.sh Disk gate arithmetic: checkpoint + output both live on the volume; the campaign convert wanted ≥146 GiB free AFTER the checkpoint lands.