以下是我详细的测试结果。
在当前这套本地栈里，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 组：当前本地模板

B 组：froggeric 模板

结果怎么解读

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. 社区帖子和我这里不矛盾，但条件不同

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

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

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