Unsloth Dynamic 3.0 GGUFs(unsloth.ai) |
Unsloth Dynamic 3.0 GGUFs(unsloth.ai) |
"Qwen3.8-27B-UD-Q8_K_XL.gguf" for instance.
The one downloaded at least 4 days ago is a different thing and is NOT the "Dynamic 3.0" GGUF which I am now downloading, which I presume will have a different sha256 checksum?
The unsloth page says dynamic 3.0 is released "today", but I have an older copy of qwen3.8 27B Q8 which I downloaded, if I remember right, at least 4-5 days ago...
hf download hf://unsloth/Qwen3.8-27B-GGUF \ Qwen3.8-27B-UD-Q4_K_XL.gguf
and then see them with `hf cache ls`.
Prune old versions with `hf cache prune`.
GIT_LFS_SKIP_SMUDGE=1 git clone https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
cd Qwen3.8-27B-GGUF
git lfs pull --include="Qwen3.8-27B-UD-Q8_K_XL.gguf" --exclude=""
(downloaded in the last few hours after the announcement of dynamic 3.0)
Qwen3.8-27B-UD-Q8_K_XL-unsloth-dynamic3.0$ openssl dgst -sha256 *.gguf
SHA2-256(Qwen3.8-27B-UD-Q8_K_XL.gguf)= af36ecb6b5db1407953345b746c14ac93f0657dda413910b4348683a2d990377
=====separator=========
downloaded at least 4 days ago:
Qwen3.8-27B-UD-Q8_K_XL-unsloth-original$ openssl dgst -sha256 Qwen3.8-27B-UD-Q8_K_XL.gguf
SHA2-256(Qwen3.8-27B-UD-Q8_K_XL.gguf)= af36ecb6b5db1407953345b746c14ac93f0657dda413910b4348683a2d990377
So they're actually the same thing, but the announcement says released today... Please let's not confuse the end users any more than they already are.
One thing that works for me is to ask the local model to make some fake data with the same format, let Claude Code work on the fake data, and then bring the code back and run it locally on the real data.
This way the real data never leaves my machine, but I can still use a stronger model for most of the coding.
Might be worth trying again now though.
I could of course download and test myself, but that would take days with my internet connection.
"We also made some smaller UD-1bit quants with UD-IQ1_S being 6.2GB (without MTP) which retain around 72% top-1% accuracy yet being 89% smaller"
If you had some use case with very small output sequences they could be interesting to try. I think dropping down to a 9B-class model would produce better results for most cases.
Currently I very much can't decide between going for a bit of a lower Q4 Quant to squeeze out a bit of buffer and ctx or wondering if a slightly higher (IQ4_XS vs Q4_K_M/XL) is worth it
[0]: https://github.com/ggml-org/llama.cpp/blob/master/tools/quan...
I use this project: https://github.com/vllm-project/llm-compressor
I'm hoping for speed improvements because the only problem running the 27B model on my Macbook pro (M4 Max) is the speed: 20 tokens per second. I benchmarked and MTP actually makes things slower, so I disabled MTP altogether. I'm hoping there will be some breakthroughs or optimizations that will allow me to run this at 30-50 tokens per second, which would make a big difference.
So far ollama managed to be the most performant of them all. I will get 30 to 40 tokes/sec with it when using the -mlx version of Qwen3.8.
Whatever the sauce the ollama folks baked into the mlx + MTP mix is currently working the best out of the box.
But 30-40 tokens/s would make a big difference.
KLD of 1%, or similar error metric that multiplies, on 10000 tokens would give accumulated error of 2,000,000%
I've seen LLMs self correct in chains of thought ("because of foo and bar, I need to... Wait, bar is not true, so that won't work") so I have to imagine this is a massive overestimate, errors do not necessarily compound.
Having "Wait, bar is not true, so that won't work" is not necessarily a correction. In fact, the problem is: across a long text it is a correction of a single mistake, but we are talking about thousands here.
But yes, of course that was a rough estimate. But the problem is - we don't really know what we are measuring here. Maybe there's a 2,000,000x difference of intelligence between coding indexes 52 and 50. By some measure that just feels small because that's how we process it akin to audio db.
Regardless the point is KLD and whatever they came up with is not meaningful. And they did not publish comparisons on real benchmarks.
but wait, the models constantly go back and forth on these things in their thinking traces, so it is unclear which self correcting is actually correct
Qwaiting for that 3.8-35B-A3B
As someone in the comments said we made a separate Q4_0 MTP if that's helpful so you can use that.
But I would suggest using UD-IQ3_XXS for 10.9GB for 16GB machines or Q2_K_XL
And I had similar experiences when Qwen3.8-27B unsloth images just came out with the full Q8_K_XL, I'm using an AMD setup which has modifications to save to disk the kv, but your (assuming you are part of the unsloth team) for some reason have been giving me similar issues.
I tried https://huggingface.co/mradermacher/Qwen3.8-27B-Uncensored-G... the 8 bit, 6 and 2 bit... the 2 bit almost use the complete KV doing it's thing and didn't loop itself.
It can be something in my setup, there is a very high chance of that, but the previous 3.6 images from qwen, the 27B, the 31A3 and 122 they are all unsloth and did work on my setup without issues...
Again could be my setup... let me know if there is any data I can supply to you to debug if needed.
For those of us with a 16GB GPU, how do they compare with ExllamaV4 at 4-bit (4.0bpw)?
It looks like that fits in 12.5GB of VRAM since embedding are left in DRAM, Unsloth Studio and other llama.cpp derivatives have to load these weights in VRAM for tied embedding models like Qwen3.8.
ExllamaV3 4.0bpw fits in 12.5G of VRAM and beats IQ4_XS according to the measurements here: [turboderp/Qwen3.8-27B-exl3](https://huggingface.co/turboderp/Qwen3.8-27B-exl3)
But those were compared against UD2.0 I guess. Also plans to support these (SOTA) quants in Unsloth Studio?
> We also removed the MTP module from smaller quants under UD-Q2_K_XL (8.37GB and lower) to converse around 500MB of disk space - you can use the Q4_0 MTP separate module if needed
Given 16GB of VRAM, what will give me the best experience in OpenCode? Currently using Qwen3.8_Q_3
I know that didn’t answer your question but I was looking for a test suite and couldn’t find anything.
After reading the logs, there is far less doom looping than with 3.6, but whether that’s a one off or not is up for debate.
Q4_K_P
Interestingly, it also seems to tend toward self-correcting, which makes lower quantizations borderline usable. There'll be more faffing around, but still converging toward a solution. I wonder if that's a deliberate product of its RL.
We do plan to do larger benchmark suites though!
The current benchmark suites that frontier AI labs use are probably a good fit, e.g.
https://z.ai/blog/glm-5.3#:~:text=Performance%20across%20com...
https://www.kimi.ai/ai-models/kimi-k3#:~:text=Performance%20...
https://www.anthropic.com/news/claude-opus-5
https://openai.com/index/gpt-5-6/
But guessing from your current benchmarks, I assume that you are severely compute-constrained. What is your time budget?
It takes forever, but it does actually get around to making things work, and it is more thorough and produces better code than previous qwen models. You just need to let it run quite awhile.
If your motherboard/cpu doesn't actually have those (few do outside some xeons, epycs and threadrippers) you can still do it - it's called a layer split and will work even with 1 lane per GPU. Each GPU will work at its maximum speed, but only 1 will be active at any given instant - imagine a relay race.
(Didn't mention which PCIe generation - obviously the higher the better. At v4 and up, even 8 lanes per GPU would be enough for a performant tensor 4-way split)
Edit: If you have more than 1 user at a time, the GPU can actually all be working all the time, if there are enough parallel requests to serve. But you need enough KV cache for all the sessions you're running in parallel.
llama-server --host 0.0.0.0 --port 8089 -m Qwen3.8-27B-UD-Q8_u.gguf --spec-type draft-mtp,ngram-mod --spec-draft-n-max 3 --spec-draft-n-min 1
if you have an igpu and want to exclude or just use some gpus you can use
--device Vulkan3,Vulkan2,Vulkan1
in my case vulkan because of amd, you can see your devices with
llama-server2 --list-devices
Available devices: Vulkan0: AMD Radeon Graphics (RADV RAPHAEL_MENDOCINO) (33515 MiB, 29349 MiB free) Vulkan1: AMD Radeon RX 7900 XTX (RADV NAVI31) (24560 MiB, 4911 MiB free) Vulkan2: AMD Radeon RX 7900 XTX (RADV NAVI31) (24560 MiB, 7681 MiB free)
Using multiple cards is one of the things that the models and software that Unsloth releases does really well in terms of ease of use and relatively good performance.
I gave it a shot now:
mlx_vlm.generate --model mlx-community/Qwen3.8-27B-4bit --prompt 'give me fizz buzz in rust' --enable-thinking --draft-kind mtp --draft-model mlx-community/Qwen3.8-27B-MTP-4bit --verbose
==========
Prompt: 58 tokens, 90.717 tokens-per-sec Generation: 145 tokens, 36.392 tokens-per-sec Peak memory: 17.419 GB Speculative decoding: 2.79 accepted tokens/round (1.79 accepted drafts/round, 89.4% of drafted, avg draft 2.00) over 52 rounds
Which is very close to ollama, thank you!
I'm not sure if I can get rid of the drafter model, if I understand correctly, the Qwen model already includes a built in draft headers, but just having --draft-kind mtp results in about 17 t/s.
> Regardless the point is KLD and whatever they came up with is not meaningful.
I'm not saying you're wrong, I'm just saying this isn't a meaningful metric either, mostly because it is using a different type of error (divergence along a trajectory) than what was actually measured (divergence at a fixed point) and so can't be used for this purpose. It could establish an upper bound but going by your work that upper bound is so high it may as well be infinite. That's somewhat concerning but doesn't necessarily suggest it performs badly in a typical case (which is how I'd interpret an expectation of 2M% error).
More cards = more communication over PCIe. The prompts don't come in and just get magically split between each card, they move sequentially through them.
Also, with 2x24GB cards you don't really have 48GB of usable memory to load a model, closer to ~42GB + context.
And then there are power concerns, motherboard limitations (PCIe slots and lanes - a lot of motherboards with multiple 16x PCIe slots don't actually have 16x lanes to each of those slots), and more. 8x GPUs are going to easily draw 2000W on their own, if not substantially more. You'll need wiring and a circuit that can support 3000W without a risk of starting a fire in your wall.
For $5k, a single 32GB 5090 might be a better choice for a lot of people versus 4x3090s with 24GB each. It will definitely perform substantially better on smaller 27B models.
For hardware:
A good motherboard with lots of PCIe lanes (7x full 16x PCIe 4.0), DDR4 support, etc:
https://www.asus.com/us/motherboards-components/motherboards...
Add in a 3xxx series Threadripper PRO, 128 or 256GB of DDR4 (going higher becomes really expensive), and a ~1400 watt power supply. You can underpower/undervolt Nvidia cards really easily, and capping them at 250W loses you minimal performance.
Often times I run into issues like this it’s because I am using settings for a different model or just forget to set them up.
My main issue at the time was that my financial data had lots of messy notes, comments, and irregular annotations. The quantized models often failed to process all of that context consistently and would miss things. So I ended up generating a fake dataset with the same structure, asking Claude Code to work out the analysis on that, and then bringing the result back to the local model for the final pass.
I was mainly using llama.cpp at the time, before B12X support was integrated into vLLM, so I think I wasn't using it then.
This person has basically run into the limit of state of the art for even a modestly sized local model (this isn't deepseek v4 flash 0731 Q8 which I am running myself locally on a great deal more hardware), this is a 27B dense, but they're just not going to have a good time if they expect good quality results out of a Q2. The choices are either upgrade hardware or pay for external inference.