实测Hermes + Qwen3.6 27B 使用Qwen-Fixed-Chat-Templates大幅提高缓存命中率
-
关注. 有空也试一下.
-
目前 hermes 好像还不能使用到 qwen3.6-27b 的 vision 功能, 它能够识别到 multimodal 的 capability, 但是尝试发送图片到 llm 好像不太成功...
-
目前 hermes 好像还不能使用到 qwen3.6-27b 的 vision 功能, 它能够识别到 multimodal 的 capability, 但是尝试发送图片到 llm 好像不太成功...
@laobenxiong 可以啊,我用llama.cpp跑的qwen3.6 27B 配合--mmproj参数，vision 能力正常
-
@laobenxiong 可以啊,我用llama.cpp跑的qwen3.6 27B 配合--mmproj参数，vision 能力正常
@刘海彬 哦. 好的, 我再试试. 谢谢
-
我试了下，效果不如我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=128000ENABLE_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 = 8forced_full_reprocess_count = 0avg_cache_hit_pct = 96.81avg_uncached_tokens = 87.38post_t1_avg_cache_hit_pct = 97.29post_t1_avg_uncached_tokens = 80.43
B 组：froggeric 模板
tool_preview_count = 8forced_full_reprocess_count = 0avg_cache_hit_pct = 94.74avg_uncached_tokens = 168.38post_t1_avg_cache_hit_pct = 95.00post_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
所以它在我这里没有收益，甚至有负收益。
- 两组都没有出现
-
系统 取消固定了该主题
-
复制收藏了。劲爆。有效。
