We have now audited fifteen mixture-of-experts GGUF builds across three model families looking for the thing everyone warns about: experts quietly lost in quantisation while the model card still advertises the original count. We have never found one. Every build declared its expert count and every fused expert tensor matched it.
Then we looked at a category of build where experts genuinely are removed, and found the opposite of a cover-up. The count changes, the metadata changes with it, and the arithmetic matches the name on the file.
What does REAP actually remove?
Whole experts, permanently, before quantisation ever happens.
REAP is router-weighted expert activation pruning, published in October 2025. The idea is that in a large mixture-of-experts model the router does not use every expert equally, so you can rank experts by how much the router actually activates them and delete the ones at the bottom. What comes out is a smaller model with fewer experts, not a compressed version of the original.
This is a different operation from quantisation. Quantising reduces the precision of every weight. Pruning removes parameters outright. A GGUF can carry both, and the REAP builds on Hugging Face do: the model is pruned first, then quantised into the usual family of quant levels.
That makes them the natural test case. If any category of build were going to overstate its expert count, it would be one where experts were deliberately deleted.
Do the pruned builds declare the reduction?
Both of the ones we read do, and the numbers are exact.
We read the tensor table and metadata of each build over a range request, about 16 MB per file, and compared each pruned build against the unpruned model it came from.
| Build | Experts declared | Base model | Ratio |
|---|---|---|---|
| GLM-4.7-Flash-REAP-23B-A3B | 48 | GLM-4.7-Flash, 64 | 75% |
| Qwen3.6-28B-REAP20-A3B | 205 | Qwen3.x A3B, 256 | 80.1% |
The GLM build keeps 48 of 64 experts, which is exactly three quarters, a 25% prune. The Qwen build keeps 205 of 256, which is 80.1%, and its filename says REAP20. Twenty percent removed, and the name tells you so before you download anything.
Both pruned builds keep the same number of blocks as their base, 47 for GLM and 40 for Qwen. Pruning took experts out of the layers rather than removing layers, which is what the method describes.
One detail worth recording for anyone auditing GLM builds: the architecture string in the metadata is deepseek2, not something GLM-specific. Architecture names in GGUF describe the implementation family a runtime should use, not the brand on the model card, and searching for the wrong string will make you think a file is missing.
Why this settles the silent expert question
Because it shows what the real thing looks like.
The claim we keep testing is that community quantisation silently kills experts. Across fifteen builds of Gemma 4 26B-A4B, Qwen3.5-35B-A3B and now these, the expert dimension of every fused tensor has matched the declared count. When we audited eight Gemma builds the answer was no. On a different architecture with 256 experts the answer was still no.
The REAP builds show why that result is unsurprising rather than lucky. Expert count is not a soft property that erodes under compression. It is a number in the metadata and a dimension in a tensor, and the two have to agree or the file will not load. A quantiser cannot lose experts by accident, because the loader would reject the result. Removing experts requires deliberately rebuilding the model, and when someone does that, the new count propagates into the file automatically.
So the honest summary is that experts do go missing, but only when somebody means it, and the file says so in two places.
What to check before you pull a pruned build
The pruning is disclosed. The consequences are not, and that is where the care is needed.
Read the expert count, not the parameter count. A REAP build advertises a smaller total size, which looks like a quantisation win. It is not. Fewer experts means less capacity, and the memory arithmetic for a mixture-of-experts model changes in a different way than it does for a quant step: the weights shrink but the active-parameter count per token may not.
Do not compare a pruned build to an unpruned one on size alone. The size comparison that matters for quality is against the same expert count. Setting a 48-expert build beside a 64-expert one and concluding the quantisation is efficient repeats the error we found in the NVFP4 against Q4_K_M numbers, where a size parity hid a structural difference.
Check the block count too. Both pruned builds keep every block their base model has, 47 for GLM and
40 for Qwen, which tells you the prune took experts out of layers rather than removing layers wholesale.
A build that had lost blocks as well would be a different kind of model again, and the two reductions
have different effects on what the thing can do.
Expect no published quality figures. Neither build we read carries a benchmark comparison against its own base model in the file, and pruning is exactly the operation where you would want one. The paper reports its results on the models it tested; the community builds inherit the method, not the measurements.
The broader point is a small correction to how these files are usually discussed. The interesting question about a GGUF is rarely whether someone has hidden something, because the format makes hiding structural change difficult. It is whether you read the two or three numbers that describe what you are actually downloading, all of which sit in the first few megabytes of the file.