Allocation explorer
Where my bits at?
Every map below is read out of a published checkpoint on Hugging Face — its own quantization metadata and its own tensor headers, fetched from the repo people actually download. Nothing is reconstructed from a local run, and nothing is estimated: what the map draws is what vLLM loads.
Sixteen published artifacts.
Pick one. Columns are transformer blocks in depth order; rows are projection types. Hover any cell for its exact format and its size on disk.
…
Counting Linears is the wrong unit.
A map gives every Linear one cell, which is the right way to see a decision and the wrong way to see a cost. Weight matrices differ in size by orders of magnitude, so a format carried by a handful of large tensors can outweigh one carried by hundreds of small ones. That is why the map above defaults to disk footprint: row heights and column widths are fitted to the room each holds in the file people actually download, measured from the checkpoint's own tensor headers rather than inferred from a nominal bit-width. Switch to even grid to get one cell per decision back, and watch which rows collapse.
What the geometry does and does not claim. Row and column totals are exact: a row twice as tall holds twice the bytes. A single cell is approximate, because a grid whose rows and columns line up cannot make every cell's area exact — the byte matrix is not a product of its margins. Nor could any layout: cell sizes span up to 73,728× inside one checkpoint, so an exact-area drawing would push the smallest cells below a pixel and they would simply vanish. Rows too thin to see are held at a minimum height for the same reason. Hover any cell for its measured bytes.
Anchored cells stay hatched: embeddings, the output head and any mixture-of-experts routers, pinned at source precision because a misroute costs far more than the bits saved. On the 27B that block alone is about a fifth of the download — a real constraint on how small a mixed-precision checkpoint can get, and one that a bits-per-weight headline quietly hides.
Watch the allocator spend.
Every point below is a real solve: the allocator was given a byte budget and returned a complete assignment, together with the Δloss its cost model predicts there. Drag the budget and watch which Linears get promoted first — that ordering is the allocator's opinion about where the model is fragile.
…
For illustrative purposes only. NVFP4 (W4A4) and NVFP4A16 (W4A16) render weights bit-identically and occupy identical bytes — measured, max deviation 0.0 — while differing by roughly 9.4% RMS activation error. The shipping cost model prices weight error alone, so it is exactly indifferent between them: W4A16 is invisible to it, not merely unattractive. This lever shows what spending that dead zone would look like, ordering Linears by how early the allocator itself promotes them. The phenomenon is measured; this response is not. Pricing the activation term properly (AQUA-AURA) has since produced one shipped artifact — Qwen3.8-27B PrismaAQUA, in the list above — but this lever is not that mechanism, and no served A/B isolating the activation term exists for either. See the sensitivity page for what was measured.
How to read a map.
- Columns are depth. Left is the embedding end, right is the output end. Allocation is rarely symmetric down a model.
- Rows are projection types. Attention, linear-attention gates, then MLP and expert projections. A row that is absent in some columns means the architecture is hybrid — not every block has the same parts.
- Hatched cells are anchored. Mixture-of-experts routers, embeddings and the output head are pinned at source precision and never offered to the allocator at all. A misroute costs far more than the bits saved, so these are not decisions — and drawing them as though they were would overstate what was chosen.
- Colour families encode precision. Violet is 4-bit weights, teal is 8-bit, amber is untouched BF16. Within a family, lightness distinguishes activation precision and codebook size — a lighter teal is a larger codebook.