The Red Hat engineer says 1,000-plus tests found embeddings and several attention tensors deserve a larger share of the bit budget.
By [RuntimeWire Staff](/author/runtimewire-staff)
· Published
Primary source: [Hugging Face Newsroom](https://huggingface.co/blog/bartowski/per-tensor-layout-maps-for-gguf-quantization)
Why it matters #
GGUF files make open models practical on local hardware. Better bit allocation could preserve more model behavior at the same memory limit, though broad independent benchmarks are still needed.
Bartowski published a tensor-by-tensor method for assigning precision inside GGUF model files on September 10th, replacing years-old general rules in his quantization pipeline with maps derived from measured sensitivity.
The senior machine learning engineer at Red Hat is a familiar operator in local AI. His Hugging Face profile is packed with compressed versions of open-weight models intended to run on consumer and workstation hardware. Quantization is the unglamorous engineering behind those releases: reduce the number of bits used to store model weights, fit the model into less memory, and try to preserve its behavior.
Bartowski's new approach changes how that limited bit budget is distributed. Rather than deciding precision mainly from tensor names, shapes and positions using fixed rules, his pipeline can generate a layout map that specifies a quantization type for every eligible tensor.
The distinction matters because models have changed faster than the old rules beneath many GGUF releases. Bartowski traced the project to the spread of mixture-of-experts models, particularly architectures with more than eight experts and small shexp tensors that proved unusually sensitive. He had already maintained a modified version of llama-quant.cpp to handle those cases. New model families and competing layout methods convinced him that another collection of special cases would eventually become the same maintenance problem.
Four days of deliberately damaging models
Bartowski worked with Claude Code to build testing scripts, then said he ran roughly 96 hours of experiments on a Framework Desktop, producing and evaluating more than 1,000 quantizations.
The central experiment was simple and computationally expensive. In a "degrade-one" run, Bartowski stored nearly every tensor at the relatively high-precision q8_0 level while crushing one tensor to q2_k. The resulting change showed how much damage that tensor could cause. He also tried the inverse, upgrading one tensor inside an otherwise low-precision model, though he said those results contained too much noise to drive the method.
The main sweeps used Qwen3.5 models at 0.8B and 4B parameters. Bartowski then checked the patterns against models from other families, including Gemma 4, IBM's Granite 4.2, MiniCPM5, Ling, Muse and DeepSeek-V2-Lite.
His measurements compared the token probabilities produced by each quantized model with those of its bf16 reference using KL divergence, or KLD. The tests used llama-perplexity on wikitext-2-raw at a context length of 512. Lower KLD meant that the compressed model remained closer to the reference.
The results, which have not been independently reproduced, gave Bartowski a hierarchy of weak spots. He reported that token embeddings dominated the sensitivity scale, producing about eight times the damage of the worst individual weight tensor in the 0.8B model and 16 times the damage in the 4B model. Early and late layers followed the familiar U-shaped sensitivity curve. Attention value and output projections, feed-forward up projections and state-space-model output tensors also ranked highly. Feed-forward gate tensors generally did not earn additional bits in his tests.
Those findings do not mean every embedding should remain at q8_0. Bartowski found that q4_k restored much of the lost performance, leaving the solver room to spend bits elsewhere when targeting smaller files.
A solver decides where each bit goes
Bartowski has published the generator, solver and frozen sensitivity data in his quantization configuration repository. The solver takes a model's shape, measured sensitivity priors, GGML block-size information and a target quantization type. It produces a --tensor-type-file for llama.cpp, assigning a type to each quantizable tensor rather than accepting the runtime's built-in heuristic.
The repository contains the public configuration, generator and sensitivity data behind the method. Bartowski's article also publishes the solver and layout-generation files used to produce the maps.
Bartowski also imposed clearer rules on GGUF's increasingly elastic suffixes. Under the new scheme, _S means at least 90% of a model's body tensors remain at the named quantization type. _M sets that floor at 70%, while _L permits up to half of those tensors to receive higher precision. Older variants including Q2_K_L, Q3_K_XL and Q5_K_L are being retired.
That cleanup exposes a practical problem with the previous naming system. Two files carrying different labels could converge toward similar bits-per-weight totals, while a supposedly lower-tier file could become larger than a higher-tier option after its embeddings were preserved at greater precision. Bartowski said the new layouts made Q3_K_M about 15% smaller on Qwen3.5-4B. In another test, Q4_K_M had slightly worse overall KLD while using just over 5% less space, giving it a better result per bit by his measure.
The goal is a menu where the label once again describes what is inside the file. Users choosing among quantizations can compare meaningful tiers instead of relying on suffixes accumulated through years of exceptions.
Release metadata makes the layouts inspectable
The method has already been used in releases for MiniCPM5-2B and Gryphe Pantheon Reasoning 26B, according to the available model-release records. Those releases show the layout method moving beyond the original test models.
The evidence remains bounded. Bartowski fit the original prior largely on two small Qwen models and evaluated KLD on one dataset. Independent tests would need to establish whether the allocation method improves task accuracy and perplexity across model families without harming inference speed or hardware compatibility.
Other community projects are working on the same allocation problem. Thireus's GGUF Tool Suite also measures the effect of degrading individual tensors and builds model-specific recipes. The field lacks a broad, independent comparison covering task accuracy, perplexity, inference speed and compatibility across hardware backends.
Bartowski's contribution is still concrete: a working pipeline, published sensitivity tables and reproducible release metadata. His next planned test is Qwen3.8-27B, followed by work on models with large n-gram tables and unusual multi-head latent attention designs.
GGUF users will encounter the change through smaller files, altered tier names and quantizations that spend precision differently. Bartowski spent four days breaking tensors one at a time so the pipeline could stop pretending they all fail in the same way.