BF16/Q8_0 GGUF?

#1
by mrexodia - opened

Could you release the BF16 or Q8_0 GGUF files? I have a DGX Spark and it would fit easily, likely with better output quality.

BugTraceAI org

Hey mrexodia! Great to hear you have a DGX Spark β€” that's serious hardware πŸ”₯ The BF16 safetensors base model is ~54GB and Q8_0 GGUF would be ~29GB. We didn't include them initially due to storage constraints on our end, but this is definitely on our radar given the community interest. If there's enough demand we'll prioritize it. You could also self-quantize from the base Qwen2.5-27B + our LoRA adapter in apex_final/ to get a BF16 merged version.

Hey mrexodia! Great to hear you have a DGX Spark β€” that's serious hardware πŸ”₯ The BF16 safetensors base model is ~54GB and Q8_0 GGUF would be ~29GB. We didn't include them initially due to storage constraints on our end, but this is definitely on our radar given the community interest. If there's enough demand we'll prioritize it. You could also self-quantize from the base Qwen2.5-27B + our LoRA adapter in apex_final/ to get a BF16 merged version.

If files in BF16 format are provided, the community could perform operations such as AMD-native ROCm FPX quantization. Support for MTP acceleration would be even better.

BugTraceAI org

Hey @mrexodia , @FREAKOJC β€” I need to correct my earlier reply, which was wrong on two counts.

CORE-Ultra-27B is built on DavidAU/Qwen3.6-27B-Heretic2-Uncensored-Finetune-Thinking, not Qwen2.5-27B β€” this repo's base_model metadata had it right, my comment didn't. And apex_final/ is the LoRA for our separate APEX model, which is a Gemma-4-26B lineage; it would not merge onto this base. So the self-quantize path I described wouldn't have worked. Apologies to anyone who tried.

On the actual request: we release BugTraceAI models in quantized form only. That's a deliberate policy, not a storage issue, and it isn't changing for this model β€” so there won't be BF16 safetensors or an adapter release for CORE-Ultra. I'd rather give you a straight answer now than leave this open.

@FREAKOJC one technical note, since it affects your planning either way: this model has no MTP/NextN modules β€” neither the merged weights nor the upstream base carry them (1,184 tensors, zero MTP). A full-precision release wouldn't have unlocked MTP acceleration.

Q6_K and Q4_K_S stay up and maintained. Thanks for the interest β€” 30k downloads on this repo is genuinely more than we expected.

Thanks for your answer! Could you elaborate a bit of the why though? And what about Q8_0?

Sign up or log in to comment