VINDEX3

QUANTIZATION · RECORDED RUNS · GRANITE-4.1-3B

HOW MANY BITS DOES A MODEL NEED?

Everyone says four. The honest answers are four and a half, five point six five, and it depends which tensor you are asking about — because precision is a property of components, not a label attached to a model.

What is LLM quantization?

LLM quantization reduces the precision used to store model weights, trading model size and memory bandwidth for numerical error. A “4-bit model” does not necessarily use exactly four bits per weight: formats such as NVFP4 also store scales, and mixed-precision models preserve selected tensors at higher precision. The rest of this chapter walks those mechanics on one real tensor.

“This is a 4-bit model” is an incomplete sentence.

WHAT THIS FIXES

Quantization gets described as a dial: sixteen bits in, four bits out, model four times smaller, done. But the scales are never free, the information loss is deliberate and permanent, the right precision differs per component — and the same policy that behaves beautifully on one model degrades badly on another. This chapter walks the real mechanics on one real tensor, and ends at the object that replaces the dial: the precision map.

layer.0.mlp.down_proj · granite-4.1-3b

shape

2,560 × 8,192

weights

20,971,520

dtype

BF16 · 16 bits each

stored

41,943,040 bytes

the first eight weights of row zero — real values

-0.012390-0.002960-0.016479-0.010132+0.022461-0.001228-0.002914-0.005890

Twenty-one million numbers in this one tensor; two hundred and eighty tensors like it in the model. Notice how tiny they are: BF16 can represent values up to about 10³⁸, and these live in hundredths — sixteen bits each, spent on a very narrow band. So: keep the position on the number line, discard the precision.

SELECTION, NOT CONVERSION

The identity below never changes — layer.0.mlp.down_proj is the same semantic component in every representation. What changes is physical: the encoding, the grouping, the scales, the error, the effective bits. Switch and watch the values snap onto a different grid.

THE SAME WEIGHTS — SELECT A REPRESENTATION

originalreconstructederror
-0.012390-0.012634-0.000244
-0.002960-0.002106+0.000854
-0.016479-0.016846-0.000367
-0.010132-0.008423+0.001709
+0.022461+0.025269+0.002808
-0.001228-0.002106-0.000878
-0.002914-0.002106+0.000808
-0.005890-0.006317-0.000427

three different inputs, one output — the highlighted rows all land on −0.002106

over all 20,971,520 weights: rms error 0.00148137 · max 0.01741537 · first group of 16 holds 8 distinct values

nominal4 bits
effective4.5000 bits / weight
scale granularity16 weights share one E4M3 scale
number systemfloating point (E2M1)
lossyyes — deliberately, permanently
stored11,796,484 bytes · 3.56× smaller
identitylayer.0.mlp.down_proj — unchanged, in every representation

The semantic component never changes. Its physical representation does — encoding, grouping, scales, error, and effective bits per weight all move together. That distinction is the whole page.

“Four bits” is the width of the code, not the cost of the weight.

Why isn't a 4-bit model always 4 bits?

Because the metadata is never free. In NVFP4, sixteen weights share one eight-bit scale and each weight spends four bits choosing a slot on it: 64 code bits plus 8 scale bits is 72 bits per sixteen weights — 4.5 effective bits each. Schemes with zero points or block minima pay similar costs. “Four bits” names the code width; the storage cost is always higher.

derived — 16 × 4-bit codes + one 8-bit E4M3 scale

16 weightseach picks a slot on the shared scale
the E2M1 alphabet0 · ±0.5 · ±1 · ±1.5 · ±2 · ±3 · ±4 · ±6
16 × 4-bit codes64 bits
+ one E4M3 scale8 bits
= 72 bits / 16 weights4.5 bits per weight
+ one FP32 scale per tensoramortised to ≈0.000…

Four-bit describes the code width, not the storage cost. Sixteen weights share one eight-bit scale, each picks one of sixteen slots on it, and one FP32 scale covers the whole tensor — two-level scaling, fully counted. Derived from the recorded 3B container's bytes, not asserted: 4.5008 bits per weight.

This is lossy compression — unlike ZIP, there is no way back to the original values.

THREE NUMBERS ENTER · ONE NUMBER LEAVES

Three different numbers go in. All three come out as −0.002106 — they landed in the same slot, and nothing anywhere can tell them apart again. That is not lossless compression: ZIP gives your bytes back. This information is gone — deliberately, permanently — and the format's job is to keep the choice honest: the lossy copy lives beside the canonical bytes as a named variant with recorded fidelity, never in their place.

What's the difference between a numeric format, a scheme, a method, and a container?

They are four different decisions the phrase “quantization format” routinely blurs. A numeric format is the alphabet a weight is written in — BF16, NVFP4, NF4. A scheme is how weights share metadata — Q4_K's blocks and superblocks, group sizes, zero points. A method is how the codes are chosen — GPTQ and AWQ live here. A container is where representations live and what is recorded about them. And execution is the kernels that finally run the chosen bytes. The exhibit below names each layer in place.

ONE WORD, FIVE LAYERS — WHAT “QUANTIZATION FORMAT” CONFLATES

“a 4-bit model”

One phrase, carrying five different decisions that the ecosystem routinely blurs together.

01 / 03 — “a 4-bit model”

“a 4-bit model” decomposes into NUMERIC FORMAT, SCHEME, METHOD, CONTAINER, EXECUTION — which the VINDEX3 chain assembles into component → represented as → representation → encoded using → numeric format → selected by → execution authority. each layer named, none conflated.

The object that replaces the dial: the precision map.

What is a precision map?

A precision map is a compiled policy that assigns a physical representation to each semantic component of a model — this tensor at NVFP4, that layer's projections at BF16 — chosen from measurements rather than intuition, and carried by the artifact itself. It replaces the single model-wide dial with a program: precision becomes a property of components, held to recorded evidence.

recorded — granite-4.1-3b · uniform 4.5 ↔ mixed 5.65 effective bits/weight

layermlp.downmlp.gatemlp.upattn.kattn.oattn.qattn.v
0–39
4.50
4.50
4.50
4.50
4.50
4.50
4.50
stored 2,221,671,460 bytesweights 3,145,728,000effective 4.5000 bits / weight

This is the object the whole argument is about. Not “the model is four-bit” — a program: these tensors at four and a half bits, those at sixteen, an effective rate that is neither — and it is a physical fact inside the file, not a flag passed at load time. Execution honours it: ask for the all-NVFP4 backend and the protected tensors run at higher precision anyway, because the pack says so.

recorded · granite-4.1-3b: uniform ≈116 tok/s · this map ≈104 tok/s · +400 MB · 3.5× better in the tail. Three axes, not one.

NEVER JUDGE BY THE TOKEN

How do you know a representation is good? Not by the answer it prints. Below is a deliberately broken image — a ×100 scaling error in the output head — that produces the same text as the reference at every position, while its probability distribution is destroyed.

“the capital of France is” — the next-token distribution, position 4

' Paris'
55.775%
' ______'
3.101%
' a'
2.501%
' called'
2.469%
'?\n\n'
1.880%
ARGMAX SAMETEXT SAMEDISTRIBUTION INTACT

A ×100 scaling bug in the output head — and every test that generates text and compares strings passes. Top-1 agreement: one hundred percent, zero flips, while the probability distribution is annihilated. Which is why fidelity is measured in probability space — KL, ΔNLL, top-k, margin — and never by the token the model picked.

recorded · granite-4.1-3b · the bug arm of the quality bank — a deliberately broken image, kept because an invariant you never see fail is decoration

EVIDENCE

The same policy is not the same outcome — RECORDED · GRANITE vs GLIMMER

One command, two models: muse-glimmer-30b degrades gently under uniform NVFP4 (KL mean 0.0312 bits, p99 0.2490) while granite-4.1-3b degrades nine times worse on average and nineteen times worse in the tail (0.2778, p99 4.6224). Representation fidelity is model-specific evidence, never a property inferred from the format name.

SUPPORTED

Protecting the obvious tensor can make things worse — RECORDED · GRANITE 4.1 3B

Keeping every down_proj at BF16 costs over a gigabyte and moves the tail from 4.6224 to 4.8010 — worse. Keeping the last five FFN layers costs 431 MiB and moves it to 1.2826 — 3.5× better. Measurements can justify a precision map, and VINDEX3 can express, compile and execute it. Automatically discovering the right map remains open — see Discovering the Map.

SUPPORTED

The file's precision map wins over the backend's request — RECORDED · GRANITE 4.1 3B

Ask for the all-NVFP4 backend against the mixed image and sixteen tensors run at higher precision anyway, because the pack says so. A compiled artifact, not a runtime option: ~104 tok/s against uniform's ~116, four hundred megabytes more, 3.5× better in the tail. Three axes, not one.

SUPPORTED

Quantization is not a model-wide label. It is a representation decision over semantic components, supported by evidence.

Q4 vs Q6 vs Q8 — which should I choose?

The chapter's honest answer: why should you have to choose one? A model is not uniformly sensitive, so a single format is the wrong shape of answer. The object that replaces the choice is the precision map — and the thing that writes the map from declared behaviour rather than intuition is REPRESENT: a composition-aware search under a frozen behavioural contract, verified on the composed model.

One question remains under all of it: we can store a precision map — but who writes it?

Cheap automatic discovery was tried, measured, and refused — four times. What finally writes the map is a search that judges the composed model against a declared behavioural contract. And what keeps those decisions honest for the life of the artifact is the representation model and the Record.

PUBLISHED 30 AUG 2026 · REVISED 31 AUG 2026 · VERSION 3.0 Candidate

CITE

site build 43a1b6b · built 2026-09-02

CITE THIS

Web page · 3.0 Candidate

Hay, C. (2026). Quantization. In VINDEX3 Specification (Version 3.0 Candidate). VINDEX3. https://vindex3.org/quantization

A chapter of the specification, citable on its own. Cite the version rather than the site — the canonical reference, and how to use it, live at /cite.