When two people quantise the same model, you expect the numbers inside to differ. That is the whole job. What you do not expect is for the models to be different shapes. We read the tensor tables of seven Qwen3.5-35B-A3B builds from three publishers, about 16 MB per file, and found that two of them disagree about how many blocks the model has.
One ships 40. One ships 41. The extra block is not a rounding difference or a metadata typo. It is the multi-token prediction head, and keeping it or dropping it decides whether the file you downloaded can do speculative decoding at all.
Why do two GGUF builds have different block counts?
Because one publisher preserved a component the other removed.
Reading the block indices present in each file gives the discrepancy plainly. unsloth’s builds contain blocks 0 through 39. bartowski’s contain blocks 0 through 40. mradermacher’s, like unsloth’s, stop at 39.
The deciding evidence is what else is in each file. Searching for tensors whose names mark them as multi-token prediction components returns four in bartowski’s build and zero in unsloth’s. Block 40 is where they live.
Qwen ships MTP tensors with this model. They are extra weights, trained alongside the main network, that let a runtime propose several tokens ahead and verify them in one pass. We covered the mechanism when we looked at how Ollama uses MTP, where the interesting detail was that Ollama exploits Gemma’s heads and discards Qwen’s.
So the same component now has three fates depending on your stack: the model ships it, your quantiser may or may not keep it, and your runtime may or may not use it.
There is a detail that confirms the intent rather than an accident. In bartowski’s builds, block 40 is not quantised like its neighbours. Across the expert tensor classes the file runs at IQ3_S or IQ2_XXS, and block 40 sits at Q8_0, the highest precision in the file. Nobody promotes a block to 8-bit by mistake. It was kept deliberately and protected deliberately.
Does the silent expert problem appear here?
No, and this is now the second model family where it does not.
Qwen3.5-35B-A3B declares 256 experts with 8 active per token, across an architecture the metadata calls qwen35moe. In all seven builds, from all three publishers, the expert dimension of every fused expert tensor matches the declared expert count. Nothing has been quietly dropped.
We went looking for this because of a claim that circulates whenever a large mixture-of-experts model gets community quants: that uneven compression leaves some experts effectively dead while the model card still advertises the original number. When we audited eight builds of Gemma 4 26B-A4B we found no evidence of it. On a different model, a different architecture and three different publishers, we still find none.
One architectural difference is worth recording for anyone repeating this. Gemma 4 fuses its gate and up projections into a single ffn_gate_up_exps tensor, so it has two expert tensor classes per layer. Qwen3.5 keeps them separate, giving three: ffn_gate_exps, ffn_up_exps and ffn_down_exps. A script that assumes two classes will silently miss a third of the expert weights.
Which quantiser protects which layers?
All of them protect something. None of them protects the same thing.
- unsloth’s MXFP4 build promotes exactly one block out of forty, block 10, in all three expert classes. A single interior block, which matches no obvious rule.
- bartowski’s IQ2_XXS promotes the first five blocks and several near the end on
ffn_down_exps, plus block 40 across the board. - bartowski’s IQ3_M splits
ffn_down_expsalmost in half: twenty layers at Q5_K, twenty at IQ3_S, on a schedule that skips blocks 7 and 10. - mradermacher’s Q4_K_M uses that same alternating shape, twenty Q6_K against twenty Q4_K, on very similar indices.
The count of distinct quantisation types in a single file ranges from three to six across this set. That is the same spread we measured on Gemma, which suggests it is a property of how the tooling is used rather than of any one model.
What to check before you download
Three things, and the tensor table answers all of them in about 16 MB.
Count the blocks. If you intend to use speculative decoding, a build that stops one block short of another build of the same model has dropped the head that makes it possible. The filename will not tell you.
Do not trust the quant name. unsloth’s Q3_K_M build for this model contains no Q3_K tensors at all; its expert weights are IQ3_XXS and IQ4_XS. That is the same filename-against-contents gap we found in a build named UD-Q4_K_XL that held no Q4_K, and it is clearly not confined to one publisher.
Check the block count against the model card. The publisher’s own repository states the layer count
for the base model, and a GGUF that carries one more block than that is carrying something extra rather
than something wrong. Knowing which of the two you are looking at takes one comparison.
Count the expert tensor classes. Two on Gemma, three on Qwen. If you are auditing how a mixture-of-experts model sizes in memory, missing a class understates the expert budget substantially.
None of this makes any of these publishers wrong. Dropping an MTP head is defensible if your target runtime discards it anyway, which for Ollama and Qwen is currently the case. Keeping it is defensible if you would rather ship what the model came with. The problem is that both choices arrive under the same model name, with the same quant labels, and nothing in the listing distinguishes them. The file that can do speculative decoding and the file that cannot are told apart only by opening them.