我试了下，效果不如我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
所以它在我这里没有收益，甚至有负收益。