Converter: per-tensor-type mixed precision (int8 for shared/o_proj/kv_b_proj, int4 rest)

[woolcoxm]

Summary

Splits the converter's resident weight classification into 5 sub-types, each independently controllable to a different bit width. The recommended plan puts the 3 most error-sensitive tensors (shared expert, o_proj, kv_b_proj) at int8 and everything else at grouped int4 — for only +5.3 GB RAM.

Closes #237.

Problem

Not all tensors suffer equally from int4 quantization. Three categories of weights compound their error on every token:

1. Shared expert — fires on every token regardless of routing. Error pollutes every forward pass.
2. o_proj — reconstructs the attention output. The last matmul before the residual stream.
3. kv_b_proj — reconstructs the KV cache on every decode step. Error is cumulative — once in the KV cache, it persists for the entire conversation.

The other ~95% of weight mass (routed experts, dense MLP, other attn projections) is either routed (error isolated to one expert) or lower-sensitivity.

Changes

c/tools/convert_fp8_to_int4.py (+52 lines, -8 lines):

The classify() function is split from 3 types (resident/expert/io) into 5 sub-types:

Type	Tensors	Default bits
sh	shared expert	ebits (4)
o	o_proj	ebits (4)
kvb	kv_b_proj	ebits (4)
attn	q_a, q_b, kv_a projections	ebits (4)
dmlp	dense MLP (first 3 layers)	ebits (4)

New CLI args:

--shared-bits N    # shared expert (default: ebits)
--o-bits N         # o_proj
--kvb-bits N       # kv_b_proj
--attn-bits N      # other attention projections
--dmlp-bits N      # dense MLP

Recommended usage

python tools/convert_fp8_to_int4.py \
  --indir /path/to/GLM-5.2-FP8 \
  --outdir /path/to/glm52_i4_mixed \
  --ebits 4 --io-bits 8 --group-size 128 \
  --shared-bits 8 --o-bits 8 --kvb-bits 8

Cost

Tensor	Count	Extra RAM (int4→int8)
shared expert	3×78	+6 MB
o_proj	78	+234 MB
kv_b_proj	78	+117 MB
Total		+5.3 GB (1.4% of 372 GB)

Backward compatibility

• With no --*-bits flags, behavior is identical to the previous converter
• Composes with --group-size 128 (orthogonal: grouped scales reduce error, mixed precision protects sensitive tensors)
• No engine changes — the engine already supports int8 (fmt=1) and int4 (fmt=2/4) side-by-side, auto-detected per-tensor

Stacked on

This PR includes the grouped-quant base (#242) because quant_int4_grouped is used by the mixed-precision path when --group-size > 0 and bits <= 4.

Test plan

• Converter produces correct bit-width per tensor type (verified via scale array sizes)
• Backward compat: no flags = same output as before
• Production quality A/B: mixed vs pure int4 (requires FP8 download, FP8 download tool: dual-source (ModelScope + HF), parallel, resume — for the 379 GB GLM-5.2-FP8 checkpoint #239)

[JustVugg]

Closing — this is already on dev, and you're the one who put it there.

The whole thing (classify splitting resident weights into sh/o/kvb/attn/dmlp, bits_map, the five --*-bits flags) landed in 69f65d5 — "Windows-dev: grouped quantization + mixed precision + expert budget + download tool". It's at convert_fp8_to_int4.py:141-231 right now.

I checked rather than assumed: I trial-merged this PR onto current dev and git diff --stat dev...HEAD came back empty. Merging it is a literal no-op.

For what it's worth, I reviewed it as if it were new before I found that out, and it's good work: single caller for classify, no hidden kind == "q" checks left behind, and empty bits_map falls back to ebits so the old behaviour is bit-identical. I also verified the engine side actually supports it — qt_from_disk detects the format per tensor from the byte counts (nb==O*I → int8, nb==O*ceil(I/2) → int4, then group-size detection), so a model with int8 o_proj and int4 experts really is read correctly. The feature works end to end.

The reason this PR is a ghost is the same thing you were laughing about on #298: that mega-commit bundled grouped quantization + mixed precision + expert budget + the download tool together, so its pieces landed without their own PRs closing. Three of your issues (#237, #238, #239) were in the same boat — all delivered, all still open. Closing those too.

The one that bundle also carried was EXPERT_BUDGET, which is now quarantined (#303). Worth noting as the argument for smaller commits: when everything arrives together, the good parts can't be told from the one that had to be pulled back out.

[woolcoxm]

ok will keep that in mind, was it one of my experimentation branches by chance?? i work on them for hours at a time and when i find things that work i submit them, they usually contains changes that i didnt mean to submit.

usually i will create a new branch for the experiments, but if its the one im thinking it was, that one had a ton of experimentation done on it and i tried to submit one change at a time but couldnt figure out how to do it properly. it had 2-3 hours worth of work im sure, sorry about that :D