Misc. bug: Vulkan – slow token generation with AMD DGPU Resizable BAR disabled

快速结论：在 llama.cpp 的 Vulkan 后端下，AMD 独显未开启 Resizable BAR（或驱动把 DEVICE_LOCAL | HOST_VISIBLE 显存放置到系统内存）时，token 生成（tg）会异常变慢；应优先检查 BAR 设置与 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM 开关对吞吐的影响。

适用环境：Linux x86_64，llama.cpp 0.1.0-dev（build 10438，commit 9d57ce456，GNU 16.2.1 编译），Vulkan 后端；显卡 AMD Radeon RX 7900 XTX（RADV NAVI31，uma: 0）。评论区另报告 Intel Arc A770 + Windows 11 出现同类症状，属于不同环境，仅供参考。

最快修复方案：设置环境变量 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 后重跑 llama-bench，Issue 中该操作使 tg128 从 13.89 t/s 提升到 37.09 t/s。这是 Issue 中已验证有效的临时方案，并非代码层面的修复。

注意事项：该环境变量是全局开关，会改变 Vulkan 后端对 host-visible 显存的分配策略，在其他显卡/驱动组合上的效果未经验证；评论区的自动检测补丁（vulkan-detect-small-bar 提交）仅为个人分支，尚未合入主线，也未在 Issue 中确认被采用。

问题场景

用户使用 llama.cpp 的 Vulkan 后端运行 llama-bench，加载 Qwen3.8-27B-UD-Q4_K_XL.gguf（表中显示为 qwen35 27B Q4_K – Small，16.68 GiB，27.32 B 参数）进行基准测试：

llama-bench -dev Vulkan0 -m Qwen3.8-27B-UD-Q4_K_XL.gguf -p 512 -n 128 -d 0,4096 -r 3

现象是 prompt 处理（pp512）速度尚可，但 token 生成（tg128）很慢，只有 13.89 t/s；在 BIOS 中未开启 Resizable BAR 的 AMD 独显上出现。

报错原文

Misc. bug: Vulkan - slow token generation with AMD DGPU Resizable BAR disabled

ggml_vulkan: 0 = AMD Radeon RX 7900 XTX (RADV NAVI31) (radv) | uma: 0 | fp16: dot2 | bf16: 0 | fp4: 0 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat

| qwen35 27B Q4_K - Small | 16.68 GiB | 27.32 B | Vulkan | -1 | Vulkan0 | tg128 | 13.89 ± 2.16 |

原因分析

Vulkan 后端在分配 DEVICE_LOCAL | HOST_VISIBLE 类型显存时，驱动可能把这部分缓冲区放到系统内存里。当 Resizable BAR 关闭、BAR 窗口较小时，host-visible 显存堆远小于主显存堆，此类分配落不到真正的显存上，导致 token 生成阶段访存变慢。

证据上，Issue 中 vulkaninfo 显示 memoryHeaps[0] 为 DEVICE_LOCAL（约 23.75 GiB），memoryHeaps[1] 无 flags（约 31.36 GiB），符合“host-visible 堆比主显存堆小”的特征。禁用 host-visible 显存路径（GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1）后吞吐明显恢复，说明瓶颈在该内存选择路径上。评论区的 Intel Arc A770 + Windows 11 案例在 ReBAR 已开启时仍复现，因此“严格由 Resizable BAR 关闭导致”这一结论尚不充分，可能是驱动对 host-visible 显存的放置策略问题。

环境排查

确认 llama.cpp 版本与提交，如 build 10438 / 9d57ce456，排查时保持版本一致。
确认 Vulkan 后端识别到的显卡与驱动，如 AMD RX 7900 XTX、RADV NAVI31、uma: 0。
在 BIOS/驱动面板中确认 Resizable BAR（或对应 BAR 设置）是否开启。
用 vulkaninfo 查看各 memoryHeap 的 size、budget 与 flags，检查 host-visible 堆是否明显小于 DEVICE_LOCAL 堆。
分别在不设置/设置 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 的情况下跑同一基准，对比 tg 数值。
Windows 或 Intel 显卡用户可打开 GGML_VK_MEMORY_LOGGER=1 观察 device/host 内存分配，并用系统 GPU 适配器内存计数器区分显存与共享内存占用。

解决步骤

先复跑原始命令，记录基准基线（Issue 中 tg128 为 13.89 t/s）。
在同一命令前加环境变量重新基准测试：
GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 llama-bench -dev Vulkan0 -m Qwen3.8-27B-UD-Q4_K_XL.gguf -p 512 -n 128 -d 0,4096 -r 3
对比 tg128 与 tg128 @ d4096 的提升幅度；Issue 中 tg128 升至 37.09 t/s，tg128 @ d4096 升至 36.33 t/s。
若确认有效，可在调用 llama.cpp 的脚本或服务中持续设置该环境变量作为临时方案；同时可考虑在 BIOS 中开启 Resizable BAR，但 Issue 未验证开启后可否不设该变量即达到同等速度。
可优先尝试：使用评论区提供的补丁思路（在 host-visible 显存堆小于主显存堆时自动设置 disable_host_visible_vidmem，且不覆盖用户已设置的 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM），但该补丁来自个人分支，合入状态未知，需自行评估。

验证方法

用相同的模型、参数和重复次数（-r 3）分别在有/无 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 下运行 llama-bench，确认 tg128 与 tg128 @ d4096 是否出现明显且稳定的提升；若提升幅度与 Issue 中接近（约 2~3 倍），即可认为触发了同一问题路径。Windows/Intel 用户还可检查 GPU 专用（dedicated）内存占用是否随标志开启而增加、共享内存占用是否下降。