快速结论:当你在 llama.cpp 的 Vulkan 后端上用两块 GPU 跑 --split-mode layer 时,如果出现 token 生成速度比旧版本慢 2-4 倍(提示处理基本正常),通常与 #29741 引入的多设备访问 GPU 可见主机内存的行为有关;可优先排查/升级到包含 #30468 的版本。
适用环境:llama.cpp v0.7.0(commit 620d2225c),Linux(Arch Linux,kernel 7.1.8),Vulkan 后端,Mesa / RADV 26.2.4,Vulkan loader 1.4.363;显卡为 2x AMD FirePro D700 6 GB(Tahiti,GCN 1.0,无 Resizable BAR);构建参数为 -DGGML_VULKAN=ON -DGGML_OPENMP=ON -DGGML_NATIVE=ON,Release。Issue 中未提及 Python、CUDA、PyTorch 环境。
最快修复方案:使用包含 PR #30468 的 llama.cpp 版本。Issue 报告者确认 #30468 解决了该问题。
注意事项:该现象已在特定老平台(GCN 1.0 / Tahiti、无 ReBAR、双 GPU)上复现和验证;如果你的减速由其他原因引起,升级到包含 #30468 的版本不一定有效。Issue 已被关闭,但标签为 bug-unconfirmed,其他平台和硬件组合的效果需要自行验证。
问题场景
用户在 Linux 上使用 llama.cpp 的 llama-server,通过 Vulkan 后端把模型分布到两块 GPU 上(--device Vulkan0,Vulkan1 --split-mode layer),运行如 granite-4.0-h-tiny Q5_K_M、gemma-4-26B-A4B Q6_K_XL、Qwen3-Coder-Next Q5_K_XL 等模型时,发现 token 生成速度从旧版本开始明显下降。单 GPU 场景和 prompt processing(提示处理)基本不受影响。回退 #29741(e0bcaccbe)后速度恢复原状,说明性能回退是在该提交之后引入的。
报错原文
Misc. bug: Vulkan: generation 2-4x slower with two GPUs since #29741 (GCN 1.0 / Tahiti, no ReBAR)
First Bad Commit
e0bcaccbe
vulkan: allow multiple devices to access gpu-visible host memory (#29741)
Issue 中没有传统意义上的崩溃堆栈或报错信息,这里的“报错”表现为性能回退:双 GPU 下 generation 速度从约 24.70 tok/s 降到 10.31 tok/s(granite),gemma 从 8.18 tok/s 降到 1.94 tok/s,Qwen3-Coder-Next 从 7.44 tok/s 降到 3.56 tok/s。设置 GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 并没有改善。
原因分析
可能原因是:#29741 允许每个设备直接访问其他设备的 GPU 可见主机内存(或共享主机缓冲区)。在两块老 GPU(GCN 1.0 / Tahiti)且没有 Resizable BAR 的机器上,这种跨 PCIe 的直接访问可能远慢于先把数据复制到本地 VRAM。Issue 报告者推测,旧版本更倾向于一次复制,而新版本每个 token 都可能发生跨设备直接读取,导致 generation 阶段被拖慢。
Issue 评论指出,该问题可能与 #30552、#27097 是同一类问题,并指向 PR #30468 作为修复。
环境排查
- 确认 llama.cpp 版本或 commit:Issue 中为 v0.7.0(
620d2225c),首个坏提交是e0bcaccbe(#29741)。 - 确认 Vulkan 后端已启用:构建参数包含
-DGGML_VULKAN=ON。 - 确认 GPU 设备与拓扑:两块 AMD FirePro D700 6 GB(Tahiti,GCN 1.0),是否支持 ReBAR。Issue 环境为无 ReBAR,每卡 256 MB CPU 可见 VRAM。
- 确认驱动与 Vulkan 组件:Mesa / RADV 26.2.4,Vulkan loader 1.4.363。
- 确认运行参数:是否使用双 GPU 的
--split-mode layer,以及是否完全卸载到 GPU。单 GPU(--split-mode none)不受影响。 - 确认环境变量:
GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1在 Issue 中被测试,未解决问题。
解决步骤
- 先记录当前基线:用 Issue 中的复现命令跑一次短 prompt 补全,记录
timings.predicted_per_second。 - 确认当前版本是否包含 #29741(
e0bcaccbe),并确认慢速只出现在双 GPU +--split-mode layer的 generation 阶段。如果单 GPU 正常,则更符合本 Issue 的现象。 - 升级或切换到一个包含 PR #30468 的 llama.cpp 版本(可优先尝试)。Issue 报告者确认 #30468 解决了该问题。
- 如果暂时无法升级,可回退 #29741(仅回退
e0bcaccbe)作为临时规避;Issue 报告者在 v0.7.0 上回退该提交后速度恢复到 24.68 tok/s。
验证方法
用同样的模型、同样的 --device Vulkan0,Vulkan1 --split-mode layer 参数,在修复版本或回退版本上重新跑一次 /completion 请求(n_predict=100),对比 timings.predicted_per_second。Issue 中修复后的预期表现是恢复到旧版本水平:granite 约 24.7 tok/s,gemma 约 8.18 tok/s,Qwen3-Coder-Next 约 7.4-7.5 tok/s。同时可确认 prompt processing 没有异常波动。
参考来源
相关 Issue 与 PR:#30552、#27097、#30468。
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。


![[Bug]: Scale-out token path breaks stop strings: stop text leaks into derendered output (include_stop_str_in_output ignored) and --tokens-on](https://www.chat-gpts.plus/wp-content/uploads/2026/10/57052-93eb6054-768x403.jpg)