45 lines
3.6 KiB
Markdown
45 lines
3.6 KiB
Markdown
---
|
||
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.
|