Eval bug: MiMo-V2.6-Distill-Qwen-9B chat template misdetected as Qwen3-Coder (tool calls never complete)

快速结论：这个报错通常出现在用 llama-server 跑 MiMo-V2.6-Distill-Qwen-9B（GGUF）并调用 OpenAI 兼容 tools API 时，模型自带的 chat template 被误判为 Qwen3-Coder 模板，导致工具调用永远走不到正常结束。优先排查 llama.cpp 版本是否过旧，升级到 b11102 及以上即可。

适用环境：Issue 中确认的环境为：llama.cpp fork csantiago78/llama.cpp @ bccbacd；后端 Vulkan；显卡 AMD BC-160（Navi12/V520）。模型为 MiMo-V2.6-Distill-Qwen-9B GGUF Q5_K_M（bartowski/MiMo-V2.6-Distill-Qwen-9B-GGUF），GGUF 元数据中标称架构 qwen35。Python、CUDA、PyTorch 版本未在 Issue 中给出。

最快修复方案：升级到 llama.cpp b11102 或更高版本。该问题已由 PR #29257 修复（评论中明确说明 Already fixed by #29257 b11102, update）。

注意事项：如果暂时无法升级，Issue 中提供过一条已验证的临时规避方案：用 --chat-template-file 传入修改后的模板，把字面量 <function= 拆成 <func ~ tion=，使渲染结果字节不变但不再命中子串匹配。该规避依赖模板源码细节，仅作为不改代码/不重编译时的临时手段，仍建议升级到修复版本。

问题场景

用户用 llama-server 加载 MiMo-V2.6-Distill-Qwen-9B 的 GGUF 模型，使用模型自带的嵌入 chat template（未加 --chat-template 覆盖），并通过 OpenAI 兼容的 /v1/chat/completions 接口传入非空 tools 数组发起工具调用。结果每次工具调用都以 finish_reason: "length" 结束，模型始终无法产出可解析的工具调用；原始 completion 里能看到不断产生却永不闭合的 <tool_call>/<function=...> 片段。服务端日志会打印 Using specialized template: Qwen3-Coder，确认发生了误判路由。

报错原文

Eval bug: MiMo-V2.6-Distill-Qwen-9B chat template misdetected as Qwen3-Coder (tool calls never complete)

Using specialized template: Qwen3-Coder

finish_reason: "length"

原因分析

根因在 common/chat.cpp 约 3596–3601 行的 chat-template 自动检测逻辑：它是对模板源文本做子串匹配，而不是根据模型架构或模板名称字段判断。只要源文本中同时出现 <tool_call>、<function=、<parameter= 三个子串，就会路由到硬编码的 Qwen3-Coder XML 工具调用解析器。

MiMo-V2.6-Distill-Qwen-9B 的 GGUF 嵌入模板恰好包含这三个子串，但它实际发出的语法与 Qwen3-Coder 不同：Qwen3-Coder 解析器要求每个开标签后紧跟换行，并且字符串参数只在 \n</parameter>\n 处闭合。MiMo 的标签没有这种精确的换行位置，因此在 Qwen3-Coder 语法下调用被视为永不闭合，生成一直跑到 max_tokens，永远产生不了可用的工具调用。

环境排查

确认 llama.cpp / llama-server 的构建版本号；低于 b11102 的版本包含该误判逻辑。
确认是否使用模型自带嵌入模板（未加 --chat-template 覆盖），以及是否通过 --chat-template-file 传入过自定义模板。
确认模型文件来源与量化版本，Issue 中为 bartowski/MiMo-V2.6-Distill-Qwen-9B-GGUF、Q5_K_M。可用 llama-server 启动日志或 GGUF 元数据查看架构字段是否为 qwen35。
确认后端与显卡环境，Issue 中为 Vulkan + AMD BC-160（Navi12/V520）。
检查服务端启动日志中是否出现 Using specialized template: Qwen3-Coder，这是误判的直接证据。
Python、CUDA、PyTorch 版本 Issue 未涉及，通常与本问题无关。

解决步骤

将 llama.cpp 升级到 b11102 或更高版本（该版本已包含 PR #29257 的修复），重新构建或替换 llama-server。
若暂时无法升级，可采用 Issue 中已验证的模板源码规避法：准备一份模型自带 chat template 的副本，把其中字面量 <function= 改成拼接写法，例如 '<tool_call><func' ~ 'tion=' ~ tool_call.name，保证渲染输出字节不变，但源文本不再包含连续的 <function= 子串。
用 llama-server --chat-template-file <修改后的模板文件> 启动，模板其余内容保持不变。
确认启动日志中不再出现 Using specialized template: Qwen3-Coder。
重新发起带 tools 数组的 OpenAI 兼容请求，观察返回结果。

验证方法

发起一次带非空 tools 数组的 /v1/chat/completions 请求，确认：服务端日志不再打印 Using specialized template: Qwen3-Coder；响应中 finish_reason 为 tool_calls 而不是 length；工具调用参数是合法 JSON 且能正常闭合。Issue 中报告在应用规避后即得到 finish_reason: "tool_calls" 和有效的 JSON 参数。