Eval bug: vulkan: slower prompt processing with multi-device + cpu-moe MoE after #29741 (e0bcaccb)

快速结论：这是在 Vulkan 后端、多 GPU（Vulkan0,Vulkan1）+ --cpu-moe 运行多专家（MoE）模型时出现的提示处理/预填充性能回退：升级到包含提交 e0bcaccb 的构建后，prefill 从大约 95 tk/s 降到大约 4 tk/s，两块 GPU 的占用都上不去。优先排查构建版本是否落在该回退区间，并尝试回退或换用已修复的构建。

适用环境：llama.cpp 0.6.0-dev (build 3841, commit 23deec02)，GNU 15.2.0，Linux x86_64；Vulkan 后端；硬件为 E5-2697 v2 + 2x RX 570；模型为 unsloth Qwen3.6-35B-A3B-MTP Q8_0 与 Qwen3.8-Flash-Next Q8_0。

最快修复方案：暂无确认的一步修复方案。Issue 中可确认有效的规避方式是把代码回退到回退提交之前的版本（例如 git checkout 0a731cce 后重新构建）；同一讨论链中另有 PR #30468 被指修复了同类问题，但该 PR 与本 Issue 的对应关系未在此处验证。

注意事项：回退构建会失去 e0bcaccb（#29741，允许多个 Vulkan 设备访问 GPU 可见主机内存）带来的改动，若其他场景依赖该提交的行为需重新验证。PR #30468 是否完整覆盖本 Issue 的多设备 + --cpu-moe 组合尚未确认，建议先在测试构建上复测。

问题场景

用户在 Linux 上使用 llama.cpp 的 llama-server，加载 unsloth Qwen3.6-35B-A3B-MTP Q8_0 等 MoE 模型，启用 Vulkan 后端并指定两块显卡（--device Vulkan0,Vulkan1），同时用 --cpu-moe 把 MoE 权重放到 CPU。命令中还包含 --flash-attn auto、--spec-type draft-mtp、--fit off、--load-mode none、--lazy-mode off、-t 46、-c 0 等参数。升级到提交 e0bcaccb 之后，提示处理（prefill）严重变慢：回退提交 0a731cce 时约 95 tk/s，单卡满载；e0bcaccb 之后约 4 tk/s，两块 GPU 占用都只有 4% 左右。

报错原文

Eval bug: vulkan: slower prompt processing with multi-device + cpu-moe MoE after #29741 (e0bcaccb)

e0bcaccbe50a773c8addec49bbfc8b7ba953c63b is the first bad commit
commit e0bcaccbe50a773c8addec49bbfc8b7ba953c63b (tag: b11594)

    vulkan: allow multiple devices to access gpu-visible host memory (#29741)

原因分析

根据二分定位，性能回退首次出现在提交 e0bcaccb（#29741，vulkan: allow multiple devices to access gpu-visible host memory）。该提交改动了 Vulkan 缓冲区与设备内存管理相关实现。可能原因是：在多设备 + --cpu-moe 的场景下，MoE 权重位于 CPU 侧主机内存，需要经由 GPU 可见主机内存访问，新逻辑使这条路径上的数据搬运或同步开销显著增加，导致 prefill 阶段 GPU 无法满载。具体机制尚未在 Issue 中给出确认结论，以上为可能原因。

环境排查

确认 llama.cpp 构建版本与提交：llama-server --version，检查是否包含 e0bcaccb 或更晚的提交。
确认后端为 Vulkan，且 --device 中列出的 Vulkan 设备与系统实际枚举一致（Vulkan0、Vulkan1）。
确认是否使用 --cpu-moe，以及模型是否为 MoE 架构（Qwen3.6-35B-A3B-MTP、Qwen3.8-Flash-Next）。
确认 --flash-attn、--fit、--load-mode、--lazy-mode、线程数等参数与复现命令一致，避免其他参数干扰对比。
Issue 未提供 Python、CUDA、PyTorch 或 Vulkan 驱动版本信息，无需据此判断。

解决步骤

记录当前构建版本：llama-server --version，确认是否为含 e0bcaccb 的构建。
可优先尝试回退规避：切换到回退提交之前的版本，例如 git checkout 0a731cce，重新编译后复测同一命令的 prefill 速度。
如需保留新版本特性，关注同一讨论链中提到的修复 PR（ggml-org/llama.cpp#30468，该 PR 在关联 Issue #30552 中被提及），用其构建替换后复测。
复测时保持命令行参数不变，重点比较 prefill 速度与两块 GPU 的占用率。

验证方法

用相同的 llama-server 命令和同一模型重新发起提示处理，观察 prefill 速度是否恢复到回退前量级（Issue 中约 95 tk/s），并确认 prefill 阶段至少一块 GPU 接近满载，而不是两块都在 4% 左右。若切换构建后指标仍无改善，说明问题可能还与其他参数或驱动有关，需继续二分。