The size jump from previous q4_k_m GGUF is making this unusable on M5 Max 128GB

#18
by alxarch - opened

The last commit mentions:
gguf: replace Q4_K_M with mixed-precision Q4_K_Mx40-BF16x8 (bf16 sensitive layers)

That caused a huge size jump to 96GB for the 4bit variant (presumably because of the un-quantized layers).
The 96GB size is prohibitive for large context sizes on 128GB unified RAM.
Is this a mistake? Why not use a q8_0 or similar for the sensitive layers? Was just ready to switch from the unsloth quantization to the 'official' one but now I am not sure what to do. If someone from poolside could clarify the situation about what was the reason for switching sensitive layers to uncompressed, it would help us make informed decision about whether to use this or the unsloth UD-q4_k_xl to be able to take advantage of 256k context

Agreed, the jump from 68.2GB to 96GB is a bit extreme.

I can download the previous version from the git history, but I'm curious why the decision was made to bf16 sensitive layers from q8_0. Was the previous version not performing well enough?

The previous version fit perfectly on a 96GB VRAM or 128GB unified memory setup with 256k of FP8 context. That's a really popular class of setups, ranging from quad 3090/4090s, Blackwell 6000, plus all of the 128GB devices like Macbook Pro / Mac Studio, DGX Spark, AMD Strix Halo...

The new version doesn't fit on ANY of those... 😢

I'm trying to fine tune an LLM that will detect that loops in real time and end reasoning when it's looping so it will generate an answer, i will update later.

I uploaded a version here with the BF16 parts quanted down to Q8 without touching anything else. Made the model fit again in 96GB VRAM and the higher precision should still make it an improvement over the straight Q4_K_M variant.

I uploaded a version here with the BF16 parts quanted down to Q8 without touching anything else. Made the model fit again in 96GB VRAM and the higher precision should still make it an improvement over the straight Q4_K_M variant.

I tested it, it still lopping

Since my quantization is nearly byte-identical to the official GGUF (only the later BF16 parts were requanted), it wouldn't change behavior present in the base model to any major degree.
I haven't had any looping issues myself but I'm running fairly conservative settings in a custom harness. I did however have issues getting the reasoning to work reliably as it performs quite poorly without it.

Sign up or log in to comment