AbsorbQuant Shipped 4-Bit FLUX and SDXL Weights. The Code to Run Them Does Not Exist.
Seven W4A4 NVFP4 checkpoints, 27 GB of real files, unusually correct license accounting, and a git clone command pointing at a repository that is not there.
On September 5, someone uploaded a Hugging Face repository holding four-bit versions of six of the most-used open image models: FLUX.1-dev, FLUX.1-schnell, SDXL base, SDXL-Turbo, SANA-1.6B and PixArt-Sigma. The file sizes are the kind that change what you can do on a consumer card. FLUX.1-dev arrives at 6.6 GB against a transformer that is 11.9 billion parameters in bf16. SDXL comes in at 1.7 GB. PixArt-Sigma at 325 MB.
The card is careful in ways most quantization drops are not. It names its calibration set. It states which license each checkpoint inherits. It describes a verification script that re-derives the files bit-for-bit and prints a content digest. It reads like someone who expects to be checked.
You cannot check it. Every install path on that card starts with git clone https://github.com/chenjiaj109550158/AbsorbQuant, and that repository does not exist.
Why four-bit activations are the interesting part
Four-bit weights are ordinary now. GGUF quants, NF4 builds and int4 safetensors have been passed around for two years, and the pitch is always the same: the file gets smaller so it fits on your card. The math still runs in bf16 or fp16 after a dequantize step, which means you save VRAM and gain nothing on speed.
W4A4 means both sides drop to four bits. The weights and the activations flowing through them. That lets the multiply itself run on a native four-bit tensor core instead of a widened one, and that is where actual wall-clock speedup comes from. The AbsorbQuant card says its files run on nunchaku's gemm_w4a4 kernel, which is the real thing rather than a dequantize-and-pretend path.
This matters if you generate images for a living or close to it. A FLUX render that takes 40 seconds is a different creative process from one that takes 12, because at 12 seconds you iterate and at 40 you commit. The whole four-bit push is about moving that line.
The mechanism, and the paper it re-derives
The hard part of four-bit quantization is outliers. Inside any given layer, a handful of channels carry values far larger than the rest, and a four-bit grid has sixteen slots. Spend those slots covering the spikes and you have nothing left to describe the ordinary values, which is most of the signal. The result looks like a smeared, low-contrast version of what the model should have made.
AbsorbQuant's answer is to split each layer in two. A rank-32 branch stays in fp16 and runs on the raw input. Everything left over goes into a GPTQ-quantized NVFP4 residual. The low-rank part in full precision soaks up the outliers, so what remains quantizes cleanly at four bits. The card calls this "decompose-first H-metric low-rank quantization."
If that shape sounds familiar, it should. SVDQuant, published at ICLR 2025 out of MIT Han Lab, introduced exactly this idea: an added low-rank branch that absorbs quantization difficulty in both weights and activations. Its authors report a 3.5x memory reduction on the 12B FLUX.1 model, with a 3.0x speedup on a 16 GB laptop RTX 4090 using INT4 and 3.1x on an RTX 5090 using NVFP4. Note the laptop part; it gets dropped every time that number is quoted, and it matters, because a mobile 4090 is a different card from the desktop one. The official checkpoints live under nunchaku-ai on Hugging Face, and the FLUX.1-dev repository there ships two files named svdq-fp4_r32-flux.1-dev.safetensors and svdq-int4_r32-flux.1-dev.safetensors.
Note the r32. Rank 32. The same rank AbsorbQuant uses. The two nunchaku files total 13.8 GB, so roughly 6.9 GB each, against AbsorbQuant's 6.6 GB. This is the same technique, at the same rank, producing a file of almost the same size.
That is not an accusation. AbsorbQuant says outright that its calibration uses "only the 128 fixed COCO-derived prompts shipped in the repo, no SVDQuant calibration artifacts," which reads as a deliberate claim to have built the pipeline independently rather than forking one. Independent reimplementation of a published method is good work. It is also the kind of claim that lives or dies on whether anyone can run your pipeline.
What is actually new here, once you subtract what already existed
I started writing this section as a coverage argument and had to throw it out, which is the useful part.
The obvious pitch is that AbsorbQuant covers models nunchaku does not. That is mostly wrong. Nunchaku's official Hugging Face org already ships SVDQuant checkpoints for the FLUX family (dev, schnell, fill, kontext, krea, canny, depth) and for SDXL: nunchaku-ai/nunchaku-sdxl and nunchaku-ai/nunchaku-sdxl-turbo both went up on September 20, 2025, quantizing the same stabilityai/stable-diffusion-xl-base-1.0 that AbsorbQuant targets.
So five of AbsorbQuant's seven files duplicate work that already has a public runtime. What is genuinely uncovered is PixArt-Sigma, which has no nunchaku checkpoint under either nunchaku-ai or mit-han-lab as far as I can find. That leaves the real differentiation as: one model nobody else has pre-quantized, plus a from-scratch reimplementation claim.
This makes the missing repository worse, not better. The value of an independent reimplementation is entirely in the pipeline. If I can run your calibration and get your digests, you have shown that the method reproduces without the original authors' artifacts, and that is a real contribution to a field where most "reproductions" just reuse someone else's calibration set and say nothing about it. If I cannot run it, the checkpoints are a slower path to models I could already download working versions of.
Then a second problem stacks on top. A four-bit checkpoint is not self-contained. It needs a loader that knows the packing format and dispatches to the right kernel. A methodology document published September 2 by another quantizer, working on a different model, lists what nunchaku's own ComfyUI loader supports: "Flux / Z-Image / Sana / QwenImage." PixArt is not on that list. The one file here with no existing alternative is the one with no obvious way to load it, which means the missing scripts/generate.py was not a convenience. It was the only documented way in.
I verified the repository's absence three ways, because "repo not found" is exactly the sort of thing that turns out to be a caching artifact. A cache-busted shields.io star query returns "message":"repo not found". The GitHub API endpoint returns nothing. A cache-busted raw.githubusercontent.com fetch of the README returns an empty body. Whatever the explanation, the code was not public as of September 6.
Put this into practice
The honest advice is: do not download 27 GB today. Here is what to do instead, and it takes about fifteen minutes.
1. Get four-bit FLUX or SDXL from the source that ships a runtime. Install ComfyUI, install the nunchaku wheel matching your torch and CUDA version, and pull nunchaku-ai/nunchaku-flux.1-dev or nunchaku-ai/nunchaku-sdxl. For the FLUX repo, pick svdq-fp4_r32-flux.1-dev.safetensors if you have a Blackwell card; the card's own wording for the other file is "for users with non-Blackwell GPUs (pre-50-series)," which is broader than the Ampere-or-Ada framing people usually repeat. The choice is not cosmetic: fp4 needs Blackwell tensor cores to mean anything.
2. Time one render before and after. Same prompt, same seed, same step count, once on your normal bf16 or fp8 checkpoint and once on the four-bit build. Write both numbers down. If the four-bit path is not meaningfully faster, your kernel is falling back to a dequantized path and you are carrying the quality cost for none of the benefit. That check takes two minutes and almost nobody runs it.
3. Adopt a pre-download check for any four-bit checkpoint you find. Three questions, in this order:
- Does the loader exist, and is it public? Open the repository the card tells you to clone. Do it before you start the download, not after.
- Does your card's architecture match the format? NVFP4 needs Blackwell. Several int4 kernels need
major == 8, meaning Ampere or Ada, and silently take a slower branch on anything newer. - What license does the file actually carry? Not the badge at the top of the card. The base model's license, which the quantized file inherits.
4. Read the license line, not the license badge. AbsorbQuant gets this right and it is worth copying the phrasing: "The quantization code is Apache-2.0. Each checkpoint here is a derivative of its base model and inherits that model's license." The practical translation is that its FLUX.1-dev file carries the Black Forest Labs Non-Commercial License and its SDXL files carry CreativeML Open RAIL++-M, regardless of the Apache tag on the repository. Most quantizers put an Apache badge on the page and say nothing further, and a lot of people have shipped client work on that misreading.
Honest limitations
I have not generated a single image with these files, because there is no documented way to. Everything above about method comes from the model card, and the card is the only source that exists. Treat the H-metric description, the calibration claim and the bit-identity guarantee as the author's own statements, unverified.
The frozen configs are a real hint that work happened. Each file carries a different setting: λ=0.001 for SDXL base, λ=0.01 for FLUX.1-schnell, λ=0.3 with an rms scale at 0.25 for FLUX.1-dev and SANA. Nobody fabricating a repository picks seven distinct per-model hyperparameters. Someone tuned these. That makes the missing code more frustrating, not less.
There is no quality comparison anywhere on the page. No side-by-side against the bf16 reference, no benchmark, no sample images. For a method whose entire pitch is "the low-rank branch preserves what naive four-bit destroys," the absence of a single picture is the gap that matters most, and it would have cost the author an afternoon.
And the repository may simply be unpublished rather than gone. Private-during-review, a renamed account, a deleted org: all ordinary. If it appears next week, most of this article becomes a footnote about publishing order, and I would be pleased about that.
The part worth arguing about
The four-bit ecosystem has split weights from runtimes, and the split is now wide enough that a model card is a claim about software you have to find somewhere else. Hugging Face will happily host 27 GB of correctly-tagged, correctly-licensed, carefully-described tensors that nothing on Earth can currently open, and no part of the interface will tell you that.
I do not think the fix is on the platform. I think it is a norm: if you publish a quantized checkpoint, publish the loader in the same breath, and if the loader is someone else's, say which one and which version. The people doing this properly already do. The pottokao H3 work I linked above ships a loader node, a methodology document, and a paragraph explaining why the alternatives did not work. That is the standard, and it exists, and it is not hard.
So the question I would put back to you: how many four-bit files are already sitting on your drive, and for how many of them could you name the exact kernel they dispatch to? I checked mine after writing this. It was not a comfortable audit.
If you get AbsorbQuant running, or if the repository turns up, I want to hear about it.
Medium metadata
Subtitle: Seven W4A4 NVFP4 checkpoints, 27 GB of real files, unusually correct license accounting, and a git clone command pointing at a repository that is not there.
Suggested kicker: A four-bit checkpoint is a promise about a runtime you have to source separately.
Primary sources:
- AbsorbQuant checkpoints: https://huggingface.co/chenjiaj109550158/AbsorbQuant-NVFP4
- SVDQuant official FLUX.1-dev build: https://huggingface.co/nunchaku-ai/nunchaku-flux.1-dev
- Existing official SVDQuant SDXL builds: https://huggingface.co/nunchaku-ai/nunchaku-sdxl and https://huggingface.co/nunchaku-ai/nunchaku-sdxl-turbo
- SVDQuant paper (ICLR 2025): https://arxiv.org/abs/2411.05007
- nunchaku kernel: https://github.com/nunchaku-tech/nunchaku
- FLUX.1-dev base model: https://huggingface.co/black-forest-labs/FLUX.1-dev
- Loader-support list, dated September 2, 2026: https://huggingface.co/pottokao/H3-RotNVFP4-ComfyUI-Loader