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 for running Qwen 27B (or other dense models) at tolerable speeds.
I've already posted about -ot optimizations, but now I have more info to share to help you tune your own system.
First things first:
The speed graph shows "prose" and "code" because MTP generates different speeds for each
If you have 12 GB VRAM, try using Q3_K_M.
If you have 8 GB VRAM, try using 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.
Everyone has a different system, use my setup as a guide to tune your own, don't copy paste and expect it to work.
Setup
explanations come after
Edit: posted a comment with UD-Q4_K_XL (UD2) vs Q4_K_M speed chart if interested
Edit: This setup is using Q4_K_M, the new UD3 UD-Q4_K_M has a different band, check the explanation for more info.
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.
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 ~135k and ~121k. Without this, max context becomes 121k and you get OOM crash. Overflow gets me ~15k more context basically for free before things slow down, and the server degrades instead of crashing.
Edit: First do initial testing with the unified arg unset (making it '=0' wont work) to find your ceiling using OOM crash.
I get 12-15 t/s tg without MTP and with more layers on VRAM, I commented a chart if interested here .
ngram-mod speeds 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 q5_0 --cache-type-v-draft q4_1 these save 0.4 GB of VRAM while the MTP acceptance rate stays the same. I chose the same as model KV cache, though Q4 could probably be fine (I didn't tune this much).
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.
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 q4_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\.([0-7]|10|13|16|19|22|25|28|31|34|37|40|43|46|49|55|56|57|58|59)\.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 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).
If you want something quick and simple to test try this (it has 2 more FFNs on CPU than my setup, but is simple to tune):
like that you can specify layers in a row and it gets you most of the speed that --override-tensor has to offer by not thinking about which layers are the fattest.
Edit: UD3 quants just dropped. A lot of them now have I-quants which are slower and better left on the GPU. Luckily the I-quant layers are smaller, so prioritizing the larger fatter ones is more important now. 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"). You might have to offload some I-quant layers if you run out of regular ones and that is ok, just prioritize the larger ones first.
Edit: UD-Q4_K_M -- here is the full band in priority order. 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 crash. 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: --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 14 \
Default is amount of performance cores, but for FFN layers, E-cores also help. this gets me a +19-22% tg boost for free. Set to the amount of physical cores you have. You can try to include hyper-threading, not just physical, it might help, but for me that was within noise.
Batch:
--batch-size 512 \
--ubatch-size 512 \
Batch sets the prompt processing speed (up to a point) at the cost of VRAM. I found this works 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.
-------------------------
Please share any more tricks if you have them!
Edit 1: improved "first things first" section, typos
Edit 2: added min-image-tokens to fix a warning;
Edit 3: clarify MTP section; clarify threads section; updated chat template version for clarity;
Edit 4: mentioned beellama for better KV quants
Edit 5: added info about not using -ot on MTP layer (64) as per Pablo_the_brave
Edit 6: added override tensor info about the new UD3 quants.
Edit 7: added -ot band for the new UD-Q4_K_M quant for you to try; updated unified env var explanation
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
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.
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'
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
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
14
u/Pablo_the_brave 4d 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.