vulkan: ~3x decode regression with spec decode + large -c on multi-device systems since e0bcacc

快速结论：当 Vulkan 后端同时枚举到多个 GPU、并使用大上下文（如 -c 196608）配合投机解码（ngram-map / draft-mtp）时，自 e0bcacc 起 decode 吞吐量可能下降约 3 倍，而 draft 接受率不变。优先确认是否处于多 Vulkan 设备可见状态，以及构建是否包含 #30468（a8d9a7e）。

适用环境：llama.cpp Vulkan 后端，Ubuntu 26.04；计算卡为 AMD Radeon RX 7900 XTX（gfx1100，RADV/mesa），同机另可见 Intel iGPU、NVIDIA CMP 40HX、NVIDIA RTX 5060 Ti。构建参数 -DGGML_VULKAN=ON -DGGML_NATIVE=ON -DLLAMA_CURL=OFF -DCMAKE_BUILD_TYPE=Release。Issue 未给出 Python、CUDA、PyTorch 版本信息。

最快修复方案：升级到包含 #30468 的 master（a8d9a7e 及之后）。Issue 在同一机器上复测，master a8d9a7e 的 decode 152.9 t/s 与 pre-e0bcacc 的 153.6 t/s 基本持平，RADV 下回归已解决。

注意事项：#30468 针对的是 amdgpu/RADV 的 per-page-recheck 机制，非 AMD 的多设备系统上 e0bcacc 路径仍会生效，原问题（单设备选择时是否跳过 gpu-visible host-memory pool）未确认修复。此外，仅用 –device Vulkan1 指定计算卡并不能规避该问题，因为其他设备仍会在启动时被枚举和初始化。

问题场景

用户运行 llama-server 加载 Qwen3.8-27B-UD-Q4_K_S.gguf，启用投机解码 –spec-type ngram-map-k4v,draft-mtp，配合 -c 196608 大上下文、-fa 1、–cache-reuse 256、–mmproj，在可见 4 个 Vulkan 设备的机器上推理。 -c 8192 时好坏构建速度相当；-c 196608 时坏构建 decode 吞吐量塌到约裸内存带宽水平，而 prefill 不受影响。该问题由 git bisect 定位到 e0bcacc（PR #29741，“vulkan: allow multiple devices to access gpu-visible host memory”）。

报错原文

vulkan: ~3x decode regression with spec decode + large -c on multi-device systems since e0bcacc

原因分析

可能原因：e0bcacc 引入的多设备 gpu-visible host memory 路径在大上下文 + 投机解码验证批次下，使验证批次脱离快速 mat-vec 路径，吞吐量跌至接近内存带宽。
依据：draft 接受率在好坏构建间逐位一致（0.835/0.835/0.727，同 seed/prompt），仅吞吐量变化；回归被上下文规模门控；单 revert e0bcacc 即可恢复约 92%。
后续：评论指出 #30468 中的 amdgpu per-page-recheck 机制与 bisect 观察到的现象吻合（接受率不变、仅吞吐塌陷、被大上下文门控），合入后 RADV 上恢复持平。

环境排查

确认 llama.cpp 提交是否落在 3d65c90..b76b1337 区间，或是否包含 e0bcacc 之后的多设备主机内存改动。
确认已包含 #30468（a8d9a7e）或更新 master。
确认 Vulkan 后端可见设备数量：多设备可见即满足触发条件，即使 –device 只指定了其中一块。
确认上下文大小：用 -c 196608 与 -c 8192 对比，观察回归是否只在更大上下文下出现。
确认投机解码配置（–spec-type、–spec-ngram-map-k4v-size-n、–spec-draft-n-max 等）与报告中一致。
AMD 平台确认驱动为 RADV/mesa，并记录显卡型号（gfx1100）。

解决步骤

先按原始参数复现并记录 decode t/s：512 生成 token、temp 0、seed 42、重复句提示，取 3 次中位数。
用 -c 8192 和 -c 196608 各跑一次，确认吞吐差异是否只在大上下文下出现。
用 GGML_VK_VISIBLE_DEVICES=<计算卡索引> 仅暴露计算 GPU，对比 decode t/s；若恢复，则确认是多设备路径触发。
升级到包含 #30468 的 master 构建后重新测试；在 RADV 上预期与 pre-e0bcacc 持平（参考 152.9 vs 153.6 t/s）。
若仍无法升级，可优先尝试在 e0bcacc 之上 revert 该提交作为临时规避，并做一次生成正确性冒烟测试（推理与数学题）。
非 AMD 多设备平台若升级后仍复现，收集可见设备列表与前后吞吐对比，提交到上游讨论单设备选择时是否应跳过 gpu-visible host-memory pool。

验证方法

以相同命令、相同 seed/prompt 重新测量 decode t/s，与 pre-e0bcacc 基线对比：若大上下文下吞吐恢复到接近基线（如 152.9 vs 153.6 t/s），同时 draft 接受率保持逐位一致，即可确认回归已解决；另可确认 -c 8192 与 -c 196608 下吞吐不再出现 3 倍级差异。