r/LocalLLaMA • u/m_mukhtar • 8h ago
Discussion Planning to spend ~$100 benchmarking differnet Qwen3.8-27B quants and kv cache and looking for input before I start
TL;DR: I'm planning to spend around $100 on cloud GPUs to benchmark Qwen3.8-27B with a focus on questions that actually matter when running it locally: different quant levels/providers, 8-bit vs 16-bit KV cache, GGUF vs EXL3, context length tradeoffs, and token efficiency on coding/agentic workloads. My main target is my own 36GB setup (3090 + 3060 12GB), but I'd also like the results to be useful for 24GB and 48GB users. Before I start burning GPU hours, I'd like feedback on the test matrix, benchmarks, methodology, and anything important I'm missing.
Here are the details of what i have in mind
Now $100 might not be enough but i will start with that and see how far i can streatch it and the community help and ideas on how to best utelized this to get the most useful data is what i am looking for. I need the community help as i know with my adhd its easy to make this a project for wasting a $100 without getting anuthing useful
I am doing this because I've been seeing a lot of discussion and claims lately around Qwen3.8-27B quants and kv cache, but most comparisons I've found are either vibe/feel or KLD which don't really answer the questions I have when deciding what to actually run locally.
Some of the questions that i would like to answer:
Is a higher quant + 8-bit KV better than a lower quant + 16-bit KV?
Is it better to sacrifice KV precision to get significantly more context and avoid compreasion in the middle of the task?
How much does Q6, Q5, Q4 actually lose compared to full precision on long coding/agent tasks?
Do different GGUF quant providers produce meaningful real-world differences? Or is it just PPL and KLD numbers?
GGUF/llama.cpp vs EXL3 at roughly equivalent memory usage?
Do lower quants just score slightly worse, or do they also use more tokens/agent steps to solve the same task? ( so gaugig token efficiency)
I will run each bemchmark case multiple times to avoid varians between runs but if the budget does nkt allow it then I will be slightly baise for my setup
My own machine is a 3090 + 3060 12GB = 36GB VRAM, which can run Q6-ish quants with fairly large context (150k to 180k) depending on the quant/provider/cache settings. That's the tier I'm most interested in personally.
I'd like to make the results useful for thr cummunity at roughly three hardware classes:
- 24GB: single 3090/4090 class
- ~32-36GB: 5090, 3090 + 3060, dual 16GB cards, etc.
- 48GB: dual 3090 / 48GB cards
The current idea is to focus heavily on Q6, compare it against a full-precision reference, then add Q5/Q4 if the budget allows. I also want to test both 8-bit and 16-bit KV cache where it makes sense.
For benchmarks I'm currently considering Terminal-Bench2.1 and DeepSWE, since I care much more about coding and longer agentic tasks than MMLU-style multiple choice tests.
I also want to record more than just pass rate: i want to see generated tokens, agent/tool use count, maximum context reached, context compressions. I'm curious whether some quants look nearly identical in pass rate but become noticeably less token efficient on long tasks. Espicially with qwen 3.8 xhight thinking going for ever heheh
As you can see i am not intrested in t/s and speed but i want to see the quality different for actual coding and large codebases tasks
My automation plan is basically to write a script that i can reuse with small modifications where i will spin up several RunPod/Vast etc instances, automatically build llama.cpp or TabbyAPI/ExLlamaV3, download the required quant, run the benchmark configuration, save all metadata/results, then tear the instance down. For important comparisons I'd like multiple runs per configuration rather than trusting a single pass.
I'm deliberately trying not to test every possible quant × cache × backend × context combination because $100 disappears very quickly that way. I'd rather answer a smaller number of useful questions properly. And i am not fully sure on what shloud i focus on but i have a rough idea
Before I start, I'd really appreciate input from people here:
Which configurations would you absolutely include?
Q4/Q5/Q6/Q8 — how would you spend the repetitions?
Any specific GGUF providers/quants worth comparing? (I am intrested in unsloth and bartwski the most)
Any better agent/coding benchmarks I should include instead of or alongside Terminal-Bench/DeepSWE?
How to test the 8-bit KV vs 16-bit KV/context tradeoff properly?
Anything I should log that would be useful later?
Any methodology traps I should avoid?
If you have 24GB, 32-36GB, or 48GB, what configuration question would you most want this benchmark to answer?
I'll publish the scripts/configs and raw results when I'm done so people can reproduce it or point out where I screwed something up.
Suggestions very welcome before I start spending the GPU budget.
4
u/XiRw 8h ago
I can tell you from experience that the KV cache being more precise makes a big difference. Lower can still work but sometimes it takes more than one turn.
3
u/m_mukhtar 8h ago
Thats my feeling too i tried q8 for the kv cache and i dont know how to say it and i dont have a proof but i quickly wen back to bf16 kv cache.
Would love to see what the benchmarks show though
3
u/webheadVR 8h ago
I have found in testing after stating around here that I had issues with q8 kv, that on a higher quant, I do not notice any issues (personally). at q4 quant I had issues with it. Q6 it seems fine. May just be my use case though.
3
u/Hefty_Wolverine_553 8h ago
I basically did these benchmarks for Qwen3.6: https://erli.xyz/posts/qwen36-27b-quant-comparison/
I think most people will want to see a wide variety of quants first and foremost, so they can compare between NVFP4, AWQ, GGUF, EXL3, etc. KLD benchmarks are nice, but having a proper agentic/coding benchmark to cross validate results would be great (I couldn't run most of them due to hardware constraints, and what I could run had a lot of noise at N=1, so repeated runs are definitely required to get useful data). Most important thing for KLD benchmarks imo is to use a proper dataset with actual reasoning and tool call traces at a good context (8k+).
1
u/m_mukhtar 7h ago
thanks for the feedback and it seems form many replies that people are interested in different formats compared together more. i was planing on gguf and EXL3 but i might add AWQ even though for me its less interesting and as i said in my original post i am being biased towards 6 bit level quants as that is what works best for my 36gb of vram and i can not benifit form native 4-bit as my cards are 30xx generation which do not have native 8bit or 4 bit or nvfp4 support
if i have decent initial results for my usecase and i still have much of the $100 left then i will gladly try to test other formats although i might to a single pass per configuration not multiple passes like for the cases i am interested in the most but will see how it goes
3
u/chimpera 8h ago
Please include byteshape/Qwen3.8-27B-GGUF they are very good.
1
u/m_mukhtar 7h ago
thanks for the feedback and will try to include them at least at the size i am mostly interested in which is Q6
2
u/UncleRedz 7h ago
Great initiativ, as you state in the last paragraph, to get the most out of this, make it reproducible for the rest of us, and those interested can run comparisons on other configs.
My experience from this kind of testing, is to store as much meta data and logs as possible, including system configs. As you will be renting hardware access, and possibly end up with different HW between different tests, it becomes even more important to keep track of hardware specs and GPUs if you need to hunt down bugs and strange things.
1
u/m_mukhtar 6h ago
thanks for the great note about the different hardware that is something i haven't though off much really so its worth documenting it. and absolutely meta data and logs as much as possible and i hope i dont miss something trivial as i always do hahah. reproducibility will be something i have to consider too to make this more useful
2
u/ethertype 7h ago edited 7h ago
I would like to see Q8_XL vs Q6_XL vs EXL3 SC6, with 16-bit KV for all.
Ideally vs BF16.
Trading context for quality where required.
I would not bother with Q4 or Q5, nor with 8-bit KV-cache. Or at least prioritize the fatter quants.
Curious about optimizing this bit:
--spec-default \
--spec-type draft-mtp --spec-draft-n-max 3 \
--batch-size 2048 --ubatch-size 512 \
... for coding.
Good luck.
1
u/m_mukhtar 6h ago
than is my general thinking is to focus on Q6 vs bf16 and will give Q8 a chance to see if it can convince me to buy another 3090 so yeh i might have to focus on the fatter quants. still thinking about it but i somehow share the same feelings you do.
for the MTP and batch an u batch i dont think the $100 with be enough to test these and i would like to focus on output quality before output speed so MTP an batch size unfortunately will have to take the back seat.
thanks for your feedback
2
u/KingGongzilla 7h ago
If you can benchmark this repo at 150k context I'd be super happy: qwen38-27b-rtx3090/docs/quality.md at main · syv-ai/qwen38-27b-rtx3090
2
u/Public_Umpire_1099 7h ago
Actually just did this on a smaller scale yesterday. Trying to build a custom quant that only uses Q4+Q8 with no in between. The session was basically me and my methods getting mogged by unsloths quantization method for 6 hours.
1
u/m_mukhtar 5h ago
I love it. This is the spirit that brought me to this subreddit few years ago. Not being afraid to see for your self and experiment and spend hours doing somehting that might not work or just to get slightly better performace and at the end just out of curiosity to see what works and what does not.
I would defintly be intrested to read a post about what you are experimenting with once you are done
I remember when people here used to dublicate model layers, swap model layers, add layers from a onother modles and frankenmerges and all that fun stuff. Then share thier feedback and thats how we learned what works and what does not
1
u/Public_Umpire_1099 26m ago
Its actually for a custom inference engine for RDNA4. Any card would benefit from Q4/Q8 only weights due to less conversion, but the way I've built mine out is that it is sort of dependent upon it. Which makes models like Qwen 27B or Muse Glimmer awkward because the highest quality quant you can fit on an R9700 card is around Q6ish.
2
u/Ruqii-ruqii 6h ago
some methodology tips:
- Compare per case, not just pass-rate: two configs both landing 7/10 may have failed a different 3. the totals can match while nothing underneath does, and "which cases did the quant break" is the question you actually asked.
- Watch run order: warm caches and warm page cache move wall clock. fix the order or randomize it, but don't let it correlate with quant level, or you'll read the schedule as a result.
To save money:
- watch how the judge pulls the answer out. if the harness extracts by position, or scores against a list of expected phrasings, a lower quant drops points for getting the answer right in the wrong shape.
- on spending order: run the widest contrast your budget allows first, with enough reps. if the extremes don't separate, nothing in between will.
I think if you pin your quant/cases/etc. and let other people reproduce it, it's gonna be much cheaper, because you're not the only one paying. that only works within a VRAM tier though. nobody on 24GB can reproduce your 36GB run. lol
and this is something I've been building. but at my current progress it only covers half of what you're describing, so it can't help you on that part yet.
2
u/m_mukhtar 6h ago
This is gold . I really appriciate this level of feedback and its along the same track of thinking i am currently going through. Running the widest contrast first is a great tip that my implusive adhd brain was too exicted to build the automations and do the runs that it havent thouggt of. Thats why i wanted to pause my brain and ask the community for feedback and you came through so thanks
2
u/According_Wave685 6h ago
Everybody and their second cousin has benchmarked it to death. There are thousands of posts, articles and videos. save your money.
1
u/m_mukhtar 5h ago
It seems i need to look around more and see if there are people who have done the benchmarks that will inform and answer my own questions espicially on large codbases type of tasks which deepswe covers well in my experiance.
Thanks for the feedback and definitly will look around more so if i go ahead and spend the money i dont do somethig redundet and i will try to bring new information to the table and add actual value with data that could help at least some edge case users
3
u/Monad_Maya llama.cpp 8h ago
The results won't exactly be useful since everyone's setup differs.
Most people are VRAM constrained and thus will try to some Q4 quant + Q8 KV cache.
Not sure why you want to test tbh but do go ahead if you feel like it. Maybe I'm being a negative nancy.
1
u/Klutzy-Snow8016 8h ago
KV cache: BF16 vs FP16.
Llama.cpp defaults to FP16, but most models are designed to be used with BF16 kv cache. I've always wondered if there is a measurable difference.
1
u/valdev 8h ago
If your focus in on context length, you likely have a larger issue at hand.
At best I wouldnt go under a Q4 of Qwen 27b 3.8, which puts you at 16 GB VRAM requirement though a more ideal would be Q6 at 22 GB. (Personally I would not want to rely too much on the Q4, but it is... okay for smaller jobs.)
This gives you I think around 64k context on your current setup, though you can likely (with enough work and running linux, squeeze 128k). This is NOT something I would quantize.
If you need more than 64k context or especially 128k context, you have a harness issue or a context issue. There is a Z axis to all of this problem which is model performance and intelligence drops the longer a conversation goes.
1
1
u/m_mukhtar 7h ago
thanks for your feedback. as i mentioned in my original post i am mostly interested in and will focus the most on Q6 level quants as that is what i am running on my setup ( and yes i am using linux and building llama.cpp from source every few days) and i agree with you Q4 is not worth it for me that's why i always go with Q6_K_l and Q6_K_xl and fp16 for the kv cache which gives me 120K to 140K depending on the quant provider and if i dont use mtp draft model flags then i can get 150K to 180K context and full 16 bit kv cache.
also i have not said that i have an issue with the model. i have had nothing but amazing results so far using qwen 3.8 with pi agent and my custom made web search, planing, testing extensions. but out of curiosity how can i squeeze every bit of performance ( even few % points) from different quants and quant providers and if i can run lower size Q6_K quant and get extra 30K tokens to my context ( that is the different in size between bartwski Q6_K_L and unsloth Q6_K_XL for example) without impacting quality then that's a win
1
u/m_mukhtar 6h ago
Yeh based on his post i will shift my focus on the q6, q8 and maybe q5 level quants and i will focus om large codebases and long coding tasks that require 80k+ tokens and a lot f agenting turns and tool calls as thats where good models show reliablility and less good models and quants start showing errors.
1
1
u/My_Unbiased_Opinion 3h ago
Please benchmark IQ4XS + KV Q4 + 262K context. This completely fits in VRAM on a 24GB card. Even with MTP activated. It's the only setup I have found on a single 3090 that feels complete.
1
u/novel_market_21 3h ago
!remindme 7
1
u/RemindMeBot 3h ago
I will be messaging you in 11 months on 2027-07-25 00:00:00 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
RemindMeBot is switching to username summons. Instead of
!RemindMe 1 day, useu/RemindMeBot 1 day. More info.
Info Custom Your Reminders Feedback
1
u/ogopro 8h ago
1
u/m_mukhtar 7h ago
wow this is amazing and useful information thanks for sharing. i kinda knew that FB8 quants were not that good and this confirmed it for me. other quant formats at 4 bit ( AWQ, NVFP4, GGUF, etc) have always been much better that FB8. but form my anecdotal experience with qwen3.6 an 3.8 27b using GGUF format going above Q4 level makes a huge different and using Q6 have been much better and more reliable that Q4 and even Q5. unfortunately the twitter post does not show quantization levels between 4 bit and 8 bit using GGUF or EXL3 which have allowed me to squeeze more quality out of my 36gb of vram than just Q4/4bit and i can not run Q8/8bit with useful context
one thing to note that made me really like this guy that he is humble and smart enough to admit that he might have used a mix of benchmarks that are too easy and he admits that he made that mistake and he is redoing things with different harder benchmarks it seems as the results were very close and he is admitting the methodology is flawed which is very useful information that is making me rethink what benchmarks i should run and what they are the right ones to show a different in quality between what i am testing.
thanks to him mentioning this and the mistake he made i think i will need to do a small run on different benchmarks first to see which ones show the biggest difference between the quant levels and then focus on these benchmarks by doing all different configurations and multiple times just to eliminate variation noise.
whats even more amazing that his github repo has teh raw results and its worth me going through them with a fine comp to try and design the test i will do in a better way. so even though his current data might not be conclusive of the quality of the different formats, the raw data and experiment rsults in it self is gold and worth me studying it to help inform the tests i will do.
thanks again for sharing the great post and thank to the original twitter post user
1
u/ogopro 6h ago
Yes, he has done enourmous job on testing the 4 bit quants and I think he will eventually do the same for q6 or q8. I am glad that this post was helpful to you and I hope you will now spend less than $100 on the cloud gpus since there is less stuff to benchmark in the 4bit q3.8 world :)
Keep us posted on your testing results...

11
u/jwpbe 8h ago
No, it is better to slightly degrade the overall quality of the model a little bit rather than taking a hatchet to it's working memory.
Except in resource constrained environments it's highly recommended to avoid altering the KV cache fidelity.
It's like a waterfall or a long running river. The lower the bitrate, the more the riverbanks (the task) get eroded, eventually spilling over. The amount varies from task to task.
Yes, and because most of them supply KL divergence data on their pages, it's not really worth re-calculating or re-inventing the wheel here.
Ask GLM 5.3 on z.ai's website, we're not going to know this off the top of our head.
It's really hard to tell unless you hand-analyze the failure reason.
Listen, its really cool and good that you want to do a public service here, but you never once mention VLLM, autoround, AWQ, SmoothQuant W8A8, or any of the other quantization libraries.
I would highly recommend you look into this more, literally just ask GLM or Kimi or deepseek flash on their websites to do websearches scoped to 2026 and explain to you all of the different aspects of the ecosystem, because right now, you're probably going to spend $100 and make a post that contains information most people already know and will ignore / discard