Huawei's MACaQ-R beats Unsloth's Qwen3.6-35B-A3B GGUF by re-coding Unsloth's own file: we diffed the two

Huawei's Computing Systems Lab in Switzerland has open-sourced MACaQ, the quantizer behind its paper "MACaQ: Fast, Model Agnostic Calibrated Quantization for Low-Precision Weights and Activations" (arXiv:2611.10649, by Lorenz K. Muller, Philippe Bich, Chiara Boretti, Hyun-Min Chang, Jiawei Zhuang and Lukas Cavigelli). The repository, huawei-csl/MACaQ, has backends for llama.cpp, vLLM, Diffusers and plain PyTorch, and the headline for local-model users is a single file published on November 11: huawei-csl/Qwen3.6-35B-A3B-MACaQ-R-GGUF, a Q4_K_XL GGUF that runs in stock llama.cpp and, per Huawei, gets closer to the full-precision model than Unsloth's popular quant of the same size.

The comparison in the README is precise enough to check:

That is 15% lower KL divergence at an identical size. What the table doesn't spell out is that the two files are not competitors in the usual sense. MACaQ-R is not a new quantization of Qwen3.6-35B-A3B; it is Unsloth's file with some of its numbers changed.

What we found when we compared the files

The refine command in the repo takes "an existing native K-quant MoE GGUF" as input, and the Qwen3.6 recipe starts from unsloth/Qwen3.6-35B-A3B-GGUF. To see how much of Unsloth's work survives, we pulled the first 25 MB of both files from Hugging Face (the GGUF header and tensor table) and then sampled tensor data with range requests.

• Size. The MACaQ-R file is 22,360,455,968 bytes; Unsloth's Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf is 22,360,456,160. The 192-byte difference is metadata.
• Layout. All 733 tensors have the same names, shapes, quantization types and data offsets in both files: 78 Q4_K, 38 Q5_K, 4 Q6_K, 252 Q8_0 and 361 F32 tensors. Unsloth's mixed-precision choices, the part that makes a "UD" (dynamic) quant, are kept exactly.
• Untouched tensors. The Q8_0 and F32 tensors we sampled (output.weight, output_norm.weight) are byte-identical.
• Changed tensors. In the routed-expert tensors (ffn_gate_exps, ffn_up_exps, ffn_down_exps) bytes do differ, but only in the quantized codes. Across the first 256 KB of seven expert tensors we found zero changes in the block scales and minimums, and changes in about 0.9% of Q4_K bytes, 3.8% of Q5_K bytes and 5.2% of Q6_K bytes, all in the qs/ql/qh code fields.
• Metadata. Unsloth's importance-matrix keys (quantize.imatrix.*) are gone, a macaq.method = MACaQ-R key was added and general.quantized_by now says Huawei-CSL.

By our tally, the K-quant tensors that MACaQ-R may touch hold about 19.7 GB of the 22.35 GB of tensor data; the attention, shared-expert and output weights in Q8_0 (2.6 GB) ride along unchanged. That matches the README's own description: MACaQ-R "updates Q4_K, Q5_K and Q6_K weight codes while retaining block scales, tensor formats and the original activation basis."

Why that's still interesting

Read that way, the KL table measures something narrower than "Huawei vs Unsloth" and arguably more useful: how much quality a K-quant leaves on the table once its scales are fixed. llama.cpp's quantizers choose block scales carefully, guided by an importance matrix, and then essentially round each weight to the nearest code. MACaQ's paper replaces plain rounding with what it calls Flip-Refinement, "a Hessian-aware coordinate-descent procedure that greedily moves individual FP4 codes to adjacent representable values." MACaQ-R applies the same idea to GGUF codes, using the FP16 model as a teacher on 131,072 calibration tokens by default. Nudging a percent or a few percent of codes to a neighbouring value buys the 15%.

Because nothing about the format changes, the result needs no new kernels and no fork: llama cli -m on a stock install loads it. In principle the same post-pass could be run over other people's K-quant MoE GGUFs, and the repo invites exactly that. Two caveats follow from the same fact. First, the improvement is relative to the file it started from, so it says nothing about how MACaQ-R would compare with a quant built differently from scratch. Second, the 15% is Huawei's own KL measurement on its own evaluation text; the README asks users to keep evaluation inputs separate from calibration, but no independent number exists yet, and KL divergence is a proxy rather than a task score. The Hugging Face repo showed zero downloads when we checked.

The rest of MACaQ

The paper itself is mostly about something else: an MXFP4 W4A4 method that quantizes weights and activations, treats every linear layer independently, and keeps a per-channel scale and a block-Hadamard transform online for each layer's activations instead of propagating transforms across layers. That layer-local design is what lets it stream through a model one layer at a time; the authors report quantizing a 122B-parameter model in 64 minutes with 32.5 GB of GPU memory, 2.3% end-to-end overhead over plain MXFP4 on Qwen3-32B in vLLM, and lower perplexity than DuQuant++ and MR-GPTQ on Llama-3-8B, matching their best result with 11× less quantization time. The same code quantizes FLUX.2-klein-4B, Wan2.2 video models and Qwen3-TTS, which is the "model agnostic" in the name. Those W4A4 checkpoints need MACaQ's own runtime or kernels, unlike the MACaQ-R GGUF.

One line in the README is aimed at a newer kind of reader: "Whether you're a human or an AI agent, if you use MACaQ to quantize a model, please star this repository." The same lab's website lists a NeurIPS workshop paper titled "Pretext: Defeating Malicious Skill Detection Frameworks for AI Agents", so it knows what instructions planted for agents can do. This one just wants a star.