---
name: radiance-requant-source-audit
description: "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)
```bash
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 `.rad`s 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.