mradermacher

/

DeepSeek-V4-Flash-0731-Abliterated-FP8-GGUF

Like 5

Also, why is your Q8 nearly twice the size of Unsloth's DeepSeek-V4-Flash-0731-UD-Q8_K_XL?
Even the full weight original version is only 167g versus this at 280g

• The main reason is that unlike gguf-split the legacy split format supports zero copy. This means you can split and combine files without having to read/write any data or using any additional storage on a file system that supports zero copy. So once the GUUF is done we can simply split it without having to read/write any data and withing a fraction of a second and the same everyone can do after downloading our quants. The gguf-split file format was so terrible designed that it is incompatible with zero copy and so every time you want to split or concatenate GGUFs in that format you need to perform a full read and write of all the data which would make our IO bottleneck and storage issues much worse than they already are. Many of our users would also lack double the storage of a massive model required to concatenate them again. Sure one technically could run a gguf-split without concatenation but not archiving GGUFs in thar concatenated form is ugly.
• The split format we are using was invented by TheBloke and the standard everyone used at the time Team Mradermacher started. We predate the gguf-split file format and switching to it would confuse our millions of existing users that are all used to the legacy split format.
• Our convenient download page (https://hf.tst.eu/model#DeepSeek-V4-Flash-0731-Abliterated-FP8-GGUF for this model) that let's user's browser concatenate GGUFs while downloading relies on the legacy file format as the new file format can no longer easily be concatenated using JavaScript.
• The reason files where spitted in the first place is because HuggingFace used to have a 50 GB per file limit. With the introduction of XET this got removed. The only reason we even still split them if larger than 100 GB is because of https://github.com/huggingface/xet-core/issues/592 but with the implementation of a WebAssambly based XET client the CAS Bridge might soon be history after which splitting GGUFs is a thing of the past unless we are talking of trillion parameter sized models as XET has its per file limit set to 500 GB. And even with the current per file limit us having to split models is very rare and is only needed for a hand full of massive models while back in the LFS days even 70B models had to be spitted.

Also, why is your Q8 nearly twice the size of Unsloth's DeepSeek-V4-Flash-0731-UD-Q8_K_XL?
Even the full weight original version is only 167g versus this at 280g

This is because our Q8 is genuinely Q8 while other quarters take quant naming far less strict and are comfortable leaving tensors smaller than Q8 at their original size instead of upscaling them or in the case of Unsloth just naming them in whatever way they want and sometimes even renaming quants to be of a different size class after the fact like they did for https://huggingface.co/unsloth/Qwen3.8-2.4T-A95B-GGUF/commit/3bf1e5ef6c554803f4df9e179a2fb968b4184ae9. There are many arguments to be made for booth approaches. Some could consider our approach a waste of resources as it takes more storage, RAM and GPU memory but on the other hand if someone runs our models on hardware optimized for Q8 it will run faster as our model genuinely contain Q8 tensors. There are many devices that have hardware optimized for a specific quant and so the content not honoring the name of the GGUF is not something we like to do. The only exception to this rule is MXFP4 based models where we keep MXFP4 tensors as is as they already run very efficiently on many hardware and upscaling a 4bit tensor to Q8 seems like a waste of everyone’s resources.

Cool. Thanks for the reply and Thank you for your service.