Eval bug: QWEN3.8:27b + lemonade server’s rocm b10472 + cline (vscode) = tools partially working (MCP failures), while vulkan works flawless

快速结论：该问题通常出现在 Windows + AMD APU（gfx1151）上，使用 lemonade server 的 ROCm/HIP 后端配合 Cline（VS Code）调用 Qwen3.8:27b；表现为原生 Cline 工具可用，但 MCP 工具被注入上下文后模型无法正确调用。优先排查是否命中 HIP ubatch 拆分导致的输入张量写入竞争。

适用环境：Windows；lemonade server 11.7.0 + rocm b10472；GGML 后端 HIP（ROCm）；硬件 AMD AI MAX 395+ 64 GB（gfx1151）；模型 Qwen3.8:27b（同环境也提到 Qwen3.6:27b 与 35b-3ba）；客户端 VS Code + Cline 4.1.x。加载参数含 --flash-attn on --cache-type-k q8_0 --cache-type-v q8_0 --no-mmap。

最快修复方案：暂无确认的一步修复方案。Issue 中可优先尝试的运行时规避方法是让整段 prompt 落入单个 ubatch：若 lemonade 允许透传，设置 --batch-size 8192 --ubatch-size 8192（取值需大于实际 MCP 上下文 token 数，需自行测量）。同时可尝试 integrated=false 作为 stopgap。根因修复指向 #27311 / #25863，尚未在 Windows ROCm 发布产物中验证。

注意事项：增大 ubatch 会增加 compute buffer 显存占用，需按实际 prompt 长度从低到高试探；ub == b 只在该 Issue 讨论中被描述为规避手段，不是上游合并的修复；Issue 已标记 stale 且带 bug-unconfirmed，未确认的推测性结论不应视为已解决。用户环境为 APU，且未提供 llama.cpp 日志，只提到可提供 lemonade server 日志。

问题场景

用户在 Windows 上通过 VS Code 的 Cline 4.1.x 连接 lemonade server（11.7.0 + rocm b10472），后端为 HIP/ROCm，加载 Qwen3.8:27b（同一环境下也测试过 Qwen3.6:27b 和 35b-3ba）。在使用原生 Cline 工具（read_files、search_codebase、editor 等）时可以正常识别与调用；一旦在 Cline 中接入 MCP 服务器并把 MCP 工具 schema 注入上下文，模型就无法正确调用这些 MCP 工具。同一套配置切到 Vulkan 后端时工具调用完全正常。用户推测问题与上下文长度有关，因为 MCP 工具 schema 会显著抬高 prompt token 数。

报错原文

Eval bug: QWEN3.8:27b + lemonade server's rocm b10472 + cline (vscode) = tools partially working (MCP failures), while vulkan works flawless

原因分析

讨论中把症状归因到 HIP 路径上的 process_ubatch 输入写入竞争：在 APU 的 host-buffer 路径（#24233 引入）下，图输入张量存在 write-after-read，导致在长上下文 / 大量工具数组场景下工具调用内容被破坏。已知的触发条件（在 gfx1151 上测量）是 n_ubatch < n_batch，或在普通生成时 prompt_tokens > n_ubatch；唯一表现正常的配置是整段 prompt 落在单个 ubatch 内。该失败模式表现为大工具数组的头部内容丢失、尾部仍被正确读取，模型仍能流畅作答但看不到最前面注入的工具——这正好解释了“原生 Cline 工具可用（数量少）、MCP 工具失败（数组大、prompt 长）”的差异。

需要注意：#27705 是另一个缺陷（MTP/nextn 路径上的 output_reorder 索引空间不匹配），与本症状无关。相关根因修复指向 #27311（Scheduler UMA ring buffer）以及更小范围的 #25863。上述仍属讨论中的推断，Issue 本身带 bug-unconfirmed，未在本环境上完成验证。

环境排查

确认运行平台为 Windows，GPU 为 AMD AI MAX 395+ 64 GB（gfx1151），后端为 HIP/ROCm。
确认 lemonade server 版本为 11.7.0，ROCm 构建为 b10472。
确认 llama.cpp 是 lemonade 的 fork/打包版本，而不是带 #27311 / #25863 修复的上游 master。
确认 VS Code 中 Cline 版本为 4.1.x，并确认 MCP 服务器确实已连接、工具 schema 已注入。
确认启动参数：--flash-attn on --cache-type-k q8_0 --cache-type-v q8_0 --no-mmap --temp 0.1 --repeat-penalty 1.0 --top-k 20 --top-p 0.95 --min-p 0 --chat-template-kwargs '{"preserve_thinking":true,"reasoning_effort":"low"}'。
记录实际 MCP 上下文的总 prompt token 数，用于判断是否超过 n_ubatch。
对比同一配置在 Vulkan 后端下的表现，以确认问题只在 HIP 路径出现。

解决步骤

先在 Vulkan 后端复测同一套 Cline + MCP 配置，确认 MCP 工具在 Vulkan 下能正常调用，作为对照基线。
若 lemonade 支持透传 llama.cpp 参数，尝试将 batch 与 ubatch 设为相等且大于实际 prompt token 数，例如 --batch-size 8192 --ubatch-size 8192，并确保 ubatch 能容纳完整的 MCP 上下文。
在该配置下重复触发 MCP 工具调用；若 MCP 工具开始被正确调用，再把 ubatch 调回 512 复测一次，观察是否复现失败，用来确认与 ubatch 拆分缺陷的关联。
可优先尝试 integrated=false 作为临时规避，绕过 APU host-buffer 路径，观察 MCP 工具是否恢复。
若需要根因修复，等待 #27311 或 #25863 合入上游并同步到 lemonade 的 llama.cpp fork；#27705 与本问题无关，不要用它来验证。
注意 Windows ROCm 的 zip 产物来自 master 的 release workflow，PR CI 中没有 Windows ROCm job，因此无法直接取 PR 构建产物验证。
若长时间停留在 ROCm 没有收益，可考虑直接使用 Vulkan：讨论中提到在该芯片上 Vulkan prefill 慢 5–9%，但 decode 提升 24%（49.5 → 61.5 t/s），且 Vulkan 下用户已确认工具调用完全正常。

验证方法

在 ub == b 且 ubatch 足够大的配置下，重新连接 MCP 服务器并触发 MCP 工具调用，确认模型能正确识别并调用被注入的工具；随后把 ubatch 降回 512，确认失败复现。若 MCP 工具在单 ubatch 下稳定可用、在拆分 ubatch 下稳定失败，即可确认与所述 HIP 输入写入竞争缺陷一致。最终以上游修复合入并在本机实测通过为准。