实测Hermes + Qwen3.6 27B 使用Qwen-Fixed-Chat-Templates大幅提高缓存命中率

Colt

主机：

AMD 7900XTX 24G （Vulkan驱动）
AMD 9600x + 32G内存
llama.cpp version: 9293 (1acee6bf8) + Hermes Agent v0.14.0 (2026.5.16)

llama.cpp 启动参数：

~/llama.cpp/build/bin/llama-server -m models/Qwen/MTP/Qwen3.6-27B-Q4_K_M.gguf \
--spec-type draft-mtp --spec-draft-n-max 3 \
--flash-attn --n-gpu-layers 99 on --threads 6 --parallel 1 \
-ctk q8_0 -ctv q4_0 --ctx-size 96000 \
-b 3072 -ub 1024 --no-warmup --no-mmap \
--host 0.0.0.0 --port 8080 \
--reasoning off --jinja --chat-template-file models/Qwen/chat_template.jinja

MTP加持下，本地跑 Qwen3.6-27B-Q4_K_M 速度50+tokens/s，搭配hermes很够用。但是每聊那么几句，控制台总是输出上下文缓存不命中的信息，类似：

17.27.663.317 W slot update_slots: id  0 | task 2894 | forcing full prompt re-processing due to lack of cache data (likely due to SWA or hybrid/recurrent memory, see https://github.com/ggm-org/llama.cpp/pull/13194#issuecomment-2868343055)                                                                                                                                         
17.27.663.319 W slot update_slots: id  0 | task 2894 | erased invalidated context checkpoint (pos_min = 51198, pos_max = 51198, n_tokens = 51199, n_swa = 0, pos_next = 0, size = 231.851 MiB)
......

然后就是缓慢的 prompt processing 和 created context checkpoint 过程。持续几十秒到几分钟不等，显卡风扇呼呼转。聊得越久，context越大，出现得越频繁。这种情况非常影响思路连贯性，乃至情绪。研究了几个晚上，问遍国内外AI模型，尝试了各种参数组合，都不得其果。

昨天意外刷到了 Qwen-Fixed-Chat-Templates 的介绍，一番试用后，发现效果明显，聊了近一个小时，反复网络搜索+工具调用，缓存不命中的情况只出现个位数次数。感觉流畅很多，不敢独享，记录下来，希望对遇到类似问题的朋友有用。

特别感谢 https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates 作者。下载方式：

hf download froggeric/Qwen-Fixed-Chat-Templates chat_template.jinja --local-dir models/Qwen

至于它的原理，Huggingface 页面上有详细介绍。我偷懒让Gemini去总结，回复如下：

terry

我靠，这个绝对是意义重大，有没有屌丝们抄作业验证下？我先置顶！

? 离线

很强很强，晚点我也回去测试下

laobenxiong

关注. 有空也试一下.

laobenxiong

目前 hermes 好像还不能使用到 qwen3.6-27b 的 vision 功能, 它能够识别到 multimodal 的 capability, 但是尝试发送图片到 llm 好像不太成功...

? 离线

@laobenxiong 可以啊,我用llama.cpp跑的qwen3.6 27B 配合--mmproj参数，vision 能力正常

laobenxiong

@刘海彬哦. 好的, 我再试试. 谢谢

blackjack

我试了下，效果不如我hack的Hermes好啊。

以下是我详细的测试结果。
在当前这套本地栈里，froggeric/Qwen-Fixed-Chat-Templates 没有带来更好的 KV 复用，反而比我现在用的 Qwen3-stable-reasoning.jinja 更差。

关键结论：

两组都没有出现 forcing full prompt re-processing due to lack of cache data
两组都能稳定走完 8 轮真实工具调用
但 froggeric 模板每轮需要重算的 token 明显更多
受控重跑里，现有模板的 cache hit 更高，uncached token 更少

所以社区帖子里“fixed chat template 大幅提高 Hermes + Qwen3.6 cache 命中率”这件事，至少不能直接外推到我当前这套：

custom-agent-stack/hermes 本地定制
ik_llama.cpp/build-mmq/bin/llama-server
单槽 MMQ + MTP + 128k ctx
本地 replay / save-restore / diagnostics 改造后的工作流

更像是：

对方原始模板或运行栈本来就更容易漂
而我当前本地模板已经处在一个相对稳定的状态

测试目的

验证这篇帖子里的说法，是否适用于我当前本地工作流：

https://lcz.me/topic/298/...
主题：Qwen-Fixed-Chat-Templates 是否能显著降低 Hermes 长会话下的 cache miss / forcing full

测试原则：

同一个 llama-server 二进制
同一个模型
同一套 MMQ / MTP / 128k 参数
同一个 Hermes 启动链
只换 chat template

模板 A / B

A 组：当前本地模板

文件：~/custom-agent-stack/local-agent-setup/templates/Qwen3-stable-reasoning.jinja

B 组：froggeric 模板

来源：https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates
本地文件：~/.cache/local-agent-setup/templates/froggeric/chat_template.jinja
sha256：4649b3fa3db3fda4d51173ed4ff0175fde7ece8bbceb9d595d04d862020c9746

运行环境

模型：~/models/Qwen3.6-27B-MTP-IQ4_KS.gguf
server：~/src/ik_llama.cpp/build-mmq/bin/llama-server
launcher：~/custom-agent-stack/local-agent-setup/start-llama-server-ik-mmq.sh
Hermes：~/custom-agent-stack/local-agent-setup/start-hermes-mmq.sh

共用参数：

CTX_SIZE=128000
ENABLE_VISION=off
--parallel 1
-ngl 999
--cache-type-k q8_0
--cache-type-v q8_0
--flash-attn on
--multi-token-prediction
--draft-max 2
--draft-p-min 0.0
--merge-qkv
--merge-up-gate-experts
--cache-ram 32768
--ctx-checkpoints 32
--jinja
--reasoning off

对照方法

这次实际做了两轮测试。

第一轮：普通多轮工具请求

~/.cache/local-agent-setup/ab-qwen-fixed-template-iq4ks-20260526-060644

这一轮能看出大方向，但有一个污染点：

A 组首轮没有调用工具，模型直接答出了 alpha beta gamma
B 组首轮走了真实 terminal

所以这轮只能算：

初筛结论
不能作为最终严肃证据

第二轮：受控随机文件重跑

~/.cache/local-agent-setup/ab-qwen-fixed-template-iq4ks-controlled-20260526-061256

这轮才是有效结论。

控制方式：

预先生成 8 个随机文件
每轮都要求模型必须用 terminal 执行 cat <file>
文件内容是模型不可能预知的随机 UUID
两组都达成 8/8 真实工具调用

这保证了：

不是“模型猜中了输出”
不是“某组首轮偷答绕过工具”
两边历史链条的结构尽量一致

受控重跑结果

总结指标

A 组：当前本地模板

tool_preview_count = 8
forced_full_reprocess_count = 0
avg_cache_hit_pct = 96.81
avg_uncached_tokens = 87.38
post_t1_avg_cache_hit_pct = 97.29
post_t1_avg_uncached_tokens = 80.43

B 组：froggeric 模板

tool_preview_count = 8
forced_full_reprocess_count = 0
avg_cache_hit_pct = 94.74
avg_uncached_tokens = 168.38
post_t1_avg_cache_hit_pct = 95.00
post_t1_avg_uncached_tokens = 168.71

turn-by-turn

A 组：当前本地模板

turn	prompt_tokens	cached_tokens	uncached_tokens	cache_hit_pct
1	2089	1953	136	93.49
2	2338	2270	68	97.09
3	2590	2451	139	94.63
4	2844	2774	70	97.54
5	3098	3027	71	97.71
6	3353	3282	71	97.88
7	3609	3537	72	98.00
8	3866	3794	72	98.14

B 组：froggeric 模板

turn	prompt_tokens	cached_tokens	uncached_tokens	cache_hit_pct
1	2348	2182	166	92.93
2	2623	2457	166	93.67
3	2901	2732	169	94.17
4	3181	3013	168	94.72
5	3461	3292	169	95.12
6	3742	3573	169	95.48
7	4024	3854	170	95.78
8	4307	4137	170	96.05

结果怎么解读

1. 这不是 forcing full 级问题

两边都没有出现：

forcing full prompt re-processing due to lack of cache data

说明当前本地链路已经比较稳定。

也就是说，这次 A/B 主要比较的是：

谁的共享前缀更长
谁每轮需要补算的 token 更少

而不是比较“谁会炸、谁不会炸”。

2. froggeric 模板在我这里更重

受控重跑里，froggeric 模板几乎每轮都比本地模板多重算接近一倍的 token：

本地模板后 7 轮平均 uncached：80.43
froggeric 后 7 轮平均 uncached：168.71

这不是小抖动，而是明显更差。

3. 社区帖子和我这里不矛盾，但条件不同

更合理的解释不是“帖子错了”，而是：

对方的原始模板更容易在 tool_call / tool_response / think 边界上漂
我本地模板和 Hermes replay 链路已经被专门收拾过
froggeric 模板在我这套本地定制栈里没有形成更短、更稳的共享前缀，反而引入了更多稳定额外 token

所以它在我这里没有收益，甚至有负收益。

neo

牛牛牛，加了Qwen-Fixed-Chat-Templates之后，测试了下，缓存果然没有不命中了，没毛病

Tide

这个必须去了解一下。。。谢谢楼主分享

kos or

看來是個很重要的東西先收藏了留著之後注意研究感謝樓主分享 ; 動態省略 <think>...</think> 推理過程是合理操作但是也造成緩存命中率的問題

neo

感谢楼主的分享，经过几天测试，发现使用后确实kv缓存被prefill的次数明显减少，这点非常到位，同时也发现在hermes中agent调用工具时频繁出现只说不做的情况，不知大家是否也有这样的情况？我准备试着结合Qwen原版和Fix版本合成一个新的版本来测试一下，有相同情况的朋友可以来指导探讨下。

williamlouis

复制收藏了。劲爆。有效。

whjwyc

感谢楼主的付出，测试有效!

sil041

感謝~先準備抄作業

抡锤者

实测Hermes + Qwen3.6 27B 使用Qwen-Fixed-Chat-Templates大幅提高缓存命中率

主机：

llama.cpp 启动参数：

测试目的

模板 A / B

A 组：当前本地模板

B 组：froggeric 模板

运行环境

对照方法

第一轮：普通多轮工具请求

第二轮：受控随机文件重跑

受控重跑结果

总结指标

A 组：当前本地模板

B 组：froggeric 模板

turn-by-turn

A 组：当前本地模板

B 组：froggeric 模板

结果怎么解读

1. 这不是 forcing full 级问题

2. froggeric 模板在我这里更重

3. 社区帖子和我这里不矛盾，但条件不同