Misc. bug: generation started to crawl after update

快速结论：该问题通常出现在升级到含 Vulkan 多设备相关改动的 llama.cpp 版本后（Issue 中指向 b11594 及之后的构建），在多块 Vulkan 设备（尤其双 RADV/AMD 显卡，或 NVIDIA + AMD 混合环境）上跑模型时生成速度骤降。优先排查是否处于多设备 Vulkan 环境，并尝试只暴露一块设备。

适用环境：Issue 中已确认的环境为 Linux；涉及 llama.cpp Vulkan 构建（b11592 正常，b11594 起出现退化，b11624、b11610 仍有问题）；显卡包括 RX 7600 XT + Renoir iGPU（双 RADV）、双 R9700、RTX 3090 + RX 7900 XT（RADV NAVI31）、2x FirePro D700（Tahiti，GCN 1.0）；Mesa/RADV 26.2.4、Vulkan loader 1.4.363（仅 FirePro D700 的报告中给出）。Issue 未提供 Python、CUDA、PyTorch 版本信息。

最快修复方案：Issue 评论中验证有效的处理是设置环境变量 GGML_VK_VISIBLE_DEVICES=0，让 Vulkan 后端只使用一块设备；评论同时指出 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 无效。

注意事项：该方案只是绕过多设备路径，代价是无法利用多 GPU 进行 layer split；若模型依赖多卡才能放下，需改用回退到 b11592 或回退相关提交。该修复仅在部分报告者环境验证通过，不同硬件与构建上的效果可能不一致。

问题场景

用户在 Linux 下使用 llama.cpp 的 Vulkan 后端（Issue 中为 llama-server，模型为 Qwen3.6-35B-A3B 的 GGUF，使用 -ncmoe、MTP draft 推测解码、--load-mode none 等参数）运行推理。升级到 llama-b11594-vulkan-x64 及之后版本后，生成速度从约 37 t/s 跌到 0.07 t/s，仅处理 prompt 就要约 40 秒；回退到 b11592 则正常。后续评论在双 R9700、NVIDIA + AMD 混合组合、以及 2x FirePro D700 上复现了同类退化。

报错原文

Misc. bug: generation started to crawl after update

原因分析

根据 Issue 评论中的定位，根因是非 b11596（该版本仅为测试代码），而是 b11594 引入的“允许多个设备访问 GPU 可见主机内存”改动。该改动在检测到多块 Vulkan 设备且均支持 VK_EXT_external_memory_host 时，把设备标记为 multi_device，并让 ggml_vk_host_malloc() 不再分配 Vulkan pinned memory，而改用普通的 aligned malloc。模型中有大量权重位于 Vulkan_Host 缓冲区，这些权重因此从真实 Vulkan 内存变成普通匿名内存，再按设备惰性导入；在 RADV 上导入页的 GPU 读取速度极慢（评论给出约 230 MB/s），导致加载张量时间从约 0.75 秒涨到约 41 秒，且每次图执行都出现约 41 秒的固定开销，与 batch 大小无关。

其他评论报告了相似现象：解码速度均匀下降、预填充反而略快、amdgpu GTT 占用升高并在生成过程中增长、minor faults 大幅增加，说明问题出在分配路径本身，而非张量放置。在 2x FirePro D700 上仅回退提交 e0bcaccbe（#29741）即可恢复旧速度，进一步印证该结论。

环境排查

确认 llama.cpp 构建版本：b11592 正常，b11594 起出现退化；需核实当前所用构建是否包含该提交。
确认 Vulkan 设备数量与型号：是否存在两块及以上 GPU（包括核显），以及每块设备是否都暴露 VK_EXT_external_memory_host。
确认 AMD 驱动栈：Issue 中为 Linux + Mesa/RADV；不同 Mesa 版本表现可能不同。
确认日志中 Vulkan_Host 模型缓冲区大小、load_tensors 耗时、每次图执行耗时是否出现固定的大额开销。
确认是否使用了 --split-mode layer、-ot（把部分层放到 CPU）、--moe-cache-mib 等参数；评论显示多设备 + --split-mode layer 时退化明显，配合 --moe-cache-mib 会进一步恶化。
Issue 未提供 Python、CUDA、PyTorch 版本信息，无需按这些项排查。

解决步骤

先确认当前是否处于多 Vulkan 设备环境：在同一容器/主机上对比只启用一块设备时的生成速度。
可优先尝试设置 GGML_VK_VISIBLE_DEVICES=0，让 Vulkan 后端只使用编号为 0 的设备，然后重新启动 llama-server 并复测。这是 Issue 评论中验证有效的方案。
若模型必须依赖全部显存才能加载，可回退到 b11592 或回退 b11594 对应提交后再验证。
不要依赖 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1：评论中该设置对退化无效。
如保留多设备结构，可测试去掉 --split-mode layer、将全部层放在单卡（如 --device Vulkan0 --split-mode none），以及移除以 CPU 放置层为主的 -ot 与 --moe-cache-mib 组合，观察生成速度是否恢复。

验证方法

在相同容器/主机、相同模型和参数下对比修改前后的生成速度（token/s）与 prompt 处理耗时；同时观察 llama.cpp 日志中 load_tensors 耗时是否从数十秒回落到秒级、每次图执行是否仍有固定的大额延迟。若设置 GGML_VK_VISIBLE_DEVICES=0 后生成速度回到接近 b11592 的水平，即可认为问题已被绕过。