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.

Sign up or log in to comment