Conclusion: The article below contains some errors and should be discarded. It is true that there are people experiencing the same issue, but we have confirmed that it does not appear when using at least the Hermes agent.
Issue with prompt being re-processed on every call in llama.cpp + Qwen3.6-27B — --swa-fullSolved nearly 50%
In llama.cpp build b200 (25b1bc9c2), I was using Qwen3.6-27B-MTP with Hermes-based coding agents, but every call resulted in the prompt being re-processed from nearly the beginning. Despite having the same system prompt and the same codebase, the cache miss rate was 50%. The context window filled up quickly and each call was slow.
Same Issue Reports
There are reports of the same symptoms on Reddit — it's an issue that opencode/pi.dev users are experiencing together:
"https://www.reddit.com/r/LocalLLaMA/comments/1td9stc/"
Cause (Estimated)
Qwen3.6 is a hybrid SSM-Attention architecture (Gated DeltaNet). According to the logs, n_swa = 0 means sliding window attention shouldn't be used, but it appears that the hybrid/recurrent memory path internally shares SWA cache removal logic. As a result, the cache gets truncated every time.
Attempts That Didn't Work
Solution
Add one line of --swa-full to the server execution options:
llama-server ... --swa-full
This is an option that preserves the entire SWA cache without truncating it. VRAM increases by approximately +1.2 GB — no burden for a 24GB card.
Measurement Results
Configuration
| Miss rate
| Prefix reuse rate on Hits
|
|---|
Default (MTP on)
| 50%
| 92%
|
MTP off
| 60%
| 89%
|
preserve_thinking
| 100%
| (Insufficient samples)
|
+ swa-full
| 25%
| 98%
|
The same workflow was measured twice (17 calls total). Although the sample size is small, both sessions showed consistent results.
Bonus — MTP --spec-draft-n-max Sweep
While at it, I also measured the number of speculative draft tokens:
n-max
| TPS
| Accept rate
|
|---|
0 (off)
| 36.75
| —
|
1
| 51.46
| 89%
|
2
| 57.23
| 85%
|
3
| 51.33
| 68%
|
n=2 is the sweet spot. For n=3, the accept rate drops, and the wasted draft cost reduces the gains.
Note
--swa-full doesn't catch everything. The remaining 25% miss is due to calls where the actual prefix changed (new sessions, system prompt changes, etc.), which is unavoidable. A more fundamental fix is being worked on upstream through PRs #22826 and #22929.
It's a definite improvement and adds no burden since it's just one line, so for those experiencing the same symptoms, I recommend trying it out.