Misc. bug: Slow decode speed with large tool sets

问题场景

用户通过 llama-server 运行 unsloth/Qwen3.8-27B-GGUF 模型（262k 上下文），使用 Cline “next” 版本发送 OpenAI 风格的 tools 数组（包含 263 个来自 MCP 服务器的工具，其中 Ghidra 服务器贡献 200+），并设置 tool_choice=auto。对比同一对话在 Cline 旧版（工具以纯文本形式写在系统提示词中，不携带 tools 字段）时的表现，发现解码速度从约 70 tok/s 下降到约 30 tok/s。

报错原文

Misc. bug: Slow decode speed with large tool sets
~30 tok/s with 263 tools vs ~70 tok/s without, same model and hardware.
Chunk timestamps show a constant ~30 tok/s across all 66 s of generation (not a slow start).
The output of that request was pure free text ... never contained a tool-call marker,
so the lazy grammar sat in awaiting-trigger state for the entire response.

原因分析

可能原因是：当请求携带大量工具定义时，llama.cpp 会为每个工具添加一个触发模式（trigger pattern）。在 Qwen3-Coder 风格模板中，每个工具名称都会生成一个 <function=工具名> 的触发词，加上默认的 <tool_call>，263 个工具会产生 264 个触发模式。每个模式都会被编译为独立的 std::regex。在等待触发词期间，每个接受的 token 都会对累积输出执行一次正则搜索，导致总计算量为 O(工具数 × token数的平方) 次字符扫描。这解释了为什么工具数量越多、输出越长，性能下降越明显，且开销均匀分布在生成全程。

需要说明的是，Issue 作者标注了”AI slop analysis, may be bs”，即此根因分析可能不完全准确，但 PR #27679 确实修复了该问题。

环境排查

• llama.cpp 版本：确认是否低于 build 10610（或包含 PR #27679 的版本）
• 操作系统：Windows x86_64
• CUDA 版本：13.3（对应 llama-b10610-bin-win-cuda-13.3-x64 包）
• 显卡：RTX Pro 6000 Blackwell 96GB
• 模型：unsloth/Qwen3.8-27B-GGUF（Q8_K_XL 量化）
• 上下文长度：262144
• 工具数量：263 个 MCP 工具（含 Ghidra 工具 200+）

解决步骤

1. 升级 llama.cpp：获取包含 PR #27679 的最新构建版本，该 PR 已确认修复此问题。
2. 复测性能：使用相同模型、相同工具集、相同对话，对比升级前后的解码速度。
3. 如果仍存在问题：检查是否还有其他因素（如模板差异、线程数设置等）影响性能。Issue 中使用了 --threads 2，可尝试调整线程数。
4. 临时规避（如无法升级）：可考虑减少单次请求携带的工具数量，或改用旧版 Cline 方式将工具描述放入系统提示词。

验证方法

使用相同的对话请求（携带 263 个工具、tool_choice=auto），对比升级前后 llama-server 的解码速度（tok/s）。如果速度从约 30 tok/s 恢复至接近无工具时的水平（约 70 tok/s），则确认修复生效。可通过日志代理捕获 SSE 输出的 chunk 时间戳来计算实际解码速度。

参考来源

ggml-org/llama.cpp #27675

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。