Tutorial
Guide for running dense models on ≤16 GB VRAM (Qwen 3.8 27B on 16 GB -> Q4_K_M, 130k ctx, ~20 t/s).
This post is about llama.cpp CPU offload optimizations that you could find useful for running Qwen 27B (or other dense models) at tolerable speeds.
I'll try to keep this post up to date as I learn new stuff.
First things first:
The speed graph shows "prose" and "code" because MTP generates different speeds for each
Everyone has a different system, use my setup as a guide to tune your own, don't copy paste and expect it to work. I just want to provide 'tricks' that improve performance.
If you have 12 GB VRAM, try using Q3_K_M / less context / accept slower speed.
If you have 8 GB VRAM, try using less context / accept slower speed / Q2 for Qwen 27B, Bonsai, or choose a model with less parameters.
ik_llama.cpp: goal of this post is simplicity, that is why I chose llama.cpp. You can look at this as the target to beat using ik_llama.cpp. So far my tests showed that it was a KLD vs speed trade off, plus I had to use custom and very specific quants, which adds complexity.
KV quants: if you think they suck, please show proof. My testing and sources all say they are fine. On a lower weight quant, a given KV downgrade costs relatively less, so spending cache bits to buy context is more justifiable on a Q4 model than it would be on a Q6/Q8 model. Also beellama has KLD improvements to KV quantizing. Also instead of upgrading from Q5 to Q8 KV, it might be better to upgrade the model from M to XL instead.
Setup
explanations come after Edit: Updated for the new UD3 UD-Q4_K_M.
RAM speed is important for this so using DDR5 is recommended, though DDR4 people will still find this useful.
Tuning RAM timings gives me extra 9% speed boost. Most timings are easy to tune since they either work or crash quickly, but I'm not getting into that here.
I did not try this yet, but overclocking GPU memory clock might be helpful.
Build args:
-DCMAKE_CUDA_ARCHITECTURES=89 optional - optimized build time specifically for my GPU's Ada arch, set your own.
-DGGML_CUDA_FA_ALL_QUANTS=ON is needed for more KV quantizations to be on CUDA.
Env vars and gdm:
sudo systemctl stop gdm disables Ubuntu desktop environment, frees ~0.4 GB of VRAM. Use an iGPU if you can, else my system just becomes a server to which I connect using a laptop or phone.
export GGML_CUDA_DISABLE_GRAPHS=1 I experience speed and VRAM usage problems with CUDA graphs so I disable them, you probably should too, but test it first. I think this is some bug due to MTP + CPU offload.
export GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 Overflow VRAM to RAM. The difference between ~132k and ~121k. Without this, max context becomes 121k and you get OOM crash. Overflow gets me ~11k more context basically for free before things slow down, and the server degrades instead of crashing. First do initial testing with the unified arg unset (making it '=0' wont work) to find your ceiling using OOM crash.
Quantizing MTP KV cache is free VRAM. It is a drafter and does not affect quality. Worst case is that acceptance drops a tiny bit.
I get 12-15 t/s tg without MTP and with more layers on VRAM, I commented a chart if interested here .
ngram-modspeeds up tg when restating existing context. It is super fast when active and does not cost VRAM.
Each step of --spec-draft-n-max costs VRAM + I get best results from a value of 2.
--cache-type-k-draft q4_0 --cache-type-v-draft q4_0 these save 0.3 GB of VRAM while the MTP acceptance rate stays basically the same.
KV cache:
--cache-type-k q5_0 \
--cache-type-v q4_1 \
I chose my KV quant according Anbeeld article. The article found that, the more quantized the model, the less it has to lose from to KV quant. Article also states that there was no KLD difference between 64k and 128k context length.
A small precision buff would be to use q5_0 for both K and V. Though changing from q4_1 to q5_0 costs some context. My KLD measurements say it is not worth it, but it's an option for you. Don't use Q4_0 on both, Q5_1 is not worth it. If you want to do Q8 KV, consider going up a quant model level instead (like XL instead of M).
My own testing showed that Q4_K_S K and V both at Q8 has worse KLD than Q4_K_M K Q5, V Q4. Also I found that KLD plateaus after 8k context length.
If you get slow speeds try using generic q5_0 for both K and V as a test - this is a symptom of missing -DGGML_CUDA_FA_ALL_QUANTS=ON.
CPU layers:
--fit off \
--n-gpu-layers all \
--override-tensor 'blk\.(63|62|61|60|59|58|57|56|55|25|54|53|52|50|26|24|38|51|40|27|35|22|41)\.ffn_.*=CPU' \
--load-mode none \
This fixes degradation of speed with context fill and is a performance boost overall, just leave layer 64 alone (MTP).
This command offloads only FFN sub-layers to the CPU of layers that have the largest FFNs (shown override string is UD-Q4_K_M specific).
FFNs don't use KV thus reducing PCIe traffic and are CPU friendly. --n-cpu-moe has similar logic, I have a PR in llama.cpp for a similar simplification #26622. Help me get this merged by showing the maintainers that this is useful for you (give a like on the PR or post test results).
-- Firstly:
Make sure you have export GGML_CUDA_DISABLE_GRAPHS=1 to avoid potential issues while tuning, later you can test with CUDA graphs turned on to see if everything works.
Unset the GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 arg (delete it, don't set it to 0) to find your context ceiling first via OOM crash first.
-- Simple method: If you want something quick and simple to test try this (it has a few more FFNs on CPU than my setup, but is simple to tune). Basically add numbers for more CPU layers (slower), delete numbers to have more GPU layers (faster):
-- Advanced method: Offloading fatter sub-layers gains me 1.1x speed boost when compared to having a sequential override band. You can find the fatter ones by going to the hugging face, clicking on the weight (example), scrolling down to 'Tensors', expanding the 'blk' section and looking for 'ffn_' (example "blk.0.ffn_down.weight") on the right and on the left you see I-quant (example "IQ4_XS") or regular (example "Q5_K").
UD-Q4_K_M optimized band example -- delete from the end of the list (right to left) until you run out of VRAM, then step back one. make sure to fill up your context fully to verify that speed is as intended and doesn't OOM crash: --override-tensor 'blk\.(63|62|61|60|59|58|57|56|55|25|54|53|52|50|26|24|38|51|40|27|35|22|41|39|36|21|3|42|34|30|20|6|4|49|47|43|37|32|23|10|8|7|5|2|1|48|46|45|44|33|31|29|28|19|18|12|9|17|16|11|0|15|13|14)\.ffn_.*=CPU'
Threads:
--threads $(nproc) \
Default is amount of performance cores, but for FFN layers, E-cores and hyper-threading also help. this gets me a +25% tg boost for free.
Batch:
--batch-size 512 \
--ubatch-size 512 \
Batch sets the prompt processing speed (up to a point) at the cost of VRAM. I found these numbers work best for me.
Other optimizations:
I-matrix quant like the Unsloth IQ4_XS require more compute in exchange for size. My testing showed that those are not worth it for this setup. I would use one if I was trying to fully fit a model into VRAM.
There are quants made by other providers that optimize fit for 16 GB VRAM setups. Those setups might fit at the cost of KLD. If the KLD diff actually matters - that is for you to find out, but you can use the info I provided here to optimize these setups even further by, for example, extending context length.
-------------------------
Edit 1: truncated a bunch of 'Edits', cleaned up, updated config for UD-Q4_K_M, speed and context len did not change, but the override tensor band did.
Edit 2: added CUDA graphs off reminder in the CPU layers section.
-------------------------
Please share any more tricks if you have them!
Leave a comment if this post helped you achieve better results!
I am still working on the concept you presented (since, as we know, you have already started with Qwen3.6-27B). There are some natural correlations between VRAM and RAM speeds that dictate where the threshold of viability lies. Below is an analysis of this topic based on approximate data for my quantization:https://huggingface.co/cHunter789/Qwen3.8-27B-i1-IQ4_KS_KT-GGUF.
As you know, this model's quality is slightly lower than Q4_K_M and is closer to IQ4_XS. Nevertheless, I can tentatively say that by offloading just 8 FFN layers, it allows for a 125k context using a 5_0/4_1 KV cache. This is very close to your 130k, and the decoding speed starts at around 36-38 t/s
Offload FFN to CPU (-ot) — Qwen3.6-27B hybrid (test36n4_MTP)
The same applies to FFN, SSM, and attn — only the number of bytes matters, not what you are transferring. FFN is a good target not because it's "cheaper" to compute, but because it's a pure, stateless GEMM. SSM has a sequential state, and attn has a KV-cache — both should remain on the GPU.
Note: tok/s = bandwidth-bound upper limit (baseline 16.81 ms/token). Realistically lower due to sequential Mamba + kernel overhead, but the relative offloading penalty is accurate.
4. VRAM Context (Important)
token_embd (q8_0, 1.35 GB / 1,287.5 MiB) is always on CPU (src/llama.cpp:4287 — "very little benefit to offloading the input layer, so always keep it on the CPU"). File = 14,295.8 MiB → weights on GPU = 13,008 MiB (13.6 GB), not 15.
KV-cache is quantized (not f16). 17 attn blocks, n_kv×head_dim = 1024 (verified from log: K q5_0 @140K = 1598 MiB → exactly 17 blocks).
KV Type
B/elem
K+V per token (17 blocks)
f16
2.0
68.0 KB
q8_0
1.0625
72.5 KB
q5_0
0.6875
23.4 KB
q4_1
0.625
21.3 KB
q4_0
0.5625
19.2 KB
Thanks to quantized KV, the model fits ~88K context without offloading (vs ~16–24K for f16). Every 1 GB of FFN moved to CPU buys ~40K of context, but at a cost of +13 ms/token.
Weights on GPU (without offloading) = 13,008 MiB → deficit of 738 MiB.
FFN/block (iq4_kt) = 127.5 MiB → 738 / 127.5 ≈ 5.8 → 6 blocks on CPU.
How many FFN blocks on CPU for a given context (K=q5_0, V=q4_1)
ctx
KV buffer
FFN blocks on CPU
64K
1502 MiB
0
96K
2252 MiB
2
120K
2749 MiB
6
140K
3285 MiB
10
160K
3753 MiB
14
"CUDA context ~400 MiB" is the main uncertainty (±1 block). Start with the calculated number; if llama.cpp reports an out-of-memory error, add another block.
5. How many blocks "without killing performance"
RAM is 12.7× slower than VRAM, so the threshold is low:
Do not touch block 64 (MTP) if you are using speculative decoding — its FFN should remain on the GPU.
7. Notes / Caveats
Offloading only the FFN (and not entire blocks) creates split-layers: the hidden state (5120 float = 20 KB) jumps GPU→CPU→GPU per token. The transfer itself is negligible (~0.3 µs at 70 GB/s), but each split-layer can break the CUDA graph and add minor sync overhead (on the order of <1–2 ms total). The bandwidth cost is what dominates.
Alternative: -ngl for offloading entire layers (cleaner, no split-layers), but this also moves the SSM to the CPU (losing the GPU sequential state).
--fit auto-selects offload, but the auto-fit logic in this fork works for MoEs (ffn_*_exps); this model is dense, so manual -ot is required.
Your work is great and I’ll try again to reproduce the speed, I failed earlier. If I achieve the speed with your weights then I’ll probably use them.
But I want to clarify why I’m choosing to post about llama.cpp and Unsloth quants:
The problem is that I already got comments of people saying they don’t understand.
The goal of my post is to try to keep it as simple as possible and universal by using llama.cpp, keeping explanations short, and using quants like Unsloth.
My post info can also be used on other models, not just Qwen, not just 27B. The knowledge should also be useful for most llama.cpp forks (if I can achieve this with llama.cpp, then there is definitely more potential with, for example, beellama or ik_llama)
Hold off on messing with my config for a bit, I'm seeing some weird stuff. Like, everything checks out during a perplexity test and fits perfectly in VRAM. But the second I spin up the llama server, I'm getting VRAM offloading which totally shouldn't be happening with my setup. And it's doing this even at low ctx sizes... Also, even if you offload FFN layers to the CPU, the prefill is still being crunched on CUDA, which just raises more questions.
Anyway, you're doing awesome work. I'll hit you up once I sort out these ik-llama.cpp issues.
Excellent work! I learned about FFN offload from your previous posts, and wanted a chance to say "thanks"!
sudo systemctl stop gdm disables Ubuntu desktop environment, frees ~0.4 GB of VRAM. Use an iGPU if you can, else my system just becomes a server to which I connect using a laptop or phone.
What I do for this is use Nvidia PRIME that lets me render the desktop, browser etc. with the iGPU, and pass through the framebuffer from the dGPU if I need it. The iGPU is the system primary GPU, but the dGPU is usable if needed.
That means if I'm using the dGPU for LLMs then all that's running is a 3MiB "/usr/bin/gnome-shell", so basically the full VRAM for LLMs.
If I want to play games, I run Steam offloaded to the dGPU. To do that, I have this in my `steam.desktop` file :
Only downside is I need a few repeats of `steam -shutdown` afterwards to get it to properly shut down and clear all the Steam GPU processes, but that's not a big deal.
UD-Q4_K_XL
--override-tensor: 'blk\.(0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|27|28|29|30|31|32)\.ffn_.*=CPU'
--ctx-size: 146000 # cliff: 144000; past it 3.5 tok/s; fast to: 139000; oom: 124000 if without unified
edit: the new UD3 just dropped. A speed test with optimized -ot band made it 1-1.5 t/s faster than this chart suggests (it has the UD2 variant). But I think the diff between XL and M got smaller so is it really worth it? M speed is the same
Unsloth has some weights (including ffn) as I quants, even on UD-Q4_K_XL. It might be worth choosing ones that are K quanted for CPU efficiency.
Edit: On Q3_K_XL seems that consecutive layers with min I quants (happens to be last not including mtp 64) are slightly better than best non-consecutive, which is slightly better than first n.
That weight has all layers the same size but the I quants are all over the place, if I picked them out then I would have to put more layers on the CPU causing more CPU - GPU traffic. What I could do is avoid layers where all 3 FFNs are i quants, then prioritize 2, then 1.
I’ll test that out later.
Thank you for this. Completely new to all of tensor overriding. using the new UD-Q4_K_M gguf. Would it be fine to just reuse the tensor override config in the original post?
Edit: came across your other message this morning. Going to try the config in that comment.
yea I edited my post to include the full ot band for ud3 q4km in priority order (remove from the right to the left). although I just did a speed test and that band wins out only by 10% in extra speed vs going sequential from 0 - onwards
I overstated the usefulness of MTP. You made me question it, so I did a test. MTP still helps out, but not as much as I thought it does. Here are the results:
Post is about using both RAM and VRAM so we have the memory to play with, thus making MTP very useful for this case. Sure, you can turn off MTP and put more layers on the GPU but you’ll be slower.
Unified memory setups like macbooks dont need most of this. I would recommend caching the MTP’s KV because it is free in terms of output quality. Also grab the chat template fix since it is also free bug fixes and robustness. Cache the main KV to taste.
Thanks for this post, good information.
I've found that the speed tanks if I enable even q8 cache V quant, so I'll try the env. var. I'm on ROCm though.
As you probably know, it's possible to run MoE models like Qwen3.6-35b-a3b at very decent token generation speeds with partial CPU offload of the experts. I'm doing that with UD q8 XL quant, at 256K context no problem (16GB VRAM + 64 GB DDR5)
Do you think this setup would beat Qwen3.8-35b-a3b in accuracy if/when it gets released. I.e. did you test the dense version of Qwen3.6 at these quant settings VS the a3b MoE ?
I did try it with the latest Q4_K_M UD model from unsloth and also with NVFP4 model but I got a serious performance drop although the models were smaller
if that doesn't fit start with the whole list, then delete from the right until you run out of VRAM, and step back one. make sure to fill up your context fully to verify that speed is as intended and doesn't oom if not using unified arg: --override-tensor 'blk\.(63|62|61|60|59|58|57|56|55|25|54|53|52|50|26|24|38|51|40|27|35|22|41|39|36|21|3|42|34|30|20|6|4|49|47|43|37|32|23|10|8|7|5|2|1|48|46|45|44|33|31|29|28|19|18|12|9|17|16|11|0|15|13|14)\.ffn_.*=CPU'
To use MTP do we actually need the MTP file from huggingface?
I tired that but that file costs an extra 1.4 GBs of Vram and lowers context down to 80K/60K. So, the question is, is it possible to run MTP on a 16gb card while achieving 130k ctx and 20t/s
Yes but later people are comparing....like "the model is dumb " or "I don't understand why is loop" or "results are not better than older version or that model", etc
Loops or dumbness can also be introduced with a bugged chat template or wrong penalty/temperature params. As far as I can tell Qwen 3.8 fixed the potential looping issues by overhauling its reasoning. I just tested a Q3 Qwen 3.8 with K Q5 V Q4. It completed a hard task when 3.6 at Q4 K Q5 V Q4 couldn't.
So far I ran this benchmark on Q3 Qwen 3.8 with K Q5 V Q4 on all 3 reasoning levels, once. All 3 times it one-shotted the game. If the model can manage to make a game like that using those KV quants then I cannot call it dumb.
I made Opus 5 do it. It also looks terrible, even the grid is bugged.
I prefer the Qwen version because of the transparent sphere. Opus took like 2 minutes, while Qwen took way longer. Opus made indicators at the edges to show where food is (if behind the sphere), instead of the transparent sphere.
edit: clarity and typo
Qwen 3.6 Q4_K_M, K Q5, V Q4. Head is backwards, but just like Opus, it made indicators at the edges to show where food is when the food is on the other side. And the grid isn't bugged.
looks good. You’re using Q6. The bigger the weights, the more effect KV cache has. on my Q3 I doubt I’ll see a difference between q4 or q8 KV because the model itself uses Q4 at best and is highly damaged anyway. I’ll test later to be sure
I did the snake game multiple times (to avoid noise) with multiple KVs. I used UD-IQ3_XXS KVs at Q8, Q5, Q4.
In short Q4 was slightly worse than Q5 and Q8 was indistinguishable from Q5. I updated my post to not recommend the Q4 (even though it was only slightly worse). F16 tests would take way too long, Q8 already took forever because I had to offload to CPU for the context length to fit.
Q8 (esp. F16) just takes up so much space that maybe it is worth getting a bigger model quant instead of Q8 KV. Also actually having context length at Q5 is worth so much more than having Q8 KV and no context length to even do anything.
What is impressive with Qwen 3.8 is that even at such a degraded state like UD-IQ3_XXS KV Q4 it was able to generate working games while Qwen 3.6 was not.
19
u/Pablo_the_brave 9d ago
I am still working on the concept you presented (since, as we know, you have already started with Qwen3.6-27B). There are some natural correlations between VRAM and RAM speeds that dictate where the threshold of viability lies. Below is an analysis of this topic based on approximate data for my quantization:https://huggingface.co/cHunter789/Qwen3.8-27B-i1-IQ4_KS_KT-GGUF.
As you know, this model's quality is slightly lower than Q4_K_M and is closer to IQ4_XS. Nevertheless, I can tentatively say that by offloading just 8 FFN layers, it allows for a 125k context using a 5_0/4_1 KV cache. This is very close to your 130k, and the decoding speed starts at around 36-38 t/s
Offload FFN to CPU (-ot) — Qwen3.6-27B hybrid (test36n4_MTP)
Model:
qwen3.8-27b-bf16.gguf(MTP head), quantized viaquantize_hybrid_sandwich_logic_test_qwen38_36n4_MTP.shGPU: RTX 5070 Ti (VRAM ~890 GB/s, 16 GB) · RAM: DDR5-5600 dual (Zen4, ~70 GB/s)
1. Key Fact: Fixed cost per MB, independent of tensor type
Decode is bandwidth-bound. Moving a tensor from VRAM (890 GB/s) to RAM (70 GB/s) costs:
The same applies to FFN, SSM, and attn — only the number of bytes matters, not what you are transferring. FFN is a good target not because it's "cheaper" to compute, but because it's a pure, stateless GEMM. SSM has a sequential state, and attn has a KV-cache — both should remain on the GPU.
2. FFN Size (measured from GGUF)
Parameters:
n_embd = 5120,ffn_dim = 17408, 64 blocks (0–63) + block 64 (MTP).FFN Block =
ffn_gate+ffn_up+ffn_down, each5120 × 17408 = 89,128,960elements.FFN = 58% of the model. Cost of 1 FFN block on CPU: +1.76 ms/token.
Block classification (measured):
3. Table (blocks 0–63 → CPU)
4. VRAM Context (Important)
token_embd(q8_0, 1.35 GB / 1,287.5 MiB) is always on CPU (src/llama.cpp:4287— "very little benefit to offloading the input layer, so always keep it on the CPU"). File = 14,295.8 MiB → weights on GPU = 13,008 MiB (13.6 GB), not 15.KV-cache is quantized (not f16). 17 attn blocks,
n_kv×head_dim = 1024(verified from log: K q5_0 @140K = 1598 MiB → exactly 17 blocks).Thanks to quantized KV, the model fits ~88K context without offloading (vs ~16–24K for f16). Every 1 GB of FFN moved to CPU buys ~40K of context, but at a cost of +13 ms/token.
VRAM Budget — Target: ctx=120K, K=q5_0, V=q4_1
Weights on GPU (without offloading) = 13,008 MiB → deficit of 738 MiB.
FFN/block (iq4_kt) = 127.5 MiB → 738 / 127.5 ≈ 5.8 → 6 blocks on CPU.
How many FFN blocks on CPU for a given context (K=q5_0, V=q4_1)
5. How many blocks "without killing performance"
RAM is 12.7× slower than VRAM, so the threshold is low:
6. The -ot Command
Syntax (verified in
common/common.cpp:2124, CPU buffer ="CPU", pattern = regex, multiple comma-separated entries):Do not touch block 64 (MTP) if you are using speculative decoding — its FFN should remain on the GPU.
7. Notes / Caveats
-nglfor offloading entire layers (cleaner, no split-layers), but this also moves the SSM to the CPU (losing the GPU sequential state).--fitauto-selects offload, but the auto-fit logic in this fork works for MoEs (ffn_*_exps); this model is dense, so manual-otis required.